前言

由於上週孩子生病，耽誤了更新，因此今天補上。
這次我們介紹一下在敏捷開發中我們如何進行任務的估算，簡單來說就是確定一項工作到底需要多少資源（一般是人*天）。
凡是做軟體開發都離不開任務的估算，因為老闆總是希望你能告訴他這個系統或軟體什麼時候能完成，大概需要多少人，這個工作一般都是費力不討好的活，很難估計，因為估計值根據需求，開發團隊的技術水平，人員狀態都有密切的關係，估的多了，老闆覺的團隊水平不行，估的少了，又是給自己挖坑，每次估算都讓人頭痛，雖然任務估算確實十分困難，但其實是有一些方法，儘管不能讓你的估算精確到多少天，但肯定可以讓你的估算更加靠譜。

估算的意義

準確的專案估算往往能帶來巨大的收益，比如：

• 可以根據估算確定產品的上線日期
• 根據估算來確定是否要招聘新的技術人員
• 根據估算可以大體確定團隊競爭力
• 根據估算可以確定大家要不要一起來996的加班

相反如果估算非常不準會有什麼結果呢，比如：

• 專案經理不再相信技術人員的估算，每次都會把估算*2再報給使用者或老闆
• 由於估算過於樂觀（99%的情況），專案經常拖期，大家績效受到影響
• 為了彌補專案拖期，大家不得不加班
• 團隊離職率飆升

估算的影響還不止於此，既然估算影響這麼大，還無法避免我們應該找一些方法來提高我們估算的能力，讓我們的估算靠譜一點。

傳統專案如何估算

簡單一句話：

開發人員根據經驗和直覺提直接拍腦袋拍出來的。

基本過程

1. 老闆把技術人員A和專案經理B找來
2. B把專案需求大體描述一下
3. A說我感覺差不多是半年
   一個典型的估算就算是完成了，稍好一些的會把專案需求分成幾大功能再來估算。其實也都差不多。

我們如何估算

如果上面的情景，現在我會這樣回答：
現在沒法給出一個精確的估算，之前專案是三個月完成的一個原型版本，如果需要進一步的估算，可以讓開發團隊和專案經理共同工作1~2個週期，就能得到相對靠譜的估算了。
由於我們的敏捷開發都是按照迭代週期進行的，因此我們這裡的估算也是指這個週期工作的估算。下面這三種方法都是基於PM能提供功能需求列表或使用者故事列表這一前提下進行的。
先計算出本週期一共的團隊資源量(人天，有必要的話可以將開發和測試分開)

計劃撲克

計劃撲克”（PlanningPoker）是一種標有數字的撲克牌。計劃撲克的目的是為了能夠在一個儘可能短的時間內，讓團隊成員更加多的瞭解需要做的工作，同時順帶得到一個可接受的估算結果，一般推薦4到8人蔘與估算。

基本玩法：
1.發牌
2.拎出一個要估算的功能，PM解釋要求
3.開發人員根據功能給出自己的估算值，用牌上 的最接近的數字代替，出牌背面朝上（每次一張）
4.大家同時翻轉牌，差距過大的人給出自己的想法
5.大家根據剛剛的發言再出牌和翻轉，直到達成一致，該功能的估算結束
6.重複2~5直至團隊資源耗盡。

好處：
1.有一定趣味性
2.再解釋時能夠實現知識和技術的分享

壞處：
1.再其他人看來實在玩撲克
2.需要道具

排序法

相對於計劃撲克，排序法需要的是一塊大一些的白板和卡片。
基本過程
1.大家把全部功能逐一寫到卡片上
2.把卡片用磁鐵貼到白板上
3.大家一起來將卡片按照自己估算的工作量大小進行排序，鼓勵進行相互交流
4.把大家分歧大的卡片挑出來，大家說明自己估算的依據以及PM及時站出來解釋
5.都說明後再把卡片交給大家進行重新排序，直到大家的排序意見一致
6.根據排序的結果將任務分別大中小三種級別，對於不符合這三個級別的再進行拆分和重新排序
7.對於三種級別給出估計值，在計算全部綜合即為估算。

好處：
速度快

壞處：
場面比較難控制
需要道具

總結

估算的第一要義就是：
不要試圖進行長時間的精確估算。
估算的第二要義就是：
估算的目標越小，就越準確
估算的第三要義就是：
保持冷靜和一定的悲觀
估算的第四要義：
作對事情更重要