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

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

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

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

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

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

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

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

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

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

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

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

适用场景：

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

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

优点

缺点

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

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

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

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

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

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

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

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

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

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

客户合作高于合同谈判；

响应变化高于遵循计划。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

适用场景

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

优点

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

缺点

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

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

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

外部原因：

内部原因：

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

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

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

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

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

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

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

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

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

参考资料：《Scrum精髓》

作者：卖油翁，来源公众号：数字化洞见

本文由@数字化洞见 授权发布于人人都是产品经理，未经许可，禁止转载。

题图来源于Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。