本文笔者依据工作中项目实践的所思所想，并结合案例等分享了团队看板使用中需要注意的一些问题，供大家一同参考和学习。

整个敏捷开发软件里，若是用于敏捷团队管理，最核心的就是看板机制。

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

看板一词来源于，日本的丰田制造。最早为了解决，生产机器之间的协作生产问题，发明了“kanban”：B机器在空闲时，发出一张“kanban”卡，A机器接收到此卡就进行推送任务。

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

To Do

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

需求，往往是使用级别的事务。而且很多需求需要经过分析后，转换为若干待办事项。

比如：“想要一辆自动驾驶的车”，这是一个需求，但是经过分析，可能会拆分为，“自动驾驶系统实现”，“车架生产”这两项工作项。

而且，整个敏捷团队开发就是为了快速小步迭代，有时一个需求拆分出的多个工作项，为了实现快速迭代，不一定会将这些工作项统一放到一个迭代中。

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

Done

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

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

Doing

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

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

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

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

如果说，看板是整个敏捷开发的核心，核心的核心就是工作项。

敏捷开发的核心思想中，为了快一开始就抓住最核心的功能，从小画大，由内向外，逐级构建，就像是滚雪球一样。

所以，为了滚好这个雪球，一般会把一整个项目，拆分成多个冲刺（或叫迭代，二者有一定区别，下次再分析）

一个项目，可能被拆分为多个冲刺，每个冲刺里的需求，被拆分为多个工作项。

项目>冲刺>工作项。（需求可被直接存放在项目里，也可以在冲刺里）

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

而看板只是工作项的展示容器，工作项的状态就等于看板的泳道。而工作项的状态，就是由实际业务角色决定的，这也就是上面提到的“泳道是由团队角色决定”。

一个工作项从头跑到尾，状态的不断变化，就体现在了“生产过程”的看板上，也使此看板有了具体的使用意义——以丰富的方式展现团队的进度，利于站立会召开，以及团队协作的信息交流。

使用场景

1. 为整个团队协作服务。能够在看板上，进行便捷化的操作，例如拖拽变更状态、快速编辑信息、分派人员等。
2. 为实际开发工作作为指导。明确团队成员每人每天要做的工作，整个团队的待办清单。
3. 项目进度的管理。整个看板，其实也是某一段冲刺的大进度条。开发团队每日的站立会议使用工具，项目经理的进度监控板。

本文由 @29号同学 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。