瀑布与敏捷

瀑布与敏捷

每个软件开发项目都需要一种管理方法,来保证项目能够成功交付。在项目管理中,最具挑战性的问题之一就是:该如何选取正确的管理方式来让团队在舒适的环境中开发软件并取得成功呢?这是一个关于方法论的讨论。

在现代软件开发行业中,有两种最基本和最流行的项目管理方法:

  • 瀑布(Waterfall),也被称为「传统的软件开发方法」;
  • 敏捷(Agile),这种管理方法比瀑布模式更新。

接下来我们来看看瀑布式和敏捷式的区别。

Agile-vs-Waterfall-review

(图片来自网络)

一、瀑布方法论

waterfall

(图片来自网络)

瀑布模型是一种线性的开发方法,传统的方法是在严格的计划基础上,一步一步地实施计划。 在这种方法中,事件序列是这样的:

  • 收集和记录需求,并生成文档;在下一阶段的工作中,所有的操作都将基于此文档进行。 客户只是在项目的第一阶段和最后阶段才参与项目的执行,其它阶段并不严格要求参与。
  • 设计;在这个阶段,开发人员会努力找到一个合适的形式来满足客户的所有要求。
  • 代码和单元测试;这个阶段的主要任务是测试代码和单元。
  • 执行系统测试。
  • 执行用户验收测试(UATUser Acceptance Testing)。
  • 解决测试中出现的问题。
  • 向用户交付成品。

1、优势

瀑布模型的线性特性也就是它的优势。

  • 易于管理和控制;瀑布中的每个阶段都代表了软件开发的一个完全独立的阶段,都有具体的可交付成果和审查过程,每个阶段通常在下一个阶段开始之前结束。通常在每个之间还有一个阶段闸门,例如,在开始设计之前,软件需求必须经过客户的审查和批准。

    这种线性特性,让开发人员和客户在开发工作生命周期的早期就达成了交付内容的一致,这使得规划和设计更加简单。所以,在使用瀑布方法进行软件开发时,由于在某个阶段的工作内容非常纯粹,因此开发工作可以更加小心和完整地进行,易于项目管理。

  • 准确的文件;瀑布方法需要准确记录每个阶段,以创建一个准确的文档库。

  • 结果明确;开发人员和客户在开发工作生命周期的早期就达成了交付内容的一致,客户从一开始就知道程序的功能及其外观,因此,项目成本和时间表也都是已知的。这种确定性会让人比较踏实。

2、缺陷

瀑布模式的缺陷也是显而易见的。

  • 客户可能会对交付的产品不满意; 因为所有的可交付内容都是基于最初的文档化的需求,客户可能只有在几乎完成之后才能看到要交付的内容。这个时候如果有需求变更,可能就难以实现了,而且代价高昂。这在软件开发中是一个非常致命的缺陷 —— 因为能否满足客户需求才是软件的意义所在

  • 只在交付的尾声进行彻底的测试;如果这个时候出现严重的错误,整个项目可能就要宣告失败。

  • 并且,如果在软件开发开始时需求不明确,那么瀑布模式就是一个不太有效的方法了。

二、敏捷方法论

敏捷方法论的核心是迭代开发Iterative Development)。迭代开发的意思就是「重复开发」。

对于大型软件项目来说,传统的开发方式是采用一个大周期(比如一年)进行开发,整个过程就是一次「大开发」;迭代开发的方式则不一样,它将开发过程拆分成多个小周期,即一次「大开发」变成多次「小开发」,每次小开发都是同样的流程,所以看上去好像是在重复做同样的步骤。

迭代开发将一个大任务,分解成多次连续的开发,本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本,然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤,不断改进产品,添加新功能(也就是增量开发)。通过频繁的发布,以及响应对前一次迭代的反馈,最终接近较完善的产品形态。

agile

提出敏捷方法论的那群志愿者,发布了一个敏捷宣言,可以总结为四句话:

  • 个体与交互优于流程与工具

  • 客户协作优于合同谈判

  • 响应变化优于遵循计划

  • 可工作的软件优于面面俱到的文档

尽管右项有其价值,我们更重视左项的价值。

敏捷开发强调协作和反馈。协作体现在团队与客户之间、团队成员之间的协作;反馈则是体现在项目开发中的任何环节,包括代码质量、自动化测试、部署、项目进度、需求变更、客户验收等等,反馈越快越好,获取反馈之后,团队快速做出调整,及早发现问题,响应问题。

1、优势

敏捷的优点是显而易见的。

  • 客户可以在早期,频繁得看到正在交付的项目,并在整个开发项目中做出决策和变更;通过在整个项目过程中与项目团队进行广泛而直接的合作,客户可以获得了强烈的主人翁感。这样一来,也就最大程度了降低了交付成果不满足客户需求的风险。
  • 通常,敏捷团队根本没有任何文档,也不需要文档,因为客户的参与,可以让他们随时查看工作的内容和进度。
  • 能够早期交付,降低成本;瀑布模式中,每个阶段都需要等到前一个阶段完成后才能开始,通常交付的周期会很长;而敏捷可以在一个较短的周期里向客户交付产品中最有价值的部分(MVP)。
  • 允许改变;市场是不断变化的,通过及时了解市场需求,通过迭代,调整产品,降低产品不适用的风险,也就是说敏捷是允许不断试错的。
  • 提高软件质量;通过将项目分解为可管理的单元,项目团队可以专注于高质量的开发、测试和协作。 此外,通过在每个迭代中进行的频繁的构建、测试和评审,可以快速发现和修复缺陷,并及早识别预期的不匹配,质量得到了提高。
  • 更加关注业务价值;通过允许客户确定工作的优先级,团队更加理解什么对客户的业务是最重要的,能够在迭代中交付可以提供最大业务价值的功能特性。
  • 如果在前期,市场需求不确定,或者对该领域不熟悉,那么敏捷开发几乎是唯一可行的应对方式。

2、缺陷

当然,敏捷也有一些缺点。

  • 客户的高度参与,虽然对项目很有好处,但可能也会给客户带来一些问题,这些客户可能根本没有时间或兴趣参与
  • 如果在最初的架构设计中,没有整体考虑系统,那么敏捷开发的迭代特性可能会导致频繁的重构。 如果不进行这种重构,系统的整体质量可能会下降。 这在大规模的和高度集成的系统中尤为明显。
  • 敏捷非常注重人与人直接的协作,当团队成员位于同一物理空间时,当然没什么问题,但是这并不是可以完全保证的。所以,有的时候团队需要采取一些方式来加强交流协作,比如网络摄像头、协作工具等。

三、最后

瀑布方法更为传统,但是它已经变得不那么受欢迎了,现在越来越多地企业开始采用敏捷。我也是敏捷的爱好者和推崇者。后面,我也将会输出更多在工作中所接触到的敏捷实践,欢迎大家一起探讨。


转载请注明: Deepspace 瀑布与敏捷

相关文章 
目录