你好，我是石雪峰。

提到敏捷开发方法，你可能会情不自禁地联想到双周迭代、每日站会、需求拆分等。的确，作为一种快速灵活、拥抱变化的研发模式，敏捷的价值已经得到了行业的普遍认可。但是，即便敏捷宣言已经发表了将近 20 个年头，很多公司依然挣扎在敏捷转型的道路上，各种转型失败的案例比比皆是。

我曾经就见过一家公司，一度在大规模推行敏捷。但是，这家公司很多所谓的敏捷教练都是项目经理兼任的，他们的思维和做事习惯还是项目制的方式。即便每天把团队站会开得有模有样，看板摆得到处都是，但从产品的交付结果来看，并没有什么显著的变化。没过多久，由于组织架构的调整，轰轰烈烈的敏捷转型项目就不了了之了。

这家公司虽然表面上采用了业界流行的敏捷实践，也引入了敏捷工具，但是团队并没有对敏捷的价值达成共识，团队领导兼任 Scrum Master，好好的站会变成了每日工作汇报会。甚至在敏捷项目复盘会上，领导还宣称：“敏捷就是要干掉变化，我们的目标就是保证团队按照计划进行。”这种“貌合神离”的敏捷，并不能帮助企业达到灵活响应变化、快速交付价值的预期效果。

作为一种最广泛的敏捷框架，Scrum 的很多理念和实践都深入人心，比如很多时候，迭代式开发几乎等同于跟敏捷开发。但是，Scrum 对于角色的定义并不容易理解，在推行 Scrum 的时候，如果涉及到组织变革，就会举步维艰。

实际上，企业的敏捷转型并没有一条通用的路径，所用的方法也没有一定之规。今天，我就跟你聊聊另外一种主流的敏捷开发方法——精益看板。与 Scrum 相比，看板方法的渐进式改变过程更加容易被团队接受。我之前所在的团队通过长期实践看板方法，不仅使产品交付更加顺畅，还提升了团队的整体能力。

那么，这个神奇的精益看板是怎么回事呢？

如果你之前没听说过精益看板，还是很有必要简单了解下它的背景的。其实，“看板”是一个日语词汇，泛指日常生活中随处可见的广告牌。而在生产制造系统中，看板作为一种信号卡，主要用于传递信息。很多人认为看板是丰田公司首创的，其实并非如此，比如在我之前所在的尼康公司的生产制造车间里，看板同样大量存在。

当然，看板之所以能广为人知，还是离不开丰田生产系统。《改变世界的机器》一书首次提到了著名的丰田准时化生产系统，而看板正是其中的核心工具。

简单来说，看板系统是一种拉动式的生产方式。区别于以往的大规模批量生产，看板采用按需生产的方式。也就是说，下游环节会在需要的时候，通过看板通知上游环节需要生产的工件和数量，然后上游再启动生产工作。

说白了，所谓拉动式生产，就是从后端消费者的需求出发，向前推导，需要什么就生产什么，而不是生产出来一大堆没人要的东西，从而达到减低库存、加速半成品流动和灵活响应变化的目的。我你分享一张有关丰田生产方式的图片，它演示了整个丰田生产方式的运作过程，你可以参考一下。

图片来源：https://www.toyota-europe.com/world-of-toyota/this-is-toyota/toyota-production-system

软件开发中的看板方法，借鉴了丰田生产系统的精益思想，同样以限制在制品数量、加快价值流动为核心理念。也就是说，如果没有在制品限制的拉动系统，只能说是一个可视化系统，而不是看板系统，这一点非常重要。

比如，很多团队都在使用 Jira，并在 Jira 中建立了覆盖各个开发阶段的看板，围绕它进行协作，这就是一个典型的可视化板，而非看板。那么，为什么对于看板方法而言，约束在制品数量如此重要呢？

就像刚才提到的，加快价值流动是精益看板的核心。在软件开发中，这个价值可能是一个新功能，也可能是缺陷修复，体验优化。根据利特尔法则，我们知道：平均吞吐率 = 在制品数量 / 平均前置时间。其中，在制品数量就是当前团队并行处理的工作事项的数量。关于前置时间，你应该并不陌生，作为衡量 DevOps 产出效果的核心指标，它代表了从需求交付开发开始到上线发布这段时间的长度。

