敏捷開發一千零一問系列之二十七：各自分工下如何撲克牌估算？

問題這是敏捷開發一千零一問系列的第二十七篇。（在這裡提問，之一，之二，之三，問題總目錄）

來自提問帖 15樓 http://blog.csdn.net/cheny_com/article/details/7564388

原問題摘錄如下：

開發組中可能同時進行幾個專項開發，那麼就有人蔘與這個專項，不參與另一個專項。
那麼撲克估算的時候，針對某一專項的任務，要怎樣做，是否是開發組所有人員都參加評估，還是這個專項相關的人員才參與？

可能一個專項就一兩個人來做，專門估算，跟單獨拍腦袋差別不大；
如果大家一起估算，存在效率很低的問題；

分析估算的目的是什嗎？

在估算之前，一個非常重要的一定要問自己的問題是：估算的原因或目的是什嗎？

估算有很多原因，但實際上有些不太經得住推敲，或者說若遇到有人喜歡杠頭，則很難反駁。比如：

1. 為了知道多少行代碼可以完成（如果用程式碼估計）。

杠頭：無論知道是1000行還是不知道，做完了一數都是1000行，為什麼要提前估計呢？（這個是我8年前被問到的一個問題）

2. 為了知道多久才能完成，以便做計劃。

杠頭：我們計劃都是反推的，領導說多久，我們就做多久，估算有什麼價值？

……

那麼有哪些估算是無缺缺少或極具價值的呢？大致有兩種。

1. 在報價/合約發生之前的估算

若能在此之間完成估算，就能把握商務的主動。即使“被迫簽訂合約”，做到“心裡有數”還是要好很多。

這個屬於早期造價估算，以後再詳述，但可以參考http://blog.csdn.net/cheny_com/article/details/7672333。

2. 能改善結果的估算

如果之前以為要1000行——而且直接做也真的要1000行，結果估算完了發現只要100行，就很值得估算。

如果之前以為要100天——而且直接做也真的要100天，結果估算完了發現只要10天，也很值得估算。

這個是撲克牌估算的最佳應用情境。

預備活動 原理

估算能改善估算結果的原理是：通過溝通共用資訊，從而降低浪費。

一般而言浪費活動有兩種：

1. 需求理解錯誤造成的浪費

在估算中，通過不同的人、不同側面的問題，來抽絲剝繭發現需求的真相，可以有效避免這種浪費。

測試人員和開發人員共同估算，是一種弄清楚需求的常見方法。尤其是開發人員，由於經常深入核心，所以常常聽到一點點需求，就想當然地理解為自己曾經想過的一個類似需求，然後急于思考實現方法。

2. 實現方法錯誤/重複造成的浪費

一種是重複代碼，重新發明輪子……；

一種是錯誤實現，比如曾經有人由於不擅長使用“模板”（就是泛型），而把1個函數寫成65個；

一種是蠻幹，比如曾經有人為了圖省事使用寫入程式碼來實現碼流打包拆包，結果碼流在接下來的日子裡不斷變化，結果騎虎難下，2個月的工作因為品質低下而被扔掉，2周就重新設計編碼結束了。

……

水平不同、負責不同部分的程式員充分溝通、共同估算可以避免這些情況。尤其是高手、老手，可以提醒新手避免犯錯。

浪費與反浪費

必須意識到一點，儘管估算可以防止浪費，估算本身也要花費時間，因此要思考估算的效率。

提高效率的方法包括：

1. 若無必要，不牽涉太多人員進行估算

139團隊是一種方法，就是如果我們有13個人，那麼嘗試分為3組，每組有4個人，這四個人是基本估算單元。他們應該負責相似的功能，平時也坐在一起，因此溝通起來比較順暢。

2. 嘗試使用較大的顆粒度

常常聽說有敏捷開發實踐者把任務且分到2小時左右的，甚至有0.5小時的。這裡不直接說應不應該切分，而是提醒一下：4個人吵吵15分鐘，就是1小時。我們可以花費1小時，但一定要知道獲得了什麼，如果真的值得，就去做；如果不值得，就換大一點的顆粒度。

3. 嘗試更快速的估算方法

撲克牌估算就是一種很快速的方法了，因為如果出牌數字相同，基本上就不討論了（如果第一次就相同，推薦讓一個人說一下，其他人沒有太大的不同意見就過）。

方案

分析清楚了，方案就比較好寫了。

方案1最容易實現但效果也最不好，後面的則效果好但實施起來更費勁。

