从方法论的海洋到方法论的灯塔

敏捷方法有40多种，可以称为方法论的海洋。学海无涯，对于沉浸其中的人不会觉得有什么，而对于受众，敬而远之恐怕只能算作一种正常的态度。

我们需要找到方法论的灯塔，即其中简单的可理解的直指本质的东西，亦即其目的和逻辑。

敏捷的目的和敏捷方法论（Scrum和Kanban）的三个层次

大野耐一说：“丰田生产方式就是赚钱的工业工程。”敏捷的目的也是赚钱，也应该成为一种“直接涉及经营管理的全公司性生产技术”（大野耐一《丰田生产方式》）。

而敏捷的逻辑，可以提炼为敏捷方法论（Scrum和Kanban）的三个层次

• 可视化价值流

• 流动管理

• 持续改进

以城市交通系统的隐喻来个感性理解

在城市交通系统中，可视化至少有两个方面，一是交管部门能了解整体交通态势，二是每一辆车的司机看到他需要看到的东西。交管部门需要预测节假日等事件对交通的影响，这也是可视化的一部分。司机需要观察视野范围内的情况，以便应对。借助导航，司机还可了解更远处的情况。这些都是可视化。可视化做得不好，比如路况信息不透明，或者司机注意力不集中，都会给整个交通系统的能效带来问题。

车是拿来开的，这个就是流动。影响流动的因素，包括流量和波动。一条道路有一个保持流动性的最大容量，超过这个容量就会塞车。在这个保持流动性的最大容量之内，也会有引发整体速度下降的因素，比如加塞、频繁变道、突然刹车等，这些是波动因素。如果能够识别和控制流量，管理好波动，就天下无塞了。

道路系统的持续改进，主要是交管部门的责任。在深圳湾到香港这有段路上，提前一段就会连续出现前方多少米减速的提示。而在湛江往海安路段，则有多处限速突然从70降到40这种，等着你的只有摄像头。香港的车速整体很快，但事故也不一定很多。这些例子中，我们可以看出持续改进的空间。作为司机来说，遵守交通规则本身就是一种持续改进，相对于不遵守的情况来说。

敏捷方法论（Scrum和Kanban）的三个层次

一、可视化价值流

解决的问题是，“好混乱啊。”

跳出细节，Scrum和Kanban的区别是很微小的。可视化价值流是Scrum和Kanban的第一个层次。

在Scrum中，价值流被分为Discovery和Delivery两段。Discovery的成果是一个准备好的产品列表。而在Delivery侧，为了强化无角色之分，价值流的状态通常被简洁优雅地表述为To do/Doing/Done。

在Kanban当中，Discovery和Delivery被串接为一条流。在Discovery侧，需求可跨越多个状态，比如需求收到、需求双方理解一致、需求进入开发队列等。在Delivery侧，不介意分为开发、测试等阶段。

可视化价值流，可以提炼出两个原则：

• 从物的角度的最小封装单元

• 从人的角度的职责清晰

最小封装单元指的是如何封装我们的关注对象。任其小化，就变成一堆沙子，任其大化，就变成一块巨石。大致有这么几方面：

• 从可视化这个角度来说，Scrum和Kanban的区别是，Scrum没有把业务人员的工作可视化，而是把产品列表作为业务人员的输出作为一个单元封装出来。所以从这一点出发，用哪一种方式，取决于是否需要把业务人员的工作可视化出来。

• 颗粒度问题，模板问题，用户故事是解决方案。

• 层级问题，可以采用Theme/Epic/Story/Task的层级。

• 还有一个问题是关于可视化的单位，任务个数和故事点等都是可用的选项。

• 可视化的物理板也可以分层嵌套。

职责清晰，指的是在必要的时间系统中必要的人能以必要的方法开始必要的工作。

• 分团队问题：事情多到超出一个团队的容量，在价值流中的哪个状态开始分解为小团队呢？是从业务侧开始就能把工作解耦到一个个开发团队，还是到方案阶段才能分？

• 上下游传递的机制：保证中间球不会掉在地上。

• 团队内人员工作的均衡，要能方便看出来。

看得清的理想状态是，系统中每个人都能看到他刚好需要看到的信息，这是我们在设计可视化时的最高指导原则。被自己的雷炸死是可悲的。看得清是管理的第一步，第二步是让事情流动起来。

从混沌到有序，抵制熵增，从可视化开始。而这，需要有系统地设计。从此就人猿相揖别了。

可视化的最后一问：还有什么没有可视化？可视化的够不够清晰（对每一块板的使用者而言）？

二、管理流动

解决的问题是，“不出活儿。”

物有四种状态：加工、检查、运输、停滞。加工的状态是流动，其他三种状态都是不流动。不流动也叫浪费，浪费是系统低能效的根源。

流动的另一个反义词是调度。甘特图是调度的一种表征。调度给人一种可控的假象，调度中蕴藏着浪费。

Scrum和Kanban都支持限制在制品（WIP）。Scrum的在制品限制就是迭代列表，而看板的在制品限制是每道工序可以同时并行的工作条目。在制品限制的目的是消除浪费。

没有规则控制的流动是低质无效的流动。需要显式化规则。限制在制品本身就是一条规则。Scrum中的DoR和DoD都是规则。Kanban中，每道工序向下道工序的迁移标准，需要提炼出规则。

Scrum中的各个事件，是对规则的贯彻和流动的管理。精化会是使产品列表达到DoR的标准，计划会是使迭代列表达到可承诺的标准，每日站会是监测流动并达到DoD的标准。

对流动监测有两个重要方面是：趋势和风险。趋势可以幻化为速率、周期时间等。风险则是阻碍流动的因素。

对于团队来说，首要的是以严密的纪律监测朝向目标和理想状态的趋势。

管理者的重点，应当从调度转移到帮助团队排除障碍，加速流动。流动的可是滚滚黄金（伯乐《金矿》）。解决问题，是一种职责，不是一种特权。

菩萨畏因，凡夫畏果。解除不流动的根源，而不是打鞭子。

管理流动的最后一问：流的正常吗（当然前提是有正常的标准）？

三、持续改善

我们可以从流动管理的延伸来谈持续改善。能够持续解决日常工作中的障碍，就已经是持续改善。持续改善，是最重要的学习。一个持续改善的组织，就是学习型组织。

心理安全很重要。持续改善，最重要是组织上下开诚布公平等交流的氛围。大野耐一说：员工投入宝贵的时间给公司，如果只利用到他一双手，就太亏了。丰田做的事很简单，就是给员工发挥智慧的空间。

在形态上，Scrum的评审会和回顾会都是改进的好时机。回顾会议的形式千差万别，最重要是产生持续改进的行动（Action）。

现实中还有一个障碍是，问题不能解决不能改变的集习。这时候我们更需要的，是对该问题的一个上下一致的说法。

持续改善最后一问：我们这个迭代比上个迭代有进步吗？不一定从指标来看。可以列举进步事项。

结语

Scrum已经25年了，敏捷也已经17年了，但要实施仍有鸿沟。组织的认知就是这个鸿沟。有生而知之，有学而知之，有困而知之。当一切都不灵的时候，你所要做的就是等待时机。一切都是最好的安排，随时都是最好的时候。