在【Kanban】简介及快速实施中，我们已经学习了如何在团队里快速开展Kanban方法，并推荐大家在一个大的白板墙上，画出了自己的Kanban流程并贴上了工作便签。其实到这里，大家已经在遵守Kanban方法的第一大原则了，那就是可视化。今天将围绕这个原则，展开更加详细的说明，在这个过程中，你可能还需要修正Kanban流程和工作便签，使它们更加符合可视化原则。
一点说明：
为了更好的兼容Scrum，我会在以后的文章中统一使用Scrum的术语。
Scrum中的用户故事(User Story)，大家可以理解为传统项目开发中的功能/任务；
Scrum中的任务(Task)，大家可以理解为传统项目开发中的子任务；
Scrum中的Scrum Master(SM)，大家可以理解为传统项目开发中的项目经理或团队Leader；
Scrum中的Product Owner(PO)，大家可以理解为传统项目开发中的产品经理；
1. 流程可视化
这一部分的内容在上一篇文章关于快速实施Kanban的方法中已经略有涉及。这里再进一步做个详细说明。
1.1. Kanban墙
Kanban墙的基础就是一张白板或者一块干净的墙面，通过在上面添加列和便签的方式来可视化工作流程和工作进展。Kanban墙是需要经常更新的，从而使每个人都能看到最新的信息并据此有所行动。
Kanban墙的创建应该是由整个团队一起设计完成的，而不应该是由SM决定，这样才能够达成一个共识的规则和流程。
1.2. 列
我们通过列来定义工作中的各个环节，但是并不是所有的工作项都有相同的流程，有些工作项可能会跳过一些环节，例如测试工作就没有开发节点。所以在列的定义上我们要花一些时间。我们可以通过对列名的修改来让一个工作流程能够容纳更多的工作项。例如当把一个列名叫做“测试”的时候，可能是因为我们只想到了对代码的测试，这样就使得像“测试用例评审”这类工作，不太适合放到这个列了，这时候可以考虑把列名改为“检查”或“验证”这样更加抽象的名词。
1.3. 队列
队列，例如上一篇中的“开发”、“待测”等列中的便签列表，就是队列，它可以帮助我们管理工作交接，从而让工作更加平稳的流动。同时也起到一个信号系统的作用，当开发人员把工作移动到开发完成后，就发出了一个信号，指示测试人员，可以从这里拿到工作项进行测试了。另外队列也有利于帮助我们以后发现Kanban瓶颈。
2. 规则可视化
我们已经通过Kanban墙上的列实现了可视化，但是工作项完成到什么程度才能流转到下一个环节，这个也是需要提前约定好的。在Scrum中，开始一个Sprint有DoR（Definition of Ready，准备就绪）的要求，用户故事有AC（Acceptance Criteria，验收标准）的要求，测试前有TC（Test Case，测试用例）的要求等等，这些要求都是在限定一个流程是否可进入下一流程，如果每个列的流转没有这些规则的限制，我们就无法保证最终的交付质量了。
但是这些要求如果都贴到物理Kanban上，这些内容会非常多，写起来也会很累人，所以我们公司一般是放到Jira上的，大家在迭代计划会、开发、测试、验收的过程中，都是对照Jira来做的。
3. 工作内容可视化
工作项便签用来将我们的工作内容可视化，工作项便签都要显示哪些内容呢？下图是一个例子，展示了在工作项便签上描述的各种信息，这里并不是要求大家完全按照这个格式去做，只是说明哪些信息在卡片上是可以体现的。在实际的应用中，团队可以按照自己的需要定制适合自己的卡片风格。
说明：
- 引入软件系统编号，如果你的需求都在一个软件系统里管理（如Jira、禅道等），那么可以在卡片上添加故事编号和任务标好建立关联；
- 工作量，表示了这个完成这个工作项所需要的大致工作量
故事点数，熟悉Scrum的朋友应该对点数不陌生，它是对一个工作项的预估值。 - 我们公司会统计一个工作项在某列停留的时间，以便对工作效率提出改进。所以每天晨会的时候，会要求大家在自己的工作卡片上画上一个对号作为记录。
注意：研发和测试的对号要区分不同的颜色。 - SM同时要记录一个故事的开始和结束日期，以便统计每个故事的耗时，这个统计对后期的工作效率提升也会给出很好的指标参考。
- 当任务超过一天没有完成，SM需要及时发现它。这时候可以通过添加彩色标签的形式，提示大家应及早关注此问题。如果当事人要求，SM应该及时帮助当事人协调处理这个问题（排除团队障碍是SM的职责）。
