“为什么上周没发布？”
作为管理人员，很容易将延迟发布的责任归咎于开发团队成员。但是你是否有认真想过，这些“慢悠悠”的程序员是否真的是不能按时发布的真正原因？
我们采集了大量关于程序员开发周期的数据，主要记录他们需要多久才能完成不同类型（Stories、Tests、Bugs）和不同大小（S、M、L、XL）的任务。
看看我们的发现
首先：程序员的工作效率是非常平均的。这些数据显示，我们所有试验者的周期都非常的相似：75％的开发人员大多会在175小时之内完成任务。
第二：不过要是在开发过程中又加进来另外一个任务，事情就有变化了。因为此时的利益相关者会先停下来考虑哪个优先。我们在看板中称之为反应时间。这时很多的时间被浪费在这个阶段上：
第三： 团队从“写软件”过渡到“测试，并准备发布”也需要一定的转变时间。
什么，你觉得自己的团队总是发布得不够快？那么你真的错怪开发人员了！
到底是什么延迟了开发进度？
对啊，既然不是开发人员的错，又是什么延迟了我们的开发进程呢？
含糊其辞的需求
需求的编写非常重要。试问，要是程序员不理解功能的要求又怎么能正确地开发出相应的功能呢？
“事实证明，很多时候，需求分析人员并没有彻底得考虑清楚，只有当我们开始设计和开发之时，才能发现真的有很多漏洞。” ——Eager Moose。
很多时候，客户自己都没有想清楚需要什么样的功能。所以开发人员不但需要理解用户的需要，还得领会用户没有说出口的潜台词。
如Sprintly网站采用填写的方式以了解用户的想法：
“当你打开Sprintly，面对这样的填空： As a ___, I want ___, so that ___。事实则是 当用户在填写这些空格的时候，根本就没法表述自己想要的功能特征。”——Darren Rogan。
这种形式虽然有助于指出某个特定功能的特定方向，但是其给出的范围却是很小的。
不断变化的需求
工作早就已经开展了，需求却还是不断地变来变去，开发人员常常抱怨自己要累觉不爱了！
一位《Hacker News》的用户，对此有一个很恰当其分的比喻：
我们：“终于砌好了墙壁，安装好了上面的屋顶，真心不容易啊！”
他们突然来一句：“这个墙壁的位置要改一下。”
来一道雷劈死他们吧！
其中一个可以避免需求中途更改的方法是在开发工作开展之前，先构建交互式的实物模型：
“要是我们的模型能做到符合客户的真正想法，那毋庸置疑我们的开发速度必定能加快不少。有时候只是因为我们自己不够努力理解用户所求或者没有充分交互，从而导致后面我们最终不得不在实施的过程中重新思考，然后再重建。”——Tobin Harris，Pocketworks总监。
敏捷的工作方式并不意味着我们可以随时改变需求。在理想情况下，我们在中途学到的知识都应该包括并考虑进将来的迭代中。
另一种阻止需求变化（和范围蠕变）的方式是预测进程。Sprintly还有一个功能就是允许我们在完工之前估算出所需要的开发时间：
要是有新加任务，这一功能也会让我们知道需要多多少时间才能完成开发工作。
开发任务转接
最后一个拦路虎大概就是开发任务转接了。这有下面几种形式：
1.开发人员任务A做到一半，突然要求他去做任务B。
2.开发人员任务A做到一半，突然要求他也去做任务B。
例如，我们有一个很棒的首席开发人员，能力很强，做过大量的代码审查，参加过很多会议，遇到过种种紧急情况。
先看看我们团队的开发时间周期：
在这种情况下，我们发现不同的首席开发人员其完成任务时间也不尽相同。
特别是，要是这时候你，作为一名管理人员，中途还要让开发人员去接手新的任务，问题就会愈发严重。变换重点就是在浪费团队资源。
关于开发任务转接，Joel Spolsky着实讲到了点子上：
在这个问题上我们得到的经验教训是，绝对不能让程序员同时做两件事情。首先要确保他们知道要做的是什么。其次，好的管理人员，应当能为他的团队消除障碍，以便于他们能专心致志地完成手头的工作和任务。要是出现紧急情况，要先想想自己能否处理，实在不行才能打断正在埋头刻苦攻关的程序员。
承担责任
作为管理者，提供一个助力程序员成功的环境是我们的工作。在将延迟发布的矛头指向开发人员、责备他们的失职之前，我们应该先看看自己有没有做到位。
下面这些步骤能确保你不是在拖团队的后腿：
1.让你的团队明白这一点：你们这是在努力让用户的生活变得更加美好。关键是要清楚用户的真正需要。得到大家的认同和支持很重要。开发人员对软件功能的激情才是提升开发速度的最大动力。
2.为你创建的每个任务制作一个任务模块或模板。每个开发人员都有对细分的任务说“No”的权力，直至出来一个可行的详细说明。
3.不可随意打断开发人员，减少任务切换的成本。在你向他们发送电子邮件或者下达命令之前，先评估一下对生产力产生的负面影响。
总而言之，千万不要随意责怪开发人员“太慢”，因为很有可能是你自己工作流程的问题导致了他们速度的减慢。