如何做effort的estimate?本文給出了敏捷開發模式中的乙個方法。
---專案經理被問到最多的問題就是，「這個專案什麼時候才能完成？」
被問的時候，可能專案才定下來，僅僅知道大概的功能模組，非功能性需求還模糊不清，甚至團隊成員都沒到位。但是上級、銷售、客戶急切地要知道，這個專案什麼時候才能完成？
被問的時候，也可能專案已臨近結束，或者說臨近當初計畫的交付日期。然而待完成的功能還有一堆，測試出來的bug有一大堆，客戶又提出了新的需求，團隊正有人要離職 …。但是上級、銷售、客戶非常急切地要知道，這個專案到底什麼時候才能完成？
這還不算糟糕。更頭疼的問題是：「再有三周，專案應該完成了吧？」
因為後者根本不是問題，而是命令。專案經理必須要能夠合理解釋為什麼三周不能夠完成專案；或者說明在三周內，能夠完成什麼。
我們都用過ms project， 但是那上面的漂亮**對這樣的困境毫無幫助。相反，正是project 中的甘特圖和日程表，埋下了陷阱。因為，在project 中無法預估需要多少工作日才能完成模糊不清的需求，也無法體現實際情況發生變化後對進度的影響。
當我們討論進度的時候，其實包含了兩個未知的變數。第一是完成需求所要的工作量，包括需求定義、開發內容邊界；第二是團隊的工作能力，包括成員的行業知識專業技能，成員之間、成員和外部的溝通能力，等等。
關鍵就在於，這兩項都是變數。如果任務是搬一千塊磚頭，每分鐘每人能搬10塊，那麼結果是顯而易見的。
在敏捷開發中，採用相對估算和迭代求精的方法來處理專案進度的問題。
首先是工作量。用估算**行數或者介面元素的方式，就像論斤賣書一樣，只適用於粗製濫造的軟體生產過程。使用者需要的並不是**或者按鈕，而是可靠易用的功能。
在敏捷方式中，先由使用者和設計人員粗略估計各個功能模組的相對規模和難度，給出一定的分值。分值不代表具體人月，起相對比較的作用。例如有查詢、顯示、修改三個模組，如果實現顯示模組的工作量是10分，那麼查詢模組可能是15分，而修改為20分。
下一步，選擇乙個工作量估分最低的模組，例如這裡是顯示模組，然後進一步考量其工作量。例如要準備資料庫、設計介面、執行查詢，顯示內容等等。假設這輪估算得出此模組需要10人天，從而得出單位分值對應的人天為1；那麼，整個專案就需要45人天。
這個估算建立在對專案的初步了解上，主要依賴專案經理的經驗。有偏差？沒關係。接下來通過迭代來求精。先來實現顯示模組，如果事實上花費了12人天，那麼根據比例關係，剩餘內容的估算大約就是42人天。
當然，比例關係也不是一成不變的。隨著模組的逐個完成，專案經理對專案的認識也在加深，他可以再調整剩餘模組的相對分值。
在實際操作中，專案經理首先按照優先順序排列功能模組。然後把高優先順序的模組盡可能地細分，再選擇分值最小的模組開始開發。統計總工作量時，按比例累加其他模組的工作量，並加一定的調整係數，因為模組的複雜度不是線性增長的。每次迭代開發完成後，逐步降低調整係數。通常4~5次迭代後，可以將調整係數歸零。
在上面的例子中，第一次估算的初步結果是45人天，因為完全是憑經驗，因此要給較大的調整係數，比如說0.4，因此給出的估算工作量區間為[45*0.6,45*1.4],即27到63人天之間。為保險起見，專案經理上報的工作量為70人天。
第二次估算，剩餘內容的初步估算為42，調整係數下降為0.3，因此給出估算區間為30到50人天之間。依此類推，通過不斷迭代，對剩餘工作量的估算將越來越精確。
這樣估算的好處在**？
首先，工作量變數的很大一部分因素，存在於非功能需求，例如介面的美觀程度。而同 一項目的不同模組之間，非功能需求往往是一致的，相對估算法過濾了這一層複雜度。團隊能力這一變數因素也是如此。當然，隨著專案的進展，成員的開發能力應 該有一定的上公升，但隨著加班出差等因素，投入程度也可能下降，因而會相互抵消。總之在週期6個月以內的專案中，很少出現團隊工作能力戲劇性變化的情形。因此相對估算也過濾了這個複雜度。
其次，迭代求精的方式讓專案經理對估算時間更有把握。最初出現偏差是必然的，但只要團隊穩定，沒有大的需求變動，估算範圍將迅速收縮。這比一次性報數更準確。
它的額外好處是，敏捷開發是遵循優先順序的，即使對剩餘時間（即低優先順序模組的開發時間）的估算不十分準確，影響也不是非常大。
對比一下甘特圖方式，在開發初期就要把各個模組的開發時間估算出來以統計總量，這就是瀑布開發的模式。
進度問題的另一方面，是專案經理如何了解團隊以及每個開發人員的開發速度。當任務分配之後，專案經理如何做到心中有數，估算任務實際完成時間。
敏捷開發過程中，由開發人員自己來估算完成該任務所需要的時間。當然，每個人的能力不同；每個人的心態也不同，有的人保守，有的人樂觀。沒關係，還是靠迭代來逐步求精。
在每天的例會上，開發人員被要求對當前任務的剩餘開發時間做重估。不同於project 統計每人每天在任務中花費了多少時間，敏捷方式只關心這項任務還需要多少時間去完成，直到歸零，然後再來統計實際的工作時間。
為什麼？因為統計開發過程中的花費時間是毫無意義的。這和搬磚頭不同，也許昨天用了8個小時沒有一點進展，今天一旦想通了就事半功倍。我們真正關心的，就是到底還需要多少時間來完成任務，而不是已經花費掉不可恢復的時間成本。
在每天例會中，專案經理需要注意時間曲線保持水平的成員，他是不是遇到瓶頸了，是 否需求幫助？也要留意時間曲線下降幅度過大的成員，他發現了什麼好的辦法，有沒有低估需求？這樣，專案經理會更面向結果，只要按計畫保證質量完成任務就 行，成員到底花了多少時間是個人的事。傳統做法記錄每個人每天的工作內容，第一是因繁瑣而失真。其次，一旦上級發現某人工作時間不夠（即便他完成了任 務），忍不住會派新任務，從而造成越幹活越多，反過來打擊程式設計師的積極性。
敏捷估算的關鍵之處，是把成員能力這個變數的估算，交給最合適的人去做，即程式設計師本人。然後通過比較歷次迭代時的預估和實際時間，給出校正係數，以避免程式設計師過於保守或過於樂觀。這肯定不是絕對準確的，但效果往往比專案經理自己拍腦袋估算，然後強行指定deadline 要好得多。
在敏捷開發中，做計畫比計畫本身更重要。專案經理需要時刻向前考慮，考慮各種動態因素，而不是死報著計畫本身。在進度估算的時候，專案經理應該在不同階段，根據實際情況，給出合乎情理的回答。
對敏捷開發的誤解
對敏捷開發的誤解 誤解一 敏捷對人的要求很高 很多人在嘗試實施敏捷時說 敏捷對人的要求太高了，我們沒有這樣的條件，我們沒有這樣的人，因此我們沒法敏捷。可是，敏捷對人的要求真的那麼高麼？軟體歸根到底還是一種創造性活動，開發人員的技術水平和個人能力對軟體的質量還是起著決定性的作用，各種過程與方法只是幫助...
敏捷開發 敏捷開發中的質量
有小夥伴就問，我們都敏捷了，我們是在效率和質量中找平衡，說敏捷開發中的質量是不容易控制的，要回答這個問題，我設計了乙個faq，內容如下 敏捷開發是什麼？敏捷開發是以需求為中心，以交付價值為目的，持續增量交付的一種軟體開發方法，至於什麼是敏捷，就去問問度娘吧。對於敏捷團隊來說，是乙個自組織的，有集體目...
敏捷開發筆記 評估進度
度量真實的進度 待辦事項 估計任務真正花費的時間，可能前幾次估計的不准，比如第一次估計是2天完成，而實際上是6甜完成，那麼下次估計的時候，就乘上這個3這個係數。前幾次這個係數會波動，越到後面，這個係數會穩定，最終趨近於1 不要用不恰當的進度來欺騙自己和團隊 sprint，評估任務和資源，如果任務超過...