请不要再责怪你的程序员“太慢”

“为什么上周没发布？”

成都创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站建设、网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的万年网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

作为管理人员，很容易将延迟发布的责任归咎于开发团队成员。但是你是否有认真想过，这些“慢悠悠”的程序员是否真的是不能按时发布的真正原因？

我们采集了大量关于程序员开发周期的数据，主要记录他们需要多久才能完成不同类型（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.不可随意打断开发人员，减少任务切换的成本。在你向他们发送电子邮件或者下达命令之前，先评估一下对生产力产生的负面影响。

总而言之，千万不要随意责怪开发人员“太慢”，因为很有可能是你自己工作流程的问题导致了他们速度的减慢。

译文链接：http://www.codeceo.com/article/your-programmer-are-not-slow.html

英文原文：Your developers aren’t slow

翻译作者：码农网 – 小峰

当前题目：请不要再责怪你的程序员“太慢”
文章出自：http://www.gawzjz.com/qtweb2/news45/10645.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联