引言
傳統(tǒng)的項目管理方式下雄可，項目估算是項目計劃階段的重頭戲，在在對需求分析進(jìn)行拆分后缠犀，把每個模塊根據(jù)經(jīng)驗計算出所需人天數(shù)数苫，平衡三劍客 - 時間，質(zhì)量和成本后計算出項目所需時間以及人員數(shù)辨液，基本由項目庫經(jīng)理帶頭和技術(shù)專家一起進(jìn)行估算虐急。
在敏捷的框架下，估算進(jìn)行的更為頻繁室梅，在每個迭代開始時進(jìn)行估算戏仓，估算的方式不再是人天而是故事點數(shù)，估算的人員也不再是項目經(jīng)理亡鼠，而是整個scrum團(tuán)隊赏殃。
如何在敏捷框架下進(jìn)行估算？在估算過程中一般團(tuán)隊會有什么樣的困惑间涵？會落入什么樣的陷阱仁热？
敏捷項目估算方法
估算標(biāo)尺
Scrum里根據(jù)用戶故事的難易程度進(jìn)行估算，通常會選擇如下的度量標(biāo)尺在進(jìn)行估算
- 數(shù)字（從1到10）
- 衣服尺碼（XS, S, M, L, XL, XXL, XXXL）
- 斐波拉契數(shù)列（1, 2, 3, 5, 8, 13, 21）
比較常用的是斐波拉契數(shù)列勾哩， 其中又集中在用1 - 13的數(shù)字進(jìn)行估算抗蠢，因為有研究表明，人類大腦比較善于處理第一數(shù)量級（即各位）的排序思劳，而斐波拉契數(shù)列在第一數(shù)量級的基礎(chǔ)上又把數(shù)字進(jìn)行了跳躍區(qū)分迅矛，讓大腦更容易做決策。雖然1和2很好區(qū)分潜叛，但是數(shù)字越大比如8和9就會變得很難區(qū)分秽褒，這時候用8和13就可以提高區(qū)分度。有人可能會問威兜，要是有的用戶故事比13還大怎么辦销斟？可以嘗試把這個用戶故事拆小。要是用戶故事不能再拆小或者還沒有到需要拆小的時候呢椒舵？那么可以用比價大的數(shù)字比如20,40,100蚂踊。13點以上不建議完全按照斐波拉契數(shù)列來列舉，因為那些數(shù)字（21,34,55）確實不好記笔宿，既然是較大的待拆用戶故事犁钟，用整數(shù)來標(biāo)記也無妨棱诱。
撲克估算法
在迭代梳理會議或者計劃會議上，可以用玩撲克的方式來進(jìn)行估算特纤，步驟如下
1. 向大家解釋1,2,3,5,8,13,20,40,100的意義是什么军俊。
可以選幾個數(shù)字定義一下對應(yīng)的用戶故事是什么侥加。比較常定義的是1,3,5捧存。
比如：
如果是第一次估算，和團(tuán)隊一起定義出難度標(biāo)準(zhǔn)担败，如果不是第一次估算昔穴，也需要再次審核以前的標(biāo)準(zhǔn)是不是有所變化
2. PO或者用戶閱讀用戶故事，向團(tuán)隊陳述所期望的功能提前。
在這期間吗货，團(tuán)隊如果又任何疑問都可以提出，由PO或者用戶回答陳清
3. 每個人暗自選擇一個撲克點數(shù)
暫時保密你選擇的點數(shù)狈网，手中的卡片必須在同一時刻揭曉宙搬。這條規(guī)定的目的是防止團(tuán)隊成員間決策的相互影響。
4. 最高和最低點數(shù)的人陳清他們點數(shù)的原因
原因可能多種多樣拓哺，有可能是對需求的理解不一致勇垛，有可能是對點數(shù)的標(biāo)準(zhǔn)有誤解，還有可能是對實現(xiàn)的方式有不同的方法士鸥。無論怎樣闲孤，都需要進(jìn)行陳清討論，有必要的話還需要記錄下來各自的原因烤礁，這些討論的內(nèi)容很有可能在開發(fā)過程中非常有用讼积。
5. 在討論的基礎(chǔ)上重復(fù)步驟三進(jìn)行再次估算，直到團(tuán)隊達(dá)成基本一致
估算陷阱
只讓少數(shù)人參加估算
一周的迭代一般需要2個小時的估算會議脚仔，有人會說如果每個人都參加會浪費很多時間勤众。所以有的團(tuán)隊會選擇讓部分人參加，有可能是資深人員鲤脏，有可能是團(tuán)隊成員輪流著參加们颜。但是這樣的結(jié)果是，沒有參加會議的人會花更多的時間去理解會議上發(fā)生了什么凑兰，又或者沒有參加會議的人有更好的解決方案掌桩，但是失去了在估算會議上提出方案的機(jī)會。讓所有人參加才是明智之舉姑食，因為本身估算就是收集所有人意見的過程波岛，來自各個職能團(tuán)隊的專家們是估算的最佳人選。如果聽到抱怨說參加估算會議的人太多影響了效率音半，那就要考慮是否拆分團(tuán)隊则拷，或者用更為有效的組織形式贡蓖。
估算結(jié)果固然重要，估算過程中思維的碰撞對需求的理解才是更重要的目的煌茬。
1 點 = 幾個人天斥铺？
傳統(tǒng)的項目管理會有“人天”作為單位來進(jìn)行項目估算，在scrum中采用故事點數(shù)坛善。那么這兩者之間有什么換算關(guān)系呢晾蜘？打個比方，從上海距離杭州200公里眠屎，開車3個小時剔交。故事點數(shù)好比距離計量兩地之間有多遠(yuǎn)，“人天”好比時間計量需要多久改衩，這兩種計量方式的換算是基于速度有多快岖常。200公里的距離，開車是3個小時葫督，坐動車是2個小時竭鞍。同理，一個1000點的項目橄镜，資深團(tuán)隊需要60個人天偎快，一個初級團(tuán)隊可能需要180個“人天”。
如果公司里有人執(zhí)意要在兩者之間進(jìn)行換算蛉鹿，那么建議取消故事點數(shù)的概念滨砍，直接用“天數(shù)”或者“小時”進(jìn)行估算。
相對估算 vs. 絕對估算
相對估算妖异，即預(yù)先設(shè)置一個標(biāo)準(zhǔn)惋戏，其余的項與這個標(biāo)準(zhǔn)進(jìn)行比較，得出一個相對而言的結(jié)果他膳，例如响逢，如果我們知道A樓高100米，看上去B樓是它的2倍高棕孙，我們可以估算B樓高200舔亭，C樓高度在A和B中間，可以估算C樓高150米, D樓的高度也在A和B中間蟀俊，但是與B樓的高度更接近钦铺，那么可以估算D樓高180米
絕對估算，是比較精確的估算方式肢预，即通過工具的輔助矛洞，估算出A樓高103米，B樓高194米烫映。
為什么我們在進(jìn)行故事點數(shù)估算是選擇用相對估算呢沼本？
- 絕對估算方式并不適合軟件項目
用絕對估算固然準(zhǔn)確噩峦，但是卻不適合用作軟件項目。因為軟件項目基本依賴于人腦抽兆，人與人之間水平的參差不齊识补，每個人每天實際用做編碼的時間也不盡相同。況且就算用于編碼的時間相同辫红，效率也不一樣凭涂，再加上項目千變?nèi)f化，很難有好的標(biāo)尺來進(jìn)行絕對估算厉熟。與其絞盡腦汁進(jìn)項絕對估算导盅，不如大概估算且多次估算更準(zhǔn)確，更能適合千變?nèi)f化的項目揍瑟。 - 相對估算易于讓團(tuán)隊中不同能力的成員達(dá)成共識
不可避免的是，團(tuán)隊中成員的編碼水平參差不齊乍炉，對需求的理解也是不可勝舉绢片。要是用人天來做估算，勢必會出現(xiàn)john說3個人天岛琼，Bill說1個人天的情況底循，這樣并不能達(dá)成共識。而用相對估算就能解決這個問題槐瑞，比如假設(shè)做功能A故事點數(shù)是2熙涤，John和Bill都覺得比較而言功能B需要比功能A多一倍的工作量，并且跟功能C有交錯的地方可能有風(fēng)險困檩，那么他們達(dá)成共識功能B的點數(shù)是5祠挫。 - 故事點數(shù)將估算與具體的時間概念區(qū)分開，也把團(tuán)隊成員的感性情緒排除開悼沿。
當(dāng)成員用人天進(jìn)行估算的時候等舔，心里活動是這樣的：一個人天算多少個小時呢？我們每周都有人請假要多估算點糟趾；我們還應(yīng)該招兩個人但是也不知道還要多久才能到位可能需要多估算點慌植；我們團(tuán)隊有兩個實習(xí)生是不是多留點空間？
在如此多的心理暗示下义郑，還能準(zhǔn)確的進(jìn)行估算嗎蝶柿？要是用故事點數(shù)就會排除心理暗示，只是純粹的對完成功能需要多少工作進(jìn)行估算非驮。
單一標(biāo)準(zhǔn)衡量故事點數(shù)
人們?nèi)菀渍J(rèn)為故事點數(shù)即是完成一個功能的工作量交汤，但其實這只是故事點數(shù)的一個方面，故事點數(shù)應(yīng)該包含的是開發(fā)一個功能要做的所有的努力院尔，它受到復(fù)雜度蜻展，不確定性喉誊，風(fēng)險，工作量等等各方面因素的影響纵顾。
- 工作量
單純從“量”來考慮伍茄，比如一個頁面有1個輸入項，第二個個頁面有100個輸入項施逾，那么第二個頁面的工作量就是第一個頁面的一百倍 - 工作復(fù)雜程度
除了“量”敷矫，還要考慮復(fù)雜程度。比如第三個頁面也有100個輸入項汉额，但是在這個頁面有日期選項曹仗，有對數(shù)字輸入正確性的驗證等要求，那么在這個頁面的故事點數(shù)要明顯高于第二個頁面 - 風(fēng)險以及不確定因素
如果一個頁面還有不確定因素蠕搜，那么也要適當(dāng)?shù)脑黾庸适曼c數(shù)怎茫，并且做好風(fēng)險應(yīng)對措施。 - “完成”的依附工作
團(tuán)隊會制定“Definition Of Done”妓灌，比如自動化測試轨蛤。在進(jìn)行估算因為這樣附加的工作量而增加點數(shù)。
拒絕用時間單位估算
故事點數(shù)適合對長遠(yuǎn)的計劃進(jìn)行估算虫埂，但是并不適合近在咫尺的任務(wù)估算祥山。
試想下在早會時一下兩種說法哪一種更好理解呢？
- “我的任務(wù)昨天基本完成掉伏，今天還需要一個小時結(jié)尾”
- “我昨天完成了2個點缝呕，我還剩1個故事點要完成”
顯然第一種方式更加具體易于理解。故事點數(shù)是大概的相對的估算斧散，對于較長時間段內(nèi)的項目估算很適合供常，易于達(dá)成共識，但是當(dāng)我們討論每天的工作時颅湘，用時間更接地氣话侧。
常用的做法是，對于一個功能用故事點數(shù)進(jìn)行估算闯参，但是具體怎么完成這個功能拆成任務(wù)后用小時或者天數(shù)進(jìn)行跟蹤瞻鹏。比如，針對招聘網(wǎng)站上的職位進(jìn)行條件篩選并查找的功能鹿寨，故事點數(shù)是8新博。然后前端，后端脚草，測試會把這個功能拆分成不同的小任務(wù)赫悄，由不同的成員負(fù)責(zé)完成。后端任務(wù)需要6個小時完成，前端任務(wù)再拆分成兩個埂淮，由小王和小李各自做4個小時完成姑隅。每天早會更新的時候，每人也會針對自己所在的任務(wù)進(jìn)行更新倔撞。
估算膨脹
什么是估算膨脹讲仰？
同一個功能，在上個月估算的時候是5個點痪蝇，但是這個月再估算變成了8個點鄙陡，并不是功能或者解決方案有變化，單純只是團(tuán)隊成員估算的時候增加了點數(shù)躏啰。和貨幣的通貨膨脹一個道理趁矾。估算膨脹是如何發(fā)生的？
團(tuán)隊有來自外部的壓力给僵，要求在這個迭代完成更多的故事點數(shù)毫捣，或者有人通過故事點數(shù)來衡量團(tuán)隊的生產(chǎn)率，所以團(tuán)隊成員會有意識的增加故事點數(shù)怎么樣防止估算膨脹想际？
設(shè)置至少兩個標(biāo)準(zhǔn)培漏，并且在估算是提醒團(tuán)隊與標(biāo)準(zhǔn)進(jìn)行比較后再給出點數(shù)。
如果標(biāo)準(zhǔn)設(shè)置的時間太久了胡本，或者開始一個全新的模塊需要重新設(shè)置標(biāo)準(zhǔn)便于團(tuán)隊成員理解比較。
估算結(jié)果 = 承諾畸悬？
在本文章中已經(jīng)澄清過侧甫，故事點數(shù)只是估算有多少工作量，并不能直接作為團(tuán)隊當(dāng)前迭代完成多少的承諾蹋宦。
那么披粟，怎樣讓團(tuán)隊開始承諾，承諾的依據(jù)是什么呢冷冗？在這之前守屉，先了解下什么是團(tuán)隊速率Velocity。一個相對穩(wěn)定的團(tuán)隊蒿辙，在穩(wěn)定的環(huán)境下一個迭代能完成的故事點數(shù)即為速率拇泛。這是一個比較理想的定義，在實際操作過程中思灌，比較常用平均速率俺叭，在排除掉那些占了長假的或者是團(tuán)隊進(jìn)行大調(diào)整的迭代后算出過去5個迭代的平均速率。
有了平均速率泰偿，也有有了承諾的依據(jù)熄守，當(dāng)然平均速率只是一個參照，具體還要考慮團(tuán)隊當(dāng)前迭代實際情況，比如團(tuán)隊成員要請假裕照，要完成的功能對別的團(tuán)隊依賴太大等等攒发。
敏捷項目可以作長計劃嗎？
項目經(jīng)理關(guān)心產(chǎn)品估算工作量多少需要多少人用多少錢晋南，老板關(guān)心產(chǎn)品什么時候能上線惠猿，是否賺錢。所以單個迭代的計劃并不能回答老板的問題搬俊，我們不可避免的要做長計劃紊扬。由項目經(jīng)理一拍腦袋想出個日期？還是試試以下兩種辦法
- 初始會議
在項目一開始唉擂，可以安排一個初始會議餐屎，在會議上對項目或者項目的獨立功能做估算，與迭代計劃會議的估算不同玩祟，在初始會議上很可能只是對一個史詩級用戶故事進(jìn)行初略估算腹缩，估算的單位也要提高一個量級，比如10,20,30,50,80空扎。然后團(tuán)隊再根據(jù)團(tuán)隊的速率來計算出完成需要的時間藏鹊。重要的是項目發(fā)起人以及項目負(fù)責(zé)人可以從開發(fā)團(tuán)隊那里直接獲得估算結(jié)果 - 產(chǎn)品POC
如果這是一個新的團(tuán)隊，或者連團(tuán)隊都沒有并沒有歷史經(jīng)驗應(yīng)該怎么進(jìn)行估算呢转锈？建議用最短的時間盘寡，比如半個月做一個產(chǎn)品的POC，根據(jù)對產(chǎn)品的了解撮慨，還有團(tuán)隊成員間的合作情況再進(jìn)行估算竿痰。
最后
估算的目的是為了更好的做計劃，商場如戰(zhàn)場瞬息萬變砌溺，一成不變的計劃不是好計劃影涉，需要時時調(diào)整計劃。
Estimation is nothing, Estimating is everything. by no one from 艾森豪威爾
