“为什么上周没发布？” 作为管理人员，很容易将延迟发布的责任归咎于开发团队成员。但是你是否有认真想过，这些“慢悠悠”的程序员是否真的是不能按时发布的真正原因？
我们采集了大量关于程序员开发周期的数据，主要记录他们需要多久才能完成不同类型（Stories、Tests、Bugs）和不同大小（S、M、L、XL）的任务。 看看我们的发现首先：程序员的工作效率是非常平均的。这些数据显示，我们所有试验者的周期都非常的相似：75％的开发人员大多会在175小时之内完成任务。 第二：不过如果在开发过程中又加进来另外一个任务，事情就有变化了。因为此时的利益相关者会先停下来考虑哪个优先。我们在看板中称之为反应时间。这时很多的时间被浪费在这个阶段上： 第三： 团队从“写软件”过渡到“测试，并准备发布”也需要一定的转变时间。 什么，你觉得自己的团队总是发布得不够快？那么你真的错怪开发人员了！ 到底是什么延迟了开发进度？对啊，既然不是开发人员的错，又是什么延迟了我们的开发进程呢？ 含糊其辞的需求需求的编写非常重要。试问，如果程序员不理解功能的要求又怎么能正确地开发出相应的功能呢？
很多时候，客户自己都没有想清楚需要什么样的功能。所以开发人员不但需要理解用户的需要，还得领会用户没有说出口的潜台词。 如Sprintly网站采用填写的方式以了解用户的想法：
这种形式虽然有助于指出某个特定功能的特定方向，但是其给出的范围却是很小的。 不断变化的需求工作早就已经开展了，需求却还是不断地变来变去，开发人员常常抱怨自己要累觉不爱了！ 一位《Hacker News》的用户，对此有一个很恰当其分的比喻：
来一道雷劈死他们吧！ 其中一个可以避免需求中途更改的方法是在开发工作开展之前，先构建交互式的实物模型：
敏捷的工作方式并不意味着我们可以随时改变需求。在理想情况下，我们在中途学到的知识都应该包括并考虑进将来的迭代中。 另一种阻止需求变化（和范围蠕变）的方式是预测进程。Sprintly还有一个功能就是允许我们在完工之前估算出所需要的开发时间： 如果有新加任务，这一功能也会让我们知道需要多多少时间才能完成开发工作。 开发任务转接最后一个拦路虎大概就是开发任务转接了。这有下面几种形式： 1.开发人员任务A做到一半，突然要求他去做任务B。 2.开发人员任务A做到一半，突然要求他也去做任务B。 例如，我们有一个很棒的首席开发人员，能力很强，做过大量的代码审查，参加过很多会议，遇到过种种紧急情况。 先看看我们团队的开发时间周期： 在这种情况下，我们发现不同的首席开发人员其完成任务时间也不尽相同。 特别是，如果这时候你，作为一名管理人员，中途还要让开发人员去接手新的任务，问题就会愈发严重。变换重点就是在浪费团队资源。 关于开发任务转接，Joel Spolsky着实讲到了点子上：
承担责任作为管理者，提供一个助力程序员成功的环境是我们的工作。在将延迟发布的矛头指向开发人员、责备他们的失职之前，我们应该先看看自己有没有做到位。 下面这些步骤能确保你不是在拖团队的后腿： 1.让你的团队明白这一点：你们这是在努力让用户的生活变得更加美好。关键是要清楚用户的真正需要。得到大家的认同和支持很重要。开发人员对软件功能的**才是提升开发速度的最大动力。 2.为你创建的每个任务制作一个任务模块或模板。每个开发人员都有对细分的任务说“No”的权力，直至出来一个可行的详细说明。 3.不可随意打断开发人员，减少任务切换的成本。在你向他们发送电子邮件或者下达命令之前，先评估一下对生产力产生的负面影响。 总而言之，千万不要随意责怪开发人员“太慢”，因为很有可能是你自己工作流程的问题导致了他们速度的减慢。 原文： https://sprint.ly/blog/your-developers-arent-slow/
本文转载自：微信公众账号 - Linux中国，版权归原作者所有！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
