【導讀】
對于估算，團隊常常會有這樣的困惑：花了大把時間來估算，最后卻發(fā)現(xiàn)與實際還是有不小的偏差，到底有沒有必要做估算，怎樣來做估算？
俗話說，行百里者半九十，意思是說一百里的路走了前面九十其實只完成了一半，剩下的十里仍需要花很大的功夫。那么現(xiàn)實的生活和工作中，我們是不是也經(jīng)常遇到這樣的情況呢？
回想一下，會不會有這樣一種經(jīng)歷：打掃衛(wèi)生，讓房子從凌亂到整潔只需要20%的努力，要讓房子從整潔到一塵不染卻要花費80%的努力。那么我們就要審視一下，在精力有限的情況下，從整潔到一塵不染的過程有沒有必要，房子從凌亂變到了整潔是不是就已經(jīng)足夠。我想沒有潔癖的一般人，就如我，都會覺得后面那個過程的性價比實在太低，完全沒有必要。
回過頭來看看我們在項目中的估算是不是也可以類比，從無估算到有估算其實花的是比較有限的精力，但是從有估算到追求“準確”估算卻是個漫長的過程，并且有數(shù)據(jù)顯示我們花一些時間得到的估算數(shù)據(jù)跟花費大量時間而得到的結(jié)果不會差很多?！睹艚莨烙嬇c規(guī)劃》這本書中提到，估計的準確度和投入的工作量之間存在以下關(guān)系：
因此我推薦在進行估算的時候不必強求精確，更何況我們也無法做到精準，估算只是估算，只要做到盡量合理，盡量貼近真實值即可。
估算單位的選擇
有的團隊往往會在估算開始時糾結(jié)于如何選擇估算單位，因為合理的選擇是影響估算成功的關(guān)鍵因素。那么究竟該如何選擇呢？
1/3 理想人日
理想人日是指成員在不受干擾的情況下，全部時間都用于開發(fā)一需求所需的天數(shù)。
理想人日的劣勢在于：小組成員對技術(shù)和項目的熟悉程度，個人的經(jīng)驗和能力不同，都會導致基于理想人日的估算值有一定差異。例如，你問一個擅長C語言的成員某個需用java開發(fā)的功能的理想人日，他也許會告訴你是5天。但是你問一個擅長java的成員同樣的問題，他的回答也許就是1天。這樣的差異會導致我們對任務規(guī)模認識的偏差，很難衡量項目的實際“大小”。而它的優(yōu)勢則在于：對于團隊外部的人來說理想人日更容易被理解，無需解釋。對于團隊而言，它使估算更容易開始。
2/3 理想人時
理想人時是對應理想人日而存在的，只不過它的粒度更小。當熟悉需求的情況下，用理想人時的估算會更準確些。想象一下，讓你估算接下來1個小時能完成多少工作任務和接下來一天能完成多少任務，哪個的會更接近真實情況些？我想應該是前者吧。因為一天內(nèi)能做多少工作，我們需要去除很多“雜事”（如喝水，上廁所，跟同事嘮嗑，戳網(wǎng)頁...）來估算純干活的時間，這一點往往較難一些，總會存在一些偏差。但是如果要估算接下來1個小時能做什么，應該就比較容易了。理想人時的估算優(yōu)勢就在于：在充分理解需求的情況下，能幫助團隊做到更靠近真實值的估算。而缺點是：對于一些大的需求無法做到如此細粒度。
3/3 故事點
故事點是來自于敏捷的概念，是對任務規(guī)模的估計，它是一種相對概念。例如：需求X為4個故事點，需求Y為8個故事點，則表示Y的規(guī)模是X的兩倍，但并不表示開發(fā)Y比開發(fā)X要多一倍的時間，因為這還取決于是由什么樣技術(shù)熟練度的人員開發(fā)。故事點的優(yōu)勢在于：
一方面，基于故事點的估算更純粹，不會因為開發(fā)人員的變更，時間的推移而改變。換句話說，項目半途有成員離職，加入新的成員，此時我們不需要對每個任務都重新估計，只需要重新評估一下是否有需要調(diào)整插入到當前迭代的故事點數(shù)。
另一方面，由于人們往往更擅長于相對估算，所以故事點會讓估算更迅速。想象一下，讓你估算一杯水是另一杯水的幾倍，是不是會比讓你估算兩杯水各是多少毫升來的更容易呢？劣勢在于：一方面，而且由于編程語言不同或者業(yè)務分塊，大家很難找到一個共同熟悉的需求作為基準，那么用故事點的作為估算單位的方式就很難開展了。另一方面，故事點相對于其他估算單位更難被理解，這也使估算難以開始。
估算的幾種常用方式
1/3 自底向上的估算
由每個開發(fā)人員估算自己的任務時間，然后將所有的任務匯總，并考慮過任務間的依賴關(guān)系后，就排出了計劃。該方式適用于具有以下特點的團隊：成員間業(yè)務獨立性強，相互之間的業(yè)務熟悉度不高且熟悉成本較大，較難進行共同估算；各成員的經(jīng)驗相對豐富，對自己的任務能進行較好的評估。
在這樣的團隊應用該估算方式有以下優(yōu)勢：
1.估算效率較高，各自任務的估算可以并行。
2.準確度也會較高，因為對各自的任務比較熟悉。
2/3 專家判斷
由一個或多個專家根據(jù)相應開發(fā)的情況給出任務的估算值，但前提是你能找到這樣一個熟悉整個項目所有業(yè)務和整個項目團隊成員的專家或?qū)＜医M，在筆者所在的團隊一般會有開發(fā)leader來充當這樣的角色。
它的好處顯而易見：
1.通常不需要太多的時間，一個人估算就不存在太多的交流成本
2.準確度也有一定的保障。甚至有證據(jù)說這種估算方法比其他的分析性方法更準確。
3/3 撲克估算
是以撲克牌的形式進行團隊估算。估算開始前，每個估計者會分到一疊撲克牌，每張上有一個數(shù)值，如0,1,2,3,5,8•••然后由負責人對某個需要進行估算的需求或者任務進行講解，講解完之后，所有人可以向該負責人提問關(guān)于該條需求或任務的問題，直至足夠了解以做出估算。所有成員各自挑選一張撲克牌代表自己對該條目的估算。例如A給出8，而B只給了2，這樣就需要A和B各自給出理由說明自己估算的理由，這樣一輪下來，大家對該條目又加深了了解，然后進行第二輪估算，如果相差還是很大，則繼續(xù)下一輪。大多數(shù)情況下至多經(jīng)過兩輪，大家的估算值已經(jīng)非常接近了，就可以取平均值作為對該條目最終的估算。
撲克估算的好處在于：
1.集合了所有團隊成員的意見，比一個人的估算少了很多主觀成分；
2.其次，在估算過程中，強化和深入了大家對需求和任務的理解，將其考慮地更加細致，降低了不確定性給計劃帶來的沖擊；
3.最后，這種形式使相對嚴肅的計劃和估算會變得更加有趣。但是不得不承認，這需要比前兩種方式更多的時間成本。
實際應用中的估算
團隊1
組成：4人團隊（3人開發(fā)，1人測試）。
現(xiàn)狀：團隊穩(wěn)定合作近2年，嘗試敏捷一年多，開發(fā)語言統(tǒng)一，成員間對相互的業(yè)務也都比較熟悉。
估算單位和估算方法：由于很容易找到大家熟悉的一個用戶故事作為基準，目前團隊正應用基于故事點的撲克估算。團隊在經(jīng)過幾次迭代之后，基本上確定團隊的開發(fā)速率（每個迭代能完成的故事點數(shù)）。在接下來的迭代中，團隊通過撲克估算確定每個用戶故事的故事點，再根據(jù)用戶故事的優(yōu)先級一個個插入迭代開發(fā)計劃中，直到不能再承諾完成為止。
團隊2
組成：9人團隊（7人開發(fā)，2人測試）
現(xiàn)狀：團隊組建不到3個月，開發(fā)語言不統(tǒng)一，成員比較年輕，對系統(tǒng)的熟悉程度也不高。
估算單位和估算方法：一方面，由于成員之間的業(yè)務熟悉度不高且開發(fā)語言不統(tǒng)一，團隊無法輕易找到一個合適的基準用戶故事，所以團隊的估算都是基于理想人天開展的。另一方面，由于開發(fā)人員數(shù)量較多且一部分成員經(jīng)驗比較欠缺，無法很好的進行團隊估算，所以團隊目前采用專家判斷（開發(fā)leader給出估算）為主的方式進行計劃。
團隊3
組成：13人團隊（9人開發(fā)，4人測試，2人運維）
現(xiàn)狀：團隊組建約1年多，產(chǎn)品模塊較多，不同模塊有不同的負責人，成員對自己模塊的業(yè)務邏輯比較清楚，但是對其他模塊的業(yè)務了解甚少。
估算單位和估算方法：由于成員間業(yè)務熟悉度不高且開發(fā)語言不統(tǒng)一，團隊無法找到合適的基準故事點，所以團隊選擇采用理想人日作為估算單位。另一方面，也由于模塊較多，開發(fā)leader不能熟知各業(yè)務邏輯，所以團隊采用了自底向上的估算方式。由成員各自估算各自的任務，進而給出開發(fā)計劃。
團隊4
組成：4人團隊（3人開發(fā)，1人測試）
現(xiàn)狀：團隊組建2年多，產(chǎn)品已經(jīng)處于成熟期，目前大部分工作處于查漏補缺的階段。各成員對自己負責的部分比較精通。項目采用1周的短迭代形式。
估算單位和估算時間：由于迭代時間較短，團隊成員又在自己的領域比較精通，故能做到基于理想人時的自底向上的估算，估算的偏差一般較小。
通過以上幾個例子，筆者想說明的是：各種估算單位和估算時間本身并沒有好壞之分，只有合適不合適只說。每個團隊都需要根據(jù)成員和項目的現(xiàn)狀來進行選擇。如果生搬硬套只會弄巧成拙，得不償失。
關(guān)于估算，我們必須明白
1.我們要知道，估算僅僅是一個預測，當對外承諾項目完成時間的時候，最好提供一個日期范圍，讓聽者知道你的估算只是估算；
2.不管是用什么估算方法，更小塊的工作總是更容易被估計；
3.團隊需要練習估算并且收集反饋，沒有反饋的估算最終將被證明是毫無價值的。每一次估算對應的開發(fā)結(jié)束后，大家需要回過頭看看我們當初做的估算是否合理；
4.估算也許需要反復進行，當項目進行到一半時，發(fā)現(xiàn)估算過于樂觀了，那么就需要對剩下的工作進行重新的估算。
（本資訊于2017-12-11首次發(fā)布）
