TFS看板的迭代規劃

故事點

故事點更多體現的是用戶情景或者bug的規模，採用斐波拉契數列(1,2,3,5,8,13)這樣的數字表示，包含以下內容：

1. 相對工做量
2. 複雜度
3. 風險和不肯定性

相對工做量

下面演示一個Case來講明：
假設有個編輯頁面A有10個字段,B有100個字段：

B的相對工做量應該是較大可是不是絕對的10 倍。可能3-5倍。反應的就是故事點增長

若是考慮到已有的動態表單生成，那麼A和B兩個case應該是複雜度一致,反應的是故事點一致。

複雜度

對於上面100個字段這個case，若是字段中有一些數據綁定，複雜控件等等，那麼必然帶來複雜度的上升，反應的也是故事點的增長。

風險和不肯定性

對於新的技術調研分析等，例如最開始去調查一個第三方api。某個技術實現可行性分析能夠轉化成工做量。

注意

1. 考慮到不一樣實現思路帶來的不一樣工做量估算差別，開發應該能夠對故事點進行調整。
2. 就拿距離來講，對於絕對距離的估算每每沒有相對距離準確。
3. 故事點只作相對大體的估算便可，不要求十分精確，可是要有足夠說服力。

速度圖

速度圖在待辦事項列表右上角，隨着時間的推移，速度應該是顯示一個可靠的，可用於預測平均完成故事點的數量。爲了發揮速度圖的效益，須要知足如下要求：

1. 按照團隊來規劃迭代內容(不要在頂層團隊規劃)
2. 爲團隊定義迭代(迭代的時間應儘可能相同)
3. 爲每一個團隊選擇迭代計劃(應儘可能多分配2-3個迭代)
4. 需求儘可能獨立,不要有太多關聯性(需求不要嵌套需求)
5. 迭代結束之後要及時更新將待辦項關閉，若是未關閉放到積壓工做從新規劃

6. 複雜bug須要評估故事點和任務拆分(複雜性須要開發本身評估)

   由於迭代內默認是由必定時間修復迭代內bug的，若是時間足夠能夠修復歷史bug，可是部分複雜Bug須要時間較長，建議看成需求同樣來估算

速度預測

在情景代辦事項列表中打開趨勢預測(推薦隱藏進行中的項目)便可打開預測工具。
能夠根據速度圖合理設置速度預測的值，便可使用預測功能。

注意事項

1. 要求針對每一個用戶故事和Bug設置故事點
2. 能夠對用戶故事和任務進行排序來從新預測
3. 速度的預測只是一個相對的值並不是一個絕對的估算(這部分參照迭代容量規劃)

做用

1. 對項目將來的進度進行大體的規劃
2. 對待辦事項進行規劃(排序和優先級)
3. 針對預測合理的分配團隊的資源

容量規劃

基於迭代速度預測是大體的一個判斷，容量規劃能夠幫助咱們作精確的計算。可是容量的規劃，根據團隊的狀況實際能夠調整，不該該提早太多，這部分能夠能夠由團隊在迭代開始之初在計劃會議上肯定。
配置步驟:

1. 選中某一個迭代，打開容量選項卡
2. 選擇團隊人員(能夠包含產品，開發，測試等)
3. 配置天天的工做量(注意能夠配置不一樣的活動).
4. 配置團隊休息日(週末默認休息，可把開發封板之後的工做日看成休息日)
5. 通常能夠複製上個迭代的規劃，按照須要稍做修改便可

右邊便可出現團隊的容量

任務拆分

有了容量規劃,迭代的大體規劃後，咱們須要對詳細作什麼進行規劃，而迭代的具體工做是根據任務來劃分,使用故事點作大體預測，使用任務剩餘工做作詳細劃分,緣由以下:

1. 故事點只是一個相對的概念，比較模糊
2. 需求拆分的過程能夠對某個需求或者bug作實現層面的設計
3. 需求的拆分包含設計過程能夠對需求的缺陷作提早的預防
4. 任務更加詳細方便作更加精確的估算
5. 任務初始估計和剩餘工做新建時候相等
6. 任務初始估計和剩餘工做以小時未單位

需求或bug拆分的任務須要填寫初始估計和標題便可，能夠根據須要填寫詳細的內容。默認是誰的需求誰來拆分，誰拆分的任務就是分配給誰的。注意事項:

1. 需求應該由測試拆除一個用例設計的任務，活動爲用例設計
2. 複雜Bug應該拆分任務。活動爲bug修復

通過上述拆分之後在右邊既能夠顯示每一個人員整體的時間和完成迭代內任務須要的時間。根據最終拆分的結果適當的進行需求的刪減。

燃盡圖

選中某個迭代之後,右上角圖形即爲燃盡圖。
可用容量的直線(最高點迭代開始出可用的最大工做時間，最低點0)
理想趨勢(最高點剩餘工做的最大值，最低點0)
剩餘工做(天天剩餘工做的折線圖)

以下參考資料學習燃盡圖:

1. https://docs.microsoft.com/zh-cn/vsts/work/scrum/sprint-burndown
2. http://www.methodsandtools.com/archive/scrumburndown.php