TFS看板的設計

列

產品開發的整個流程以下圖,將流程配置到看板的列：

需求池-->就緒-->開發-->測試-->待驗收 -->待發布 -->已關閉

通常將Bug和需求放在一塊看版上處理,工做項有本身單獨的狀態,能夠經過模板設置調整，可是不推薦這麼作(配置難度較大，而且自帶的比較通用)，因此這裏工做項須要對應看板列，這樣在看板中操做時候能夠利用流程作一些默認數據的填寫(例如指派給，時間等等),看板列和狀態對應關係以下:

類型\列	需求池	就緒	開發	測試	待驗收	待發布	已關閉
需求	新建	新建	活動	已解決	已解決	已解決	已關閉
Bug	新建	新建	活動	已解決	已解決	已解決	已關閉

泳道

按照順序從上往下依次爲

1. 插入事件:緊急發佈的需求,Bug或者急需解決的事項
2. Bug:需求缺陷或者數據缺陷
3. 需求:只放當前迭代的需求

在製品限制

不管開發仍是測試最好是一次之作一件事情。若是同時處理兩件，那麼通常是兩種狀況

1. 某一個事情出現阻礙中止(須要其餘人員協助解決)。
2. 兩個事情關聯性比較強(需求拆分不合理)。

這兩個問題都是須要及時的暴露出來而後去解決.

在製品限制的一個重要做用就是及時的發現問題，找到問題的根源去解決和改進。每列對應的限制以下(0)爲不限制,初始設定每一個人同時能夠作兩件事情,根據團隊實際使用狀況能夠作調整;限制以下:

需求池	就緒	開發	測試	待驗收	待發布	已關閉
0	0	開發人數x2X(是否拆分:是-2,否-1)	測試人數x2X(是否拆分:是-2,否-1)	0	0	0

卡片設計

用戶情景

字段

1. ID
2. 指派人
3. 故事點
4. 標記
5. 區域路徑
6. 優先級
7. 狀態更新日期

樣式

前一日新增的需求(米色)

1. 迭代日期=@當前迭代
2. 建立日期≥@今天-1

3天無進展的工做項(橙色)

迭代日期=當前迭代
更改日期≤當前日期-3
狀態 ≠ 新建
板列 ≠ 待發布

Bug

字段

1. ID
2. 指派人
3. 故事點
4. 標記
5. 區域路徑
6. 嚴重級別
7. 狀態更新日期

樣式

3天未解決的BUG(黃色)

1. 激活日期≤當前日期-3
2. 狀態≠（新建，已關閉）

2個月前提交未關閉的BUG(紅色)

1. 建立日期≤當前-60
2. 狀態≠已關閉

當前未關閉的嚴重BUG(紫色)

1. 迭代日期=當前迭代
2. 狀態≠已關閉
3. 嚴重級別=嚴重

任務

字段

1. ID
2. 指派人
3. 剩餘工做
4. 標記
5. 活動
6. 初始估計

樣式

初始估計超過8小時(紅色)

1. 初始估計>8