敏捷还是瀑布：为您的企业选择合适的软件项目方法

当企业决定构建新的应用或系统时，迟早会遇到一个听起来很技术化的问题：我们用敏捷还是瀑布？供应商谈论冲刺、待办列表和迭代，而财务部门想要的是价格与日期都确定的合同。这两个世界似乎相互冲突，许多企业主夹在中间感到迷茫。

事实上，没有哪种方法永远正确。每种方式在某些情形下有优势，在另一些情形下会带来问题。危险之处在于，因为潮流或因为名称听起来时髦就做出选择，却不理解工作方式、风险分担以及您作为企业主的角色究竟发生了什么变化。

本文用通俗的语言解释敏捷与瀑布的区别、各自适用的场合、如何为两者设计合同和预算，以及混合方式为何常常是中小企业最现实的答案。目的是让您能够与供应商平等地讨论，避免项目中途出现意外。

摘要

• 瀑布按顺序逐阶段推进；敏捷反复交付小块成果
• 瀑布适合稳定而清晰的需求；敏捷适合仍在演变的需求
• 敏捷需要企业主积极参与，而不只是在开头和结尾签字批准
• 只要设计得当，敏捷中的合同和预算同样可以保持纪律
• 许多真实项目采用混合方式：前期规划，分阶段交付

构建软件的两种思路

瀑布把项目看作一系列有序的阶段：收集需求、设计、开发、测试，然后交付。每个阶段完成并获批后，下一阶段才开始。一个容易理解的类比是盖房子：先完成完整的图纸，然后才按图施工建地基和墙体。

敏捷把项目看作一个反复学习的过程。团队不是等到全部完成，而是在短周期内（通常为两到四周）交付小而可用的功能片段。每个周期结束后，成果会被评审、反馈被收集，并为下一周期调整优先级。

根本区别在于对不确定性的看法。瀑布假设需求在开始时就能被完全理解。敏捷承认在许多软件项目中，需求只有在人们接触到真实的东西之后才会真正明白。因此，敏捷以计划的确定性换取调整方向的能力。

瀑布的优势与不足

瀑布的主要优势是可预测性。范围、进度和成本在开始时就已确定，便于在不同供应商之间比较，也便于写入固定价格合同。文档通常齐全，这在系统需要移交给其他团队或接受审计时很有帮助。

不足之处在现实发生变化时显现。用户往往在看到系统运行之后才意识到自己真正需要什么，而在瀑布中这发生在最后阶段，此时修改最昂贵。结果可能是一个符合文档却不符合现场需求的系统。

对于需求清晰稳定的工作，瀑布依然非常合理，例如结构化的数据迁移、与固定法规的对接，或构建已被充分理解的模块。在这类情况下，周密的规划反而节省时间和成本。

敏捷的优势与不足

敏捷的优势是早期反馈。用户在数周之内就能看到并试用真实成果，因此误解在修复成本还很低时就被发现。当市场情况变化时，企业也可以调整优先级，而无需重新谈判整份合同。

敏捷的风险在于纪律。没有清晰的目标和坚定的产品负责人，项目可能无休止地蔓延，因为总有新东西可以添加。如果没有共同守护的边界，预算和完成日期就会变得模糊。

敏捷还需要您的时间。团队需要一位了解业务的人每周甚至每天快速做出决定。如果企业主只在上线时才出现，敏捷就失去了它的主要优势，变成了一场混乱的瀑布。

如何根据项目情况选择

首先评估您的需求有多清晰。如果业务流程已经成熟，最终成果可以详细描述，那么更有计划性的方式会很高效。如果您在探索新产品、尝试新的服务模式，或用户从未使用过类似系统，敏捷要安全得多。

还要考虑您和团队的可用时间。健康的敏捷需要业务方有一位既有时间又有决策权的人。如果做不到，前期结构更为严谨、评审节点明确的设计可能更现实。

最后看风险的性质。如果最大的风险是误解用户需求，就用分阶段交付来降低它。如果最大的风险是违反法规或集成过于僵硬，那么前期规划和全面测试更为重要。

敏捷项目的合同与预算

最常见的担忧是：范围不锁定时如何签合同？答案是锁定别的东西。您可以设定最高预算、截止日期和清晰的业务目标，然后让功能清单在这些限度内调整。

一种常见形式是带上限的按团队或按时间计费合同，您按周期付款，并可在某个周期结束后停止或改变方向。另一种变体是在每个周期之前就商定的按功能包固定价格。两者都保持了纪律，又不会让团队困于过时的规格说明。

确保合同涵盖重要事项：代码所有权、对代码库和环境的访问、每个成果的验收标准，以及以有序交接结束合作的权利。无论采用哪种方法，这些都能保护您。

您作为企业主的角色

在敏捷中，企业主或其代表扮演产品负责人这一重要角色。任务是确定优先级、快速回答问题，并决定哪些内容进入或退出下一个周期。这一角色不能委托给不了解业务或没有权限的人。

养成按业务价值而不是功能数量来评判成果的习惯。问一问：用户现在能做到哪些以前做不到的事？节省了多少时间？这样的衡量有助于您拒绝那些看似诱人却毫无影响的附加项。

安排简短而稳定的定期评审。每周二十分钟的评审，远比每月一次两小时的会议更有用。出现问题时要立刻讨论；任由意外堆积是项目出问题的主要原因。