比如，1 个加油站只有 1 台加油设备，每辆车平均加油时长是 5 分钟，如果有 10 辆车在等待，那么前置时长就是 50 分钟。

但是，这只是在假设队列中的工作都是顺序依次执行的情况下，在实际的软件开发过程中。如果一个开发人员同时处理 10 件事情，那么在每一件事情上真正投入的时间绝不是 1/10。

还拿刚刚的例子来说，如果 1 台加油设备要给 10 辆车加油，这就意味着给每一辆车加油前后的动作都要重复一遍，比如取出加油枪、挪车等。这样一来，任务切换的成本会造成极大的资源消耗，导致最终加满一辆车的时长远远超过 5 分钟。

所以，在制品数量会影响前置时间，并行的任务数量越多，前置时间就会越长，也就是交付周期变长，这显然不是理想的状态。

不仅如此，前置时间还会影响交付质量，前置时间增长，则质量下降。这并不难理解。比如，随着工作数量的增多，复杂性也在增加，多任务切换总会导致失误。另外，人的记性没那么可靠。对于一个需求，刚开始跟产品沟通的时候就是最清晰的，但是过了一段时间就有点想不起来是怎么回事了。这个时候，如果按照自己的想法来做，很有可能因为对需求的理解不到位，最终带来大量的返工。

再进一步展开来看的话，软件开发工作总是伴随着各种变化和意外。如果交付周期比需求变化周期更长，那就意味着紧急任务增多。比如老板发现一个线上缺陷，必须高优先级修复，类似的紧急任务增多，就会导致在制品数量进一步增多。这样一来，团队就陷入了一个向下螺旋，这对团队的士气和交付预期都会造成非常不好的影响，以至于有些团队 90% 的精力都用来修复问题了，根本没时间交付需求和创新。

更加严重的问题是，这个时候，业务部门对 IT 部门的信任度就会直线下降。业务部门往往会想：“既然无法预测需求的交付实践，那好吧，我只能一次性压给你一大堆需求。”这样一来，就进一步导致了在制品数量的上升。

可见，一个小小的在制品数量，牵动的是整个研发团队的信心。我把刚刚提到的连环关系整理了一下，如下图所示：

当然，针对刚才加油站的问题，你可能会说：“多加几台加油设备，不就完了吗？何必依赖同一台机器呢？”的确，当并行任务过多的时候，适当增加人员有助于缓解这个问题，但是前置时间的缩短是有上限的。这就好比 10 个人干一个月的事情，给你 100 个人 3 天做完，这就是软件工程管理的经典图书《人月神话》所讨论的故事了，我就不赘述了。这里你只需要知道，随着人数的增多，人与人之间的沟通成本会呈指数级上升。而且，从短期来看，由于内部培训、适应环境等因素，新人的加入甚至会拖慢原有的交付速度。

了解了精益看板的核心理念，以及约束在制品数量的重要性，也就掌握了看板实践的正确方向。那么，在团队中要如何开始一步步地实施精益看板方法呢？在实施的过程中，又有哪些常见的坑，以及应对措施呢？这正是我要重点跟你分享的问题。我把精益看板的实践方法分为了五个步骤。

  1. 第一步：可视化流程；
  2. 第二步：定义清晰的规则；
  3. 第三步：限制在制品数量；
  4. 第四步：管理工作流程；
  5. 第五步：建立反馈和持续改进。

今天，我先给你介绍精益看板实践方法的第一步：可视化流程。在下一讲中，我会继续跟你聊聊剩余的四步实践。

第一步：可视化流程

在看板方法中，提高价值的流动效率，快速交付用户价值是核心原则，所以第 1 步就是要梳理价值交付流程，通过对现有流程的建模，让流程变得可视化。关于价值流建模的话题，在专栏第 5 讲中我已经介绍过了，如果你不记得了，别忘记回去复习一下。

其实，在组织内部，无论采用什么研发模式，组织结构是怎样的，价值交付的流程一直都是存在的。所以，在最开始，我们只需要忠实客观地把这个现有流程呈现出来就可以了，而无需对现有流程进行优化和调整。也正因为如此，看板方法的引入初期给组织带来的冲击相对较小，不会因为剧烈变革引起组织的强烈不适甚至是反弹。所以，看板方法是一种相对温和的渐进式改进方法。

