开发模型的理解：瀑布模型/增量式/迭代/敏捷开发——笔记

首先，不管采用何种开发模型。软件开发都至少具有以下的周期，包括：

1. 需求获取/分析（系统分析、软件分析）
2. 设计
3. 实现
4. 测试
5. 发布（运行）
6. 维护

既然所有的开发模型都具有相同的开发周期，那不同的开发模型的差别从哪里体现呢？或者说不同的开发模型在指导开发过程中的差异点在哪里？

我理解的差别点主要体现在：

1. 每个周期活动的工作上限
2. 每个周期被重复的次数
3. 周期活动被重复的时机
4. 对软件开发活动的指导范围

按照上面的理解，看一下常用的开发模型：

• 瀑布模型：期望整个系统从开始到结束都是一个整体，所有的周期活动只进行一次。也就是只做一次需求获取(一次就获取到所有的需求)，一次需求分析(一次将所有的需求分析完整)，一次设计等等。
• 增量模型：增量模型将整个系统结构化的拆成几个增量（功能模块）-- 比如3个，每一个完整的周期完成一个增量，有几个增量就重复几个周期。
• 迭代开发：在迭代开发中，将系统的开发工作划分成一个个迭代，不要求一次行完成整个系统的开发（相对于瀑布开发而言）。迭代开发目前有两种，一种是在每个迭代中使用瀑布模型。另一种是每一个迭代中完成软件开发阶段的某一个阶段。前一种好理解。在后面这种迭代模型中，每个迭代开始的时候只需要确定当前迭代的需求就可以开始迭代。如迭代0完成迭代1的需求获取以及架构设计，开发、测试等的准备工作，迭代1完成迭代2的需求获取和迭代1的设计，迭代2完成迭代3的需求和迭代2的设计和迭代1的开发，迭代3完成迭代4的需求、迭代3的设计、迭代2的开发和迭代1的测试。此时，迭代1可以发布了。后续每一个迭代都可以做一次发布。这样持续循环。
  • 演化模型：演化模型属于迭代开发。演化开发不需要（或者无法）在一开始确定所有的需求。所以先开发一个相对精简的原型并上线（这中间采用瀑布模型），然后在根据各种需求来源确定下一个迭代需求，在重复瀑布模型完成下一次迭代。
  • 螺旋模型：螺旋模型属于演化开发（也属于迭代开发）。螺旋模型结合了演化开发的迭代和瀑布模型的系统性和监控。最大的特点就是引入了其它模型不具备的风险分析。在每一个迭代里，当确定了目标、方案和限制条件以后，进入风险评估阶段（识别并消除风险）。如果有不确定的风险，则需要进一步工作以将所有风险都确定。风险过大甚至会终止项目。当风险识别完成并有确定的风险消除方案以后，就继续采用瀑布模型完成一次迭代开发。在多次迭代以后，达成所期望的戏疼。
• 敏捷开发：如果只是从开发的核心阶段来看，敏捷开发就是迭代开发。然而实际上迭代开发是敏捷开发的一部分，指导开发阶段的那一部分。敏捷开发还包括了迭代开发不包含的：开卡、结卡、TDD、Pair programming、review、feedback等等实践活动。敏捷开发在迭代开发的基础上，通过引入一些活动来达到团队自循环、自我完善，从而对团队本身进行迭代，以提高团队的开发效率、质量、体验等。
• 喷泉模型：喷泉模型体现了软件开发的无边界性（每个阶段之间没有清晰的边界）和反复性。就像喷泉水喷出又落下。开发的阶段也是这样，可能从某个阶段回落到之前的任何一个阶段（比如，从测试回到需求获取）。PS：感觉像边改边做模型。
• 边改边做模型：边改边做模型属于软件开发的奔放模型（也是软件开发最容易成为的模型）。边做边改模型下的软件开发没有固定的、明确的周期和阶段。当任何一个想法的出现（都还不能说是需求），就开始做设计（需求分析被无意识的融入到了设计和开发甚至是测试环节）。等产出30版以后在选择第一版开始开发。开发到一半决定在加点灵感（可能推翻了之前做的功能）甚至是决定采用第二版。反复的重新设计、重新开发以后，终于开发了一半，发现资源/时间不够，于是被告知明天必须上线。最终延期半年上线以后发现bug一堆（系统功能组合bug、设计bug、开发bug等），开始进入边甩锅边修bug的阶段（很可能项目开发一半就夭折了）。

