故事點 到底是什么含懊？
故事點身冬，理想人天，故事個數(shù) 有何區(qū)別岔乔？
團隊又要如何選擇呢酥筝？
針對這些問題，很多實踐了多年的敏捷教練也不一定能夠回答的清楚雏门。敏捷落地的過程中經(jīng)常會有人對點數(shù)估算覺得困惑和難以理解嘿歌，所以就更不容易執(zhí)行到位了。
有人說故事點是規(guī)模茁影，也有人說是工作量宙帝，還有人說是復(fù)雜度，還有人說其實就是理想人天（不是某一個人的人天募闲，而是大家達成相對一致的抽象的人天）步脓。
哪個才是最準確的？
甚至有些教練開始拋棄“晦澀難懂”的故事點蝇更，而直接采用理想人天（有些團隊實際落地會采用）沪编，或者不進行估算而直接采用數(shù)故事個數(shù)的方式（DevOps中經(jīng)常采用此方式）。
故事點的定義
來看看敏捷大師們是如何定義的年扩？
Mike Cohn：故事點是一個度量單位蚁廓，用于表示完成一個產(chǎn)品待辦項或者其他任何某項工作所需的所有工作量的估算結(jié)果。
Robert C.Martin：故事點是工作量的單位厨幻，被估算的不是時間相嵌，而是工作量腿时。
讓我們來給故事點做個通俗的解釋：
故事點就是? 工作量或規(guī)模 +復(fù)雜度因素+風(fēng)險因素+不確定性因素，采用相對估算法估算出來的一個抽象的綜合估值（數(shù)字）饭宾。
是不是依然感覺晦澀難懂批糟，頭有點暈？
讓我們換一種表達形式：
故事點數(shù) = 完成故事所需的工作量 + 復(fù)雜度/風(fēng)險/不確定性因素
（類似考試時候的：分數(shù) = 基礎(chǔ)分 + 附加分 ）
這就是說我們在做點數(shù)估算的時候看铆，首先要對比基準點的故事徽鼎，進行相對故事工作量/規(guī)模大小的估算，然后要額外考慮故事的復(fù)雜度因素弹惦，風(fēng)險因素否淤，不確定性因素，并且為這些因素額外加上對應(yīng)的點數(shù)棠隐，這樣估算出來的點數(shù)就更加具有參考價值石抡，也具備了相對準確性（注意：不是絕對準確，也不應(yīng)該追求絕對準確）助泽。
注意：
1.一個點不代表任何時間長短啰扛，所以敏捷團隊只有通過迭代實際交付衡量驗證，才能知道團隊實際產(chǎn)能嗡贺，才能將速率（一個迭代Sprint交付的點數(shù)總和）和排期計劃結(jié)合起來做規(guī)劃隐解。
2.團隊每個迭代產(chǎn)出的故事點大小，只能團隊和自己比較暑刃，速率的變化厢漩。
3.故事點數(shù)衡量的是團隊，而非個人岩臣。并且不能用于績效考核溜嗜，以免產(chǎn)生負面效果，數(shù)據(jù)失真架谎。
估算數(shù)字選取
通常采用?斐波那契數(shù)列炸宵，有時根據(jù)具體情況也可以采用自然數(shù)來替代（具體要看故事之間的差別，思考怎樣的數(shù)字間隔差異更加適合團隊具體的情況）谷扣。
使用斐波那契數(shù)列有著源自自然的優(yōu)勢土全，斐波那契數(shù)列又稱為黃金分割數(shù)列，大自然的奧秘蘊含其中会涎，隨著數(shù)字間距的擴大裹匙，對于顆粒度較大的需求更加便于我們判斷選擇哪個數(shù)字，隱晦和模糊的數(shù)字有其美妙之處 -- “大數(shù)定律”末秃，當(dāng)數(shù)量變大時概页，模糊性就消失了！
估算方法
通常采用:?敏捷撲克估算法
基本過程：
1）選擇一個基準故事练慕，點數(shù)設(shè)為1（團隊達成共識惰匙，并且之后所有迭代以此故事為基準故事）
2）PO依次介紹故事背景技掏，內(nèi)容，驗收標(biāo)準 等信息
3）團隊成員對故事做各自的點數(shù)估算项鬼，同時出牌（常用 斐波那契數(shù)列：1哑梳，2，3绘盟，5鸠真，8，提供8倍的估算范圍）
4）團隊成員對牌面數(shù)字偏差較大的進行解釋估算理由（較大奥此，較小 都要簡單闡述理由）
5）然后重新進行第二輪估算（一般情況下弧哎，考慮到估算成本和效率雁比，每個故事2輪估算即可稚虎，必要時可以進行多輪）
6）直到團隊成員達成基本一致（不是絕對一致，最終結(jié)果簡單協(xié)商確定即可）
這樣做的好處是估算過程偎捎，團隊可以充分討論和溝通蠢终，信息得到充分快速的交流，并且避免一言堂或信息披露不足茴她。
這樣的方式可以加快風(fēng)險寻拂，障礙，依賴的提前發(fā)現(xiàn)丈牢，并促進了團隊信息交流和達成一致祭钉，團隊內(nèi)部信息披露也更加充分。
另外一種更加便捷的方法：用手指己沛，來替代撲克牌進行出牌（過程相同）慌核，省去了撲克牌的準備。
這里要注意的核心點是：敏捷估算是?相對估算申尼，所有故事的點數(shù)大小垮卓，均參考基準故事來進行相對比較。
那么 故事點师幕，理想人天粟按，故事個數(shù) 有何區(qū)別？團隊又要如何選擇呢霹粥？
下面我們來聊聊這些方法到底有哪些區(qū)別灭将，以及分別在什么場景下進行選擇，才是最適合我們的方式后控。
［故事點數(shù)]
場景：
經(jīng)典的敏捷團隊庙曙，團隊氛圍友好，跨職能自組織團隊忆蚀。促進團隊交流矾利，發(fā)揮團隊的力量姑裂。
優(yōu)點：
1.通過估算游戲，團隊成員對每一個故事進行了充分溝通和討論男旗，分享了彼此掌握的知識和信息點舶斧，提前發(fā)現(xiàn)了部分風(fēng)險和障礙，加強了對故事的認知和理解察皇，達成全方位的需求共識茴厉。
2.通過估算游戲，獲得了一個團隊共同認可的相對準確的數(shù)據(jù)衡量什荣。
3.所有迭代的基準點對齊后矾缓，可以對迭代計劃和團隊迭代交付速率有了數(shù)字量化的依據(jù)和衡量。（一個點不代表任何時間長短稻爬，所以敏捷團隊只有通過迭代實際交付衡量驗證嗜闻，才能知道團隊實際產(chǎn)能，才能將速率和排期計劃結(jié)合起來）
缺點：
1.估算過程需要花費一點時間桅锄，但實際執(zhí)行過程可以有簡化提效的空間琉雳，抓住核心點是溝通達成理解一致。
2.點數(shù)估算比較抽象友瘤，新的團隊不容易掌握和理解概念翠肘。
[理想人天]
場景：
涉及人力成本統(tǒng)計或者人員安排和排期預(yù)算等情況下。
優(yōu)點：
比較好理解和安排計劃辫秧，理想人天是對人天估算進行了人員抽象束倍，也可以采用敏捷撲克估算法。
缺點：
執(zhí)行起來盟戏，估算者容易和自己的實際工作情況聯(lián)系绪妹，干擾到估算結(jié)果。
估算結(jié)果很容易被拿來做績效考核抓半，或者和個人產(chǎn)出掛鉤喂急，導(dǎo)致對團隊產(chǎn)生負面影響（敏捷團隊考核團隊而非個人）
[故事個數(shù)]
場景：
在DevOps的需求流交付模式下，通常會采用此方法笛求，大量需求廊移，需求顆粒度相對均勻，團隊較為成熟探入，并且企業(yè)更加關(guān)注宏觀需求數(shù)量（通常作為一段時期的吞吐量數(shù)據(jù)被采集使用）狡孔。
優(yōu)點：
快速簡單易用，直接數(shù)個數(shù)蜂嗽，便于統(tǒng)計苗膝，省去了估算的成本。
缺點：
1.需求顆粒度不均勻的情況下植旧，導(dǎo)致偏差較大辱揭，數(shù)據(jù)的可信度較低离唐。
2.需要配合嚴格的需求拆分標(biāo)準執(zhí)行，例如規(guī)定較為嚴格的需求顆粒度上限问窃，并且需要立即執(zhí)行到位亥鬓，對于大顆粒度的需求缺少過度過程（敏捷需求是漸進明細，允許大顆粒度需求的存在域庇，點數(shù)可以有更大的用處）嵌戈，對于較為成熟的團隊比較合適，新團隊需要適應(yīng)听皿。
3.增加了較大的前期需求拆分成本熟呛，團隊缺少執(zhí)行的過度時間。
了解了以上內(nèi)容尉姨，我的團隊又該如何選擇呢庵朝？
如果你的團隊想了解經(jīng)典的敏捷實踐，并且前期需求顆粒度大小不夠均勻啊送，需求經(jīng)常需要討論偿短，請選擇故事點數(shù)。
如果你們的需求拆分的很到位馋没，顆粒度比較均勻，可以選擇不進行估算降传，直接數(shù)個數(shù)篷朵。
如果你需要盡快做出計劃和預(yù)算，或者外包項目需要提前上報人日成本婆排，可以選擇理想人日声旺。
當(dāng)理解了以上概念的深層次含義，你也可以根據(jù)實際需要將三種方式進行部分結(jié)合段只，靈活運用腮猖。
作為一名敏捷教練和工程效率專家，在經(jīng)過了多年以上三種實際實踐后赞枕，我個人最喜歡的方式還是 敏捷點數(shù)估算澈缺。
需要思考的是，在保持敏捷故事點數(shù)原滋原味的優(yōu)點基礎(chǔ)上炕婶，將點數(shù)估算的落地成本降低姐赡，并且基準點做必要的對齊和選擇，這樣你就可以靈活運用點數(shù)獲得你想要的效果柠掂。
那么你會如何選擇呢项滑？