接下来，就可以根据价值流定义看板了。看板的设计没有一个标准样式，因为每个组织的价值流都不相同。对于刚刚上手看板方法的团队来说，看板的主要构成元素可以简单概括成“一列一行”。

1. 一列。

这是指看板的竖向队列，是按照价值流转的各个主要阶段进行划分的，比如常见的需求、开发、测试、发布等。对识别出来的每一列进一步可以划分成“进行中”和“已完成”两种状态，这也是精益看板拉动式生产的一个显著特征。对于列的划分粒度可以很细，比如开发阶段可以进一步细分成设计、编码、自测、评审、提测等环节，或者就作为一个单独的开发环节存在。划分的标准主要有两点：

  1. 是否构成一个独立的环节。比如对于前后端分离的开发来说，前端开发和后端开发就是两个独立的环节，一般由不同的角色负责，这种就比较适合独立阶段。
  2. 是否存在状态的流转和移交。看板是驱动上下游协同的信号卡，所以，我们需要重点关注存在上下游交付和评审的环节，这也是提示交付吞吐率和前置时长的关键节点。

除此之外，看板的设计需要定义明确的起点和终点。对于精益看板来说，覆盖端到端的完整价值交付环节是比较理想的状态。但实际上，在刚开始推行看板方法的时候，由于组织架构、团队分工等多种因素，只能在力所能及的局部环节建立看板，比如开发测试环节，这并不是什么大问题，可以在局部优化产出效果之后，再尝试向前或向后延伸。

另外，即便看板可以覆盖端到端的完整流程，各个主要阶段的关注点各不相同，所以，也会采用看板分类分级的方式。对于开发看板来说，起点一般是需求准备就绪，也就是说，需求经过分析评审设计并同研发团队沟通一致准备进入开发的状态，终点可以是提测或者发布状态。流程的起点和终点同样要体现在看板设计中，以表示在局部环节的完整工作流程。

2. 一行。

这是指看板横向的泳道。泳道用于需求与需求之间划清界限，尤其在使用物理看板的时候，经常会因为便利贴贴的位置随意等原因导致混乱，而定义泳道就可以很好地解决这个问题。比如，高速公路上都画有不同的行车道，这样车辆就可以在各自的车道内行驶。

当然，泳道的意义不只如此。泳道还可以按照不同维度划分。比如，有的看板设计中会加入紧急通道，用于满足紧急需求的插入。另外，非业务类的技术改进需求，也可以在独立泳道中进行。对于前后端分离的项目来说，一个需求会拆分成前端任务和后端任务，只有当前后端任务都完成之后才能进行验收。这时，就可以把前后端任务放在同一个泳道中，从而体现需求和任务的关联关系，以及任务与任务之间的依赖关系，快速识别当前阻塞交付的瓶颈点。

当然，看板的设计没有一定之规。在我们团队的看板中，往往还有挂起类需求区域、缺陷区域，以及技术攻关类区域等，用于管理特定的问题类型。比如对于长期挂起的需求，在一定时间之后就可以从看板中移除，毕竟，如果是几个月都没有进入任务队列的需求，可能就不是真正的需求，这些可以根据团队的实际情况灵活安排。如果你在使用 Jira 这样的工具，虽然没有区域的概念，但是可以通过泳道来实现，比如按照史诗任务维度区分泳道，然后新建对应区域的史诗任务就可以啦。

总结

今天，我给你介绍了敏捷常用的两种框架 Scrum 和看板。看板来源于丰田生产系统，以拉动式生产为最典型的特征。关注价值流动，加速价值流动是精益看板的核心，限制在制品数量就是核心实践，因为，在制品数量会直接影响团队的交付周期和产品质量，甚至还会影响团队之间的信任，导致团队进入向下螺旋。

在团队中实践精益看板，可以分为五个步骤，分别是：可视化流程、定义清晰的规则、限制在制品数量、管理工作流程和建立反馈并持续改进。今天我给你介绍了第一个步骤，也就是可视化流程，通过价值流分析将团队的交付路径可视化，建立起看板的主要结构，那么接下来就是开始应用看板了。下一讲，我会跟你聊聊其余的四个步骤，敬请期待。

思考题

最后，给你留一个思考题：你所在的公司是否也在实践敏捷呢？在敏捷转型的过程中，你遇到的最大问题、踩过的最大的坑是什么呢？

欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。