下面重点讲一下瀑布模型、增加模型、迭代开发、敏捷开发。

瀑布模型

也可以看成是软件的生命周期模型。

主要阶段直接映射基本的开发活动：

• 需求分析和定义：通过咨询系统用户建立系统的服务、约束和目标。并对其详细定义形成系统描述。
• 系统和软件设计：系统设计过程通过建立系统的总体体系结构将需求区分为硬件需求和软件需求。软件设计包括识别和描述一些基本的软件系统抽象及其之间的关系。
• 实现和单元测试：在此阶段，将软件设计实现为一组程序或程序单元。单元测试就是检验每个单元是否符合其描述。
• 集成和系统测试：集成单个的程序单元或一组程序，并对系统整体进行测试以确保其满足了软件的需求。在测试之后，软件系统将交付给客户使用。
• 运行和维护：正常情况下（不是必须的），这是一个具有最长生命周期的阶段。系统被安装并投入实际的使用中。维护包括改正那些在早期各阶段末被发现的错误，改善系统各个单元的实现，并当新的需求出现时提高系统的服务能力。

主要问题在于它将项目生硬地分解成这些清晰的阶段。因此只有在对需求了解得好，而且在系统开发过程中不太可能发生重大改变的时候，适合使用瀑布模型。

增量式开发

思想是先开发出一个初始的实现，给用户使用并听取用户的使用意见和建议，通过对多个版本的不断修改直到产生一个充分的系统。描述、开发和有效性验证等活动不是分离的而是交织在一起。同时让这些活动之间都能得到快速的反馈信息传递。

增量式开发反映了我们解决问题的方法，系统的每一个增量或版本包括用户需要的一部分功能。通常，系统的早期增量包括最重要或最紧急的功能需求。这就意味着在早期开发阶段，用户可以相对早地评估系统，看它是否满足需要。若不满足需要，就只需要改变当前的增量即可，又或许有新的功能被发现并为下个增量做准备，因此可以大幅度地减少成本。

增量式开发相比于瀑布模型的一些重要优点：

降低了适应用户需求变更的成本。重新分析和修改文档的工作量较之瀑布模型要少很多。

• 在开发过程中更容易得到用户对于已做的开发工作的反馈意见。用户可以评价软件的现实版本，并可以看到已经实现了多少。这比让用户从软件设计文档中判断工程进度要好很多。
• 使更快地交付和部署有用的软件到客户方变成了可能，虽然不是所有的功能都已经包含在内。相比于瀑布模型，用户可以更早地使用软件并创造商业价值。

从管理的角度看，增量式方法存在的问题：

过程不可见。管理者需要通过经常性的可交付文档来把握进度，若系统开发速度太快，要产生反映系统每个版本的文档就很不划算。

伴随着新的增量的添加，系统结构在逐渐退化。除非投入时间和金钱用在重构系统结构上以改善软件，否则定期的变更会损坏系统的结构。随着时间的推移，越往后变更系统越困难，而且成本也将逐渐上升。

迭代开发：

那么什么是"迭代开发"呢？迭代的英文是 iterative，直译为"重复"，迭代开发其实就是"重复开发"。

迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进。所以他的定义就是：

在迭代开发中， 整个工作被划分为一系列袖珍的、固定时间的小项目，这叫系列迭代，即是迭代开发。

早在20世纪50年代末期，软件领域中就出现了迭代模型。

最早的迭代过程可能被描述为“分段模型（stagewise model）”。迭代模型是RUP推荐的周期模型。被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。

在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。

实质上，它类似小型的瀑布式项目。

RUP认为，所有的阶段都可以细分为迭代，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

迭代开发本身是一种有计划的修改策略：通过多次开发来改善正在构建的特性，逐步得出一个完善的解决方案。例如，对一个知之甚少的产品，开始时可以先创建原型以获得重要知识，接着可以创建一个更好一点的修订版，再接下来是一个相当好的版本。例如，在文章写作过程中，我在收到反馈以及对如何表达主题有了更深刻的理解后，把每章都修改了几次。

增量开发与迭代开发的区别

