4.糾結的估點

    敏捷開發系列文章目錄

估點的意義不是爲了獲得精確的工做量這個數字，而是經過估點這個過程把這個故事的複雜度找出來。

1.估點的流程
    PO在講完故過後，SM讓開發人員對這個故事有什麼疑問沒有，有疑問PO繼續答疑，若是你們都沒有疑問SM會要求你們出點，這時候每一個人手上都有一副敏捷估點撲克牌，每一個人會把本身估算的點數對應的撲克牌抽出來，放在桌上蓋起來，不能提早翻看讓別人看到，等你們都出牌後，SM會讓你們一塊兒亮牌。通常來講你們出的牌確定會不一樣，這時候SM會要求出最大牌的人說一下本身的理由，而後讓出最小牌的人說一下本身的理由，說理由的過程當中確定會引起你們的討論。等這兩人闡述本身的理由完以後，SM會要求你們再從新出牌，此次基本上你們的點數就會差很少了，若是仍是最大和最小差異很大，那就最大和最小再說明本身的理由，而後繼續估點，若是第三次仍是相差很大，那麼表示這個故事你們沒有搞得太清楚，那麼就先把這個故事放一邊，看後面的故事。等本次迭代全部故事都估完後，再拿起這個故事進行估算，大多數這時候就能過去了，由於故事之間是有關聯關係的，剛開始可能對這個故事的複雜度看不許，看完後面的故過後就有可能有把握了。萬一到最後仍是估不出來，那必定是故事自己有問題，可能太大了或者需求不明確，這時候就讓PO收回此故事完善好後，放入下個迭代再開發。
咱們用的估算撲克牌上的數字是斐波納契數，一、二、三、五、八、1三、21，還有兩張喝咖啡和問號的牌，後來咱們把大於3的撲克牌都不容許出了，由於太大的點沒有意義，點越大表示估算確定準確程度就越低，還有就是咱們的基準點（1個點）團隊成員完成它須要1天的工做量，而咱們一個迭代兩週，每一個人開發的時間只有8天，你作一個5個點的故事，那就會出現頭一週都完不成一個故事，致使然盡圖根本就無法將下來，迭代失敗的風險也就越高，因此咱們最後決定大於3的牌都不容許出了，通常遇到大於3個點的故事，PO都會拆分紅多個故事。固然這是咱們團隊的方法，別的團隊的基準點可能沒有這麼大，那麼大點也仍是有用的。另外還有一張問號的牌就是在估出來的點太大或者估不出來的時候就出它，喝咖啡的牌表示本身須要休息一下。

 

2.估點不會被誇大，只會估得過於樂觀
    咱們作了這麼多個迭代，確實沒有出現開發人員刻意去誇大故事點，反而有失敗的迭代故事點的複雜沒有考慮完整，致使估點樂觀了。估點過程當中，SM必定要把握好，必定要引導你們正確的估點，而不是讓你們跟風，或者隨便說一個點數，但又說不出理由，這種估法確定就有問題，SM必定要糾正你們。

3.基準點的做用
    基準點是一個參照物，全部故事估點都必須是它的相對值，因此選定的基準點必須是你們都作過的功能好一點。咱們團隊選定的基準點是一個單表操做的字典維護功能，包括增刪改查等功能，如何估算了，好比單據維護的故事，包括單據頭和單據明細，那麼對比基準點，單據頭有增刪改查的功能，單據明細也有增刪改查的功能，因此咱們會估2個點。不能這樣搞，我作過這種相似的單據維護功能，我只須要1個點，這就是錯誤的估點方式，又好比我估3個點，由於除了兩個增刪改查還要實現單據頭和單據明細的關聯，由於要關聯展現因此多一個點。你說出的理由你們若是都承認的話，那下次出點的時候確定就會把這個因素考慮進去。

 

4.估點不是站在本身的角度來估，而是站在團隊的角度。
    估算爲何採用點數，而不是工時，由於工時是一個絕對值，而點數是一個相對值，這個故事對於你是2個工時，而對於我則須要5個工時，由於每一個人的飯量是不同的。點數只是一個對比基準點的相對值，因此基準點的定義很重要，團隊必定要達成一致。我以爲工時會不自覺的讓你們站在本身的角度來估算，而點數則不會這樣，因此作敏捷必定不能用工時來估算。後面領用故事的時候，並非由SM或PO來分配故事，而是隨機分配或自由領用，只有採用點數才合適。團隊一個迭代能完成多少個點，是有一個比較穩定的值的，也就體現團隊的速率，是有團隊每一個開發人員可以承擔點數之和，團隊中經驗豐富的老手承擔的點數確定比新入職的點數要高，老員工咱們是10個點的話，新員工咱們只給分配給他5個點或更少，隨着新人的成長對應的點數確定也會提高。
團隊中有開發人員和測試人員的話，那測試人員要怎麼估點了，咱們是開發人員站在開發的角度估點，測試人員站在測試的角度估點，開發和測試都是同一個基準點，原本基準點裏即包含有開發也包含測試工做。若是測試估的點大於開發估的點，那通常這種故事的測試工做量比開發工做量大，最後故事的點數確定採用大的。
還有一個疑問就是，測試執行工做必須在開發完成以後作的，因此都以爲估算的點數是否是應該開發的點數加上測試的點數纔對，其實不是，第一測試的大部分工做量並非在測試執行階段，而是在測試用例編寫，第二就是就是測試用例編寫階段是能夠與開發並行的而不是串行的，因此開發和測試相加是不太合理的。

5.估點的意義不是爲了獲得精確的工做量這個數字，而是經過估點這個過程把這個故事的複雜度找出來。
    產品開發除了進度很重要，產品的質量更重要，質量不行的產品最後仍是要返工的。若是你開發以前對這個故事的複雜度瞭解得越清楚，那麼你在開發過程當中就會越順暢，任務安排得也就越合理。另外敏捷就是注重團隊總體的成功，因此一些難點應該利用團隊的力量來解決，同時團隊中的每一個人也能夠更快得獲取成長。

團隊必定要有這個認識，不是說點數差很少，而忽視這些點數背後的理由是不行的。

    敏捷開發系列文章目錄