但是在敏捷項(xiàng)目中，如何進(jìn)行故事點(diǎn)的估算呢？
在軟件開發(fā)過程中，我們可能經(jīng)常聽到老板和客戶問我們需要多少時(shí)間來完成項(xiàng)目？或者到某一個(gè)時(shí)間點(diǎn)，產(chǎn)品能做到什么程度？在瀑布模式下，項(xiàng)目經(jīng)理們基本會(huì)給出明確的項(xiàng)目上線時(shí)間。
但是在敏捷項(xiàng)目中，特別是Scrum開發(fā)框架下，項(xiàng)目團(tuán)隊(duì)變成了一個(gè)自組織團(tuán)隊(duì)，沒有了“經(jīng)理”，那我們?nèi)绾伍_展這項(xiàng)工作？如何進(jìn)行故事點(diǎn)的估算呢？
在Scrum的開發(fā)框架下，團(tuán)隊(duì)共擔(dān)責(zé)任，集體承諾每個(gè)Sprint的工作，因此對(duì)于工作量的估算通過集體估算的方式進(jìn)行。集體估算通常采用估算撲克作為工具。
估算撲克是基于共識(shí)的，游戲化的估算方法。估算撲克是寬帶德爾菲法的一種變體，由一組類似斐波納契數(shù)列的數(shù)字組成，這些數(shù)字包括：0，0.5，1，2，3，5，8，20，40，?，∞。它最常用于敏捷軟件開發(fā)，特別是Scrum和極限編程。那么如何采用估算撲克進(jìn)行估算呢？
分牌
在估算會(huì)議上，team中的每位人員都會(huì)得到一副紙質(zhì)撲克，當(dāng)然，隨著移動(dòng)互聯(lián)網(wǎng)的普及，目前大多數(shù)敏捷團(tuán)隊(duì)使用了更為便捷的電子撲克。無論電子撲克，還是紙質(zhì)撲克，牌上都需要包括這些數(shù)字1/2,1，2，3，5，8，13，20，40, ∞。
講解用戶故事
產(chǎn)品負(fù)責(zé)人按照排定的優(yōu)先級(jí)順序從Product Backlog中選擇一個(gè)用戶故事，為大家詳細(xì)講解該用戶故事；team針對(duì)該用戶故事進(jìn)行討論并提出問題，產(chǎn)品負(fù)責(zé)人逐一解答大家的問題。
當(dāng)團(tuán)隊(duì)成員確認(rèn)已經(jīng)對(duì)該用戶故事完全了解、無任何重大問題后，大家開始對(duì)該用戶故事進(jìn)行估算。
估算時(shí)，首先，選擇一個(gè)比較小的用戶故事，確定其故事點(diǎn)，并將該故事作為基準(zhǔn)故事。然后再將其他用戶故事和基準(zhǔn)故事進(jìn)行比較，得出其他用戶故事的相對(duì)點(diǎn)數(shù)，評(píng)估完成后，進(jìn)行下一個(gè)用戶故事點(diǎn)數(shù)的評(píng)估。
估算點(diǎn)數(shù)差距比較大的處理辦法
如果估算值差距明顯，代表大家對(duì)該用戶故事的大小沒有獲得共識(shí)，高估計(jì)和低估計(jì)的人需要給出他們?cè)u(píng)估的理由。如在某一個(gè)用戶故事的評(píng)估中，有的人評(píng)估的故事點(diǎn)數(shù)為3，有的人評(píng)估的故事點(diǎn)數(shù)為13，有的人評(píng)估的故事點(diǎn)數(shù)為8，則評(píng)估故事點(diǎn)數(shù)為3和13的人需要說明評(píng)估理由，大家對(duì)該故事所包含的任務(wù)達(dá)成共識(shí)后，在對(duì)故事點(diǎn)數(shù)進(jìn)行重新評(píng)估，直至大家對(duì)故事點(diǎn)數(shù)的評(píng)估基本達(dá)成一致。
如果對(duì)于同一個(gè)用戶故事的評(píng)估中，可能評(píng)估的故事點(diǎn)數(shù)不完全一致，但點(diǎn)數(shù)之間差距不大，比如在3和5個(gè)故事點(diǎn)之間，該用戶故事評(píng)估故事點(diǎn)數(shù)可以采用平均值法進(jìn)行計(jì)算，將平均值結(jié)果與評(píng)估的故事點(diǎn)數(shù)比較，并把與評(píng)估故事點(diǎn)差值較小的故事點(diǎn)數(shù)作為用戶故事的最終點(diǎn)數(shù)。
如在A故事點(diǎn)的評(píng)估中，共有7人參與評(píng)估，其中4人評(píng)估的故事點(diǎn)數(shù)為3,3人評(píng)估的故事點(diǎn)數(shù)為5，則取平均值后的故事點(diǎn)數(shù)為3.85，與評(píng)估的故事點(diǎn)3和5比較，平均值與故事點(diǎn)3差值更小，所以，該用戶故事的最終點(diǎn)數(shù)為3，該用戶故事點(diǎn)數(shù)評(píng)估完成。
相關(guān)的問題
在哪一個(gè)會(huì)議上進(jìn)行用戶故事點(diǎn)評(píng)估？
故事點(diǎn)評(píng)估一般在沖刺計(jì)劃會(huì)時(shí)進(jìn)行，并需要選定主持人，主持人一般由Scrum Master擔(dān)任。
為什么需要產(chǎn)品負(fù)責(zé)人講解用戶故事？
講解用戶故事的步驟是team和產(chǎn)品負(fù)責(zé)人之間的交互的環(huán)節(jié)，能夠幫助team和產(chǎn)品負(fù)責(zé)人共同加深對(duì)用戶故事的理解。同時(shí)產(chǎn)品負(fù)責(zé)人也會(huì)根據(jù)大家的反饋，進(jìn)一步完善用戶故事。
根據(jù)我的經(jīng)驗(yàn)，在講解用戶故事的過程中，千萬不要指定該用戶故事的負(fù)責(zé)人或明顯的傾向于某些人來做這個(gè)用戶故事，因?yàn)橐坏┲付素?fù)責(zé)人員，可能會(huì)大大降低不負(fù)責(zé)該用戶故事的team其他成員的積極性，甚至?xí)_亂估算的秩序與結(jié)果。
估算完成后，可以任意亮牌嗎？
估算時(shí)每個(gè)人選出代表自己估算值牌面上的數(shù)字，每個(gè)人都將牌面朝下，不可立即亮牌，待team所有人員示意完成評(píng)估后，參與估算的所有人員同時(shí)亮牌。在估算過程中，團(tuán)隊(duì)成員之間不可以互相商討。
這樣做是為了避免影響其他參與者，如果說出一個(gè)數(shù)字，它可能聽起來像一個(gè)建議，并影響其他參與者的評(píng)估。這一過程也是逐步提升team獨(dú)立思考的能力的一種手段。
估算與人/天，人/時(shí)有關(guān)系嗎？
估算的是一個(gè)相對(duì)值，而不是絕對(duì)值。和人／天，人／時(shí)沒有關(guān)系。假設(shè)我們以開車從北京到保定的工作量為參考基準(zhǔn)，是1個(gè)故事點(diǎn)，那么從北京到太原的距離大概是從北京到保定的3倍，那么我們可以估算從北京到太原的工作量為3個(gè)故事點(diǎn)。
估算時(shí)，需要找一個(gè)參照物進(jìn)行估算嗎？
每次估算時(shí)，最好使用相同的標(biāo)準(zhǔn)用戶故事，這樣對(duì)于整個(gè)項(xiàng)目的統(tǒng)計(jì)有很大幫助。使用相對(duì)值進(jìn)行估算，可以有效的監(jiān)控團(tuán)隊(duì)的生產(chǎn)能力。
對(duì)于初次實(shí)施敏捷的團(tuán)隊(duì)，對(duì)故事點(diǎn)的評(píng)估可能還是不太容易理解，根據(jù)我的實(shí)踐經(jīng)驗(yàn)，初次實(shí)施評(píng)估故事點(diǎn)時(shí)，可以嘗試1人/天的工作量作為一個(gè)故事點(diǎn)（與文中描述的“故事點(diǎn)和人／天，人／時(shí)沒有關(guān)系”這句話并不矛盾）。
產(chǎn)品負(fù)責(zé)人和Scrum Master參與估算嗎？
關(guān)于參與估算的人員范圍，team中的所有人員都要參與估算，可能的角色包括開發(fā)人員、測(cè)試人員，但不包括產(chǎn)品負(fù)責(zé)人和Scrum Master。這也是為什么建議team人數(shù)5-9人的原因之一，人數(shù)太少，會(huì)使估算結(jié)果偏差很大，人數(shù)太多，會(huì)拉長(zhǎng)估算時(shí)間，降低估算效率。
評(píng)估時(shí)最大點(diǎn)數(shù)不超過多少合適？
取決于團(tuán)隊(duì)。我們團(tuán)隊(duì)確定的用戶故事最大點(diǎn)數(shù)為13，超過13，會(huì)將故事卡片進(jìn)行進(jìn)一步的拆分。
實(shí)際開發(fā)中發(fā)現(xiàn)了估算失誤要不要修改點(diǎn)數(shù)？
不必。估算是為了輔助我們的工作安排，而不是用來管理員工的績(jī)效表現(xiàn)。為了達(dá)到精準(zhǔn)的估算而耗費(fèi)了過多的時(shí)間盒精力，這是本末倒置。
有的故事卡片會(huì)比預(yù)計(jì)的先完成，有的會(huì)耗時(shí)更長(zhǎng)一些，這些經(jīng)驗(yàn)的積累都會(huì)為團(tuán)隊(duì)的下一次估算奠定更好的基礎(chǔ)。所以，單純地修改點(diǎn)數(shù)是沒有意義的。畢竟快速迭代就是方便我們?cè)囧e(cuò)、改善。但如果做著做著發(fā)現(xiàn)故事卡中有深坑，建議再開一張卡片來填坑，這是比較常見的做法。
作者： 張洪強(qiáng)? ，微信公眾號(hào)：PMO雜談
本文由 @PMO雜談 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Pexels，基于CC0協(xié)議
愛盈利-運(yùn)營(yíng)小咖秀(www.jza6.com) 始終堅(jiān)持研究分享移動(dòng)互聯(lián)網(wǎng)App運(yùn)營(yíng)推廣經(jīng)驗(yàn)、策略、全案、渠道等純干貨知識(shí)內(nèi)容；是廣大App運(yùn)營(yíng)從業(yè)者的知識(shí)啟蒙、成長(zhǎng)指導(dǎo)、進(jìn)階學(xué)習(xí)的集聚平臺(tái)；
想了解更多移動(dòng)互聯(lián)網(wǎng)干貨知識(shí)，請(qǐng)關(guān)注微信公眾號(hào)運(yùn)營(yíng)小咖秀（ID: yunyingshow）
