“為什么上周沒(méi)發(fā)布？”

作為管理人員，很容易將延遲發(fā)布的責(zé)任歸咎于開(kāi)發(fā)團(tuán)隊(duì)成員。但是你是否有認(rèn)真想過(guò)，這些“慢悠悠”的程序員是否真的是不能按時(shí)發(fā)布的真正原因？

我們采集了大量關(guān)于程序員開(kāi)發(fā)周期的數(shù)據(jù)，主要記錄他們需要多久才能完成不同類(lèi)型（Stories、Tests、Bugs）和不同大?。⊿、M、L、XL）的任務(wù)。

看看我們的發(fā)現(xiàn)

首先：程序員的工作效率是非常平均的。這些數(shù)據(jù)顯示，我們所有試驗(yàn)者的周期都非常的相似：75％的開(kāi)發(fā)人員大多會(huì)在175小時(shí)之內(nèi)完成任務(wù)。

第二：不過(guò)如果在開(kāi)發(fā)過(guò)程中又加進(jìn)來(lái)另外一個(gè)任務(wù)，事情就有變化了。因?yàn)榇藭r(shí)的利益相關(guān)者會(huì)先停下來(lái)考慮哪個(gè)優(yōu)先。我們?cè)诳窗逯蟹Q之為反應(yīng)時(shí)間。這時(shí)很多的時(shí)間被浪費(fèi)在這個(gè)階段上：

第三： 團(tuán)隊(duì)從“寫(xiě)軟件”過(guò)渡到“測(cè)試，并準(zhǔn)備發(fā)布”也需要一定的轉(zhuǎn)變時(shí)間。

什么，你覺(jué)得自己的團(tuán)隊(duì)總是發(fā)布得不夠快？那么你真的錯(cuò)怪開(kāi)發(fā)人員了！

到底是什么延遲了開(kāi)發(fā)進(jìn)度？

對(duì)啊，既然不是開(kāi)發(fā)人員的錯(cuò)，又是什么延遲了我們的開(kāi)發(fā)進(jìn)程呢？

含糊其辭的需求

需求的編寫(xiě)非常重要。試問(wèn)，如果程序員不理解功能的要求又怎么能正確地開(kāi)發(fā)出相應(yīng)的功能呢？

“事實(shí)證明，很多時(shí)候，需求分析人員并沒(méi)有徹底得考慮清楚，只有當(dāng)我們開(kāi)始設(shè)計(jì)和開(kāi)發(fā)之時(shí)，才能發(fā)現(xiàn)真的有很多漏洞。” ——Eager Moose。

很多時(shí)候，客戶自己都沒(méi)有想清楚需要什么樣的功能。所以開(kāi)發(fā)人員不但需要理解用戶的需要，還得領(lǐng)會(huì)用戶沒(méi)有說(shuō)出口的潛臺(tái)詞。

如Sprintly網(wǎng)站采用填寫(xiě)的方式以了解用戶的想法：

“當(dāng)你打開(kāi)Sprintly，面對(duì)這樣的填空： As a ___, I want ___, so that ___。事實(shí)則是 當(dāng)用戶在填寫(xiě)這些空格的時(shí)候，根本就沒(méi)法表述自己想要的功能特征。”——Darren Rogan。

這種形式雖然有助于指出某個(gè)特定功能的特定方向，但是其給出的范圍卻是很小的。

不斷變化的需求

工作早就已經(jīng)開(kāi)展了，需求卻還是不斷地變來(lái)變?nèi)?，開(kāi)發(fā)人員常常抱怨自己要累覺(jué)不愛(ài)了！

一位《Hacker News》的用戶，對(duì)此有一個(gè)很恰當(dāng)其分的比喻：

我們：“終于砌好了墻壁，安裝好了上面的屋頂，真心不容易啊！”

他們突然來(lái)一句：“這個(gè)墻壁的位置要改一下。”

來(lái)一道雷劈死他們吧！

其中一個(gè)可以避免需求中途更改的方法是在開(kāi)發(fā)工作開(kāi)展之前，先構(gòu)建交互式的實(shí)物模型：

“如果我們的模型能做到符合客戶的真正想法，那毋庸置疑我們的開(kāi)發(fā)速度必定能加快不少。有時(shí)候只是因?yàn)槲覀冏约翰粔蚺斫庥脩羲蠡蛘邲](méi)有充分交互，從而導(dǎo)致后面我們最終不得不在實(shí)施的過(guò)程中重新思考，然后再重建。”——Tobin Harris，Pocketworks總監(jiān)。

