整个敏捷开发里，最核心的就是看板机制。所谓的看板机制，就是将团队内的各个角色成员，安排在类似一条生产线上，各司其职，通力合作。

 整个看板的原型，有两个重要的点：1.To Do 起始点 2.Done 终点。在两点之间夹杂着任务的生成过程。

To Do

可以称为待办清单，但在敏捷开发里，一般称之为 积压板。注意，这里的To Do 里的内容，基本上是已经确定要处理的事，和需求清单有一定区别。

需求，往往是使用级别的事务。而且很多需求需要经过分析后，转换为若干待办事项。比如：“想要一辆自动驾驶的车”，这是一个需求，但是经过分析，可能会拆分为，“自动驾驶系统实现”，“车架生产”这两项工作项。而且，整个敏捷团队开发就是为了快速小步迭代，有时一个需求拆分出的多个工作项，为了实现快速迭代，不一定会将这些工作项统一放到一个迭代中。

积压板区域，最大的作用就是告诉团队成员，“我们还有多少工作没做”。

Done

这是个事务完结区，主要是开发完成的工作项（待办清单内容进入实际开发中，就称为工作项），基本上都是已上线的工作项。

之所以有这个区域，一是因为敏捷开发时，有些功能是灰度上线——有可能带着不经意察觉的问题，万一上线的出了大问题，可以调度工作项。另一原因就是，能够告知整个团队，此次迭代完成了哪些工作项，能够在后期团队项目总结时，有根可寻。

Doing

在起止点之间的部分，就是生成过程了，也就是开发过程。

可以用泳道来标识各个状态。而泳道是由团队角色决定的，常规开发团队中有 产品、开发以及测试。那中间的状态泳道往往是由这三类角色所需要的状态构成。

有了看板原型，我们可以看到各个整个团队成员的工作，能够了解每个人工作量，大致预览项目进度。

但是撑起整个看板的，不是看板本身，而是工作项。

如果说，看板是整个敏捷开发的核心，核心的核心就是工作项。工作项是大家实际的工作指导，以及实际开发过程的数据载体。从一开始界定要实现的目标，就记录在工作项上，再到中间的开发过程都应反馈在工作项本身，以及后面所暴露的开发缺陷，一个工作项都可以承载。

既然看板是工作项的展示容器，工作项的状态就等于看板的泳道。一个工作项在正常进行中，是从头跑到尾，但是难免有些工作项因为种种原因被关闭了，所以此时会有一个回收站来收集这些工作项。

这些泳道中，最核心的就是三条 产品（设计分析）、开发、测试。

表设计部分

看板只是个容器，看板所承载的工作项才是具体的业务，虽然说工作项可以存在各个泳道，但是从数据存储上，它其实就是一张表，通过不同的字段来区分,例如，工作项的时间 虽然有九个日期，因为整体业务表现都是依序进行的，所以除了两个完结时间点，其他的从新建（积压板状态）直到测试完成 采用的是 ADate、BDate…GDate,关闭采用的是ClDate/发布则是用RelDate。

而对于工时，这张表就是工作项表的细表，因为一个工作项可能产生多个工时，也就会产生多行工时数据。

To be Continued

当然，以上所述这些，都是一些指导性原则，任何东西都有个性化的一面，就像加勒比海盗里说的那样

法典只不过是一些指导，它并不是必须遵守的规定