project 敏捷转型行动笔记：看板搭建

一个采用瀑布模型开发的传统团队进行敏捷转型应该从哪里开始？怎么开始？除了前期的相关准备工作（包括敏捷松土、导入敏捷培训、价值流分析等等），在我的实践经验中，我认为最好的做法是直接从看板开始。将工作中的各项事情搬到看板上，让事情在团队内充分可见，有利于更好地协作。
其实在前面的价值流分析工作中，就已经涉及到看板的搭建问题，今天这里针对看板方法的起源、建模及相关核心实践等简单聊聊。

1、看板方法的起源

看板方法（Kanban）源自丰田的“及时生产”（JIT=just-in-time）系统。尽管生产软件是一项创造性活动，与批量生产汽车有所不同，但是生产线管理背后所蕴含的原理仍然适用。看板方法是用于高效管理软件开发流程的新技术。
看板定义了一个增量和渐进的改变技术开发和组织运营的方法。它的核心机制是限制在制品数量的拉动系统，通过它暴露系统运作或流程中的问题，并激发协作以改进系统。

2、看板方法建模

针对看板方法的建模，归结起来，主要有以下几个步骤：
（1）进行输入分析，包括分析工作项类型及其对应规则，识别服务分类及其对应规则；
（2）分析输入和交付节奏，包括分析交付的协调和事务成本，分析更合适的发布节奏，比如1个月发布一次、2周发布一次等等，明确合理的输入和优先级排序节奏等等；
（3）识别主要工作项的价值流，这里面涉及的方法也是前面提到的价值流分析的重要部分，包括活动、频率、工作项及粒度、角色及人数、完成的定义、WIP、周期时间等等；
（4）设计初始的虚拟看板墙，通过看板墙的方式尝试引入拉取的方式开展工作；
（5）利用看板墙识别约束，包括共享资源的约束、技能方面的约束、人力资源方面的约束、产能配比方面的约束等等。

3、看板方法的核心实践

看板方法有六大核心实践，分别是可视化工作项及流程、度量和管理流动、显示化规则、形成多层次反馈环、限制在制品数量（WIP）、协作式/实验式持续改进。

在进行看板实践的时候，可视化工作项和流程是基础，比如下图是我们在一个项目组中开始尝试将工作流程及全部工作项可视化到看板墙上，将各类待分析需求、分析中的需求、设计中的任务、开发中的任务、测试中的任务等等都写到便签纸并贴到对应的泳道和队列中。

同时，结合项目组实际工作，增设了应急通道，用于处理各类紧急需求和问题。

项目组尝试举行了每日站会，并结合几次站会的相关情况，及时做了相应的总结：
（1）好的做法
a、团队成员第一次围着看板墙一起回顾和计划；
b、每一个成员能相对主动地对自己的工作进行陈述；
c、明确了站立会议的规则；
d、对任务卡片进行了改进；
e、在看板墙上对开发成员进行了区域划分，便于一眼判断出是谁的任务。
（2）需要改进的地方
a、看板墙缺少了deployment环节（阶段），需要加上，特别是有一些任务是开发直接完成并需要现场配合发布和验证的，这样才有可能做到端到端；
b、目前对于开发成员进行了区域划分，其实可以进一步改进，毕竟对于紧急任务走到应急通道时又如何快速识别出来是谁在负责呢；
c、目前的在制品数量是没有限制的，后面随着任务的增多，需要适时考虑；
d、看板墙上有关设计的内容其实应该还有不少已做设计但未开发的，也需要放到看板墙上，不要遗漏；
e、应急通道上的问题似乎放了不少，要考虑一下是否合理，同时也需要考虑相应的优先级，大部分都是紧急问题便会成为没有紧急可言；
f、可以在渐进改进的过程中，考虑利用excel等形式绘制累积流图，这方面建议APT小组协同推进。
g、要让团队成员主动参与，主动发言。
另一方面，对工作过程和结果的度量及流动的管理也非常重要，在迭代开启后，采用燃尽图、累积流图等方式进行统计分析，其中几个迭代的燃尽图示意如下图所示：

后续就是一系列的实践及持续改进。总体来说，看板方法的实践，要充分结合实际情况，从现状开始，同时团队成员要对追求渐进式改进达成共识。在进行看板方法实践的时候，可以尊重已有的角色、职责及职位名称，这样有利于快速地、更小阻碍地实践看板方法，并看到一些效果，从而有利于正向驱动团队持续学习、持续改进。

在看板方法有关的书籍方面，个人推荐以下两本书籍：《看板方法-科技企业渐进变革成功之道》、《精益产品开发》。