瀑布与敏捷:哪种方法最适合项目管理?

发布于 2022-05-20 08:13

洞察数字化未来！

来源：CDO之家

作者：Eden（花名：一灯大师）

全文共 2933个字，建议需 6 分钟

混沌是自然规律，秩序是人类的梦想。
——亨利·亚当斯

在任何基于服务的行业工作时，时间表和流程都非常重要。

无论采用何种技术堆栈，构建功能丰富且性能俱佳的产品都需要不同的部门一起工作，且需要付出巨大的努力，这就像一部运转良好的机器，需要齿轮和齿轮相互协作一样。协调或沟通中的任何失误都可能使整个项目陷入混乱。这不仅会浪费公司和客户的时间与金钱，还可能使公司的声誉面临风险。

大多数公司选择软件开发方法时，有两种不同的项目管理方法来提供选择——瀑布模型和敏捷方法。这两种方法都提供了结构化的流程和单独的、差异化的阶段。但是，两者都有各自的用途和用例。因此，下面让我们详细了解这两种项目管理方法。

01 什么是瀑布方法？

您可以将瀑布模型视为分层项目管理方法，其中项目的下一阶段将仅在当前阶段完成时开始。项目的每一个方面都是事先计划好的，并且进展是线性的、单向的。因此，项目经理有责任在创建计划、管理时间表或适当分配预算和资源之前收集所有利益相关者的需求和期望。

一旦项目启动，任何更改或变更都是需要花费很大精力了，有时候甚至变更变得不可能。因此，瀑布方法适用于具有可预测的重复流程的项目或需求易于理解的小型项目。整个项目管理模型分为六个单独的阶段，如下图所示：

1、需求分析

项目经理预先收集所有项目需求。然后，制定项目的所有不同指标，例如成本、假设、风险、依赖关系、成功 KPI 和完成时间表，并以与客户讨论确认。一旦获得批准，项目将进入下一阶段。

2、系统设计

制定项目规范，如编程语言、框架和架构/模型在此阶段最终确定。此外，在此阶段还创建了项目执行所需的任何文档，例如：概要设计、详细设计、数据库设计、测试方案、测试用例等。

3、项目执行

程序员根据前一阶段的设计文件，开始创建一个工作原型，并将它作为一个基线版本进行发布。（基线版本：最终产品的准系统功能版本）

4、系统测试

一旦开发团队提交了基线版本产品，QA 测试团队就会开始进行测试工作，以发现并消除在前一阶段忽略的任何错误。然而，由于在前几个阶段完成了大量的计划、设计和期望需求匹配等工作，因此，任何这样的问题都将是罕见的，但一旦出现需求问题就是灾难性的。

5、系统部署

团队将可交付成果提交给客户以进行部署或发布。

6、系统维护

任何更新或漏洞补丁都作为模型维护阶段的一部分提供。

瀑布模型的优点：

在整个项目范围内，团队始终保持在同一页面上。
规划和设计变得简单明了。
里程碑的定义较早，衡量进度变得容易。
节省时间和成本。
每个阶段都有清晰的文档可以让整个团队做好准备。

瀑布模型的缺点：

不适用于大型项目。
最初的计划和设计文档是具有挑战性和耗时的。
产品的变更会带来昂贵的代价。
一旦发生错误，影响范围很大。
在产品部署之前，客户反馈非常少。
截止日期的延误和挫折可能是灾难性的。

02 什么是敏捷方法？

敏捷方法论是一种更加以客户反馈为导向的项目管理方法。

这种方法优先考虑个人责任、可交付成果之间的短时间尺度、一致的沟通、反馈和可持续发展，使其更适合大型软件开发项目。在这种方法中，整个项目被划分为称为 sprint 的小型增量构建，并且在每个 sprint 开始时，对迭代进行审查和实施。在开发阶段，客户仍然是项目的一部分，任何更改都会立即实施。

这种项目管理方法非常适合复杂的项目和交付小而快速的版本。此外，敏捷方法侧重于个人和交互，而不是流程和工具。整个敏捷方法论具有以下阶段：

1、头脑风暴

我们根据项目简介讨论了许多想法，并努力根据建议制定项目计划。

2、设计

