这是鼎叔的第六十八篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

精益理论的核心是造物先造人，消除浪费和持续改善。每个员工都有机会发现自己工作方式的问题、解决问题和进行改进。我们通过减少不增值的浪费缩短交货时间（比如，从客户下订单到公司收到现金为止）。而缺陷其实是一种不必要的浪费，从精益理论中我们可获得不少测试启发。

精益理论知识

精益理论是来自于二十世纪五十年代的丰田精益生产方式（TPS），在大野耐一的领导下，丰田汽车生产效益迎头赶上了美国同行，相关理论也在世界范围内引发学习热潮。

2009 年，精益思想屋由 Craig Larman 和 Bas Vodde 提出。它的基础是强调管理者使用并教授精益思想，以此哲学思考方法为基础做出工作决策。精益思想屋有四根支柱，如图所示。第一根是尊重他人和团队协作；第二根是持续改善（日文是 Kaizen），走进实际工作地来观察，拒绝所有不创造价值的浪费，挑战完美；第三根是流动，为了让价值快速流动起来（价值流），我们需要根据价值来驱动生产，借助可视化看板（Kanban）进行 JIT（just in time 刚刚好）的小批量生产；最后一根是创新，精益创新模式认为用户痛点和解决方案在本质上是未知的，无法完美预测，需要不断通过验证和迭代，找到真实的痛点和有效的解决方案，因此精益创新的本质就是创造价值。

那精益思想和敏捷理念有什么联系和区别呢？两者是互相渗透和借鉴的关系。精益理论产生的时间更早，在传统制造行业发挥了巨大的价值，对于软件行业的敏捷先行者也带来了极大的启发，因此敏捷实践中会大量融入精益的工具、原则和方法。尤其是看板方法深入人心，几乎是敏捷特性团队的必备工具。两者在对员工的充分信任和尊重上，价值观是高度一致的。

但是两者也有本质的不同，如敏捷是强调自组织团队，可以依靠个人克服挑战并持续改进；精益是强调领导者要具备洞察问题的能力，相信领导者可以带领团队走进新阶段。两者的组织风格差异并无优劣之分。

具体到精益看板方法和 Scrum 框架，两者也有差异。看板方法没有指明三架马车这类关键角色，也没有固定的迭代周期这种时间盒（time-box）的概念；而 Scrum 也没有强调在制品数量的限制，而是通过估算价值和工作量大小来排期。看板用 lead time（前置时间）来度量交付效率，而 scrum 通过 “迭代速率” 来度量交付效率。

纪念自己拼装的第一个看板

看板上的卡片，果然要自己挪才会有紧迫的感觉，或者成功的感觉。

精益看板实践要点

精益看板能在工作场所创建一个氛围，驱动大家讨论和解决问题，让工作流程透明化。围绕看板的渐进式改革，更容易让大家接受。

看板集体实践的难点在于提高可预测性，如何消除变异性（难以预测的事件）根源。内部变异因素包括工作项的规模，不规则紊流和返工。外部变异因素包括需求模糊，需求加急，环境事件，人员异动，市场和协调因素等。

我们可以把红色的问题贴纸，贴在受阻的任务卡片上。受阻的工作项不一定是问题根源所在。

对于精益的产品交付节奏，要考虑交付的价值和成本，如事务成本，协调成本和破坏负载。团队判断一个工作项是否为浪费，很简单，问自己：大家愿意更多地开展这类活动么？

针对需求任务卡片的优先级讨论会，低成熟度团队定期召开，而高成熟度团队按需召开。

引入外部上下游的干系人，有利于集体确认看板实践规则。

测试启发

一、优先注重员工的能力发展，探索工作的意义，并经常实地查看。

对员工信任和尊重的态度只是基础，当新时代的年轻人涌入职场，管理者有义务帮助他们揭示测试岗位发展的价值，以及我们所做的工作给用户的价值。理解了所挑战目标的意义，才能更好的调动积极性。

比如，我们为什么对某些用户场景投入大量测试心力，它更给业务成功带来多大的成功推力？我们过往的工作得到了哪些用户的真挚认可和反馈？

与此同时，管理者是否对下属的能力发展创造足够多的实践机会？员工在努力奋斗时，管理者是否有适度的观察和现场指导，还是永远只有几条感谢的 IM 消息或邮件？这都是会让领导者更受员工爱戴的重要表现，也是从源头发现可改进之处的高效习惯。

重复那句话，能力发展是敏捷转型三大成功要素中的第一要素。本公众号针对测试工程师能力发展这个话题还有深入展开分享的专题：聊聊测试工程师的核心能力模型。

二，建立价值流视图，控制在制品数量。

价值流视图对整个敏捷团队的日常提效改进非常有用，自然也对各种测试任务有指引作用。我们把研发测试的整个过程拆解为关键的子阶段，度量各个阶段执行耗时，和跨阶段的等待耗时，就可以发现真正低效的地方。

