敏捷开发与瀑布开发方法论之对比

Posted 2021-04-25 21CTO

在项目开发之前，项目经理的工作是确定应该将哪种方法用于项目生命周期。

两种最流行的方法是：

• 瀑布模型，依靠更传统的方法；

• 敏捷方法，一种快速的应用程序开发过程，比瀑布更新，并且通常使用Scrum实现。

瀑布是多年来一直使用的过程，但许多组织正在迁移到敏捷或至少尝试过它。

随着全球软件开发公司采用敏捷方法开发其产品，瀑布模式正逐渐失去欢迎。让我们深入探讨敏捷的流行背后的原因以及它与瀑布方法的本质区别。

瀑布方法论

瀑布是传统模型，相信你一定经历过以下顺序的软件开发过程：

• 需求 - 产品需要详细完成的内容

• 分析 - 开发模式，业务规则等。

• 设计 - 开发产品的架构

• 编码 - 编写代码，集成组件

• 测试 - 测试用例，调试

• 操作 - 安装，上线，支持，维护

瀑布模型是一种制造心态产生的模型，其中构建了物理对象。花更多时间在前面做正确的事情，但限制了极其昂贵的变化 - 在物理工厂，工具，机械 - 以后。

软件也可以这样，但软件中的原型设计比实际产品更容易。在长的产品开发周期中，可能会花费太多时间和精力来满足需求和分析，这导致考虑太多选项。在开发阶段，需求通常会发生显着变化。结果是产品的构建是为了提供一系列要求。问题在于，20％的功能实现了80％的价值，其余功能增加了不必要的复杂性和最终产品的价值。

请注意，瀑布模型倾向于强调功能特性，每个开发者都会完成自己的工作，并将工作交给下一个专业人员。换句话说，编写规范的人可能无法理解实际创建某些特定功能的潜在巨大复杂性 - 但这可能需要一些时间来发现。

敏捷方法论

敏捷模型是一种不同的方法，它强调以下内容：

• 一个渐进的迭代过程 - 构建，评估和迭代较小的工作特征块

• 自组织，协同，交叉 - 职能部门 -用户，设计师的小团队，和编码者共同打造项目的小版本。虽然专业仍然存在，但更密切的合作可以更好地理解实际的假设和要求以及构建产品的权衡

亨利.福特先生曾引用过一句名言：“如果我问人们他们想要什么，他们会说更快的马。”这句话的意思是说，用户在看到之前并不知道他们想要什么。花费大量时间记录他们认为自己想要的东西可能无法产生他们想要但却无法想象的真实产品。

在敏捷模型中，跨职能团队可以采用Who，What，Why方法。用户故事是敏捷方法论的主要内容，目标是记录和简化现实世界的场景。

例如在我的帐户页面上，我是信用卡帐户的消费者。在最近的收费中，我想查看上一结算算周期的费用。我希望能够按商家，类别，日期和金额对交易视图进行排序。如果我点击交易，我可以看到更多详细细节。如果我有相关问题，可以点击客户服务链接开始查询该交易。

类似这些用户故事可以用很多方式编写，但它们应该清晰人们实际想要完成的事情。

在敏捷环境中，跨职能团队致力于在短时间内提供产品的可以工作部分，这被称为冲刺，可以是1周到1个月。冲刺时间帧越短越好，因此可以对某些内容进行评估、修复，然后进行迭代。

迭代循环包含学习，构建和测量。今天许多初创公司其实只在使用它的基础部分。有一组假设，构建原型，招募用户进行评估和测试。收集反馈并重复该过程。

以下依据维基百科的敏捷原则价值：

• 流程和工具上的个人和互动

• 软件与工作的综合文档

• 合同谈判中的客户协作

• 响应改变遵循计划

从某种意义上说，它更多要求团队的是做，而不是规划。

它可能不适用于所有组织和所有产品。许多行业都有法律法规要求提供大量文档和记录。政府和其他高度官僚组织不能总是围绕这种方法组织发展。许多组织正在采用敏捷，但有些项目规模如此之大，可能需要采用混合方法。

但最终的结果——心态也很重要。一种方法强调每个阶段的流程，专业化和详细规划。另一个强调协作，用户参与，持续优先级排序和快速评估假设。

哪一个适合您的组织？答案可能取决于您的产品或服务的性质，以及看您的业务或组织使命。但即使完全敏捷的方法不适合您，在产品开发中加入它的方方面面也可能产生有效的改进。

两个方法是怎么工作的

瀑布式为软件开发提供了更顺序的方法。它遵照以下线性顺序工作。

• 收集软件需求文档

