DevOps落地笔记-04|看板方法：成员工作内容清楚明白方法

上一讲主要介绍了用户故事以及如何通过讲好用户故事解决团队沟通的问题，争取达成共识。当团队都理解了用户需求之后，就进入到后续的产品设计、代码开发、功能测试、直到生产部署等环节了。作为软件从业人员都知道，后续的步骤不太可能一帆风顺。总有这样或那样的问题影响软件的整体交付进度。比如：当前迭代中被插入其他工作事项，需要解决的问题太多导致没有时间开发新功能，团队处于不断救火的状态。这种过载现象会影响团队成员的身心健康，同时交付的软件也是问题不断，运维人员苦不堪言，这是一种不可持续的开发模式。

今天跟大家介绍的看板方法是一个能将工作流程可视化的管理方法。它通过限制每个周期中卡片的数量来限制进行中的工作项的数量，只有团队具备了处理能力，才能拉入新工作项。这种拉动的工作模式，只要设置合适的能力阈值，团队就不会出现过载现象。下面我跟你介绍一下什么是看板方法以及如何使用看板方法。

什么是看板方法
看板（kan-ban） 是一个日本词语，来源于日本丰田。看板本意为“信号卡”，在生产制造环境中，这种卡片用作一种信号，通知生产过程中的上游工序继续生产。在这种生产过程中，除非从下游工序获得该信号，否则每个工序的工人不准进行任何额外生产。这和我们生活中，地铁通过限流来防止客流量超过系统承载量，是类似的——都是通过信号控制生产系统过载。

在软件开发中，卡片的数量代表团队工作能力能够处理的上限。这里的卡片代表工作任务，除了包含之前提到的用户故事，也包含问题修复、培训等其他任务，因为这些都是需要占用团队时间和精力完成的。在这些任务没有完成之前，新到达的任务只能在队列中等待，直到有任务完成才能开始。除非是用高优先级的任务替换当前进行中的低优先任务。为了解决团队过载问题，需要将团队成员的工作可视化，了解每个人的工作内容及工作量、任务延期的卡点，从而改进团队在研发过程中存在的问题。

因此，看板方法是一个包含可视化工作流程，定义流程运作规则，限制在制品数量的拉动系统，是一种在团队成员工作不过载的前提下，实现按时交付的管理方法。

看板方法是一种从现状出发，以渐进式、增量式为特色的改进方法。团队在当前的工作流程中应用看板方法，可以发现系统中存在的工作不均、团队过载、工作延期等问题，从而采取改进措施，解决系统中的瓶颈。看板方法实施起来相对比较简单。下面我介绍一下如何使用看板方法。

如何使用看板方法

STEP 1：价值流映射。
第一步，要完成价值流映射。价值流是指从响应客户请求创造价值开始，到完成请求交付用户价值为止，所需要实施的一系列的相关行动。而将价值流可视化的工作，称为“价值流映射”。为什么要做价值流映射？软件开发的最终目标是交付用户价值，在交付用户价值的整个流程中，会涉及产品、开发、测试、运维等多个环节。因此，如果想要更快交付用户价值，需要了解整个流程的运行情况。价值流映射能够帮助我们了解整个流程。下图是某企业某产品线的价值流映射图，展示了从需求提出到用户上线的整个周期的价值流动过程。

每一个环节下面都标明了完成该环节的相关数据，含义

& LT:Lead Time，前置时间或交付时间，是指一个工作项从开始到结束所消耗的时间，包含了等待时间。

& PT:Process Time，处理时间，是指处理该工作项的时间。

& %C/A:The Percent Complete and Accurate 完整度与准确度百分比，该值表示返工的比率，一般为估计值。

由此可以看出，一个需求从提出到上线验证完成总共需要 69 天。而其中只有 36 天的时间是用来从事价值产出的活动，其他 33 天或被用来等待下一步工作，或修复发现的缺陷。这 33 天并没有产生价值。从价值流映射中，我们可以发现影响价值交付的因素和瓶颈，并对这些因素和瓶颈进行优化。

