---

还没理解项目就得规划全部？答案可能让你惊讶！

没有 Scrum 时，我们曾构建并交付完全错误、无法满足客户要求的软件和硬件产品。

职业生涯中，有时第三方公司强行规定我们应如何开发软件产品或服务。

能力成熟度模型（CMM）, ISO 9001:2008 及其他衍生框架，试图确保我们以正确方式构建正确软件。

它们多成功不属于本书话题。本书关注 Scrum 流程和优势，而非批评几乎过时的方法。

但必须补充，Scrum 前的改进框架建议分阶段的软件工程方法，我们称之为 瀑布软件工程模型.

瀑布中，项目从需求分析开始，试图理解客户需要和期望。

之后设计、实现、测试（验证），再在生产环境维护，最终走到工程生命周期终点。

但现实并非如此！

瀑布方法与 Scrum 框架

传统瀑布式软件开发模型的阶段

某个阶段的意外延误，必然影响后续软件工程阶段。

研究表明，所调查失败软件项目中，超过 80% 将瀑布方法的使用列为关键失败因素之一。 为什么？

如左图，瀑布阶段严格顺序连接，前一阶段完成才能开始下一阶段。回头通常痛苦、昂贵、挫败且耗时。

项目初期就规划时间线，只在末尾交付可发布产品。一阶段延误，后面全延误。

为避免延误，经理试图预见所有可能，早期就尽量完整、细致地定义需求。但初期定义很困难，很多需求会变，或理应改变。

研究显示，大型复杂项目约 60% 初始需求会变化。另一些按定义实施，却不是真正需要，消耗本可投入更高价值功能的时间与金钱。

划分阶段要求分别估算。问题是多数阶段并非独立，而是共同、并行工作。

例如，理性的人不会认为开发完成后才开始测试，但不幸的是瀑布过去正这样工作。

瀑布可用于小而简单的软件项目。 但对大型复杂项目，这种方式极其冒险，甚至荒唐。它通常成本更高，效率始终低于 Scrum 开发交付框架。

这就是 Scrum 前的生活。没有具备 Scrum 技能的专业指导，在团队间反复传送软件， 让工作官僚、复杂、低效.

最后不只产品受损，员工士气和对组织使命的承诺也完全被破坏。