「為什麼上週沒發布？」
作為管理人員，很容易將延遲發布的責任歸咎於開發團隊成員。但是你是否有認真想過，這些「慢悠悠」的程式設計師是否真的是不能按時發布的真正原因？
我們採集了大量關於程式設計師開發周期的資料，主要記錄他們需要多久才能完成不同型別（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總監。
敏捷的工作方式並不意味著我們可以隨時改變需求。在理想情況下，我們在中途學到的知識都應該包括並考慮進將來的迭代中。
如果有新加任務，這一功能也會讓我們知道需要多多少時間才能完成開發工作。
開發任務轉接
最後乙個攔路虎大概就是開發任務轉接了。這有下面幾種形式：
1.開發人員任務a做到一半，突然要求他去做任務b。
2.開發人員任務a做到一半，突然要求他也去做任務b。
例如，我們有乙個很棒的首席開發人員，能力很強，做過大量的**審查，參加過很多會議，遇到過種種緊急情況。
先看看我們團隊的開發時間週期：
在這種情況下，我們發現不同的首席開發人員其完成任務時間也不盡相同。
特別是，如果這時候你，作為一名管理人員，中途還要讓開發人員去接手新的任務，問題就會愈發嚴重。變換重點就是在浪費團隊資源。
關於開發任務轉接，joel spolsky著實講到了點子上：
在這個問題上我們得到的經驗教訓是，絕對不能讓程式設計師同時做兩件事情。首先要確保他們知道要做的是什麼。其次，好的管理人員，應當能為他的團隊消除障礙，以便於他們能專心致志地完成手頭的工作和任務。如果出現緊急情況，要先想想自己能否處理，實在不行才能打斷正在埋頭刻苦攻關的程式設計師。
承擔責任
作為管理者，提供乙個助力程式設計師成功的環境是我們的工作。在將延遲發布的矛頭指向開發人員、責備他們的失職之前，我們應該先看看自己有沒有做到位。
下面這些步驟能確保你不是在拖團隊的後腿：
1.讓你的團隊明白這一點：你們這是在努力讓使用者的生活變得更加美好。關鍵是要清楚使用者的真正需要。得到大家的認同和支援很重要。開發人員對軟體功能的激情才是提公升開發速度的最大動力。
2.為你建立的每個任務製作乙個任務模組或模板。每個開發人員都有對細分的任務說「no」的權力，直至出來乙個可行的詳細說明。
3.不可隨意打斷開發人員，減少任務切換的成本。在你向他們傳送電子郵件或者下達命令之前，先評估一下對生產力產生的負面影響。
總而言之，千萬不要隨意責怪開發人員「太慢」，因為很有可能是你自己工作流程的問題導致了他們速度的減慢。
英文原文：your developers aren』t slow
請重視你的程式設計師
程式設計對很多人來說有點神秘。這就造成了在公司內部，人們對程式設計的事情產生了很多懷疑和疑惑。通常，當你不了解乙個東西是怎樣做成的時，你只能說 可能是這樣吧。如果你從沒見過工地，你也許會認為幾個星期就能建出一棟大樓。事實上，在這樣的時間內是可以完成這棟建築的，只是能不能用就不知道了。如果你看過房子如...
程式設計師，請不要做浮躁的人
程式設計師，請不要做浮躁的人 請不要做浮躁的人 2.初學者請不要看太多太多的書那會誤人子弟的，先找本系統的學，很多人用了很久都是只對部分功能熟悉而已，不系統還是不夠的。3.看幫助,不要因為很難而自己是初學者所以就不看 幫助永遠是最好的參考手冊，雖然幫助的文字有時候很難看懂，總覺得不夠直觀。4.不要被...
程式設計師請不要忽視除錯技術
程式設計師請不要忽視除錯技術 想寫這篇文章已經很久了，但是一直不知道如何開始，因為除錯技術這個東西本身不像程式語言，c c 這種簡單的東西，大家想做些什麼，查查類庫，查查msdn，寫出一些功能，皆大歡喜。除錯技術本身就很枯燥，如果沒有一定定力的兄弟，看看可能就覺得犯睏，沒勁，沒成就感。但是想想程式設...