估算与应对不确定性

无论采用何种方法，时间和成本的估算都是最常令人失望的部分。项目越早期、未知因素越多，可能性的范围就越宽。诚实的供应商会给出带假设的区间，而不是看似确定却脆弱的单一数字。

要求把估算拆分为小的部分，并标出哪些风险较高。不清楚的部分应先通过简短的试验（常称为探针或原型）进行调查，让不确定性在投入大笔预算之前就降下来。

为意外情况预留合理的应急金，一般为总预算的一小部分。有计划的应急金远比项目中途紧张的重新谈判更健康，也让所有人对风险更加坦诚。

短周期中的质量与测试

短周期并不意味着可以牺牲质量。优秀的团队会在每个周期中纳入测试，而不是堆到最后。针对重要部分的自动化测试，能防止新功能加入时旧功能被破坏。

从一开始就定义“完成”意味着什么。一个功能片段在经过测试、有适度的文档、可以演示，并满足商定的验收标准时才算完成。清晰的定义能避免这样的局面：几乎所有东西都完成了，却没有一样可以使用。

在每次小型发布时让真实用户参与验收测试。他们会发现技术团队或管理层没有想到的问题，从令人困惑的术语到不合常理的操作步骤。

文档与交接

敏捷常被误解为没有文档。实际上，文档是按需、适量产出的：架构决策、系统的运行与恢复方法，以及用户指南。简短而鲜活的文档，比从未被翻开的厚厚一叠更有用。

确保您拥有所需的一切访问权限，以避免依赖单一供应商：源代码、环境、凭据和配置说明。这并非不信任的表现，而是保护双方的健康做法。

从一开始就规划交接，包括对内部团队的培训和上线后的支持期。以有序交接收尾的项目，将来无论由谁维护和扩展都更容易。

与位于不同地点的供应商合作

许多项目由位于其他城市或国家的团队完成。这完全正常，但需要沟通上的纪律。设定可重叠的讨论时段、约定的沟通渠道，以及记录决策的方式，使其不依赖记忆。

留意背景差异。对您来说显而易见的业务术语，如某种税种或审批流程，外部团队可能并不了解。提供简短的术语表和真实案例，并不要犹豫邀请团队亲眼看看日常工作是如何进行的。

定期的演示，无论录制还是直播，都能让所有相关方无需出席每次会议就能跟上进展。有了这个简单的习惯，对于管理良好的项目，地理距离很少成为障碍。

最常奏效的混合方式

在实践中，很少有项目是纯粹的某一种。常见而有效的模式是：先做轻量的前期规划，确定目标、架构和最大的风险，然后以短周期分阶段交付。这样您既获得清晰的方向，又保有灵活性。

另一种模式是把项目拆分为稳定部分和探索部分。需求明确的模块，例如会计系统集成，可以更有计划地完成，而新的用户体验则通过用户试用逐步设计。

选择一个范围窄但完整的首个版本，常称为最小可行产品。它更早触达真实用户，提供决定下一步的数据，并减少您在开始时必须下的大赌注。

项目偏离轨道的迹象

• 演示展示的功能都能运行，但没有人能从头到尾完整使用任何流程
• 需求清单不断增加，却没有任何东西被移除
• 决策因没有人有权限而拖上好几天
• 团队很少展示真实成果，多数时候只以百分比汇报进度
• 测试被推迟到最后，问题直到临近上线才暴露
• 直到项目快结束才谈到文档与交接

如果出现其中几种迹象，不要等待。召开评估会议，把重点拉回业务目标，并调整工作方式。方法不是目的，而是在风险可控的前提下交付价值的工具。

开始的实用步骤

1. 01用一两句话写下业务目标以及衡量成功的方式
2. 02梳理需求中哪些部分已经清晰，哪些仍充满疑问
3. 03在业务方指定一位有时间和权限的负责人
4. 04商定最高预算、截止日期，以及有序结束合作的方式
5. 05从一个小而可用的版本开始，然后定期评审成果
6. 06评估每个周期：什么有效、什么要改、下一个优先事项是什么

示例：选择混合方式的网店

一家网店想构建与仓库和快递公司相连的新订单系统。仓库集成的规则清晰而稳定，因此以详细规划和固定价格完成。相比之下，顾客结账体验仍有许多未知。

团队将其拆分：仓库集成在六周内以更有结构的方式完成，而结账则以两周为一个周期开发，每个周期都在真实顾客身上试用。结果是，确定的部分进度可控，仍在成形的部分则保持灵活。

常见问题

敏捷总是更便宜吗？不一定。敏捷并不会自动省钱，它降低的是构建错误东西的风险。总成本可能相同甚至更高，但所获得的价值更有针对性，因为无用的功能往往根本不会被开发。

给企业主的最后几点

无论选择哪种方法，都要守住三件事：清晰的业务目标、一位随时可用的负责人，以及定期的成果评审。这三者比方法的名称更能决定项目的成败，而且您今天就可以不花额外费用地开始。

结语

敏捷与瀑布不是敌人，而是用途不同的两种工具。决定成败的是方法与项目不确定程度的匹配、企业主的参与，以及坚守目标和预算边界的纪律。

如果拿不准，就从一个能产生真实成果、可以从中学习的小步骤开始。与供应商谈谈他们的工作方式，而不仅仅是价格，因为正是工作方式决定了您的项目是平稳推进还是充满意外。