TFS看板的设计

列

产品开发的整个流程如下图,将流程配置到看板的列：

需求池-->就绪-->开发-->测试-->待验收 -->待发布 -->已关闭

一般将Bug和需求放在一块看版上处理,工作项有自己单独的状态,可以通过模板设置调整，但是不推荐这么做(配置难度较大，并且自带的比较通用)，所以这里工作项需要对应看板列，这样在看板中操作时候可以利用流程做一些默认数据的填写(例如指派给，时间等等),看板列和状态对应关系如下:

类型\列	需求池	就绪	开发	测试	待验收	待发布	已关闭
需求	新建	新建	活动	已解决	已解决	已解决	已关闭
Bug	新建	新建	活动	已解决	已解决	已解决	已关闭

泳道

按照顺序从上往下依次为

插入事件:紧急发布的需求,Bug或者急需解决的事项

Bug:需求缺陷或者数据缺陷

需求:只放当前迭代的需求

在制品限制

无论开发还是测试最好是一次之做一件事情。如果同时处理两件，那么一般是两种情况

某一个事情出现阻碍停止(需要其他人员协助解决)。

两个事情关联性比较强(需求拆分不合理)。

这两个问题都是需要及时的暴露出来然后去解决.

在制品限制的一个重要作用就是及时的发现问题，找到问题的根源去解决和改进。每列对应的限制如下(0)为不限制,初始设定每个人同时可以做两件事情,根据团队实际使用情况可以做调整;限制如下:

需求池	就绪	开发	测试	待验收	待发布	已关闭
0	0	开发人数x2X(是否拆分:是-2,否-1)	测试人数x2X(是否拆分:是-2,否-1)	0	0	0

卡片设计

用户情景

字段

ID

指派人

故事点

标记

区域路径

优先级

状态更新日期

样式

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

迭代日期=@当前迭代

创建日期≥@今天-1

3天无进展的工作项(橙色)

迭代日期=当前迭代

更改日期≤当前日期-3

状态 ≠ 新建

板列 ≠ 待发布

Bug

字段

ID

指派人

故事点

标记

区域路径

严重级别

状态更新日期

样式

3天未解决的BUG(黄色)

激活日期≤当前日期-3

状态≠（新建，已关闭）

2个月前提交未关闭的BUG(红色)

创建日期≤当前-60

状态≠已关闭

当前未关闭的严重BUG(紫色)

迭代日期=当前迭代

状态≠已关闭

严重级别=严重

任务

字段

ID

指派人

剩余工作

标记

活动

初始估计

样式

初始估计超过8小时(红色)

初始估计>8