敏捷还是瀑布（顺序）—— 哪个更好？

作为一名敏捷实践者、培训师、教练和顾问，你可能会期待我说："敏捷是成功的唯一途径——付给我很多钱，我来告诉你为什么！"

但事实是这样的（剧透提醒）：我只能用"视情况而定"来回答这个问题。这听起来可能很模糊，但这往往是最诚实和最有价值的回答。

最终，只有你能决定什么最适合你的项目和组织，这要基于你比我更了解的驱动因素和约束条件。我希望这篇文章能帮助你自己找到答案。

让我们首先来看看每种方法背后的核心理念。

瀑布式项目管理遵循顺序化、预测性的方法。范围通常是固定的，解决方案往往在开发前就已完全确定。交付可能以单次"大爆炸"方式进行，或分阶段进行，每个阶段交付整体解决方案的重要组成部分。

典型的瀑布方法包含以下步骤：

1. 分析：识别、记录、达成一致并批准需求和任何质量标准。在IT领域，这包括非功能性需求。
2. 设计：创建并批准满足已达成一致的需求和质量标准的详细设计。
3. 构建：根据设计构建解决方案，确保满足所有指定的需求和质量标准。
4. 测试：彻底测试解决方案，以确认其满足已达成一致的需求、设计和其他质量标准。
5. 部署：将解决方案投入使用，以实现其预期的业务价值。

每个步骤都必须进行规划和资源配置，所有活动都要明确识别、估算和分配。在许多情况下，活动会被分解为详细任务并以甘特图的形式记录。对于分阶段的项目，应首先进行高层次的分析和设计，为各个阶段设定背景和范围。

瀑布方法需要一种预测性的项目管理方式，其中每个步骤都产生文档，概述下一个步骤需要做什么。

每个步骤的所有工作都基于一个期望（本身就是一个预测）进行规划，即结果将与商定的内容相匹配。经过适当批准的文档是向所有参与或受影响的人员传达项目意图的主要方式。

项目控制依赖于证明交付的工作与前一步骤的文档相匹配，以及遵循当前步骤的已批准计划。任何变更都应通过正式流程，在其中修订和批准文档。理想情况下，应定期审查文档以确保它仍然满足不断变化的业务需求。

变更可以从瀑布流程中后续步骤的工作中识别出来。例如，在测试步骤中发现的问题可能识别出指定需求与当前业务需求之间的不匹配。需要对这种不匹配进行分析，任何商定的变更都会沿着瀑布向下级联，最终需要再次测试。

因此，在瀑布模式中对成功的感知往往与预测与实际需求的匹配程度，以及产出在预算、时间表和质量方面与预测的契合程度相关。

瀑布流程起初可能看起来很简单，但往往比预期的要复杂得多。它严重依赖文档，使用分级审批，并遵循集中式规划。由于它需要详细的前期文档和规划，该流程可能变得复杂，许多相关部分需要连接起来才能使流程达到预期结果。

优势：

• 结构简单明了：逐步推进的方法对项目经理来说易于理解，也便于向利益相关者解释。
• 可预测的规划：开始时的全面分析和设计支持清晰准确的规划和预算。
• 简单的跟踪：可以通过文档（显示里程碑如何达成）监控进度，并对照计划进行检查（确认任务按时完成且在预算范围内）。

劣势：

• 复杂的变更管理：处理必要变更可能很繁琐，有时会导致团队完全绕过流程，造成失控。
• 问题发现过晚：大增量的开发加上主要集中在流程末端的测试，可能会过晚发现问题，导致意外的延迟和成本超支。
• 对业务价值的关注度降低：大量的前期分析和文档没有直接的业务价值；它们的存在纯粹是为了指导流程。

虽然它仍然具有明确的流程要素来规范开发，但敏捷项目管理方法更注重人员而非流程。前期工作有意保持轻量，仅塑造高层次的解决方案和计划，将更细致的细节留到开发前的最后责任时刻。通常，开发在固定长度的"Sprint"中逐个功能地进行。

项目参与者——重要的是，包括开发团队中的业务人员——在整个项目过程中进行协作。他们使用迭代流程，构建比传统瀑布模式更小的增量。

每次迭代都包括分析、设计、构建、测试，理想情况下还包括部署，这些周期可能只持续几个小时，也可能跨越几天或几周（而不是瀑布模式中常见的几周或几个月）。目标是在解决方案的各个部分能够交付价值时就尽快部署。

