敏捷vs瀑布:哪一种适合你的项目?

敏捷vs瀑布。这是经典阵容之一，就像凯撒对拿破仑。我们忍不住让两个看似对立的竞争者相互竞争。

但事实更为复杂和微妙。虽然从原则上讲，敏捷vs瀑布法代表了一个领域的两个明显的极端，但现实情况并不清楚。适应性和预测性项目管理(使用更有用的术语)是一个范围的两端。但两者都已经融合了对方的许多方面。没有人会明智地说你需要坚持一个或另一个极端。他们断言一个比另一个“更好”是不明智的。

本文的目的

敏捷和瀑布式(预测性)项目管理都是强大的范例。这两者的完美结合可以为您的项目创建最佳方法。因此，在本文中，我们将比较敏捷和瀑布法，并探究其中的微妙之处。我的目的是让你们对这两者都有更好的了解。

所以，这就是我们要讲的内容:

• 什么是敏捷和瀑布?
• 主要区别
• 什么时候使用每一个
• Agile-Waterfall混合动力车
• 域的影响
• 结束语

什么是敏捷和瀑布?

如果不先了解敏捷与瀑布的区别，我们就无法展开敏捷与瀑布的辩论。因此，在这一节中，我将浏览高亮部分。如果你想了解更多，我建议你看看我们的一页学习路线图和资源指南:

• 我想学习项目管理
• manbetx3.0app

瀑布式:更好的叫法是预测式或计划式项目管理

我们遇到的两个问题，源于术语的本质“瀑布”正在使用。首先，许多敏捷主义者——敏捷方法的实践者——将任何不是“敏捷”的东西称为“瀑布”。第二，他们中的许多人把它作为一个贬义词。所以我们得到了这个错误的、破坏性的三段论:

瀑布式=不敏捷

敏捷=好

瀑布=糟糕

当敏捷开发人员确实为预测项目使用替代术语时，他们最有可能用“命令和控制”替换术语瀑布。而且，虽然传统的项目经理确实渴望控制，但我认为您会发现很少有有效的项目经理通过命令来实现控制。相反，我们渴望细致的规划、有效的监督和鼓舞人心的领导。

那么，什么是预见性项目管理?

下面是一个经典的(真实的)瀑布过程。

然而，任何预测性项目管理的基本特征之一都是分阶段的方法。我们分阶段工作。

我认为还有两个特征绝对是预测性项目管理的特征(“瀑布式”)。

1. 从定义开始
   首先，我们的目标是明确定义我们的项目是什么，不是什么，以及什么功能或能力需求。我们需要清楚地表达我们的目标，目标,范围的需求。
   [链接指向解释这些条款的短视频——它们会打开新的标签页，这样你就不用用你的位置了。]
2. 谨慎的计划和预算
   二是编制全面的计划和预算，针对一个 清晰的规范。

关于瀑布的说法并不正确

有很多关于预测性项目管理的“神话和错误信息”，是由一些敏捷实践者(敏捷主义者)散播出来的。他们说瀑布项目…

• …有与客户和利益相关者的低参与度
  事实上，涉众参与的数量是由项目经理和您的团队决定的。我强烈主张将其作为优先事项，因为“决定项目成功与否的是你的利益相关者”。

• …拿一个“一下子，大爆炸式的交付方式”
  事实上，自从项目出现以来，项目经理就一直在使用分阶段的增量交付。它消除了项目的风险，并在更早的日期将价值返回给客户。渐进主义并不是什么新鲜事。
• 允许…没有细化或更改范围或规范
  事实上，我们有复杂的变更控制过程，可以做到这一点。他们这样做是有纪律和负责任的。

单词:“瀑布”

术语“瀑布”被广泛使用——通常以一种贬义的方式——用来描述非敏捷的任何形式的项目管理。然而，它最初(1976年)是指温斯顿·罗伊斯在1970年描述的一个特定的软件开发框架。《瀑布》的顺序阶段原则源自工程环境中使用的方法。当然，在物理工程的这种背景下，预测方法通常是最好的。你可以在维基百科的文章．

