从胖到胖:精益之旅(衡量标准:第3部分)


在文章中”Let’s Lean on Lean“我们讨论了如何在价值流映射流程中识别增值、增值因素和非增值因素。了解不同类型的浪费有助于采取行动消除它们,加快向利益相关者交付价值。

下面的涂鸦描绘了系统中的各种浪费。

虽然重点似乎更多地放在制造或生产系统上,但这也适用于任何旨在更快、更好地交付价值的流程。

为了能够在精益软件开发的背景下理解这一点,玛丽和汤姆·波平迪克提出了7种浪费:额外功能、移交、缺陷、技术债务、在制品、任务转换和延迟。

在产品开发生命周期的最短可预测时间内将概念转化为现金的世界中,让我们探索如何识别和消除这8种浪费。

缺点

缺陷消除效率是行业中众所周知的指标之一,它有助于在向客户发布产品之前识别和修复缺陷。在竞争激烈的世界里,在产品制造过程中,不仅要消除缺陷,还要防止缺陷,这一点至关重要。如前所述,如果我们已经理解了需求,并且按照需求进行构建,将会产生以正确方式构建的正确产品。虽然代码审查和回归测试是很好的附加功能,但是我们需要探索通过结对编程等实践来提高质量的有效方法。

交通运输

这可能与人和过程有关。自组织团队通常需要更长的时间从组建到规范再到执行。由于任何原因在产品团队内部或跨团队转移人员将影响速度和吞吐量。

如果有太多的移交或移交,它会触发另一个浪费“等待”以及更长的周期时间。我们需要确保团队能够自给自足,能够完成包括审查和验证在内的功能。依赖其他团队或人员的需要需要被分析和减轻,以限制不必要的移动。

等待

“时间就是金钱”,延迟会影响整体价值的交付。延迟无处不在,让团队等待领导的决定,开发人员等待代码评审,测试人员等待适当的构建来验证。虽然有些延迟在整体价值流中可能看起来微不足道,但从整体上看,这种贡献是足够大的。不仅仅是在回顾中,甚至在每天的站立时,团队都需要确定并寻求领导团队的帮助,以确保延迟最小化。

生产过剩

客户满意度很重要,但同样重要的是要了解客户真正想要什么,不仅要及时提供,而且要恰到好处。有许多代码行正在被编写,测试用例正在被执行以确保产品质量,但是我们要问自己的问题是,它们真的需要吗?虽然行为驱动开发和测试驱动开发等方法有助于关注需求,但重要的是交付客户要求的东西,不管我们选择构建什么方法。

存货

当产品团队致力于更长的版本(9-12个月)时,通常所有的特性都是在发布时一起交付的。尽管由于各种原因,这可能是不可避免的,但这将是一个很好的主意,不仅展示演示,而且在功能完成后让客户参与早期验证。这有助于在交付周期中尽快降低风险和不确定性。如果有可能将已完成的功能捆绑在一起并提前发布,我们可以在控制库存的同时快速实现投资回报。如果我们将功能保持在一个更长的开发队列中,改变的可能性更大,采用的阻力也更大,并且有可能输给竞争对手。

运动

用户体验是赢得和留住客户的一个重要方面。无论是新的安装还是升级,确保客户不必在不同的应用程序或步骤之间切换都是至关重要的。非功能性(也称为基础)需求需要与新功能性需求同等的关注。我们都希望有一个无缝的体验,太多的步骤和动作会让人分心和沮丧。

过度加工

"我不确定是否需要这种验证."

“嗯,我已经添加了以防万一。”

"但是用户不可能进入这个场景."

“你永远不会知道。”

我们在开发周期中经常听到的对话。虽然增加额外的步骤没有害处,但让我们不要忘记浪费的时间,这些时间本来可以用于增值项目。

例如,我们认为事务日志有助于故障排除,但最终会占用空间,有时甚至会给客户带来性能挑战。

未被利用的人才

确保提供所需的培训并有效利用个人技能,这不仅仅是领导的责任。每个团队成员都需要理解业务目的,愿意学习,获得所需的知识,并展示他们的学习如何帮助组织。个人拥有自己的职业和领导需求,以确保团队成员通过增值工作获得动力,增值工作与团队成员的激情和职业发展相一致。


简而言之,虽然八种类型的浪费在概念上似乎不同,但都是关于理解目的和需求,通过有技能的个人优化流程和运动。每个人都有责任通过识别流程中的非增值环节并消除它们来实现持续改进。