开发依赖于具备知识和技能的个人之间的深度协作，这些人员获得组织授权来开发满足业务需求的解决方案。

这些人员在规划所需的开发工作之前先定义需求的详细信息。然后他们执行这个计划，不断调整以保持专注于交付最大价值。为了实现真正的敏捷性，团队通常遵循诸如Scrum中的价值观，Scrum目前是应用最广泛的敏捷交付方法。

迭代方法对变化具有很高的容忍度，因为它将详细规划推迟到最后负责的时刻，使用实时数据和短期规划周期。解决方案不是在早期就被完全预测，而是逐渐涌现，以满足在项目开始时概述的（但没有详细定义的）需求。

通过优先考虑高层次的需求并首先处理最重要的需求，敏捷团队能够保持对截止日期和预算的严格控制。一旦达到时间或预算限制，开发就会以可控的方式结束，只有价值最低的项目会被排除在最终交付之外。

由于开发周期短（通常约两周）且固定，通过以可预测的节奏增量交付价值来衡量成功是有意义的。

迭代和增量方法，通过由被授权的自组织团队驱动的短周期时间，通常看起来很混乱。但如果配备有能力、协作、有纪律的人员，它是高效且有效的。也就是说，在能力不足、缺乏协作和纪律的个人身上使用敏捷方法的风险很可能导致失败。这使得监督（但不是管理）变得至关重要，直到团队证明了他们的集体交付能力。

优势：

• 迭代开发：通过协作机会和持续反馈的快速开发周期，降低了构建不符合实际需求解决方案的风险。
• 增量价值交付：在短时间间隔内交付有形价值，通过使进度更容易跟踪和纠正措施更容易识别来改善整体控制。
• 适应性：将细节留到最后负责任的时刻，允许解决方案的出现以满足当前而非预测的需求。

劣势：

• 可能看起来不够结构化：特别是对于那些习惯基于流程控制的人来说。它不太适合有高度控制需求的管理者和领导者。
• 需要所有参与者的高能力和协作： 领导者需要有信心去信任，有能力去授权他们的协作团队。
• 混乱和失败的潜在风险：缺乏已证实能力和专业精神的团队在没有适当监督的情况下可能会失败。

注意：上述描述的劣势适用于刚接触敏捷工作方式的团队或组织，在真正具备敏捷能力的情况下，很难识别普遍的缺点，尽管可能会出现特定情况下的缺点。

敏捷方法与瀑布方法之间的关键差异可以从5个维度来总结：

1. 解决方案开发 – 渐进式 vs. 预定义式：

• 敏捷：解决方案随着时间推移逐渐形成，以满足不断变化的业务需求。细节在接近开发时才演进，保持解决方案的灵活性。
• 瀑布：解决方案预先定义以满足预期需求。需要谨慎的变更控制来保持与变化需求的一致性。

2. 项目参与者 – 协作跨职能 vs. 孤立专业化：

• 敏捷：团队成员协同工作，角色宽泛，为实现共同目标做一切必要的事情。目标是避免通过文档进行沟通，并尽可能减少交接。
• 瀑布：虽然通常也会有一定程度的协作，但往往专注于特定的专业化活动（如需求收集）。项目参与者倾向于采用主导20世纪思维的孤立工业工程方法，通常通过文档来管理沟通和控制。

3. 管理 – 自组织 vs. 管理指导：

• 敏捷：团队自我组织和管理，决定如何完成任务并在学习过程中调整流程。
• 瀑布：团队通常接受管理者的指导，由管理者决定必须做什么、由谁做、何时做。不过，这些指令的详细程度可能因项目或管理者的风格而有所不同。

4. 变化 – 拥抱 vs. 抵制：

• 敏捷：由于团队朝着宽泛的目标努力而不预先定义每个细节，他们欢迎变化，因为新的需求或见解会不断出现。
• 瀑布：变更管理既官僚又昂贵，因为需要彻底的分析、文档记录和审批。因此，它往往成为必要变更的障碍。

5. 控制基础：专业纪律 vs. 流程合规

• 敏捷：高度依赖团队的能力、纪律和自组织。团队成员相互承诺，集体拥有任务和解决方案。
• 瀑布：使用详细规划和明确指令。每个人的角色都预先定义，项目经理协调活动。成功取决于按设计遵循计划和流程。