你可能会问:“误用瀑布有什么错?”“我担心的是，这让人太容易陷入预测式项目管理没有价值的陷阱。或者一个薄弱的或缺少的过程也是预测性项目管理的一个特征。这两种说法都不对。预见性项目管理强调有充分理由的强大过程。而且，有时候，我们需要事先仔细计划能给我们的保证。

敏捷:更好的叫法是适应性项目管理

敏捷与其说是一个项目管理框架，不如说是一套价值观和原则。然而，有一些框架和方法或多或少地符合这些价值和原则。也许介绍敏捷项目管理的最好方式是一个短视频:

敏捷的主要特征是可交付成果的增量生产、交付、测试和验收。这发生在较短的迭代中，通常是1-4周，这取决于您选择的敏捷方法。Scrum方法调用这些迭代“冲刺”．

在敏捷中，我们通常定义用户的下一组需求(“用户故事”)在每个迭代的开始，而不是在项目的开始在一个单独的定义或需求收集阶段的全部集合。之后，我们可以在冲刺过程中细化我们对用户描述的理解，以创建正式的需求。

然而，在敏捷中，我们经常在一开始就定义高级特性集。然后我们将其分解为可以在迭代中完全定义和开发的离散项。敏捷的一个关键目标是在整个开发周期中尽可能地保持灵活性。这就意味着，我们有时会用一个更精确的视角来看待问题。

敏捷宣言摘要

敏捷宣言于2001年问世，由17位作者共同完成。在这份报告中，他们指出:

个人和互动超越过程和工具

工作软件文档过于全面

客户协作关于合同谈判

响应变化按照计划行事

也就是说，在有价值的项目在右边，我们更看重左边的东西。

敏捷软件开发宣言

敏捷宣言的四个价值观是什么意思?

1. 个人和互动超越过程和工具
   敏捷非常强调自我管理团队和强大的沟通。这对于预测性项目管理来说并不陌生，但是敏捷促进了新工具和方法的创建。
2. 工作软件文档过于全面
   这里的重点是用户可以在早期开始使用的产品/可交付物，而不是记录完整的需求集。敏捷开发人员经常使用这样的术语:
   1. “最小可行产品”(MVP) -一种产品具有最小的功能和功能集来执行有价值的功能。它被用作如何改进MVP的早期反馈的基础。
   2. 可交付产品的-可以转化为有益用途的产品
3. 客户协作关于合同谈判
   我认为任何一个项目经理都会与他们的客户充分接触。对我来说，敏捷和预测性PM之间的最大区别 在这里,在于合作的程度。
4. 响应变化按照计划行事
   同样，这里的差异是程度的问题。传统的项目方法有变更控制过程。敏捷项目是围绕着一个持续的循环来构建的，这个循环就是审查和更改最终产品的下一个迭代的范围和规格。如何管理变更控制的关键决定因素是与用户/客户的关系。

敏捷的12个指导原则

为了支持敏捷宣言，作者也开始着手敏捷项目的12条指导原则，这是敏捷宣言的基础。总结一下:

1. 最优先考虑的是通过早期和持续交付有价值的软件来满足客户。
2. 更改需求，即使是在项目的后期，也是不可避免的，而且是一件好事。
3. 经常在短时间内交付可工作的软件(最多几周到几个月)。
4. 业务人员和开发人员必须在整个项目中每天一起工作。
5. 围绕有积极性的人建立项目。给他们所需的环境、资源和支持。然后相信他们能完成工作。
6. 传达信息的最好方式是面对面的交谈。
7. 进度的主要衡量标准是可用的软件。
8. 敏捷过程是可持续的，可以持续到交付客户端和用户指定的所有内容为止。
9. 卓越的技术和良好的设计增强了敏捷性。
10. 最大限度地减少未完成工作量的方法是简化。
11. 最好的工作是由自组织的团队完成的。
12. 团队思考如何更好地定期工作。他们应该相应地调整自己的行为。

敏捷:什么是真正的新?

注意，作者明确地提到了软件项目，并没有打算将他们的原则用于其他形式的项目。也就是说，其中许多原则是所有“传统”项目经理都能很愉快地执行的。

