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

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

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

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

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

第二：不過如果在開發(fā)過程中又加進來另外一個任務(wù)，事情就有變化了。因為此時的利益相關(guān)者會先停下來考慮哪個優(yōu)先。我們在看板中稱之為反應(yīng)時間。這時很多的時間被浪費在這個階段上：

第三： 團隊從“寫軟件”過渡到“測試，并準備發(fā)布”也需要一定的轉(zhuǎn)變時間。

什么，你覺得自己的團隊總是發(fā)布得不夠快？那么你真的錯怪開發(fā)人員了！

到底是什么延遲了開發(fā)進度？

對啊，既然不是開發(fā)人員的錯，又是什么延遲了我們的開發(fā)進程呢？

含糊其辭的需求

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

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

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

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

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

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

不斷變化的需求

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

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

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

他們突然來一句：“這個墻壁的位置要改一下。”

來一道雷劈死他們吧！

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

“如果我們的模型能做到符合客戶的真正想法，那毋庸置疑我們的開發(fā)速度必定能加快不少。有時候只是因為我們自己不夠努力理解用戶所求或者沒有充分交互，從而導(dǎo)致后面我們最終不得不在實施的過程中重新思考，然后再重建。”——Tobin Harris，Pocketworks總監(jiān)。

敏捷的工作方式并不意味著我們可以隨時改變需求。在理想情況下，我們在中途學(xué)到的知識都應(yīng)該包括并考慮進將來的迭代中。

另一種阻止需求變化（和范圍蠕變）的方式是預(yù)測進程。Sprintly還有一個功能就是允許我們在完工之前估算出所需要的開發(fā)時間：

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

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

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

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

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

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

先看看我們團隊的開發(fā)時間周期：

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

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

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

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

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

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

下面這些步驟能確保你不是在拖團隊的后腿：

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

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

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

總而言之，千萬不要隨意責(zé)怪開發(fā)人員“太慢”，因為很有可能是你自己工作流程的問題導(dǎo)致了他們速度的減慢。

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

英文原文：Your developers aren’t slow

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