本文是“松結對程式設計”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八）
估算是經久不衰的管理話題，大緻分為兩種流派。
第一種是上司指派，上司說這是10天的活，就必須當是10天的活來幹，如果幹不完，可以用加班、損失品質、功能縮水等各種方法曲線救場。另一個變種是大家自己估算，但是交給上司審批；上司審批其實就是砍一半的過程，還好大家之前就已經加了一倍，是以不怕。
第二種是自我管理派（偏靈活），就是由具體開發的人員自己說開發工作量，上司和他人不幹預。盡管“自組織”了，但是上司深以為這種方法留下了偷懶的種子，而隊員也覺得某人的估算很不靠譜（太長或太短），到底怎麼辦呢？
共同估算吧。
--------------------------------------------
基本概念
假設現在是一個計劃會上，PO（産品經理，策劃組長，項目經理，某銷售……）剛剛講完需求，下一步不是交給某人做估算，而是交給某個潛在的組（師傅+1～3徒弟）。
由師傅帶頭打牌，對，在計劃會上玩撲克：
1. 大家各自思考可能要花多久時間完成任務，扣一張牌出來；
2. 師傅喊開牌，大家亮牌，比較大小；
3. 一般最小和最大的兩個人PK，說出自己的觀點，大家一起讨論；
4. 差異無非來自于兩個方面：做什麼，怎麼做；PO參與讨論回答做什麼的問題，師傅和徒弟們讨論解決怎麼做的問題；
5. 讨論過後再來幾輪，直到大家覺得結果差不多了。
撲克牌估算的匿名性和開放性保證了大家不會人雲亦雲，也不會因為缺少溝通而難以達成一緻。
筆者的經驗是一局撲克牌估算大約持續1～5分鐘，還是很快的。偶然有黃莊的，一般都是因為PO那裡回答不了做成什麼樣子，某某附加功能是否也要做……等等問題時。
幾個問題
1. 為什麼分給組而不是個人？
不分個人就打牌使得每個人都不得不思考，因為怕出錯了牌又說不出是以然。這樣即使日後他不做這個功能，也對這個功能很了解。
2. 為什麼不讓最後領任務的人自己估算？
因為他很可能因為不知道某代碼可用、不知道某軟體不行、不懂template（我們是以扔過1個人月代碼）……而選擇了錯誤的實作方法。
3. 為什麼不讓師傅估算大家采納，他不是最厲害嗎？
師傅的想法常常是徒弟們了解不了的——比如為什麼不留在女兒國而偏偏去西天取經之類的，呵呵——共同估算就是讓大家在思考中對照自己的實作方法和師傅差異的過程。
4. PO怎麼還參加？不是不讓别人幹預嗎？
很多問題比如在遊戲中“顯示武林排行榜”，具體工作量可能不在于怎麼做而在于做什麼：憑什麼排名？排多少名？實時排名還是每周排名？怎麼顯示排名？……是以PO不能寫出一堆文檔，然後以不便幹預估算為名不參加靈活計劃會議。
PO可以挑戰估算，比如：“這真的要這麼久嗎？我記得上次……”但要有理有據。其實實踐中更容易看到的是，團隊往往過于激進樂觀，PO反而要讓他們意識到完整的需求和要求，做出更現實的估算。估算不準确，PO也有責。
5. 一直無法達成一緻怎麼辦？
其實估算不是為了最後那個數字，而是弄清楚做什麼和怎麼做的問題，如果這兩件事情清楚了，但結果卻是偏偏有人說4天有人說6天，随便取個數就可以了（事實是應該按墨菲定理取6天）。有師傅在，一般很少會就實作方法争執不下；有PO在，一般很少會就要實作什麼争執不下。
不排除有特殊情況比如PO發現自己也沒想過排行榜憑什麼排行，那麼就應該擱置此使用者故事；又比如大家覺得如果資料庫給力可能實時排名也行但又拿不準，可以暫時擱置到開發的時候再說，但把故事上标注一下“若需要每周自動排名+1天”。如果經常黃莊，Scrum Master要分析總結避免。
6. 四個人出牌不同，師傅先說還是徒弟先說？
想起個腦筋急轉彎：科學家 醫生 士兵 護士 ……等等一群人在飛機上，飛機結冰快墜落了需要有人（可能不止一個）跳下去，問誰跳？答案是從體重最重的人開始跳，因為可以少跳幾個。
是以我們是出牌數字最小的先說，和師徒無關。因為他極有可能掌握最佳實作方法。如果後來發現不是如此，請參考下一條。
7. 都有什麼理由可陳述？
按下面的順序，越靠前的越接近真理，感覺自己接近真理的就一定要舉手先說，馬後炮招人嫌：
經驗事實：我以前做過……咱們有個類庫……那個方法我試過不可行……
蛛絲馬迹：誰還記得上次……聽說隔壁……與上回相比……你以前不是……
邏輯推理：理論上說……我覺得……
幾個注意事項
1. 小組内不要有強分工，否則大家會預設認為肯定是某人的工作。
2. 師傅不要太搶眼，要通過估算鼓勵徒弟思考，同時也掌握徒弟的真實水準。
3. 師傅不要太較真，程式設計規範、易用性、易維護性這些紀律不能放松，但如果徒弟想嘗試一種不同但工作量也差不多的方法，可以适當鼓勵。
4. Scrum Master監控整個過程，防止太細/争執……等問題。
5. PO必須參加。
----------------------------------------------------------
共同估算依靠PO的參與解決了做什麼的問題，依靠師傅的帶動解決了怎麼做的問題。
共同估算是“跨職能團隊”的基礎活動之一，之後他們之是以能在每日立會上分享目前進展與困難，就是因為當初是他們一起思考這一任務的，是以對這一任務後來的實際情況非常關心。在發生問題的時候，大家也更可以互相幫助，而不是毫不所知。
下一篇将會涉及日常工作/每日立會等疊代期内的工作。
點選下載下傳免費的靈活開發教材：《火星人靈活開發手冊》
轉載于:https://www.cnblogs.com/JPAORM/archive/2011/07/06/2510487.html