敏捷的工作方式并不意味著我們可以隨時(shí)改變需求。在理想情況下，我們?cè)谥型緦W(xué)到的知識(shí)都應(yīng)該包括并考慮進(jìn)將來(lái)的迭代中。

另一種阻止需求變化（和范圍蠕變）的方式是預(yù)測(cè)進(jìn)程。Sprintly還有一個(gè)功能就是允許我們?cè)谕旯ぶ肮浪愠鏊枰拈_(kāi)發(fā)時(shí)間：

如果有新加任務(wù)，這一功能也會(huì)讓我們知道需要多多少時(shí)間才能完成開(kāi)發(fā)工作。

開(kāi)發(fā)任務(wù)轉(zhuǎn)接

最后一個(gè)攔路虎大概就是開(kāi)發(fā)任務(wù)轉(zhuǎn)接了。這有下面幾種形式：

1.開(kāi)發(fā)人員任務(wù)A做到一半，突然要求他去做任務(wù)B。

2.開(kāi)發(fā)人員任務(wù)A做到一半，突然要求他也去做任務(wù)B。

例如，我們有一個(gè)很棒的首席開(kāi)發(fā)人員，能力很強(qiáng)，做過(guò)大量的代碼審查，參加過(guò)很多會(huì)議，遇到過(guò)種種緊急情況。

先看看我們團(tuán)隊(duì)的開(kāi)發(fā)時(shí)間周期：

在這種情況下，我們發(fā)現(xiàn)不同的首席開(kāi)發(fā)人員其完成任務(wù)時(shí)間也不盡相同。

特別是，如果這時(shí)候你，作為一名管理人員，中途還要讓開(kāi)發(fā)人員去接手新的任務(wù)，問(wèn)題就會(huì)愈發(fā)嚴(yán)重。變換重點(diǎn)就是在浪費(fèi)團(tuán)隊(duì)資源。

關(guān)于開(kāi)發(fā)任務(wù)轉(zhuǎn)接，Joel Spolsky著實(shí)講到了點(diǎn)子上：

在這個(gè)問(wèn)題上我們得到的經(jīng)驗(yàn)教訓(xùn)是，絕對(duì)不能讓程序員同時(shí)做兩件事情。首先要確保他們知道要做的是什么。其次，好的管理人員，應(yīng)當(dāng)能為他的團(tuán)隊(duì)消除障礙，以便于他們能專心致志地完成手頭的工作和任務(wù)。如果出現(xiàn)緊急情況，要先想想自己能否處理，實(shí)在不行才能打斷正在埋頭刻苦攻關(guān)的程序員。

承擔(dān)責(zé)任

作為管理者，提供一個(gè)助力程序員成功的環(huán)境是我們的工作。在將延遲發(fā)布的矛頭指向開(kāi)發(fā)人員、責(zé)備他們的失職之前，我們應(yīng)該先看看自己有沒(méi)有做到位。

下面這些步驟能確保你不是在拖團(tuán)隊(duì)的后腿：

1.讓你的團(tuán)隊(duì)明白這一點(diǎn)：你們這是在努力讓用戶的生活變得更加美好。關(guān)鍵是要清楚用戶的真正需要。得到大家的認(rèn)同和支持很重要。開(kāi)發(fā)人員對(duì)軟件功能的激情才是提升開(kāi)發(fā)速度的最大動(dòng)力。

2.為你創(chuàng)建的每個(gè)任務(wù)制作一個(gè)任務(wù)模塊或模板。每個(gè)開(kāi)發(fā)人員都有對(duì)細(xì)分的任務(wù)說(shuō)“No”的權(quán)力，直至出來(lái)一個(gè)可行的詳細(xì)說(shuō)明。

3.不可隨意打斷開(kāi)發(fā)人員，減少任務(wù)切換的成本。在你向他們發(fā)送電子郵件或者下達(dá)命令之前，先評(píng)估一下對(duì)生產(chǎn)力產(chǎn)生的負(fù)面影響。

總而言之，千萬(wàn)不要隨意責(zé)怪開(kāi)發(fā)人員“太慢”，因?yàn)楹苡锌赡苁悄阕约汗ぷ髁鞒痰膯?wèn)題導(dǎo)致了他們速度的減慢。

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

英文原文：Your developers aren’t slow

翻譯作者：碼農(nóng)網(wǎng) – 小峰