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

問題

原問題摘錄以下：

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

可能一個專項就一兩我的來作，專門估算，跟單獨拍腦殼差異不大；
若是你們一塊兒估算，存在效率很低的問題；
 

分析

估算的目的是什麼？

在估算以前，一個很是重要的必定要問本身的問題是：估算的緣由或目的是什麼？

估算有不少緣由，但實際上有些不太經得住推敲，或者說若遇到有人喜歡槓頭，則很難反駁。好比：

1. 爲了知道多少行代碼能夠完成（若是用代碼行估計）。

槓頭：不管知道是1000行仍是不知道，作完了一數都是1000行，爲何要提早估計呢？（這個是我8年前被問到的一個問題）

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

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

……

那麼有哪些估算是完好缺乏或極具價值的呢？大體有兩種。

1. 在報價/合同發生以前的估算

若能在此之間完成估算，就能把握商務的主動。即便「被迫簽定合同」，作到「內心有數」仍是要好不少。

這個屬於早期造價估算，之後再詳述，但能夠參考http://cheny.blog.51cto.com/3988930/1102202。

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型代碼要完全造成相對困難，對「順便」產生底層庫的人要求比較高。

 

固然最後一個問題：「大家不但不打牌，還甚至不估算，這算敏捷嗎？」

怎麼說呢，這麼久以來，咱們沒有由於新人蔘加而發生從新發明輪子的事情，代碼也沒有由於新人來了而發生迅速增長或質量降低，人們知道代碼中發生的幾乎全部重大變化……目的達到了，過程就不重要了。