增量开发：

• 每个阶段都完成一个高质量的发布版本，后一阶段不对前一阶段的内容进行任何修改，只在前一阶段的基础上增加新的业务功能实现，称为增量，直至最后一个阶段，形成最终的软件产品。
• 增量开发只是在原有的基础上增加新的东西。

迭代开发：

• 第一个阶段就覆盖了项目整体范围，以后每个阶段都是在前一阶段的基础上改进、完善，没有业务范围的扩展。
• 迭代开发每一次都是在原有的基础上进行改进和完善。

迭代开发只是要求将开发分成多个迭代，并没有回答一个重要的问题：怎么划分迭代，哪个任务在这个迭代，哪个任务在下个迭代？这时，一般采用"增量开发"（incremental development）划分迭代。

所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。

敏捷开发

敏捷开发（agile development）是非常流行的软件开发方法。据统计，2018年90%的软件开发采用敏捷开发。

敏捷开发的核心是迭代开发（iterative development）。敏捷一定是采用迭代开发的方式。

敏捷开发是总体概念，而迭代式开发是实践敏捷开发概念的一个手段。敏捷开发除迭代式开发外，还包含了其他许多管理与工程技术实践，如演进式架构设计、敏捷建模、重构、自动回归测试（ART）。综上，敏捷开发与迭代开发是整体与局部的关系，前者是家族，而后者是家族成员。 虽然敏捷和迭代不一样，但是它们也是分不开的，二者的有机结合，既能保证产品质量又可保持在项目持续改进过程中的优势。吸取精华,破其糟粕，只有这样，项目才会趋于完美。

增量开发加上迭代开发，才算真正的敏捷开发。

敏捷开发是以用户的需求为核心，采用迭代、循序渐进的方式开发软件。

敏捷开发的优势

早期交付

敏捷开发的第一个好处，就是早期交付，从而大大降低成本。

还是以上一节的房产公司为例，如果按照传统的"瀑布开发模式"，先挖10栋楼的地基、再盖骨架、然后架设屋顶，每个阶段都等到前一个阶段完成后开始，可能需要两年才能一次性交付10栋楼。也就是说，如果不考虑预售，该项目必须等到两年后才能回款。

敏捷开发是六个月后交付一号楼，后面每两个月交付一栋楼。因此，半年就能回款10%，后面每个月都会有现金流，资金压力就大大减轻了。

降低风险

敏捷开发的第二个好处是，及时了解市场需求，降低产品不适用的风险。

请想一想，哪一种情况损失比较小：10栋楼都造好以后，才发现卖不出去，还是造好第一栋楼，就发现卖不出去，从而改进或停建后面9栋楼？

对于软件项目来说，先有一个原型产品，了解市场的接受程度，往往是项目成功的关键。有一本书叫做《梦断代码》，副标题就是"20+个程序员，三年时间，4732个bug，100+万美元，最后失败的故事"，这就是没有采用敏捷开发的结果。相反的，Instagram 最初是一个地理位置打卡 App，后来发现用户不怎么在乎地理位置，更喜欢上传照片，就改做照片上传软件，结果成了独角兽。

由于敏捷开发可以不断试错，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式。

敏捷开发的价值观

《敏捷软件开发宣言》里面提到四个价值观。

1. 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
2. 软件能够运行，优于详尽的文档。
3. 跟客户的密切协作，优于合同和谈判。
4. 能够响应变化，优于遵循计划。

敏捷开发十二条原则

该宣言还提出十二条敏捷开发的原则。

1. 通过早期和持续交付有价值的软件，实现客户满意度。
2. 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 不断交付可用的软件，周期通常是几周，越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
6. 面对面交谈是最好的沟通方式。
7. 可用性是衡量进度的主要指标。
8. 提倡可持续的开发，保持稳定的进展速度。
9. 不断关注技术是否优秀，设计是否良好。
10. 简单性至关重要，尽最大可能减少不必要的工作。
11. 最好的架构、要求和设计，来自团队内部自发的认识。
12. 团队要定期反思如何更有效，并相应地进行调整。

迭代开发与敏捷开发的区别

