在产品开发过程中，敏捷开发和瀑布模型都是常用的流程和开发方法，这两种方法是什么？细节是什么？这篇文章，为我们进行了解答。

成本、时间和质量是项目管理的铁三角，项目管理的核心目标是平衡好这三者之间的关系，尽量确保软件项目能够在可控的成本范围之内，符合质量要求地按期交付。

这里的质量我觉得包含了两方面：

1. 功能的完成度与稳定性；
2. 用户需求的满足程度。

在一些大型项目的交付过程中，面对交付过程中频繁变化的需求，按照既定合同内的需求以瀑布模式开发，虽然能发挥瀑布开发的优势，但在用户需求满意度方面肯定会有所损失，更严重的会导致返工改造、验收不通过。

相对“瀑布”模式的重，“敏捷开发”是一种应对频繁需求变化、快速响应的轻量开发模式，在以“瀑布模式”开发的项目中，将“敏捷”的理念引入，发挥各自优势，会对整个项目顺利的交付起到积极的作用。

本篇先讲下“敏捷开发”与“瀑布开发”的工作流程、适用场景、各自优缺点，然后将二者融合，谈一下在实际项目交付过程中的应用思考。

一、瀑布模式

瀑布模式是一种经典的线性开发模式，在传统的软件项目交付过程中被大量使用。

瀑布模式的整个项目周期是确定的，按照项目开发的时间可以分为规划阶段、需求分析阶段、软件设计阶段、编码阶段、测试验收阶段、上线阶段运维阶段等若干里程碑。

下面这张图生动地描述了瀑布开发的模式：

客户需要一辆代步工具，需要按照事先规划的方案，经过漫长的研发，最终给客户交付一辆汽车。

前期的方案是足够好，但在此过程中客户无法尽早体验产品，最终交付后产品可能不是客户实际想要的，从这个角度看风险很高。

一个典型的瀑布模式的产品研发流程

适用场景：

瀑布模式比较适合需求比较清晰的项目开发，比如签订合同的项目制交付，一般情况下合同内的需求都是确定的，乙方按照合同内的需求，按时交付即可。

理论上需求和设计方案确定后，在开发过程中需要严格执行，需求变动需要执行变更流程，或者另签一个补充协议。

优点

1. 由于需求相对比较明确，在前期可以对系统整体架构、扩展性进行整体、全面的设计；
2. 团队的目标相对明确，按照里程碑节点顺序推进，向目标前进的效率会比较高，易于管理和监督；
3. 每个阶段投入的人力不同，不同岗位的人员可以分批投入项目。

缺点

• 对业务需求的快速变化，灵活性不足，尤其是对于处于摸索阶段的新业务，这种变化是不可避免。
• 比如系统试运行、业务推进过程中会产生很多新的需求，我们之前按照合同内需求规划的设计可能要推翻或者有较大的修改，尤其在项目中后期，很可能将会导致项目延期，超出合同成本预算。
• 由于产品从研发到上线是一个线性的推进过程，在此期间客户没有真正看到过、体验过产品，最后上线，客户很可能对最终的产品不满意，重新改造的成本较高。

二、敏捷模式

敏捷模式是针对瀑布模式太重提出的一种小步迭代、快速反馈的开发模式，能有效的提高软件的开发效率，应对市场的快速变化。

下面这张图生动地描述了瀑布开发的模式。

客户想要一辆代步工具，为了快速满足可以出行的需求，按照敏捷的理念会先提供滑板、然后通过快速迭代逐步提供自行车、摩托车、小汽车。

在此过程中将产品快速投入市场，根据市场反馈，调整方向，虽然一开始提供的不是最优解决方案，但是一直在正确的方向上前进，不至于跑偏。

敏捷的核心关键词包括快速响应、迭代、增量交付、渐进式、面对面沟通、快速反馈与调整等。

敏捷项目管理通常采用Scrum敏捷框架进行实施，以固定时间盒的方式快速迭代，在实践中比较常用的是双周迭代的模式，在一个冲刺内完成增量开发的交付。

“增量开发主要是一块接着一块地构建一个系统。一部分功能先被开发出来，然后另一部分功能被加入前一部分功能，以此类推。”

《敏捷宣言》中的价值观：

个体和互动高于流程和工具；

工作的软件高于详尽的文档；

客户合作高于合同谈判；

响应变化高于遵循计划。

Scrum作为一个轻量级的团队协同工作方式，一个冲刺从开始准备到完成主要由以下几个关键活动组成：

1. 需求梳理，挑选需求并编写需求说明

