精益看板方法从理论到实战 （4）—— 显式化流程规则实践
本篇开始介绍看板方法的第二个实践——显式化流程规则，它是看板方法实践体系不可或缺的一部分，却也最容易被低估和忽略，而影响整个看板方法实施的效果。
本篇讨论的内容
团队运作离不开各类规则。如：需求的准入条件是什么；优先满足哪类需求；怎么应对紧急需求；移交给测试前，需求要达到怎样的质量标准；短期进度和长期质量冲突时，如何决策；多长时间进行一次需求排期，等等。这些正式或非正式的流程规则，在背后影响团队成员的行为和组织的绩效。
显式化规则为团队提供明确的决策依据，它最核心的要求是：团队成员对流程规则形成一致的理解和承诺，并真正“拥有”这些规则。
显式化规则的意义在于组织、明确流程规则，并让团队一致理解、承诺和拥有这些流程规则
如上图所示，我把显式化流程规则分为三个步骤，分别是：1）组织和明确流程规则：也就是按照价值流动和团队协作有序的组织和明晰流程规则；2）团队共同拥有流程规则：通过流程规则赋权团队，形成更多团队自主协作和决策；3）持续改进流程规则：以显式的流程规则为改进的基础，并将改进落实到其中。接下来我们将逐一介绍这三个步骤。
4.1 组织和明确流程规则
流程规则种类不同，有些是正式定义的，有一些则隐含在决策过程背后。它们散布在不同地方，更好地组织能方便团队成员理解和应用，以及发现不足。为此，我把流程规则归为三类：
第一：价值流转规则。它指的是价值项——如用户需求——从一个阶段进入下一阶段所要满足的标准。
第二：周期性事件相关的规则。它指的是和团队运作中定期事件——如计划会议——相关的规则。
第三：其它协作规则。它主要指与团队日常协作和运作相关的规则。
4.1.1 显式化价值流转规则
“价值流”是组织价值流转规则的自然线索。看板方法的第一个实践——可视化价值流动——为组织流程规则提供了极大的便利。如下图所示，黄色箭头框内标记的内容是价值进入某个阶段所必须达到的标准。比如：需求可以开始分析的接收标准；需求进入就绪的标准；代码提交和任务完成的标准；功能转测试的标准；功能提交验收的标准；需求发布的标准等等。
按价值流组织起来的价值流转规则
按价值流组织流程规则，更方便团队记忆、理解和应用这些规则。但，该如何确定它们呢？让我们以需求进入就绪队列的标准为例来看一看。
正如计算机领域的术语所说“进去的是垃圾，出来的也会是垃圾（Garbage in, Garbage out）”，就绪队列作为开发团队的输入环节，其需求的质量直接关系后续环节的顺畅和最终的输出质量。在《精益开发实战》中，Henrik Kniberg把就绪队列的入口标准称为 “Definition of Ready (就绪准则)”，对应于Scrum中常用的“Definiiton of Done(完成准则)”。因上下文和团队成熟度不同，每个团队的就绪标准也不同，下图抽取了几个真实团队的共性，虚拟了一个对话来表述就绪标准的确定过程。
从目标出发，对话导出了就绪标准的四个原则
从这个对话中我们看到，一旦就绪，团队当然希望需求能够顺畅地向后流动，而不是问题不断，走走停停。需求进入就绪队列时，问题还没有发生，按项目管理的属于应该称作风险。这时，应尽可能识别和应对相关风险，具体包括：业务风险——需求是否清晰并理解一致；关联风险——识别对外依赖和得到承诺；技术风险——方案基本可行。同时需求要拆分的足够小，这样才能充分讨论，避免问题被隐藏。
某团队就绪标准的实例
以上的讨论确立了就绪标准的大的原则，适用于大部分团队。但针对特定团队还需要具体化，和补充团队特有的内容，上图是一个具体实例，它反应了团队特定的上下文，他们使用的方法和工具，以及当前的成熟度等。
4.1.2 显式化定期事件相关的流程规则
除价值流转外，定期事件也是组织规则的有效线索。如下图所示，看板方法中主要的定期事件有：每日站立会议、就绪队列填充会议、产品发布规划会议，以及定期的改进活动等。
与定期事件相关的流程规则
上图中时钟图标表示了这些看板中典型的定期事件，团队需要明确它们的节奏、内容及相关规则。以就绪队列填充为例，团队需求明确：1）事件的频率，如每周进行一次就绪队列填充；2）组织的形式，如：要完成哪些目标，和大致的流程；3）适用的规则，如怎么选择需求，一次选择多少需求。4）例外情况，如：正常的就绪队列填充节奏之外，出现紧急需求如何应对。
后面的文章讨论到管理工作流动和持续改进时，还会单独描述这几个事件。这里不再具体深入，但无论如何团队需要明确相关规则并达成一致理解。
4.1.3 显式化其它协作规则
价值流和定期事件能够组织起团队大部分的流程规则，但并不是全部。剩余没有覆盖的流程规则，主要与团队的日常运作和协作相关，统称为日常协作规则，如：看板墙的更新和可视化规则；在制品限制的规则；度量、反馈的收集和分析机制；改进行动的制定和跟踪规则等。我们在看板方法的其它实践中，还会讨论到这些规则。
团队并不需要事无巨细地明确所有的日常协作规则，一个可行的做法是，首先明确那些已知对团队运作和协作影响较大流程规则。在初始时有所遗漏是可以接受的。重要的是在运作中，通过结果的反馈来完善和调整它们。
最后，显式化并不是可视化，尽管团队可以选择将明确了的规则可视呈现在看板墙或其它地方。但，真正重要的是，团队对他们达成一致的理解和承诺，并基于它们协作和决策。
团队可以按照价值流转、定期事件以及日常协作来组织和明确流程规则。规则的明确并不需要一步到位，而是在应用中不断完善。
4.2 团队共同拥有规则
流程、规则的明确是第一步，这时他们还只是没有生命的信息。赋予流程规则生命力的是应用它们。为此，团队要达成对规则的一致理解，这样才能依据这些规则更加自主的决策和协作，在需要的地方能够即时做出决定，而不依赖于更上层或中央节点的控制。
团队才是流程规则的拥有者。例如，团队的规则是：“当前工作完成后，应该从就绪队列中选取靠前的需求开始开发”，开发人员就可以自主从就绪队列中拉入新的需求，而不需要其它人的安排；或者规则是：“站会上从右往左检视需求，当有Bug时优先解决Bug”。这时，如果解决Bug和开始新任务冲突，团队自然知道应该怎么决策，而不用等待批准；又如规则告诉我们：“所有进入待测试的需求，都应该按验收条件完成自测”，那么开发人员把需求移入待测队列时，就应该满足这一条件，而不需要谁来督促和检查。
理解并共同拥有规则，是对团队的赋权，是团队自我组织和高效运作的基础之一。同时规则是保障交付结果的手段，它让团队把产品的交付质量内建于流程的每个环节[1]，而非依赖于最后的检查。团队要对交付结果负责，就必须明确和理解规则，实施和改进规则，也唯有这样，团队才可能真正对结果负责。
团队拥有规则是对团队的赋权，也是在开发过程中内建质量的保障。
4.3 持续改进流程规则
流程规则不是一层不变的。初始规则的定义可能不合理，外界环境可能发生变化，团队的成熟度也会提高，相应的规则也需要改善和演进。显式化流程规则的另一个重要作用是作为改进的基线。
4.3.1 以显式化规则为基础讨论改进
现有的流程规则是团队讨论和发现改进机会的基础，只有基于同一基础的讨论才能做到客观和理性。否则，没有清晰的基线，对改进的讨论就没有基础，容易陷入主观和情绪化。
客观和理性而非主观和情绪化
如上图所示，如果没有清晰的流程规则基线，说法可能是：“质量差就是因为团队没有起码的责任心”，这是主观和情绪化的讨论。而如果流程规则是清晰的，靠谱的做法是：“我们一起看一下，质量问题究竟根源于哪个环节，是规则不合理、不清楚、还是执行不到位，还是可执行性有问题？”，这样的讨论就更加客观和理性了。
4.3.2 将改进落实到显式化的流程规则中
另一方面，有了显示化流程规则，团队就可以把改进落实到其中，成为新的基线。否则，改进落实不明确，其效果就容易出现反复。
改进应该可靠和有序而非脆弱和反复
如上图所示，改进行动没有具体落实，就会出现这样的情况：“怎么这个问题，几天不强调就又出现了？难道需要派人一直盯着？”。而基于显式化的流程规则，更好的做法应该是：“让我们把改进落实成为规则，并确保其理解和执行到位”。显式化流程规则让改进更加可靠和有序，避免脆弱和反复。即便改进没有达到预期的效果，我们也能明确的区分是改进方案的问题，还是落实的问题，并针对性调整。
显式化的流程规则是改进的基础，让团队对改进的讨论更客观和理性，避免不必要的主观和情绪化。同时它也让改进落实成为新的流程规则，确保改进的可靠和有序，避免脆弱和反复。
当然，显式化规则只是改进的基础和落实改进的载体。至于如何改进，则需要建立建立完善的反馈机制，系统地分析改进机会，并应用科学的方法定义改进行动，衡量改进效果，形成有效的改进闭环。这是我们在第五个实践——“建立反馈，持续改进”——中将详细讨论的内容。
总结：
“显式化流程规则”是“可视化价值流动”的自然延生，它是团队运作和协作的基础。团队基于价值流动和定期事件组织和明确规则；以此为基础，团队一致的理解并应用这些规则，更多地自主决策，成为规则的拥有者；最后，团队要在实践过程中基于现有的规则发现改进的机会，并将改进落实成为新的流程规则基线。
流程规则是影响团队行为模式的DNA，同时它应该能够不断的演进，构建组织的适应性。
下期预告：
下一篇，我们将进入看板方法的最重要和核心的实践——“控制在制品数目”，它通常也是被认为最难实施的实践。我将帮大家从源头上理解为什么要控制在制品数目，以及如何平滑地实施它，并从中获取最大的收益。
文中注释
内建质量（build quality in）是精益的基本原则之一。产品开发中，明确流程规则是内建质量的手段之一，其它手段还包括，自动回归测试、测试驱动开发、小批量开发和验收等
相关文章：
精彩推荐：