前者是软件的开发周期模型，是一种开发过程；而后者是多种软件开发 项目管理方法的集合，这是两者最根本的区别。与迭代开发对应是瀑布模型、螺旋模型，而与敏捷开发对应的是Scrum，XP（极限编程），Crystal（水晶编程），所以二者不可混为一谈，但其中又有一定的联系。

敏捷开发需要超前的规划

近些年来，由于一些特定的需求，越来越多的软件团队开始采用敏捷开发模式，但是在开发过程中却对其核心思想理解不足，有些敏捷开发团队甚至没有管理者，仅设一名Scrum Master向产品经理汇报，职责划分也很暧昧。

除了软件公司，在很多常规企业中，敏捷开发已经成为一种无负责人的开发流程。所谓的产品经理与销售、CEO随意加功能、改需求，然后交给开发团队去“敏捷”开发。在开发过程中，需求调研、设计、反馈、代码评审、测试、全不需要。这就是技术大杂烩，能做到哪一步算哪一步，完全忽略了敏捷开发的实质。

而实际上，敏捷开发并不是这样的， 迭代的核心在于软件的超前规划。如果没有专业规划者的全程指导，造出来的软件系统必不合格 -- 时间超限、预算超支、充斥着各种不科学的奇思妙想、根本不管需求是否合乎逻辑。

所以，无论用什么开发思维，不管是哪种开发手段，都要制定合理科学的开发方案，这样才可事半功倍。

对于我们开发者而言，一个长期迭代的项目，软件复用是非常重要。

面向复用的软件工程

在大多数的软件项目中，都存在一定程度的软件复用。

主要阶段：

1. 组件分析：给出需求描述，然后搜寻能满足需求的组件。通常情况是，没有正好合适的组件以供选择，能得到的组件往往只提供所需要的部分功能。
2. 需求修改：在这个阶段，根据得到的组件信息分析需求，然后修改需求以反映可得到的组件。当需求修改无法做到的时候，就需要重新进入组件分析活动以搜索其他可能的替代方案。
3. 使用复用的系统设计：在这个阶段，设计系统的框架或重复使用一个已存在的框架。设计者分析那些将被重复使用的组件，并组织框架使之适应这些组件。当某些可复用的组件不能得到时，必须重新设计一些新的软件。
4. 开发和集成：当组件不能买到时就需要自己开发，然后集成这些自己开发的组件和现货组件，使之成为一个整体。在这个模型中，系统集成与其说是一个独立的活动，不如说已经成为开发过程的一个部分。

3种类型的软件组件可能用于面向复用的过程：

• 通过标准服务开发的Web服务，可用于远程调用
• 对象的集合，作为一个包和组件框架，如.NET或者J2EE等集成在一起
• 独立的软件系统，通过配置在特定的环境下使用

优势：

• 减少了需要开发的软件数量，从而降低了软件开发成本，也降低了开发中的风险
• 可使软件快速地交付

软件开发比较经典的过程模型有：

• 瀑布模型：该模型将基本的过程活动、描述、开发、有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段、软件设计阶段、实现阶段、测试阶段等。
• 增量式开发：该方法使得描述活动、开发活动和有效性验证活动交织在一起。系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。
• 面向复用的软件工程：该方法是基于已存在的大量可复用的组件。系统开发过程着重于集成这些组件到新系统中，而非从头开发。

三个模型相互不排斥，而且经常一起使用，尤其是对大型系统的开发。对大型系统，综合瀑布模型和增量开发模型的优点是有意义的。

参考文章：

一文搞定软件过程模型——瀑布模型、增量式开发/增量开发与迭代开发的区别 https://blog.csdn.net/weixin_55267022/article/details/118121466

开发模型的理解（瀑布、迭代、敏捷） https://zhuanlan.zhihu.com/p/452759262

浅谈敏捷开发概念和迭代开发方案  https://www.minjiekaifa.com/agilearticles/agile-development-and-iterative-development-solutions-80369.html

敏捷开发入门教程 https://www.ruanyifeng.com/blog/2019/03/agile-development.html

浅谈敏捷开发概念和迭代开发方案 https://www.minjiekaifa.com/agilearticles/agile-development-and-iterative-development-solutions-80369.html

转载本站文章《开发模型的理解：瀑布模型/增量式/迭代/敏捷开发——笔记》, 请注明出处：https://www.zhoulujun.cn/html/webfront/engineer/Architecture/8935.html