通过由瀑布到敏捷的转换来减少浪费

组织为什么要转向敏捷？一个原因是它可以使组织处理变化的能力更强。项目进行过程中，用户需求会经常变化，这就需要开发团队能够适应产品需求。敏捷帮助团队交付满足用户需要的产品；这些产品不包含不需要（而且没有用）的特性。精益软件开发使用术语“浪费”：一切不增加用户价值的特性都视为浪费。由瀑布到敏捷软件开发的转换是如何帮助组织减少浪费的呢？

Ron Lichty 写了一篇关于“由瀑布转换到敏捷的最具说服力的理由”的博文。如 Ron 所言，该理由与浪费有关：

但是对我而言，真正起决定作用的——使我发生了由对敏捷的热衷到对瀑布的绝望这一转变——是浪费。浪费资源，浪费开发时间，浪费精力。

他问开发人员和开发经理，当收到一份 400 页的需求规格说明书的时候，他们实际上能交付百分之几。他描述了问答过程，得到的答案如下：

（……）答案很少超过 45%——最典型的是 15% 到 25%——最少会交付需求规格说明书上 10% 的需求。

在确定交付内容的方式上，Ron 看到了敏捷与瀑布的主要区别，这一点影响了交付价值：

每次 Sprint，产品经理都会与开发负责人一起对 Backlog 顶部的事项进行协商排序，以保证团队总是致力于最有价值的需求。这是我喜欢敏捷的一点。

另一方面，在瀑布场景中，答案是几乎从不进行评估。针对我的问题，答案包括“对最简单的需求进行编码”、“我们最感兴趣的需求”（最引人注意的需求！）、“阅读需求的过程中出现的想法”或者“最有趣的需求”。一份 400 页的瀑布需求，其需求的优先级几乎普遍是由开发人员而不是产品经理来确定。

在网站“精益思维”上，Mary 和 Tom Poppendieck 描述了精益软件开发的原则。其中一项原则是“减少浪费”：

在产品开发过程中，三项最大的浪费是：

构建了错误的程序包

“没有什么跟高效地做根本不需要做的工作一样没有用处。”——Peter Drucker

程序包构建错误

如果看上去没有足够的时间进行正确的构建，那么当然也没有足够的时间进行不正确的构建。

批处理和队列思想

工作在开展过程中隐藏缺陷、超出时限、导致任务切换以及延迟价值交付。

Mike Cudemo 写了一篇名为“敏捷与瀑布——什么是关键？”的博文。在文章的开头，他解释了瀑布与敏捷处理需求的不同方式：

在蓝图设计完成后，瀑布过程试图“冻结需求”。可想而知，这不现实。需求问题发现的越晚（……），修复成本就越高。在某些情况下，都不可能进行修复。（……）敏捷方法不会试图预先一次性“确定和冻结需求”。它假设，随着用户开始可视化自己的需求，需求会发展和变化。

关于敏捷软件开发中的迭代是如何提供引导结果的可能性，他给出了自己的观点：

敏捷方法试图将需求、设计、编码和测试集中到规模较小的迭代开发阶段。本质上，敏捷方法是一系列规模较小的包含在敏捷过程之中的瀑布。最终用户和企业的利益相关人员可以在系统开发的过程中看到和体验系统。过程修正变得更明显和更易于操控。

根据 Mike 的总结，瀑布项目浪费 IT 预算：

许多 CFO 发现自己置身于一部降低运营成本和进行技术投资的复杂而又需要娴熟技巧的戏中。CFO 对 CIO 施加压力，使他们提出可以充分利用现有投资的计划，同时还要求他们发展快速响应经济增长和竞争变化的能力。项目结果没有失败选项，但根据统计，瀑布方法浪费了公司 IT 项目预算的 60%。

在博文“敏捷成本更低，对吗？”中，Kenny Grant 描述了敏捷方法是如何帮助团队识别和处理浪费的。据 Kenny 说，在开发软件的时候，敏捷软件开发本身并不比瀑布成本更低。使敏捷成本更低的是其处理范围变更和项目调整的方式：

因此，比较瀑布和敏捷就像比较苹果和桔子。在我看来，这是因为，与使用瀑布型开发方法实现相同的业务需求相比，遵循敏捷原则和过程几乎总是生产出不同的产品。（……）项目范围内几乎总是有些部分可以视为浪费，或者其价值不值得以那样的成本交付。敏捷总是不懈地专注于业务价值，并通过恰如其分的工作鉴别浪费——或者是投资回报率（ROI）不佳的需求——从而给团队改变它或者一起放弃它的机会。

考虑到业务需要和需求会在项目进行的过程中发生变化，Kenny 重新表述了问题“是否‘敏捷成本更低？’”：

“对于特定的业务需要，遵循敏捷原则和过程能够使我们开发出满足需要（不多也不少）的产品，而又比使用瀑布型开发方法成本更低吗？”在这种情况下，答案是“是的，绝对！”

查看英文原文： Reduce Waste by Changing from Waterfall to Agile