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

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

“为什么上周没发布?”

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

我们采集了大量关于程序员开发周期的数据,主要记录他们需要多久才能完成不同类型(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

翻译作者:码农网 – 小峰

责任编辑:张伟 来源: 码农网
相关推荐

2011-04-26 10:00:23

C语言程序员

2019-11-18 10:16:37

工程师开发网络

2019-11-18 10:05:43

程序员技能开发者

2011-06-02 11:26:24

程序员

2015-01-04 14:18:21

程序员

2020-12-21 06:15:15

程序员互联网年龄

2012-09-10 09:16:54

2015-04-01 13:35:33

程序员

2015-12-09 09:17:11

情绪厌倦程序员

2015-12-07 11:44:31

程序员厌倦工作

2014-06-24 15:38:25

2012-01-11 09:12:25

程序员

2015-03-19 10:15:54

程序员价值程序员价值

2020-12-15 08:05:02

redis单线程多线程

2013-03-19 10:16:07

2011-11-02 09:57:28

程序员

2015-02-12 09:48:09

程序员

2009-05-21 15:58:12

程序员工作经验职场

2015-02-12 09:29:48

2023-07-17 10:28:00

C/C++编程接口
点赞
收藏

51CTO技术栈公众号