• 该应用程序是在需求最终确定后设计的

• 开始开发且并行执行单元测试

• 执行性能测试以确保系统在负载或压力用户验收测试下表现良好

• 缺陷修复，开发人员开始处理测试团队检测到的错误

• 将应用程序部署在生产环境中

而敏捷并不遵循任何线性路径。它遵循迭代的开发方法。项目的整个持续时间分为称为sprint的阶段，而不是创建任务。敏捷通常关注四个基本价值观：

• 团队成员之间的互动而不是工具。

• 正确运行的软件而不是包含所有内容的文档。

• 客户在每个sprint中的协作。

• 快速响应变更而不是遵循计划。

要求收集阶段

如果将瀑布模型用于应用程序开发，则客户和组织都需要事先清楚地了解需求规范。一旦接受要求，就无法改变它们。

但是，在敏捷方法中，一开始就没有固定的需求文档。客户在每个sprint中提供用户故事，开发人员的工作是完成编码并演示。如果客户对产品不满意并需要更多附件，他会要求更改需求。因此，敏捷在需求方面比瀑布更有灵活性。

适合的项目

如果客户明确了要开发的软件需求，瀑布模型是最好的方法，因为它遵循线性方法，并且在第一阶段已经明确需求。

如果你计划开发的应用程序需要随着每个阶段而发展，并且项目中可能需要经常进行修改，那么敏捷方法是满足客户需求和技术前景的最佳方法。

产品对客户的可见性

当遵循瀑布模型开发时，用户或客户只能在项目结束后才能看到完整的产品，之后才能将应用部署到生产环境中。

在敏捷中，由于持续时间被分成多个冲刺，因此客户经常有机会查看产品，从而做出有关接受标准和要执行更改的决策。

作为一个团队工作

瀑布模型的最大缺点是它不允许开发人员和测试人员之间的集成协作。测试人员只有在开发阶段结束后才开始，他们才能单独工作。

在敏捷中，测试人员和开发人员一起工作。每个sprint都有一个测试阶段，每次发布新功能时，都会立即进行回归测试。

将大任务拆分为较小的任务

在瀑布模型中，软件开发变得有点复杂，因为整个应用程序将作为一个单独的项目完成。对于开发人员来说，这对于测试人员来说，当他们开始测试大型应用程序时，它会变得非常繁忙。

在敏捷模型中，该项目分为多个用户故事。开发人员和测试人员在每个阶段一起工作以了解需求，客户最终会回顾一切是否正确完成，它使工作更轻松，更快捷。

每个模型的使用统计

Standish Group在2010年提交的CHAOS报告表明，与遵循瀑布方法的项目相比，采用敏捷方法的项目面临的挑战更少，失败的机率更低。

如下图：

敏捷与瀑布模型的利与弊

瀑布方法

虽然传统，瀑布模型在许多方面都是有好处的。

• 可预测的静态工作流程确保团队可以计算出合适的成本预估并了解截止日期。

• 由于该过程需要文档，因此纸质跟踪将引领每个开发阶段。遵循过去项目的逻辑，团队也可以为未来的项目奠定基础。

• 该过程是现代的，团队不需要先验证知识就可以开始瀑布模型。

但是，缺点也总结如下：

• 由于模型是严格的，任何重大变化对于客户和团队来说都是昂贵的，如果发生变动，整个项目可能被废弃并需要重新开始。

• 在利益相关者实际查看实时应用程序之前，需求收集，开发和测试等多个阶段，这会占用了相当多的时间。

敏捷方法

由于它遵循的是迭代方法，敏捷在许多方面都是有利的：

• 较短的开发阶段使项目具有适应性，并随时可以满足客户要求的任何重大或微小变化。

• 客户可以在每个sprint期间查看项目实时状态，定期反馈可以获得更高质量的产品。

• 开发人员和测试人员与客户携手合作。有更好的团队合作可以促进个人的发展以及组织的业务发展。

它的一些缺点：

• 敏捷更喜欢工作应用程序而不是文档。这可能是一件好事，但是根据项目的复杂性，有时需要在文档和编码之间取得适当的平衡。

• 该方法适用于小型团队。因此，每个团队成员必须精通他们的专业角色和自我驱动。

最后，结果更重要

长期从事软件开发行业的人士建议，事先明确要求的规划，能够确保软件成功交付。但我们生活在一个快速交付、提高盈利能力的世界。因此，根据项目的性质，由团队和利益相关者共同决定哪种方法最适合使用。

编译：老夏

来源：https://dzone.com/articles/agile-vs-waterfall-methodology

相关文章：