一般由产品经理在冲刺开始之前从Product Backlog(类似需求池，Scrum中叫Product Backlog）中按照优先级挑选在本次冲刺（Sprint）内需求（这些需求可能为特性、用户故事、缺陷等，在Scrum中被称为PBI）。

产品负责人和开发团队要对当前冲刺准备实现的需求及冲刺目标达成一致意见，在此期间产品负责人需要完成产品方案、编写需求说明，并与需求方确认。

2. 需求澄清会（冲刺计划）

产品经理将当前Sprint中的需求向研发团队澄清，在澄清的过程中可以根据实际情况对需求的范围、方案进行调整。

每个需求澄清完毕，具体模块的研发人员可对需求的进行工作量的估算（故事点、规划扑克牌具体的估算方法这里不再具体说明）。

如估算的工作量过高，研发人员需要说明原因，最终会议结束确定本冲刺内交付范围，正式开启冲刺。

3. 任务分解

一般需求澄清回后，开发人员会将每个需要完成的需求（特性）分解成一组任务，这组任务及相关的PBI组成了“冲刺列表”，开发团队给出完成每项任务所需工作量的估算值（通常以小时计）。

4. 冲刺执行（开发实施与测试）

在团队冲刺的内容达成一致意见后，研发团队需要根据产品方案进行技术方案的设计，执行为了完成特性而所需的所有任务开发的工作。

5. 每日例会

在冲刺开始的每一天，研发团队会每天早上进行站会（通常不会超过15分钟）。

团队成员每天轮流回答下面三个问题，昨天我完成了什么？今天计划做什么工作？有什么障碍让我无法取得进展？

通过每日站会，每个人都能了解全局，知道发生了什么，冲刺目标的进展如何，是否需要帮助团队解决一些问题，实现一个冲刺内快速、流动的工作流。

6. 冲刺评审

冲刺周期的后期，团队给产品负责人和其他业务需求干系人、客户演示完成的成果，让各方了解已经交付的增量，检视和调整产品，同时业务互相交流，收集反馈并及时调整。

7. 冲刺回顾会

冲刺回顾会是检视并调整过程的时机，开发团队、产品负责人、ScrumMaste一起讨论，在上个冲刺中哪些过程是需要改进的。

需要注意的是冲刺回顾会不是吐槽、追责的会议，目的是帮助Scrum团队成长、下一个冲刺能够持续的改进。

适用场景

敏捷项目管理适用于业务需求变化频繁、比较适合创新型项目、市场需求变化快速的项目，主打一个“快速迭代”，在一些互联网公司、自研产品的公司比较常用。

优点

能够快速响应变化、提高客户满意度、减少项目风险，同时还能提高团队协作能力、加快产品上市时间。

缺点

对于一些成熟业务，由于追求快速响应，前期在系统架构设计上并不一定那么完美，另外对团队协作能力、敏捷理念的认可度要求比较高。

三、在项目交付过程中的思考

在实际的项目交付过程中甲乙双方立场的不一样，甲方期望乙方能在合同周期内尽可能多的满足需求，解决更多问题，而乙方期望能控制成本，如期交付，迫于甲方交付验收的压力，又不得不接受频繁的需求变更。

从实际经验来看，有如下原因将导致成本、质量、时间陷入三难的境地。

外部原因：

• 甲方业务比较新，存在边用边发现新问题的情况，合同外的、变更需求时有发生；
• 甲方不配合，如不配合调研、系统使用不积极、不提供数据等等；
• 实施过程中非研发类工作耗费太多时间，如数据处理、甲方汇报文件、配合业务开展等临时性工作安排、业务代运营等。

内部原因：

1. 合同签订前销售的对需求的过渡承诺，初设方案的不完善；
2. 系统规划设计阶段对整体应用架构、技术架构设计的不合理；
3. 需求分析不合格，设计出来的系统未能彻底解决甲方的问题，导致重复返工、打补丁；
4. 缺乏有效的项目管理流程，多人协作变得混乱失控，缺少风险跟踪，研发过程变得脆弱，导致研发效率和质量不高。

原因很多，本篇仅从项目管理的角度探讨，如何平衡成本、质量、时间的矛盾，达到甲乙双方共赢的目的。

有一种方式我叫做“大瀑布下的小敏捷”，将“敏捷开发”与“瀑布开发”相结合，发挥各自的优势，是一个实际可用的手段。

“大瀑布下的小敏捷”既能够按照“瀑布模式”的里程碑节点，交付目标相对明确，又能发挥“敏捷开发”快速响应需求的变化、持续交付的优势，提升客户满意度。

在大的项目周期内有明确的启动、需求调研、系统设计、编码开发、上线交付的里程碑节点，整体上看是瀑布模式的开发。

对于实际交付过程中频繁变更的新需求和合同内的老需求统一放进“产品代办清单”（Product Backlog），按照敏捷开发的模式拆分成一个个固定时间盒的冲刺，当下的冲刺内为优先级最高的需求，通过一个个冲刺完成增量产品的交付，直至项目交付。

敏捷开发是为了让团队达成一种在固定时间内持续交付的共识，一般一个冲刺开始时，该冲刺内的需求一般不允许变更。

但有些特殊情况，为了配合甲方汇报（一些G端项目常见），这些临时需求优先级会变得非常高。

此时研发团队可能正处在当前冲刺的开发中，不得不将主要精力投入配合汇报。

无论“敏捷开发”还是“瀑布开发”，流程是死的，人是活的，不同的公司、不同的业务可以根据实际情况灵活调整，切不可生搬硬套。

参考资料：《Scrum精髓》