列

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

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

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

泳道

按照顺序从上往下依次为

1. 插入事件:紧急发布的需求,Bug或者急需解决的事项
2. Bug:需求缺陷或者数据缺陷
3. 需求:只放当前迭代的需求

在制品限制

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

1. 某一个事情出现阻碍停止(需要其他人员协助解决)。
2. 两个事情关联性比较强(需求拆分不合理)。

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

在制品限制的一个重要作用就是及时的发现问题，找到问题的根源去解决和改进。每列对应的限制如下(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