看板方法的核心实践

Jira 的用户头像不可采用系统默认的空头像，空头像不具备可视化属性，会给团队带来的一定的识别困难。建议每个团队成员采用个人喜欢且有标识性的图片作为头像。

Jira 项目的项目标识英文编码在具有项目标识性的同时，编码长度不超过 6 个字母。在编码较长的情况下，Jira 问题编号也较长。必要的简化可增加可视化效果，也便于记忆和手动输入检索。

Jira 项目的 Epic 须根据演进需求或所属模块的特点，在命名上具有标识性。当存在多个产品共用一个 Jira 项目的情况时，对 Epic 的有效命名可以降低理解难度，可采用 “产品英文缩写标识-演进需求简称” 的格式对 Epic 命名。Epic 的长度也须适当控制，避免因 Epic 过长而无法在看板的便签中完整展示，建议控制在 10 个字符（含英文）以内。

看板中的工作项概要描述建议有所提炼，避免概要描述以流水账的模式记录。

看板工作项便签中的扩展显示字段在 Jira 精益看板定制案例中选择的 “经办人” “产品负责人” 和 “已更新” 3个字段，可按需进行修改和调整。扩展字段在实际处理工作项时，建议进行有效的填充。

用户可对看板所使用的浏览器进行适当的页面缩放以获得更佳的全局可视化效果。因 Jira 精益看板扩展的价值流状态列较多，在未进行浏览器页面缩放的情况下，我们会看到状态列以及每个列中的工作项存在明显的挤压现象，影响使用体验。建议将看板所使用的浏览器页面缩放至 80%，具体缩放比例可按最优可视化效果自行调整。

建立团队对限制在制品的认知。

将限制在制品应用于需要的状态列。限制在制品无须对所有列的在制品进行限制，可按照职能参与方进行分解，如产品侧可对“需求-产品设计中”中的在制品数目进行限制，而无须强制限制“需求-待评估”“需求-待评审”阶段的在制品数目。建议当对应的状态列包含“需求-产品设计中”“开发-设计中”“开发-开发中”“开发-自测中”“测试-测试中”价值流状态时，重点考虑所归属状态列的在制品设置。

在制品数目可在实践中持续优化。我们限制在制品，并不是说在制品越少越好，在制品在过少反而会引起人力资源的闲置。建议各职能方根据对应项目下的人力规模进行预估，如产品侧成员2人，可设置“需求-产品设计中”状态列的最大在制品数量为4，后续再根据实践效果进行优化和调整。

控制在制品的规模。我们提及更多的是对在制品的数目进行限制，实践中也需要对在制品的规模进行必要的控制。当我们的需求属于一个重大功能时，若未对此需求进行必要的拆解，将其直接流动到开发侧，则开发团队也会存在因为这个单一需求而过载的情况。建议这种规模较大的需求在流动到“开发-设计中”环节时，务必进行必要的拆解，拆解后的小需求尽可能满足局部交付。

及时处理限制在制品后暴露的问题。借助看板的可视化能力，我们能够很容易地识别每个状态列的在制品情况。当“开发完成-待测试”出现明显的在制品堆积时，我们可判断测试资源是否在当前团队中达到瓶颈，从而评估并调整已有工作或申请增添资源以缓解在制品的堆积。

限制在制品的数量与大小。已在 11.2.2 节进行阐述，此处不再赘述。

限制批量流动，实现持续交付。批量流动是对看板上 3 个以上的需求同时由某相同状态流动切换至相同的另一种状态，如需求统一由“需求-待评估”状态迁移至“需求-产品设计中”状态，或者统一由“准备好-待开发”状态迁移至“开发-设计中”状态。这种批量流动模式会对稳定的流动和可预测性带来影响，同时也会造成人力资源在过程处理中产生局部空闲或局部过载的情况。如开发人员已完成需求开发任务，需要等待需求任务积累到指定数量，才能处理新的需求任务，这样开发人员的等待就是人力资源的闲置。当需求任务统一进入开发过程，开发人员在有限的时间下并行兼顾多项需求任务，容易产生人力资源过载。

质量内建，减少浪费。质量是整个交付过程都需要关注的重要指标。质量内建是指在交付过程的每个环节或每个职能都对所负责的过程及交付进行质量把控，避免把质量把控的压力倾斜至测试环节或测试人员身上。质量内建是有效减少返工的重要手段，更是增强有效流动的必要条件。

可产生必要的等待，按需集中处理“需求-待评审”状态的工作项。有效的流动背后，我们需要追寻更高效的流动。有的等待是因为人力资源受限，加上需要对在制品进行控制所产生的，如处于“准备好-待开发”状态的需求开发任务需要等待满足可处理条件时，才能进入后续的处理；而有的等待恰好是为了集中进行统一处理，在“需求-待评审”环节产生必要的等待，反而能够提升团队间的协作和减少工作打断。

使用看板组织每日站会，关注整个组织的流动情况。流动需要项目团队的全员参与，如果团队中的每个人仅对自己负责的任务进行流动状态管理，是无法有效提升协作效率的。团队协作的前提是信息资源的透明、共享和传递。借助精益看板的高度可视化能力，能够实现项目团队掌握需求全局、整体需求的阶段变化或沟通并解决阻碍问题，从而提升团队的工作效率和效果。

提升后方主动性，牵引流动。我们对于流动的理解，更多偏向于前方环节的人主动把已经满足交付条件的需求推给后方环节。而精益看板则期望实现后方环节基于需求的紧急程度、进展情况，拉动前方环节进行协同交付，这样有利于改善后方职能团队的被动接受意识，作为后方职能也能主动参与项目的整体交付。

重点关注跨职能状态的规则设置。精益看板中的需求从开始的填充到最终的交付验收，经历了多个职能角色的协作和过渡。当需求的处理过程在职能角色间切换时，如果直接处理人发生变更，更容易存在交接协同的问题。显示化流程规则的实践，重点关注跨职能状态的规则设置和达成共识。在笔者的实践中，产品人员与开发人员之间的“准备好-待开发”跨职能状态、开发人员与测试人员之间的“开发完成-待测试”跨职能状态，不仅是对应需求状态的切换，更需要上游职能角色交付适当的文档材料便于下游职能角色处理。

规则设置嵌入质量内建原则。在笔者的实践中，在“需求-待评审”“开发-自测中”阶段重点进行了质量内建原则的嵌入。其中“需求-待评审”阶段要求产研测三方对产品侧设计交付的产物进行评审，“开发-自测中”阶段则要求开发人员对即将交付测试的产物进行自测。

开展日常精益晨会。精益看板毕竟只是一个工具，在精益晨会上借助精益看板的可视化能力对已有进度、项目过程、目标协同信息进行共享和讨论，构建流动能力。精益晨会是精益看板持续落地和不断优化与改进的源泉。

开展阶段性项目回顾。精益晨会聚焦于时效性较强的项目，如最近一天内的工作进展，对于阶段性或周期性的项目总结，更需要开展阶段性的项目回顾复盘。如在 Sprint 关闭时点前后，组织 Sprint 工作整体审视回顾，或两周、1个月等固定频次进行项目执行工作的整体审视与回顾。通过阶段性的项目回顾复盘，提升组织成熟度，实现组织持续改善行动的能力。

以度量数据建立流动和效能感知。我们可基于 Jira 平台原生提供的报表能力度量和感知指定项目或指定周期内的项目整体流动情况。借助度量数据更立体更完整地感知整体流动和效能情况，需要建立埋点和进行必要的基础开发，可通过附录B的效能度量示例进行了解。