STEP 2：定义工作项类型。
上面我们完成了价值流映射，下一步就要识别价值流中的工作项类型，一般包含以下几种：

& 以需求为中心的工作项，包括需求，功能，用户故事等；

& 以开发为中心的工作项，包括重构，缺陷，优化等；

& 以运维为中心的工作项，包括扩容，备份，故障等；

& 其他事务型的工作项，包括培训，会议等。

这里提到的工作项类型要体现在下面看板中。在整个软件开发流程中，我们不仅要关注能够增值的工作项（如需求），也要关注非增值工作项（如缺陷，重构，备份等）。因为这些非增值工作项可能会成为阻碍项，务必关注。

STEP 3：看板可视化设计。
将价值流映射作为输入，将其中的步骤抽象为分析、设计、开发、测试、发布几个关键环节，就可以设计出工作项需要流经的看板的列。如下图所示。需要注意的是，每一列分为“进行中”和“完成”两个子列。“完成”列是下游输入的“等待”列，这里，“完成”列是给下游的一个信号，说明上游工作已经完成，可以拉取并开始下游的工作。

在上面的看板中，我们可以非常清晰地看到以下几个关键点：

1.团队成员的工作项可视化。团队成员的主要工作项在该看板上全部体现出来。每一个蓝色的卡片代表一个工作事项。主要是一个可验证、可交付的用户需求。

2.端到端的交付流程可视化。从需求提出到交付给用户的整个过程。一般由需求分析、设计、开发、测试、发布等多个环境构成，其中“进行中”一列代表工作环节，“完成”一列代表等待环节。

3.系统瓶颈和问题可视化。能够发现当前工作流程中的问题和瓶颈。设计和开发阶段是当前系统的瓶颈，设计人员人手不足，导致分析完成的需求不能及时被处理，越积越多。开发人员当前任务饱和且功能相对较大。与此同时，测试人员处于无功能可测的状态，属于严重的资源浪费。

可视化工作流程是看板方法中最基础的实践，具有很强的问题暴露和提示改进机会的能力。

STEP 4：显示化定义规则。
如果想要让设计出来的看板能够运作起来，就需要定义一些规则。比如，任务卡片的书写规则是什么？需求具备分析的条件有什么？需求进入开发之前，需要满足的条件是什么？需求在进入测试之前，需要满足的条件是什么？每个任务完成的条件是什么？显示化定义这些规则，目的是让团队成员对流程规则有一致的理解和承诺，为团队提供明确的决策依据。其中，状态流转规则是可以放到看板中的，如下图所示。除此之外，还有一些与团队运作相关的规则，比如**站会。**站会的时间、地点、形式和内容也需要大家遵守。

STEP 5：限制在制品数量。
在制品是指进行中或等待中未完成的工作项。俗话说：“贪多嚼不烂”。同时处理多件任务，需要切换多个任务的上下文，而且也不能保证每个任务的交付质量。看板方法可以限制每个环节中在制品的数量，当环节中的在制品数量小于这个限制时，就可以从上一个环节已完成的部分拉入新的工作项，否则不允许拉入新的工作项。如下图所示。

除“发布”列之外，每列都设置了在制品的限制，明确了该环节所允许的最多可并行处理的工作项个数。在设置该值的时候，可以按当前实际的在制品数量作为初始值，当运行一段时候后，再回头审视是否需要调整。这样也符合看板方法中“从当前工作状态开始”的原则。另外，还可以根据职能团队的人的数量来设置。比如，开发人员处理“开发”列的工作，测试人员处理“测试”列的工作。那么，这两列的在制品的限制就是对应人员的数量。比如，开发人员有 5 个人，那么可将“开发”列的在制品限制为“5”。

