物理精益看板的尝试

通过可视化的物理白板实现端到端的流程改进,可以看到价值端到端的流动过程。这一思路受畅销书《精益产品开发:原则、方法与实施》作者何勉老师的启发。何勉老师是国内资深精益产品开发顾问,专注于精益产品交付、精益创业、创新及精益产品设计等领域。

何勉老师在 “阿里技术” 微信公众号上发布了一篇名为《如何在 2 周内交付 85% 以上需求?阿里工程师这么做》的文章,其中配有如图6-1所示的看板插图。笔者反复阅读这篇文章,在心中埋下了跃跃欲试的种子,最终呈现在 “程序交付经理” 的落实思路与物理精益看板的尝试中。

image 2023 11 17 18 59 53 113
Figure 1. 图6-1 看板插图

物理精益看板对于笔者所在团队中的很多人来说还是一个相对陌生的概念和实践模式。为了推进物理精益看板的有效尝试落地,除了选定试点方向外,为此还拟定了如下相关实施的说明。

设置目的与状态设置

通过可视化端到端的价值流动过程(以精益看板为核心呈现载体),基于价值流发现流动过程中的问题。识别并优化问题瓶颈和待提升点,以更好更快地推进需求价值的快速流动交付。

物理精益看板的状态设置可先通过 Excel 进行模型绘制及干系人确认,如图6-2所示。

image 2023 11 17 19 01 58 237
Figure 2. 图6-2 物理精益看板的状态设置模型示例

物理精益看板的状态最终要在物理载体上呈现,最好采用物理白板。图6-3、图6-4为在办公室玻璃墙上临时搭建的较为粗糙的物理精益看板。

便签使用

  1. 便签使用说明

    通过不同颜色和形状的便签来呈现任务的所属特点,便签区分如下。

    • 正常需求开发任务采用绿色便签。

    • 紧急插入需求任务采用红色便签。

    • 测试任务采用黄色便签。

    • 黄色细条便签代表缺陷。

    image 2023 11 17 19 04 06 314
    Figure 3. 图6-3 状态设置在物理载体上的呈现(一)
    image 2023 11 17 19 05 06 531
    Figure 4. 图6-4 状态设置在物理载体上的呈现(二)
  2. 便签书写说明

通过便签书写内容能够理解该便签对应的研发任务信息。进入开发阶段的任务便签(绿色和红色)需要包括如图6-5所示的参考信息。进入测试阶段的任务便签(黄色)需要包括如图6-6所示的参考信息。

image 2023 11 17 19 07 00 691
Figure 5. 图6-5 开发阶段的任务便签书写维度示例
image 2023 11 17 19 07 43 899
Figure 6. 图6-6 测试阶段的任务便签书写维度示例

便签流程规则

关于便签流程规则的说明如下:

“需求池” 为纳入本月或未来一段时间开发但还未进入研测阶段的任务,每个需求有对应的 Jira 任务编号。常规产品演进需求采用绿色便签呈现,紧急需求采用红色便签呈现。

若常规产品演进需求被提升为紧急开发需求,则使用红色便签进行置换。需求池可根据任务的优先级将便签上下移动,最上面的便签优先级最高;产品侧可根据达成的优先级共识输出对应产品设计产物并组织评审,以更好更快满足后期开发的准入需要。

“准备好” 为已完成需求设计评审,满足开发准入要求的待开发状态任务。卡片从需求池里获取,粘贴到该区域即可。研发侧需要把控此列需求的质量,若对应的需求还不完整或未进行评审达成共识,则不允许把对应便签贴在此列。

“开发-设计ing” 为进入开发阶段但需要进行需求的进一步消化,转化成设计实现,指导后期编码实现。该卡片从 “准备好” 中获取。此时需要把便签左下角的S(Start 首字母,代表开始开发的时间)进行填充;便签右下角的开发人员也需要罗列,书写的第一个开发人员为该任务的第一开发负责人。

“开发-开发ing” 为进入编码阶段的任务,若对应任务已完成设计并着手编码实现,则把该便签在同一个泳道移动到本列即可。

“开发-自测ing” 为进入开发自测的任务,一般较大需求存在的自测时间较长,故增加此列进行状态的标识。进入该阶段的任务,把对应任务便签在同一个泳道移动到本列即可。

“开发-完成” 为已初步完成开发和版本构建的任务,不代表此任务已经满足上线需要。若该任务在测试环节出现缺陷,则此任务便签上面会贴上细条便签,说明还需要进行缺陷修复和重新发版验证。若任务完成测试上线,则此便签会结合对应测试任务,把此任务下的所有便签放置在看板下方的“已上线”区域中,实现原泳道的清空,供后续开发任务进入。

“测试-用例ing” 为当任务进入 “开发-设计ing” 阶段时,可着手开展的测试准备工作。需要结合对应研发任务所呈现的 Jira 编号任务,并结合 “开发-设计ing” 阶段的设计产物和 “开发-自测ing” 阶段的具体实现产物说明进行测试用例框架的书写与完善。

“测试-测试ing” 为对应的任务已实现发版并进入测试执行阶段,此阶段会进行 “开发-完成” 状态的反馈,若存在缺陷,则把细条便签粘贴在对应研发任务便签上,以代表需要研发人员做进一步处理。

“测试-完成” 为该需求任务已完成整体测试,满足上线需要,但还未上线。若完成上线,则需要把此任务的所有便签放置在看板下方的 “已上线” 区域中,实现原泳道清空,供后续开发任务进入。

“待上线” 的任务状态时间最短,增加此列的目的是当对应需求的研发任务和测试任务都进入完成状态,需要等待时间进行上线时,可以把对应任务的所有便签都贴在此区域,说明上线处于等待状态。若已完成上线,则将便签迁移到看板下方的“已上线”区域中,实现原泳道清空,供后续开发任务进入。

“已上线” 为阶段周期内已完成上线的需求任务,对应任务便签迁移到此处时,需要对开发便签右下角的E(End 首字母,代表上线日期)进行填充。

便签生命周期

  1. 绿色/红色便签的生命周期

    “需求池”→“准备好”→“开发-设计ing”→“开发-开发ing”→“开发-自测ing”→“开发-完成”→“待上线”→“已上线”。

  2. 黄色便签的生命周期

    “测试-用例ing”→“测试-测试ing”→“测试-完成”→“待上线”→“已上线”。

  3. 细条小黄色便签的生命周期

    “开发-完成ing”→“待上线”→“已上线”。

维护说明

月初对本月的需求任务进行便签化处理,根据任务实际情况,粘贴至 “需求池” 或 “准备好” 等区域。

每日晨会对精益看板上的便签进行右向迁移拉动,结合看板内容组织晨会,时间控制在 10 分钟内。