敏捷開發“松結對編程”實踐之三：共同估算篇

本文是“松結對編程”系列的第三篇。

估算是經久不衰的管理話題，大致分為兩種流派。

第一種是領導指派，領導說這是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的參與解決了做什么的問題，依靠師傅的帶動解決了怎么做的問題。

共同估算是“跨職能團隊”的基礎活動之一，之后他們之所以能在每日立會上分享當前進展與困難，就是因為當初是他們一起思考這一任務的，因此對這一任務后來的實際情況非常關心。在發生問題的時候，大家也更可以互相幫助，而不是毫不所知。

下一篇將會涉及日常工作/每日立會等迭代期內的工作。