STEP 6：跟踪工作项。
正如前面提到，看板方法是为了顺畅的交付高质量的用户价值。只有每个工作项都能够顺利的，按部就班地完成，才能最终交付用户价值。因此，对工作项的跟踪，了解团队运作和工作项流动情况，就显得格外重要。目前采取的实践是：站会。

站会一般是由站会主持人带领团队成员，在每个工作日，同一时间，同一地点，对着看板来检视工作项完成情况。主持人，一般由团队负责人或者每个团队成员轮流担任。在站会时，主持人带领大家从右到左审查看板。从右到左的顺序，体现了看板方法价值拉动的方向，只有下游的任务处理完成才能从上游拉取任务。

开站会的目的在于跟踪工作项，促进价值顺畅流动。因此，我们不需要检视每一个任务项，而是关注影响价值流动的工作项。如下图所示。

一般需要重点关注的方面有：

& 积压的需求，表明该环节已经过载，影响到整体价值流的顺畅流动，如图中的开发环节；

& 中断的需求，表明某个环节供给不足，价值流出现中断，如图中的测试环节；

& 阻碍的需求，表明该需求由于某种原因无法正常进展，该类需求应推动问题的解决，尽快恢复流动，如图中的设计和开发环节中有红色标记的需求；

& 即将或已经到期的需求，指在规定完成的时间内未完成的需求；

& 长期停滞的需求，指长时间未更新状态的需求。

STEP 7：持续改进。
持续改进是敏捷软件开发方法中非常重要的一个原则。通过小批量，短周期迭代，团队能尽快收集用户关于软件产品的反馈，从而在下一个迭代中进行改进。与敏捷软件开发方法“增量式的迭代开发方式”不同，看板方法在开发上并未切分成小循环的过程，它强调的是“渐进式的变革”，是一个不断做调整的流程控制方法。这一点，可以采用戴明提出的PDCA持续改善模式。

PDCA 是 Plan-Do-Check-Action 的缩写，是一个四步循环，用来提高产品质量和改善产品生产过程。这里做个简单的介绍：

& Plan（规划）， 是指在一个周期里制定一个明确的工作计划，包括工作计划的内容，产生的预期结果，以及计划完成后的验收标准；

& Do（执行）， 执行上一步制定的工作计划，并收集执行过程中的信息和数据；

& Check（检查）， 核对上一步收集的信息和数据，和预期结果进行对比，并对哪些做对了，哪些做错了进行总结。

& Action（处理）， 对上一步总结的结果进行处理，好的经验继续保持，对于需要改进的方面提出改进方案，并交给下一个 PDCA 循环去解决。

以上面看板为例，最初制定规划，以当前现状为基础实施看板方法。在执行中，通过的跟踪工作项步骤，发现了其中积压的需求、中断的需求和阻碍的需求等问题，并记录了积压需求的数量，需求任务的工时，团队成员的数量和能力等数据。结合这些数据分析造成这些问题的原因，比如需求量多，人手不足，需求难度大等。那么在下一个规划中就要采取改进措施，有针对性的解决这些问题。

不管是做企业还是做产品，不可能一蹴而就，都需要在不断试错、改进中渐渐完善。看板方法具有很强的问题暴露和提示改进机会的能力，能有效提高组织在完整价值流上的关注程度和绩效表现。

总结

本课时从研发过程中遇到的工作过载等问题入手，分析了这种现象对软件从业人员的身心和家庭造成的严重影响，并引出看板方法。通过可视化工作流程，限制在制品数量等方法，有效控制每个周期内交付工作项的数量，进而产生这样一个良性循环。限制在制品数量，会缩短产品功能的交付周期，然后缩短用户对产品的反馈周期，进而加快团队响应速度，从而减少线上产品的缺陷。因此会提升产品质量，最终提升用户满意度。目前在一些开源的需求管理工具中都具备看板的功能，IT 从业人员加班，任务过载等现象在企业内非常普遍，不妨试一试看板方法。