請不要再責怪你的程式設計師“太慢”

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

“為什麼上週沒釋出？”

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

我們採集了大量關於程式設計師開發週期的資料，主要記錄他們需要多久才能完成不同型別（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.不可隨意打斷開發人員，減少任務切換的成本。在你向他們傳送電子郵件或者下達命令之前，先評估一下對生產力產生的負面影響。

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