敏捷開發「鬆結對編程」實踐之三：共同估算篇

本文是「鬆結對編程」系列的第三篇。

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

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

共同估算是「跨職能團隊」的基礎活動之一，以後他們之因此能在每日立會上分享當前進展與困難，就是由於當初是他們一塊兒思考這一任務的，所以對這一任務後來的實際狀況很是關心。在發生問題的時候，你們也更能夠互相幫助，而不是絕不所知。

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