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