方案1

在完全一窮二白從來沒有估算過的團隊，如果他們本來業務也是各自負責一塊，建議先以“技術相同”為條件拉幾個人在一起估算；如果這幾個人平時就坐在一起更好，可以在平時補充一些會上講不到的地方。

在公開課課堂訓練這種徹底“強分工”的環境下，我發現只要技術說的通，兩家公司的人都可以在一起估算的，何況一個團隊的小組內部。但前提是產品經理要能說明需求。

不過初期一定會發現估算很花時間，因為初次估算的時候很多背景知識都不知道，甚至那位直接負責此事的人也說不清楚，所以溝通的成本比較高。如果大家月月都花上一天討論，很快就可以避免對基本背景知識的交流了。

剛開始的兩三個月，不用太強求有何效果，大家互相理解了背景，就是個效果。

方案2

一點點建立有固定組織圖的小組，然後把估算組與小組綁定。

139團隊是一種，其實即使簡單任命一個小組長然後帶領其他3～4個人開發某種東西，就可以稱之為一個固定的小組了。

固定的小組應該開發相對接近的功能（技術是否相同反而次要），即使技術不同也可以從不同的角度提出自己的看法。有很多人認為，如果我不懂某個技術，就說不出來那部分的開發要多久，這個其實不對。如果我距離那個人不到5米遠，我們在開發同一個模組的不同部分而已，他用的技術也不涉及廣義相對論之類的很費解的內容，人們就沒有理由對某個技術“說不什麼意見出來”，尤其是小組的組長。

在01年的團隊中，我們的25人的部門經理基本上參加過每個小組的開發，包括類似機頂盒這樣的和PC完全不同的開發平台。當時機頂盒小組發現代碼裡邊有一些難以處理的缺陷，他就過去“順便幫忙”，結果是發現整個代碼過於混亂，於是用了兩周他就重構了整個機頂盒裡邊的代碼結構，在C環境下實現了接近C++的物件導向結構。當然要做到這一點需要相當天才的人。但如果只在3～4個人的範圍內，這件事情就不那麼複雜，人才也不需要太好。

方案3

建立L型代碼結構。L型代碼結構具體情況請參考松結對程式設計系列中的相應文章（大約第9篇左右開始，當前有三篇）。

我現在和程式員也“分工”，估算雖然不做（現在只有兩個人，溝通太多了所以前面提到的估算的第二個目的早實現了），但給他布置任務的時候，會討論每個方法的實現方法。主要的討論內容，是告訴他兩樣東西：

1. 整個業務過程類似我編寫過的哪個部分，可以作為整體過程的參考（一般集中於View/Controller兩個層面）。

2. 可能用到哪個底層類和函數（集中於Model，我們的Model庫佔總代碼量的67%，多數是我在編寫我的上層應用時順便寫的，他也做過維護）。

第二部門有時候我不會主動交流，因為看過1之後基本上就能看出來，有疑問時再交流。

L型代碼給估算帶來了幾個變化：

1. L型代碼的高層調用過程非常容易理解，因此關於“如何?”的討論比較簡單，不用涉及太深的底層實現。

2. 很容易找到相似業務的模組做參考。

我們平均一個Controller大約有5～10個函數（比如“使用者”的增刪改查等操作：UsersControler.Index/Details/Create/BatchCreate/Delete/Freeze/Edit），每個函數的代碼量是4～5行，所以如果要學另外一種東西的增刪改查全過程，看完這50行代碼就能大概瞭解整個過程了。

3. 由於底層庫都用過，很容易找到使用範例（用IDE搜）。

4. 每次討論的時候，會發現需要擴充一些底層庫尚未實現的功能，無論誰最終實現它們，討論過程兩個人都知道要多這個功能了，對未來充分複用很有協助。

不過，L型代碼要徹底形成相對困難，對“順便”產生底層庫的人要求比較高。

當然最後一個問題：“你們不但不打牌，還甚至不估算，這算敏捷嗎？”

怎麼說呢，這麼久以來，我們沒有因為新人蔘加而發生重新發明輪子的事情，代碼也沒有因為新人來了而發生迅速增加或品質下降，人們知道代碼中發生的幾乎所有重大變化……目的達到了，過程就不重要了。

本人正在參加CSDN部落格之星評選，如果讀完並喜歡這篇文章，歡迎投票：http://vote.blog.csdn.net/item/blogstar/cheny_com