瀑布开发与敏捷开发的区别，以及从瀑布转型敏捷项目管理的5大注意事项

事实证明，瀑布开发管理模式并不适合所有的软件项目，但敏捷项目管理却对大多数项目有效。那么当团队选择转型敏捷的时候有哪些因素必须注意？

敏捷开发最早使用者大多是小型、独立的团队，他们通常致力于小型、独立的项目。正是他们的成功经验，让世界各地的软件团队认为敏捷开发是可行的，且对自身也有改善意义。事实证明，瀑布开发管理模式并不适合所有的软件项目，但敏捷项目管理却对大多数项目有效。

也正因此，敏捷项目管理被越来越多的团队所采用，并且从单个团队扩展到多团队，甚至是软件团队之外，包括 IT、营销、业务开发等。

一、敏捷开发与瀑布开发的区别

敏捷开发与瀑布开发的区别在于：瀑布开发是最典型的预见性的方法，对那些可预测的、重复性的工作很有效。敏捷开发以用户的需求进化为核心，更适用于需求不明确、创新性强的项目，或者需要抢占市场的项目。

1、什么是敏捷项目管理？

敏捷项目管理是一种迭代式的项目交付方法，它通过高频迭代的方式，将项目分解为多个尺寸较小的“小项目”，每部分能够在远比瀑布模式短得多的周期内，快速而独立地走完计划、设计、构建、测试、发布的过程。所以每次发布后都能够根据市场/客户反馈调整，从而提升了速度和适应性。

这种方法与“预设性的”瀑布式项目管理方法不同，瀑布式项目管理遵循既定的路径，对市场变化响应及适应能力有限。当下的客户和企业需要快速响应以及调整，而敏捷提供了在开发过程中进行调整和迭代的灵活性。同时，敏捷项目管理也是 DevOps 实践的基石，开发和运营团队在该方式下协同工作。

敏捷原则：

• 敏捷项目分为几个增量步骤，并在每个增量的隔间收集反馈进行调整

• 项目需求拆解到足够小，然后按重要性排列它们的优先级

• 注重建立与客户之间的联系，团队之间的协作

• 定期调整以确保满足客户的需求

• 将计划与执行相结合，使团队能够有效地响应不断变化的需求

敏捷项目管理的优势：

• 更好的可见性和责任制

• 及早发现问题

• 更高的客户满意度

• 更短的反馈周期

• 更快响应市场变化

• 持续提升团队效率

• 价值导向的灵活优先级排序

敏捷项目管理的缺点：

• 关键路径和项目间依赖关系不如瀑布项目中清晰

• 组织适应敏捷需要考虑学习成本

• 真正的敏捷执行CI/CD，实现起来存在工程和技术成本

2、什么是瀑布项目管理？

瀑布式项目管理是一种预设性的软件开发模式，它将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六项基本活动；且规定了它们自上而下、相互衔接的固定次序，项目必须严格遵循预先计划的顺序进行。开发进程只有通过上一个阶段的验收审核，才能“流动”到下一个阶段。一旦一个阶段完成了，想再去“回头”调整前一个阶段就会很困难，且成本很高。敏捷项目管理虽然也遵循类似的顺序，但会以较小的增量和定期的反馈循环进行工作。

所以，瀑布项目管理方式对那些可预测的、重复性的工作很有效，而对于那些快速变化的工作，它可能会让开发团队落后于竞争对手以及市场。

瀑布项目在进行中如果延期或发生需求变更，就会对后续版本造成巨大影响。此外，瀑布项目中通常会让团队完全专注于下一阶段的工作，直到完成之前都是在开发全新的东西，那么这就会积累非常多的技术债务、缺陷，让解决过程变得非常痛苦。

下面是一个标准瀑布项目的示意图，它具有严格的时间阶段划分，这就使开发人员、产品经理和其他相关人员患得患失的，每个人都希望在自己的时间窗口中申请更多的时间，因为将来可能没有机会迭代。通常，瀑布团队会通过“变更控制”来控制范围蔓延，即维持原计划。

编辑切换为居中

添加图片注释，不超过 140 字（可选）

瀑布模型会加剧构建产品的一些已知挑战：

• 项目阻碍因素和依赖性的管理：传统的项目管理方式往往会有固定的流程，在彻底解决某个阻碍问题之前，项目是无法向前推进的。

• 难以获得用户反馈，对产品进行验证：在产品完全完成之前，客户无法体验和反馈，因此，产品设计和代码中的重要问题在发布前都不会被发现。

瀑布开发模式的优点：

• 每个阶段都有各自的角色和明确分工，所以一定程度会减少过程中的协调；

• 明确的项目阶段有助于明确界定工作之间的依赖关系；

• 在确定了需求后，可以对项目的成本进行估算；

• 有清晰的设计和需求文档，设计阶段更加有条不紊和结构化；

