“为什么你上周不发布？”作为经理，很容易将延迟发布归咎于开发团队成员。但是你有没有真正想过，这些“慢”的程序员是否真的是不按时发布的真正原因？我们收集了很多关于程序员开发周期的数据，主要记录他们完成不同类型（Stories、Tests、Bugs）和不同规模（S、M、L、XL）的任务需要多长时间。首先看看我们的发现：程序员的生产力非常平均。这些数据表明，我们所有实验者的周期时间非常相似：75%的开发人员大多会在175小时内完成任务。第二：但是如果在开发过程中再增加一个任务，事情就会发生变化。因为在这一点上，利益相关者将首先停下来考虑哪个优先。我们在看板中称之为反应时间。这时，很多时间浪费在了这个阶段：第三：团队从“写软件”到“测试准备发布”的过渡，也需要一定的过渡时间。什么，你觉得你的团队总是发布不够快？那你怪开发商就真的不对了！到底是什么拖延了开发进度？是啊，既然不是开发者的错，那又是什么耽误了我们的开发进程呢？VagueRequirements需求的写法很重要。试问，如果程序员不理解功能的需求，如何正确开发出相应的功能呢？“事实证明，很多时候，需求分析人员都没有考虑周全，等我们开始设计开发的时候，才发现漏洞真的很多。”-渴望驼鹿。在很多情况下，客户自己并没有弄清楚他们需要什么样的功能。因此，开发者不仅要了解用户的需求，还要了解用户没有说出口的潜台词。例如，Sprintly网站使用填空的方式来了解用户的想法：“当你打开Sprintly时，你面临填空：作为一个___，我想要___，所以___。事实是，当用户填上这些空白，就没有你无法表达出你想要的功能特性。”-DarrenRogan.虽然这种形式有助于将特定方向指向特定功能，但它提供的范围非常小。变更需求工作已经开展，但需求仍在变更。开发者经常抱怨累，不喜欢！《Hacker News》的一位用户对此有一个非常贴切的比喻：我们：“好不容易把墙打完了，上面还装了屋顶，真是不容易啊！”他们忽然说道：“这堵墙的位置需要改变了。”让一道雷电劈死他们！避免中途更改需求的方法之一是在开发工作开始之前构建交互式物理模型：“如果我们的模型能够匹配客户的真实想法，毫无疑问，我们的开发速度会快得多。.有时只是我们自己没有足够努力去理解用户的要求或者没有足够的交互，我们最终不得不重新思考和重建作为实现的一部分。”–TobinHarris，Pocketworks总监。敏捷的工作方式并不意味着我们可以随时更改需求。理想情况下，我们在此过程中学到的所有东西都应该包括在内，并考虑到未来的迭代中。另一种防止需求变化的方法（和scopecreep）是为了预测进度。Sprintly还有一个功能可以让我们在完成前预估需要的开发时间：如果有新的任务加入，这个功能也会让我们知道完成开发需要多少时间开发任务交接的最后一道坎大概就是开发任务交接了，这有以下几种形式：1、开发人员任务A进行到一半，突然被要求去做任务B。2、开发人员是任务A进行到一半，突然让他也做任务B。比如我们有一个很棒的leaderdeveloper，他非常有能力，做了很多代码审查，参加了很多会议，并且一直在各种各样的紧急情况。让我们从查看我们团队的开发时间周期开始：在这种情况下，我们发现不同的首席开发人员花费不同的时间来完成任务。尤其是，如果这个时候，作为管理者的你，不得不让开发人员在中间接手新的任务，问题就更加严重了。改变焦点是对团队资源的浪费。关于开发任务切换，JoelSpolsky说得很中肯：我们在这个问题上的教训是，绝不能要求程序员同时做两件事。确保他们首先知道该做什么。其次，一个好的管理者应该能够为他的团队扫清障碍，使他们能够专注于手头的工作和任务。如果遇到紧急情况，首先要考虑自己是否能够应付。如果做不到，你可以打断正在努力解决问题的程序员。承担责任作为管理者，我们的工作是提供一个使程序员能够成功的环境。在指责开发人员延迟发布并指责他们的疏忽之前，我们应该看看我们是否做得足够。以下是确保您不会阻碍您的团队的一些步骤：1.让您的团队了解您正在努力让用户的生活更美好。关键是了解用户的真实需求。得到大家的认可和支持很重要。开发人员对软件功能的热情是开发速度的最大驱动力。2.为您创建的每个任务制作一个任务模块或模板。在可行的详细描述出来之前，每个开发者都有权对细分任务说“不”。3、不要随意打断开发者，减少任务切换的成本。在您向他们发送电子邮件或下订单之前，评估对生产力的负面影响。总而言之，不要随意责怪开发人员“太慢”，因为很可能是您自己的工作流程拖慢了他们的速度。翻译链接：http://www.codeceo.com/article/your-programmer-are-not-slow.html英文原文：Yourdevelopersaren'tslow译者：码农-小风