正如我之前提到的，这要看情况……

在当今复杂的世界中，运行完全敏捷或完全瀑布式的项目是不太可能的。更常见的是，团队发现一些敏捷性可以为主要采用瀑布式的项目增加价值，而一些瀑布式元素在其他方面敏捷的项目中也是有意义的。这种混合通常被称为混合方法，处于两个极端之间的灰色地带。

因此，项目经理的真正问题不是"我应该选择哪种纯粹的方法？"而是"我的项目应该处于这个光谱的哪个位置？"敏捷方法在高波动性、不确定性、复杂性和模糊性（VUCA）的环境中表现出色。相比之下，瀑布方法通常在事物更加稳定、确定、简单和清晰的情况下效果最佳。

Cynefin框架可以帮助您确定项目在这个光谱中的位置。

Cynefin，发音为 kuh-nev-in，是一个威尔士语单词，意指我们环境和经验中多重交织的因素，这些因素以我们永远无法完全理解的方式影响着我们（我们如何思考、解释和行动）。

在对Cynefin框架公认的过度简化中，我们工作的环境——在这种情况下是我们的项目环境——可以被放置在一个光谱上，其特征可描述为清晰、复杂、繁复或混乱。

在项目环境中：

• 明确的，问题和解决方案之间有明显的路径。
• 复杂的，问题和解决方案之间的路径可能不明显，但良好的分析会揭示通往合适解决方案的路径。
• 复合的，即使通过分析也无法确定单一路径，因为预测只能基于理论而非经验。
• 混乱的，没有预测的基础，因为有太多变化或冲突的因素。唯一的前进方式是通过实验。

在上述情况中，明确的领域适合采用纯瀑布式方法，混乱的领域需要敏捷性。其他两种情况——现实中最常见的——可能最好采用混合方法。所以，问问自己，"上述哪种情况最能描述我的项目环境？"并让这个答案指导你选择方法。

在决定项目最合理的方法时，你还需要考虑由组织规则和文化驱动的其他约束。试图让瀑布式方法在以敏捷性为特征的文化中发挥作用，或让敏捷方法在以指挥控制为特征的文化中发挥作用，都会造成问题。

混合方法可能更容易"推销"并取得成功。

敏捷宣言经过增强，扩大了其在软件之外的适用性，它确定了四个价值声明，旨在引导从业者采用敏捷行为。任何希望以敏捷方式工作的人都应该重视：

专注于左侧的项目，同时仍然承认右侧项目的价值。

尽管关于原始宣言是否完全适用于当今世界存在争议——特别是在软件环境中——这些价值声明仍然为项目治理提供了有用的指导。基于左侧项目来制定敏捷项目的治理，基于右侧项目来制定瀑布项目的治理是有意义的。

• 人员和团队合作：监督并促进专业纪律和协作。
• 交付业务价值：专注于支持业务需求的价值，而不是简单地完成流程要求。
• 积极的业务参与：让业务代表在整个项目过程中与团队密切合作。
• 在部署时满足当前需求：确保解决方案在发布时符合真实的业务需求——即使这些需求与最初计划有所不同。

• 遵循预定义流程：确保每个人都遵守既定的步骤和审批程序。
• 制作预测性文档：制定清晰的规范并检查解决方案是否与之保持一致。
• 妥善批准变更：验证对原始文档的所有变更。
• 遵守计划：确保计划保持准确并能响应已批准的变更。

在混合设置中，治理必须在敏捷和瀑布元素之间找到合适的平衡。这涉及根据项目的具体情境，定制每种方法的哪些部分最为合适。

最有效的项目交付方法应该根据具体情况来确定——既要考虑工作的性质，也要考虑项目所处的环境。要警惕那些将纯敏捷或纯瀑布方法作为普遍适用的成功秘诀来推广的人。

最后再次引用Cynefin框架——它描述了一种困境（意为僵局）或混乱状态，这不是一个好的状态。如果你无法或不愿意将项目方法与其环境和背景相匹配，你很可能会发现自己和你的项目都在这种状态下受苦。

你需要独立思考，分析具体情况，并采取相应行动。通过这样做，你就有最大的机会从困境/混乱状态转移到其他状态，在那里某种方法（很可能是混合方法）将优化你获得项目成功的机会。