zoukankan      html  css  js  c++  java
  • 请不要再责怪你的程序员“太慢”

    “为什么上周没发布?”

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

    我们采集了大量关于程序员开发周期的数据,主要记录他们需要多久才能完成不同类型(Stories、Tests、Bugs)和不同大小(S、M、L、XL)的任务。

    看看我们的发现

    首先:程序员的工作效率是非常平均的。这些数据显示,我们所有试验者的周期都非常的相似:75%的开发人员大多会在175小时之内完成任务。

    第二:不过如果在开发过程中又加进来另外一个任务,事情就有变化了。因为此时的利益相关者会先停下来考虑哪个优先。我们在看板中称之为反应时间。这时很多的时间被浪费在这个阶段上:

    038.png

    第三: 团队从“写软件”过渡到“测试,并准备发布”也需要一定的转变时间。

    什么,你觉得自己的团队总是发布得不够快?那么你真的错怪开发人员了!

    到底是什么延迟了开发进度?

    对啊,既然不是开发人员的错,又是什么延迟了我们的开发进程呢?

    含糊其辞的需求

    需求的编写非常重要。试问,如果程序员不理解功能的要求又怎么能正确地开发出相应的功能呢?

    “事实证明,很多时候,需求分析人员并没有彻底得考虑清楚,只有当我们开始设计和开发之时,才能发现真的有很多漏洞。” ——Eager Moose。

    很多时候,客户自己都没有想清楚需要什么样的功能。所以开发人员不但需要理解用户的需要,还得领会用户没有说出口的潜台词。

    如Sprintly网站采用填写的方式以了解用户的想法:

    040.jpg

    “当你打开Sprintly,面对这样的填空: As a ___, I want ___, so that ___。事实则是 当用户在填写这些空格的时候,根本就没法表述自己想要的功能特征。”——Darren Rogan。

    这种形式虽然有助于指出某个特定功能的特定方向,但是其给出的范围却是很小的。

    不断变化的需求

    工作早就已经开展了,需求却还是不断地变来变去,开发人员常常抱怨自己要累觉不爱了!

    一位《Hacker News》的用户,对此有一个很恰当其分的比喻:

    我们:“终于砌好了墙壁,安装好了上面的屋顶,真心不容易啊!”

    他们突然来一句:“这个墙壁的位置要改一下。”

    来一道雷劈死他们吧!

    其中一个可以避免需求中途更改的方法是在开发工作开展之前,先构建交互式的实物模型:

    “如果我们的模型能做到符合客户的真正想法,那毋庸置疑我们的开发速度必定能加快不少。有时候只是因为我们自己不够努力理解用户所求或者没有充分交互,从而导致后面我们最终不得不在实施的过程中重新思考,然后再重建。”——Tobin Harris,Pocketworks总监。

    敏捷的工作方式并不意味着我们可以随时改变需求。在理想情况下,我们在中途学到的知识都应该包括并考虑进将来的迭代中。

    另一种阻止需求变化(和范围蠕变)的方式是预测进程。Sprintly还有一个功能就是允许我们在完工之前估算出所需要的开发时间:

    041.png

    如果有新加任务,这一功能也会让我们知道需要多多少时间才能完成开发工作。

    开发任务转接

    最后一个拦路虎大概就是开发任务转接了。这有下面几种形式:

    1.开发人员任务A做到一半,突然要求他去做任务B。

    2.开发人员任务A做到一半,突然要求他也去做任务B。

    例如,我们有一个很棒的首席开发人员,能力很强,做过大量的代码审查,参加过很多会议,遇到过种种紧急情况。

    先看看我们团队的开发时间周期:

    042.png

    在这种情况下,我们发现不同的首席开发人员其完成任务时间也不尽相同。

    特别是,如果这时候你,作为一名管理人员,中途还要让开发人员去接手新的任务,问题就会愈发严重。变换重点就是在浪费团队资源。

    关于开发任务转接,Joel Spolsky着实讲到了点子上:

    在这个问题上我们得到的经验教训是,绝对不能让程序员同时做两件事情。首先要确保他们知道要做的是什么。其次,好的管理人员,应当能为他的团队消除障碍,以便于他们能专心致志地完成手头的工作和任务。如果出现紧急情况,要先想想自己能否处理,实在不行才能打断正在埋头刻苦攻关的程序员。

    承担责任

    作为管理者,提供一个助力程序员成功的环境是我们的工作。在将延迟发布的矛头指向开发人员、责备他们的失职之前,我们应该先看看自己有没有做到位。

    下面这些步骤能确保你不是在拖团队的后腿:

    1.让你的团队明白这一点:你们这是在努力让用户的生活变得更加美好。关键是要清楚用户的真正需要。得到大家的认同和支持很重要。开发人员对软件功能的激情才是提升开发速度的最大动力。

    2.为你创建的每个任务制作一个任务模块或模板。每个开发人员都有对细分的任务说“No”的权力,直至出来一个可行的详细说明。

    3.不可随意打断开发人员,减少任务切换的成本。在你向他们发送电子邮件或者下达命令之前,先评估一下对生产力产生的负面影响。

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

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

    英文原文:Your developers aren’t slow

    翻译作者:码农网(小峰)

  • 相关阅读:
    Poj 2017 Speed Limit(水题)
    Poj 1316 Self Numbers(水题)
    Poj 1017 Packets(贪心策略)
    Poj 1017 Packets(贪心策略)
    Poj 2662,2909 Goldbach's Conjecture (素数判定)
    Poj 2662,2909 Goldbach's Conjecture (素数判定)
    poj 2388 Who's in the Middle(快速排序求中位数)
    poj 2388 Who's in the Middle(快速排序求中位数)
    poj 2000 Gold Coins(水题)
    poj 2000 Gold Coins(水题)
  • 原文地址:https://www.cnblogs.com/dzlishen/p/4204577.html
Copyright © 2011-2022 走看看