软件开发主要有两种方法——敏捷开发和瀑布式开发。瀑布式开发采用线性方式进行软件开发。开发人员在开发过程的每个阶段都遵循一定的步骤顺序。

敏捷方法的诞生正是为了回应瀑布式开发模式的批评。批评者认为，瀑布式开发模式中存在太多问题，往往在项目接近尾声时才被发现。而敏捷开发则将每个功能分解成小的、可识别的工作单元，并随着时间的推移逐步交付价值。

瀑布式开发模式

几十年来，软件和硬件的开发主要遵循 瀑布式 产品开发模型。

在这种模式下，开发按顺序从一个阶段推进到下一个阶段，就像瀑布从一系列陡峭的落差处倾泻而下。只有当当前阶段正确且完成时，项目才能进入下一阶段。这意味着你永远无法返回到之前的阶段。

传统瀑布模型包含以下几个阶段：

需求收集
分析与规划
设计
发展
测试
部署

瀑布模型会尽早定义目标，并从头到尾规划整个流程。表面上看，这使得项目看起来更加清晰有序。

然而，瀑布模型的缺陷显而易见。首先，它的结构非常僵化。如果遇到重大问题或决定扩大项目范围，可能就不得不从头再来。此外，它也无法根据客户和用户的反馈进行更新或修改。

此外，测试往往在项目接近完成时才进行。项目成员直到项目生命周期的后期才能确定他们拥有一个可行的产品。这使得瀑布模型风险极高。

瀑布式开发模型的主要问题是什么？它无法反映大多数人实际完成工作的方式。瀑布式模型抑制了探索、实验和迭代，从而暴露出其自身的严重缺陷。

虽然瀑布式开发方法可能适用于物理工程、制造和生产，但软件开发却截然不同。软件产品比物理产品更容易彻底拆解和重建。由于工程团队拥有代码库，他们可以轻松地对产品进行大刀阔斧的修改。

大多数利益相关者很难理解这一现实。在他们看来，这就像汽车制造商更换目前在售汽车的发动机一样。

然而，构建软件系统的方法与构建物理系统的方法截然不同。  如果遵循正确的流程，软件可以随着需求的变化和挑战的出现而进行调整。

敏捷开发模型

部分原因是出于对瀑布模型僵化的不满，17 位软件开发人员于 2001 年发表了 《敏捷宣言》。 这份文件提供了一系列作者希望在产品开发中强调的价值观和原则。特别是，宣言的作者表达了他们对以下方面的偏好：

人与互动 比流程和工具更重要
可用的软件 胜过详尽的文档。
与客户合作， 而不是争论合同问题。
应对变化 胜于遵循计划

这些理念成为了敏捷开发方法的基础 ，而我们也在 Very 采用了这种方法。“敏捷”（正如其实践者所称呼的那样）优先考虑灵活性、速度、与跨职能团队合作以及通过迭代开发不断改进。

敏捷开发将开发过程划分为若干个称为“迭代周期”（Sprint）的离散时间段，每个迭代周期通常持续 1 到 4 周。每个团队成员都有一系列必须在迭代周期内完成的任务。这些任务会在迭代周期开始前的计划会议上进行分配。此外，团队成员还会每天举行“站立会议”，讨论项目进展并集思广益，探讨遇到的问题的解决方案。

产品开发方式的这些变革对结果产生了深远的影响。与瀑布式开发不同，敏捷开发旨在应对变化，甚至拥抱变化。敏捷开发力求以快的速度交付可用的产品，并高度重视用户测试和反馈。