靈活估算：故事點與直接估算天數的差異

在靈活中直接估算天數最大的好處是直覺，壞處是很難衡量是否有故意的高估和低估，也不能比較生産力是否在提升，于是基于故事點的估算應運而生。

基本使用方式

故事點的基本做法是：把一些常見的“标準任務”給出一個“标準點數”，形成比較基線，估算的時候隻要是同一類型的任務，直接寫上故事點數而非天數。比如：

1. 對單個表進行增删改查

2. 為一個已經存在的資料表增加一個複雜報表

3. 修改一個中等難度的BUG

……

在剛開始的時候，“點數”可以就是以往完成任務的平均天數。比如曾經有4次對單個表進行增删改查，檢視曆史記錄發現天數大約是15天，則可以定為15點。以後再碰到類似任務，直接寫下“15點”，而不再做太細節估算。

若故事點使用了6個月，假設團隊人數不變，而每個月完成的故事點分别為76/82/92/81/102/98，則表明開發效率不斷改進。

當然導緻故事點生産率變化的不隻是開發效率，比如到末期可能測試/部署占用了一些可用開發時間導緻故事點減少。是以一般會同步跟進可用時間的變化。

目标

使用故事點後團隊工作可能發生一些有益的變化，這是主要的目的，比如：

1. 團隊間會橫向比較标準點數，并是以獲得一定動力

盡管不同團隊會選擇不同的标準任務，但其間難免有所重合，若一方設定某任務為10點，而另一方為20點，則雙方需要進行一定的溝通。

當然不能粗暴地認為兩者點數應該相同，但與其說其間的差異反映了團隊人員生産率的差異，更可以認為表明了雙方架構的易維護性/已有子產品的可複用性等方面的差異。對這些差異的合理分析和處理，會帶來積極的改進。

2. 估算過程整體可以不太糾結于人員能力差異，而在于“這是什麼任務”

在靈活生态系統（将另有博文詳述）中曾提到，估算的目标不在于一個數字，而在于“這是什麼任務”及“用什麼方式實作最優”。故事點在這一點上比天數更好一些。

一個附加價值是：若一個任務看上去比某标準任務難一些，可以在點數上額外估計幾點，防止錯過明顯的差異。這一點數差異是建立在任務的差異上的，而任務差異的評價過程對未來确定這個任務的範圍/标準/方法是很有用的。

3. 借助故事點生産率的變化，可以觀測實際生産率的變化

在本文開始已經提到，這是直接用天數無法實作的。

4. ……（任何用直接天數達不到的目标）

倘若在實施故事點後并未達到上述目标（甚至在實施故事點前并沒有想好有哪些目标），實施故事點基本上會失敗。  

使用難點

國内在業界極少見到使用故事點成功的案例，難點包括：

1. 故事點的項目或産品特征很明顯，幾乎無法跨團隊比較

2. 若沒有曆史資料，很難設定标準任務

3. 在标準任務沒有那麼多種類時，很難判斷一個新任務到底像哪個标準任務；而太多的标準任務又令人迷惑

有鑒于此，筆者覺得在嘗試故事點前，不妨先使用一種中間狀态的估算過程：

1. 每個疊代後都記錄所有任務的實際完成情況，并形成所有任務的曆史完成情況集合

2. 每個計劃會仍隻估計天數，但大家要随時可以感覺新任務像以往哪個任務，并迅速查找曆史（列印一個小冊子），根據任務差别在曆史資料上增減天數

這種方式無法直接打到故事點的目标，但卻可以逐漸建立标準故事集（那些最常被查找的故事），或至少可以幫助大家在腦海中把生産率具象化（“哦，單表增删改查原來要花費15天啊”）。