我的另一个担忧是，敏捷开发人员倾向于认为，有了敏捷，就会出现增量和迭代开发。然而，作为一个植根于预测性项目管理的项目经理，我可以肯定地告诉你，早在敏捷宣言发表之前，我就已经交付增量产品和迭代开发工作了。除此之外，我们还有:

• 与利益相关者仔细协商，优先交付他们最看重的东西
• 在整个开发过程中允许变更的有效变更控制过程
• 在同一地点的团队面对面地讨论当前的问题，只要问题一出现
• 来自不同职能的多技能团队，决策者都在同一间屋子里
• 每天的团队会议——我记得在一个项目中有七个人站着开会
• 定期交付和测试周期
• 经常讨论经验教训，并相应地改变实践

敏捷方法可以用于物理工程项目吗?

也许最著名的敏捷方法是Scrum。它的起源而不是项目管理，而是产品管理。1986年1月，哈佛商业评论(HBR)发表了“新产品开发游戏竹内广孝和野中郁次郎的作品。这是关于新产品的一种新方法 的发展,或NPD。他们采纳了…的想法“ba”——这是日本野中造词，意为思想和汲取知识、创造新思想的能量的汇聚之地。它使用了橄榄球运动的核心运动隐喻:Scrum。

做阅读野中和竹内的故事，以及Scrum的起源．结果是，物理产品的开发肯定能从敏捷方法、思维和工具中受益。

敏捷与瀑布法:主要区别

敏捷和瀑布模式的主要区别在于程度。

请注意:对于我在这张表中提供的每一个看似截然相反的观点，事实要微妙得多。虽然“纯粹的”瀑布式或“纯粹的”敏捷的柏拉图式理想可能符合这里的描述，但在现实世界中，我们看到项目占据了一个光谱的区域，而不是特定的端点。

传统的方法……	敏捷方法……
确定修复范围的优先级	优先考虑 范围灵活性
在开始交付之前计划一个集成项目	在交付过程中开发项目的大部分内容
计划完成后开始增量交付	在第一次迭代时开始增量交付(因此加快了利益和价值的交付)
为项目经理创建控制结构	授予项目团队成员更大的自主权
自始至终与利益相关者保持联系和协商	明确地将利益相关者放在首位
通过结构化过程控制变更	方法的核心是否有变化
通过批准的计划控制进度和成本	进度和成本的增长，以满足新兴的范围
范围是预先提交的，因此很难终止以管理成本和计划超支	范围是不断检讨的，只有在价值案例足够强大的时候才会增加

敏捷听起来不错，为什么不是通用的

首先，敏捷并不适用于所有情况，这一点我们很快就会讲到。其次，虽然这对许多组织来说可能是正确的，但经常会有一种感觉控制能力下降的恐惧。这可能会阻碍敏捷的采用——当然还有对未知的恐惧。

然而，即使您的组织确实选择进行更改，转向敏捷也是一项巨大的投资，包括时间、精力和金钱。

学习开销

瀑布式项目管理和敏捷项目管理都有专业技能，需要长期学习、实践和开发。现实情况是，“传统的”项目经理不可能只读一本书，然后就领导一个敏捷项目。

敏捷的原则很简单。技能来自于有效的练习。这需要大量的训练和经验。许多组织、项目经理和项目团队没有充分认识到这一点，或者不想投入投资或努力。因此，他们试图通过死记硬背的方式来进行敏捷项目管理——遵循一种简单的指导手册方法。然而，如果你不完全理解实践的原则和原因，领导和交付不好的敏捷项目通常不会很成功。

我的朋友，敏捷专家Chuck Cobb他指出，在典型的敏捷环境中，在团队层面没有一个人被称为“项目经理”。当然，不同的敏捷方法和实现意味着有些方法会有PM。

相反，通常可能由项目经理执行的功能分布在团队中的其他角色中。这给团队中的人员增加了非常大的新负荷，除了他们的正常角色之外，还要实际执行一些项目管理功能。这就是学习困难的一个重要原因。

这是恰克写的一篇文章:

什么是分布式项目管理?为什么说得通?

时间、成本、质量、范围:敏捷vs瀑布法的影响

比较敏捷和瀑布方法的有效方法是通过时间、成本、质量和范围这四个约束条件的镜头。在这四种情况中，范围承担了差异的负担，因为在敏捷中，范围是一个大变量。在整个项目中，时间和成本都是不同的。