为了帮助可视化最终产品，团队在此阶段生成设计概念模型、系统框架、原型和前端模型。至此，编程语言、框架和模型就确定了。

3、开发

程序员编写软件，并在设计实现的基础上为最终产品开了第一个先例。在批准后，反馈被应用，并开始为测试而改进产品的工作。

4、质量分析

在通过严格的 QA 测试之前，不允许启动任何项目或产品。使用经过时间考验的测试程序和工具，识别并修复代码中的任何问题或故障。

5、部署

在基于 Web 或基于云的服务的情况下，将最终结果发送给客户进行系统部署。

6、反馈

任何建议或调整都包括在内，这个过程在继续深入之前会循环到头脑风暴的步骤。

敏捷方法的好处

更快地响应任何迭代
更新和补丁部署速度更快
用户的反馈确保产品符合最终客户的期望
更灵活
更好的可见性/问责制
随着时间的推移，敬业的团队可以提高生产力
非常积极和自组织的项目管理方法论

敏捷方法的缺点

更难预算、时间管理和预测时间表
缺少文档的支撑
难以在项目之间更换或更换团队成员
陡峭的组织学习成本曲线
存在很多技术依赖和工程成本
如果结果不明确，很容易偏离轨道

敏捷 VS 瀑布：核心差异

因素	瀑布	敏捷
时间表	在项目开始时提到了一个固定的时间表。	更灵活的时间表，具有实验和更正的范围。
客户的反馈意见	客户只能在需求/计划阶段提供。	客户参与项目开发的每一步。
灵活性	需求必须在项目启动时冻结，后期灵活性严重受限。	即使在项目的后期阶段，短时间的工作也可以整合新信息。
成本	根据文档固定预算。因此，错过最后期限会严重限制可用选项。	相比之下，高度的灵活性导致预算的波动非常小。
流动	线性和顺序流过各个阶段，就像瀑布一样。	具有迭代循环的增量方法。
进度测量	就完成和审查的工件而言。	在开发和交付的功能方面。
文档	需要正式文件。	工作原型为基础。
测试	构建软件后执行测试。	在每次迭代期间执行连续测试。

03 敏捷 VS 瀑布：使用哪个？

您可能会担心哪种项目管理方法更适合您。因此，让我们分解瀑布和敏捷项目管理方法的理想用例。

1、何时使用瀑布方法

瀑布技术最适合有组织的、可预测的项目，因为它比敏捷更加严格。该系统仅在满足以下条件时才有效：

明确定义客户需求时：当执行阶段没有定期交互时，当项目经理准确了解利益相关者的需求时，瀑布流效果最佳。
开发决策留给项目经理：利益相关者拒绝参与执行过程，因为他们没有时间。如果他们清楚地定义其要求并坚持在项目生命周期结束时进行评估，瀑布就会起作用。
钱不是障碍：好、快、便宜：这是搜索软件开发时想到的三个词。尽管将这三者结合起来是不可行的，但项目经理可以使用瀑布过程快速生成结果。

2、何时使用敏捷方法

敏捷正是它听起来的样子：这完全是关于部署具有敏捷性的小型和更新软件。这是关于具有实验、尝试新想法以及对项目进行最后调整的灵活性。这种方法在以下情况下最有效：

期望未定义：如果您的项目利益相关者不确定他们想要交付的确切内容，敏捷方法提供了一个迭代过程，可以激发试错和客户反馈。
业务需求是动态的：某些业务需要更具适应性的策略来满足不断变化的客户期望。敏捷方法使您能够重新审视可交付成果并增强它们以响应不断变化的需求。
进行更改的成本极低：由于交付和反馈的持续循环，敏捷更容易出现预算超支。因此，如果预计进行项目修改的成本很低，敏捷将为您提供所需的灵活性。

写在最后

如果从一开始就清楚地了解项目结果，那么瀑布可能是最好的匹配。另一方面，敏捷更适合想要快速行动、尝试方向并且在开始之前不知道最终项目将如何呈现的团队。这是一种越来越受欢迎的策略，尤其适合初创企业，因为它具有灵活性以及与企业主和利益相关者经常就进展情况进行检查。

—— END ——

本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：aisoutu@outlook.com 我们将第一时间删除。