瀑布法的缺点：

• 需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。

• 变更代价大：需求变更会带来极大的时间浪费，开发人员普遍对需求变更有很强的抵触情绪。

• 束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。

• 周期漫长：整个开发持续的生命周期很长，需求和设计的耗时很大，有时候会占用三分之一甚至更多时间

• 招聘需求：满足不同阶段的专业人员意味着更多招聘岗位需求，而敏捷则提倡跨职能团队。

编辑切换为居中

添加图片注释，不超过 140 字（可选）

二、转型敏捷时要考虑的因素

敏捷转型并不容易，特别是当团队或组织长期使用传统项目管理方法的情况下，因为这将涉及观念、思维方式转变、流程的更改以及不一样的团队协作方式等。

比如，在转型的过程中，团队和利益相关者必须接受两个重要概念：

产品负责人的工作核心是优化团队输出的价值，而团队则是围绕产品负责人制定的工作优先级开展工作；

开发团队只负责他们有能力完成的工作，通常情况下产品负责人不会强制给团队指定工作；开发团队成员从迭代待办列表中领取工作任务，因为这样他们可以尝试新的任务类型。

下面我们将简单介绍，引入敏捷项目管理在组织、运行和工作流程方面必须关注的一些要素。

1、产品路线图

产品路线图是产品需求与其完成时间的概览，宏观的展示了产品的发展方向以及开发团队何时实现目标。路线图为敏捷开发提供了重要的背景信息，能够帮助团队了解以及实现增量和整个项目的目标。

有效的路线图不仅是一个强调产品发布和功能的时间表：它是一个动态的文档，产品负责人会在项目进行过程中根据实际情况不断更新，所以在创建产品路线图的初期，对需求、工作量、优先级、完成时间的估算不要求也无法很精确，这些内容都是随着项目进行不断细化调整的。产品路线图是产品负责人推动项目发展的重要工具，它告诉我们每个阶段应该做什么。

以下是产品团队的简单路线图，方框中包含大的发布计划，红色里程碑标记表示时间表。 

编辑切换为居中

添加图片注释，不超过 140 字（可选）

2、需求

路线图中的每个大的发布计划都可以分解为一系列的需求，敏捷开发中的需求指的是“轻量级”描述，而不是与瀑布项目管理中那样多达100 页的“详尽”文档。这是因为敏捷开发中的需求会随着时间的推移，团队会根据对客户和所需产品的共同理解而不断完善。

敏捷开发同时也是符合“精益”的一种方法，它要求团队中的每个人通过持续的沟通和协作达成共识，以这种方式在最终呈现完整的细节。

3、待办事项

敏捷开发中的待办事项一定是划分了优先级的。在待办事项列表中包括所有的工作项目，比如：新功能、bug、技术需求或架构任务等。产品负责人为开发团队确定待办事项的优先次序，然后，开发团队以此作为唯一的参考，确定需要完成的工作。

4、敏捷指标

敏捷团队的持续改进离不开度量指标。比如，看板方法下的在制品限制使团队专注于交付最优先的工作。燃尽图等图表有助于团队预测他们的交付节奏，而连续流程图有助于识别瓶颈。这些指标和工件使每个人都专注于目标，同时也增强了团队交付未来工作能力的信心。

5、敏捷以信任为基础

团队成员之间如果没有高度的信任，敏捷流程就很难运作。公开的流程和正确的产品目标、关于产品开展平等定期的对话，都有助于提升团队的积极性和信心。

小结

敏捷项目管理是一种创新方法，不仅适用于软件项目，而且适用于各种项目。通过提供在开发生命周期中响应变化的灵活性，团队能够交付满足客户需求且更高质量的产品。敏捷赋予团队权力，建立责任感，鼓励创新，同时促进持续改进。敏捷使您能够在不偏离轨道的情况下响应变化，这对任何工作都是有益的。

延伸阅读：

Scrum 开发指南： Scrum 框架详解 | Scrum 四个会议及正确召开方式 | 正确的计划和执行Sprint的方式 | 做好迭代计划的4大关键点 | 做好这4点让每日站会更适配敏捷团队 | 开好迭代评审会的3个关键步骤 | 为什么要召开迭代回顾会 | Scrum 3大角色及其岗位的具体职责 | Scrum三大工件在敏捷开发中的作用 | 2022年14个最佳 Scrum 敏捷项目管理软件 | 更多

Kanban 敏捷指南： 使用看板（Kanban）管理方法的5大好处 | 看板 VS Scrum：如何选择？ | 看板和 Scrum 的混合模式适合在哪些场景使用 | 更多

规模化敏捷： 规模化敏捷的价值及五大规模化敏捷框架 | 规模化敏捷之 Spotify 模型 | 规模化敏捷框架之LeSS框架 | 更多