使用预测性项目管理，我们经常确定范围，然后选择时间、成本或质量优先级。然后，我们优化剩下的东西。

让我们依次来看这四个。但是，请务必记住，我已经展示了最大的差异，我可以强调对比。当然，在现实中，差异通常更微妙，重叠也更大。

时间

预见性项目管理寻求基于以下任何一个来确定计划:

• 一个项目外部的截止日期，或者
• 在给定范围、质量和资源限制的情况下，可实现的完成日期

另一方面，敏捷提供了每次迭代的时间表确定性，因为它使用固定的时间 块,或效力。但项目完成与否并不确定。

预见性项目管理使度量和评估进度变得更加容易。然而，敏捷方法允许用户在早期阶段查看和测试工作迭代，然后在整个项目中频繁地查看和测试。这可以增加他们对新兴产品的所有权感。

敏捷开发的迭代特性很容易导致工作范围的频繁修订，超出最初的定义和设计。在这种情况经常发生的地方，客户可能会面临时间尺度显著延长的风险。这也对成本预期产生了影响……

成本

成本反映进度。在预测性项目中，我们在一开始就计划和预算整个项目。在敏捷项目中，我们做增量决策。这为我们提供了一个很好的成本控制，用于逐sprint的支出，但是 可怜的对最终产出成本的估计 开始．

毫无疑问，敏捷项目管理的某些方面确实会带来较低的成本基础:

• 减少了开发文档的开销
• 对不再符合正确规范的早期特性的返工较少
• 避免“功能膨胀”——引入不会产生足够价值的范围项目

敏捷专家还声称敏捷团队的效率更高，但我确实怀疑他们能否以可靠的证据来支持这一点。生产力取决于很多事情，对于每个高效的敏捷团队，我希望能够向您展示一个以更传统的方式工作的同样高效的团队，以及一个浪费和低效的敏捷团队!

质量

我们可以为两者设定和定义质量。但如果质量依赖于集成许多组件，你所做的事情的确定性 会交付允许预测性的方法预见集成点，并有效地计划它们。

在敏捷项目中，质量被构建在每个迭代中，而不是一个连续的活动，在时间压力下可能会丢失或最小化。在敏捷项目中还有一种感觉，团队成员在很大程度上相信质量不是“别人的责任”。在预测项目中，它经常与负责质量设计、保证和控制的人一起工作。

敏捷开发人员可以合理地宣称，这样做的一个结果是，在敏捷项目之后，客户的满意度特别高。不过，这可能是因为在各个阶段都有更高程度的客户参与。然而，在预测方法中没有任何东西阻止广泛的用户和客户参与。

范围

在敏捷中，范围是迭代增长的。我认为这是两者之间最大的区别。敏捷方法的一大优势是范围的增量定义。你没有必要过早地确定你所需要的每一部分。它还允许更容易地适应新需求，以及重新确定优先级。最后，当新的增量不能为用户提供足够的价值时，敏捷方法可以很容易地停止向范围添加内容。

敏捷的另一个好处是能够迅速将最小可行性产品投入市场或投入有益的使用。这在明确节约或领先于竞争对手方面具有巨大的商业优势。从每个新的迭代中获得的经验教训可以为下一个工作周期(迭代)的重点提供以客户和用户为中心的决策。

敏捷带来的一个挑战来自于用户和客户的高度参与:如果他们既没有时间也没有意愿去做贡献呢?良好的敏捷开发高度依赖于与用户和客户的密切合作。

敏捷vs瀑布:何时使用每种方法

二选一是愚蠢的。敏捷和预测项目管理都不是最好的。在一定范围内，每一种说法都是正确的。而且，在现实中，选择不是一个简单的非此即彼的问题。

敏捷在很大程度上受到受过敏捷训练的交付团队成员的青睐。但是他们的客户需要在截止日期前计划与操作程序的集成，他们希望有更多的确定性。当这些赞助者需要制定并遵守预算时，敏捷不愿意估算成本会非常令人沮丧。

然而，如果做得好，并且在正确的环境中使用，敏捷交付可以:

• 降低风险
• 加快上市时间
• 降低成本
• 更快地响应更改

另一方面，敏捷方法确实需要额外级别的培训。要将它嵌入一个组织，需要一大批受过训练的人员，但也不止于此。这是如何做事的一个重大变化，因此需要大量的转换工作。这样做的缺点是真正的破坏，所以如果这还不够，你需要正确地改变过程;时机将是一个关键因素。事实上，在大型项目中使用敏捷方法仍处于开发阶段。您需要注册成为早期采用者，并承担由此带来的所有风险(和潜在回报)。

但有一些关键指标可以帮助我们评估什么是最合适的:

• 规模项目的，以:
  • 预算
  • 持续时间
  • 团队规模
  • 产品集
• 复杂性项目的，以:
  • 技术
  • 相互依赖关系
  • 团队动态和物理约束
  • 涉众的政治
• 赞助的组织，及其:
  • 文化
  • 嵌入式实践
  • 客户偏好
  • 圣 一个keholder看法

传统的预见性项目管理是最好的……

让我们从两大公司开始。预测式项目管理可能是最好的起点，当你:

1. …有明确的解决方案您需要实现的是一种完整的方式。
   最明显的例子就是桥梁。半座桥也没用。你也不希望工程师对桁架或柱子的强度进行反复试验。
2. …需要高度的可预测性低不确定性
   这可能是由于治理或政治原因，或者仅仅是因为其他人需要围绕您的项目进行计划。当客户和发起人需要交付范围、预算和进度的高度确定性时，您至少需要项目的预测性外壳。

建议采用预测性方法的其他情况

• 你需要的项目 协调与其他团队，项目，职能单位，或 组织
• 当你有一个”虚拟团队”与远程工作者一起
• 小型、简单、定义良好的项目
• 客户端和用户无法参与频繁决策的项目

敏捷的，适应性的项目管理是最好的……

对于您的项目，我们有一个相应的两大指标:

1. 需求定义不清一开始
   因此，您必须通过对驱动项目开始的核心需求的一系列增量添加来发展需求。这可能是因为人们不愿意承诺一个最终状态，也可能是因为他们不能——他们没有知识。一个很好的例子是一家初创公司推出了一款新的软件产品。客户将提供反馈，以帮助开发团队确定修复程序和特性的优先级。不确定性要求自适应方法的灵活性。
2. 当你需要快速实现一些东西.．.
   但事实并非如此 完整的一开始。敏捷方法通常创造更快的开发时间，产品可以更快地投入使用或进入市场。增量开发允许在没有整个解决方案的情况下尽早交付解决方案的第一部分(MVP) 再保险或者是完全定义。

建议采用适应性方法的其他情况

• 创造力和创新可以使你创造的产品和解决方案的价值最大化
• 一个小团队负责整个项目的项目
• 您的项目在很大程度上是独立于其他活动、计划和项目的。
• 该团队位于哪里，能够很好地沟通
• 您的客户和用户已经准备好了、可用了，并且热衷于完全参与其中
• 没有必要宣布成品的确切交货日期
• 没有完全的解决方案

Agile-Waterfall混合动力车

融合烹饪不是把咖喱粘在披萨上，然后期待它的味道很好。同样，创建敏捷和预测原则和工具的工作混合是一个经验丰富的从业者的任务。而且是由一个对两种传统都有深刻理解的人。

在英国，我们有这个词“关闭”．这是将两辆或更多损坏的汽车的残骸焊接在一起，形成一辆“新”汽车。出于明显的安全考虑，这是违法的。同样，将工具和技术结合在一起的“弗兰肯斯坦怪物”式的项目方法是行不通的。你需要的是一种微妙的混合。

一个例子可能是结构化规划的外部框架，以及在该框架内进行产品开发的自适应方法。Chuck Cobb，我们推荐他的敏捷培训，说明了他的管理敏捷开发框架的一篇短文．

从预测到自适应的光谱

如何结合敏捷和预测过程、思维模式和工具，必须遵循项目的需要。在前一节中，我们已经了解了每种方法的特点。早些时候，我们看到了每种方法的作用。可问的问题包括:

• 你需要的最终结果有多清晰?
• 你的客户和赞助商的优先级是什么 确定功能、预算和进度?
• 你想通过计划来控制风险还是限制你的承诺?
• 你的团队是什么性质的?
• 你的技能和经验在哪里?
• 手头的任务有多熟悉，或者创新有多重要?

这就产生了一系列的需求和结果，您可以将其与精心制作的混合产品相匹配。我没有资格为如何做到这一点提供建议，但下图演示了如何在不同级别将敏捷过程包装到预测框架中。

将项目管理知识体系指南过程组压缩到适应性和混合环境中

项目管理学会(PMI)正在编写第7版的项目管理知识体系(项目管理知识体系指南)．我希望这次会议能深入讨论如何选择敏捷与瀑布模式，以及如何创建有效的混合项目。

但是，在写这篇文章的时候，我们有PMBOK指南第6版及其伴随敏捷实践指南(APG)。我不会在这里深入阅读《敏捷实践指南》，而是注意到第三章“生命周期选择”对混合解决方案进行了轻量级介绍。想要了解更多关于指南的信息，请查看我们的文章。PMI的敏捷实践指南:你需要知道什么”。

我要做的是看一看PMBOK指南的附录X3:“敏捷、迭代、自适应和混合的项目环境”．它比APG的第三章要短，但在我看来，它更清晰、更有帮助。

但它也解释了五个项目管理知识体系指南过程组在适应性和混合项目方面的作用。

五个过程组

1. 启动进程组
   自适应生命周期中的每个迭代或冲刺都需要自己的启动
2. 规划过程小组
   围绕自适应或混合项目将有高级计划，但没有为预测性项目创建的详细计划。在这个计划中会有迭代的、适应性的周期。
3. 执行进程组
   每个迭代都将根据您选择的敏捷方法进行管理。但这些都位于整个项目框架内。
4. 监控过程组
   与执行一样，根据您选择的方法，监视和控制将在交互中发生，并在迭代周期之上，以创建总体项目治理和报告。
5. 关闭过程小组
   同样，每个迭代都需要关闭，更广泛的项目或其中的任何阶段也是如此。

领域对敏捷和瀑布的影响

荷兰的毕马威(KPMG)编制了一份有价值的调查报告，“敏捷项目交付”(2017)。第8页的一个有趣的图表显示了在不同学科中采用敏捷和混合方法的情况。如果您已经读到这里(而不是略读)，那么结果与您所预期的非常相似。

确定性是最重要的，而创新是最不重要的，占用率最低，最依赖传统项目管理的领域是:

• 采购(约占敏捷和混合方法的15%)
• 物流(~ 25%)
• 金融(~ 30%)

在另一端，我们看到两个重视创造力和增量改进的规程，以及IT，敏捷就是在这两个规程中出现的。

• IT(大约85%采用敏捷和混合方法)
• 销售(~ 65%)
• 营销(~ 55%)

运营约占50%，人力资源约占35%。

敏捷vs瀑布:结束语

我希望在阅读这篇文章的过程中，您已经对敏捷vs瀑布困境的微妙之处有了更敏锐的认识。你不应该把它们看成是对或错，也不是二选一。相反，作为项目专业人员，您的工作是掌握这两个领域的技术，并开发有效的方法将它们结合起来，以满足项目在其上下文中的需求。

你对敏捷和瀑布有什么看法?

请务必在下方留言，我会回复所有的投稿。

关于这个主题的一些非常棒的文章

正如你所料，这是一个很多人都在写的话题——通常都是充满激情的。我试图给出一个大致客观的概述，并明确提出一些观点。其他的文章更尖锐，但仍然值得 阅读,当他们被仔细考虑的时候。我特别看重以下文章:

• 查克·科布-例如:敏捷vs瀑布法的真相是什么?
  查克是我们推荐的医生在所有级别学习敏捷．他的博客有很多关于敏捷如何工作的很棒的内容。
• 凯文·朗-例如:为什么敏捷永远不能成为一个项目管理框架
  凯文有很多关于他的文章，有些很犀利PMIS咨询博客．
• 本阿斯顿数字项目经理也有一些关于敏捷项目管理的优秀文章．
• 如果你想…
  学习敏捷项目管理.．.
  manbetx3.0app