“為什么上周沒發布？”

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

我們采集了大量關于程序員開發周期的數據，主要記錄他們需要多久才能完成不同類型（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

翻譯作者：碼農網 – 小峰