健康的流动速度会让团队有和谐感和成就感。我们重点强调以下注意事项：小批量，不间断。

如果测试任务估算动辄超过一周，我们发现风险的时间就会推迟，改善动作也难以做到精细化。当然测试任务的小批量也依赖用户故事的合理拆解。小步快跑（小测试，天天测）才是健康状态，而不是大步走走停停。由于测试任务可以按用例优先级和测试类型做分类，拆解为小批量任务的方法是非常多样的。

在制品（WIP，Work in Progress）数量，在测试阶段是指进入 “待测试” 状态和 “测试中” 状态的任务数量，它应该低于一个限制值，才能不对需求交付吞吐量带来风险。如图所示，处于 “测试中” 的任务卡片不能超过 3 个，否则就会产生瓶颈风险。

每个人员拥有 1-3 张任务卡片比较合适，这样能平衡交付和新需求速率，通过频繁交付构建团队信任。

卡片大于限制值，说明测试人员工作过载。发生在制品数量明显异常时，整个团队都有必要停下来，看看什么地方出了问题，什么环节导致测试阶段的在制品数量异常，然后采取改进措施。注意测试阶段发生的任务过载，其根本原因不一定和测试环节或者测试人员相关，团队要认真回溯分析。

这也就是著名的丰田精益管理 “安东绳” 实践，流水线中的任何员工发现异常，都可以拉绳停止流水线，大家聚过来集体解决问题。这和软件 DevOps 流水线的管理机制何其相似！

我们还能利用累积流图对 WIP 进行分析，监控受阻工作，度量产能浪费。

如果某个任务阶段成为价值流的瓶颈，我们要判断它是能力受限瓶颈，还是非即时可用瓶颈。我们优先采用成本较低的举措，比如在瓶颈前设置缓冲区。其次再实施突破瓶颈的高成本举措，如自动化测试。

三、总结常见浪费现象，形成团队敏锐度

任何不增值的活动，都属于浪费，我们可以列举下面六种典型浪费现象，团队组织研讨，重点实施清除，大部分和 Scrum 实践要避免的反模式是一致的。

1 库存。尚未完成测试，无法进入可发布状态的所有功能。虽然我们为它付出了大量心力，但是它依然不能随时发布给用户。与其做一堆当前不能发布的功能，不如集中力量保障少数急需功能的发布质量。

2 过度测试。用户不会为过度设计的功能买单。针对过度设计的功能，我们要能提出质疑或者降低测试优先级。对于纳入迭代的特性，由于测试的不可穷尽性，我们也不要过度测试，在有限的精力和拦截严重问题的概率上做好平衡。

3 频繁任务交接。通常切换任务时会带来 30% 以上的效率损耗。一鼓作气沉浸在心流状态中是效率极高的。按照研发工作流程，确实存在测试与其他角色频繁交接的情况，这时需要多思考减少交接频率和成本的方法。同理，短期项目中测试人员之间的任务交接也应尽量避免。

4 多任务并行。管理者可能认为这样会让员工产生更多的价值，其实这是一个误区，三心两意难以产生高质量的结果，真正完成了一个任务才能让价值流往下走。否则各个任务的价值流都会形成阻塞。

5 等待。前面也多次提到。等待不产生价值，还会降低士气，松懈情绪。对于经常的等待情况极其有必要做分析改进。

6 缺陷。缺陷属于不必要的浪费，而且可能耗费研发团队巨大的精力。减少缺陷的数量和严重程度，一定是向价值流的上游去推动改进。测试活动左移实践能尽快把缺陷消灭在萌芽之中。

四、看板的泳道技巧

我们在敏捷实践中经常会遇到一类难题，一方面要不断开发新需求上线，满足既定目标，另一方面，有些突发的重要工作也是要随时处理的，比如上个版本的缺陷紧急修复。我们如何利用看板的可视化，清晰地管理分工，保证两类工作的价值流都能顺利进行，又不互相影响？

横向切分的泳道就可以帮我们实现这一点。我们把新版本的开发/测试任务卡片，放在上面的泳道（宽度占 70%）进行价值流的拉通，代表占当前总工作量预估 70% 左右。再把老版本的缺陷修复/升级维护等工作任务卡，放在下面的泳道，宽度约 30%，暗示这类工作量占比约 30%（工作量没有这么多的话，优先去完成上面的 70% 主泳道工作）。

同理，我们还可以为其他类型的重要技术债准备特定的泳道，比如给专项系统测试（性能，安全等）预留一定比例的泳道空间。

五、不要把有空闲的测试人员的时间填满。

从看板卡片或者价值流视图，管理者经常可以发现有些测试人员在特定时间是比较闲的，于是很有冲动去增加他的任务以填满工作时间，提高团队总效能。这个实际上不是好的做法。团队效能还是要看完成需求的吞吐率，个人空闲与否影响不大。如果刻意让干活快的人显得更忙，就会引发他故意磨洋工的心态。还不如鼓励他利用空闲时间做感兴趣的专业学习。