2.4 快速交付开发模式

每个项目有其特有的业务需求、应用场景和交付要求，因此要依据项目自身的特点，选择合适的开发模式。快速交付开发模式分为Web和App两大类，Web开发模式主要有迭代模式、模型模式、敏捷模式和微服务模式，App开发模式分为Native、Web App、Hybrid三种。

2.4.1 迭代模式

迭代模式是现代开发方法中最具有代表性的关键实践，在这种方法中，将开发过程组织成一系列固定的短周期小型项目，称之为迭代。迭代是一个循环往复、重复实现的过程，将上一次迭代的结果作为下一次迭代的初始值。对于长周期项目和大型高风险项目，可通过多次循序渐进的迭代，在功能、质量上逐渐接近客户的要求。

迭代开发也称迭代增量式开发或迭代进化式开发，是与传统的瀑布式开发相反的软件开发过程，比传统开发方式具有更高的成功率和生产率，有助于软件的快速交付。

1.迭代模式的优点

（1）有效降低增量的开支风险。对于重复进行的迭代，直接损失也仅仅是针对此版开发有误的迭代花费。

（2）有效降低软件产品无法按照计划进入市场的风险。在软件开发的初期排查和确认风险，通过有效干预来处理和规避风险，避免后期处理行动匆忙、效率低下的局面。

（3）有效提升整体开发进度。开发人员能够准确定位问题的焦点所在，开发工作将会更有效率。

（4）有效贴近用户真实需求，有利于适应需求变化。用户需求往往会在软件开发过程中不断细化和调整，因此，迭代开发过程更能及时响应需求变化，更贴近用户的真实需求。

2.增量迭代模式

在迭代模式的基础上，产生了增量迭代模式。软件被作为一系列的增量构件来设计、实现、集成和测试，每个构件是由多种相互作用的模块构成的，由提供特定功能的代码片段实现。增量迭代模式将可运行的完整产品分解成一个个满足客户需求子集的可运行产品，同时将完整需求对应的产品拆分成若干构件，开发人员以构件为单元组织开发，分阶段交付产品。

1）增量迭代模式的优点

（1）提高了软件开发的灵活度，能更好地响应需求变化，客户也能对产品的开发成果有直接的体验。

（2）提高了人员分配的灵活度，通过配置基本的人员组成进行构件的开发，核心产品市场反响良好，则追加人员分配，以实现下一个增量。

（3）当限定期限内配置的人员无法完成指定软件产品的开发时，增量迭代模式提供了优先推出核心产品的方案，提前发布部分核心功能给客户，提高客户对产品开发的信心，降低软件产品开发的风险。

2）增量迭代模式的缺点

（1）对软件结构体系的开放程度要求高。功能子集构件是逐步合并至已有的软件结构体系中去的，要求新合并的构件必须遵循已经构造完成的系统结构体系，不能对已有结构体系产生破坏。

（2）对软件开发过程的控制能力较弱。软件开发过程始终伴随着客户需求的变化，增量模型的灵活性可以适应这种变化，相对于瀑布模型和原型模型而言有明显优势，但也存在较大概率退化为边做边改模型，失去对软件整体性的控制。

（3）如果增量之间存在相交的情况且未很好地处理，则必须做全盘系统分析。这种将功能细化后分别开发的方法，比较适用于需求经常改变的软件开发过程。

3）增量迭代模式的实现步骤

使用增量模型时，往往将第一个增量做成实现基本需求的核心产品。核心产品交付客户使用后，收集客户的客观评价形成下一个增量的开发计划，其中，包括对核心产品的修改和新功能的发布。这个过程随着每个增量的发布不断重复，直到产生最终的完善产品。

下面以开发字处理软件为例，说明使用增量模型的步骤。

第一步要实现核心增量，发布基本的文件管理、编辑和文档生成功能。

第二步要实现优化增量，发布更加完善的编辑和文档生成功能。

第三步要实现增强增量，完成拼写和文法检查功能。

第四步要实现完美增量，完成高级的页面布局功能。

2.4.2 模型模式

模型模式又分为原型模型、螺旋模型、演化模型、喷泉模型和智能模型等几种开发模式。

1.原型模型

原型模型是利用原型辅助软件开发的一种新思想，通过简单、快速地分析和构建软件原型，在试用原型的过程中加强交流与反馈，并不断评价和改进原型，使开发人员与客户达成共识，最终在确定客户需求的基础上，开发出客户满意的软件产品。具体的实现过程如下。

（1）快速构建软件原型，向客户展示待开发软件的全部或部分功能和性能。

（2）逐步调整原型，使其满足客户要求，客户对该原型进行测试评价，给出具体改进意见，帮助开发人员确定客户的真正需求是什么。

（3）在第二步的基础上对软件需求进行修改和完善，直至客户满意。

（4）按照客户认可的软件需求进行软件的实现和交付。

显然，原型模型可以克服瀑布模型的缺点，降低由于软件需求不明确带来的开发风险。

2.螺旋模型

螺旋模型将瀑布模型和原型模型结合起来，兼顾原型模型迭代的特征，以及瀑布模型的系统化与严格监控，强调其他模型所忽视的风险分析，特别适合于大型的、复杂的、系统级的软件开发。

1）主要的迭代活动

（1）制订计划，确定软件目标，选定实施方案，弄清项目开发的限制条件。

（2）分析风险，评估所选方案，考虑如何识别和消除风险。

（3）实施工程，即实施软件开发和验证。

（4）客户评估，即评价开发工作，提出修正建议，制订下一步计划。

螺旋模型是一种风险驱动的方法体系，强调可选方案和约束条件，支持软件重用，有助于将软件质量作为特殊目标融入产品开发之中。

2）具体的限制条件

（1）软件开发客户接受度不高。螺旋模型强调风险分析，说服客户接受和相信这种风险分析并不容易。因此，螺旋模型一般适用于内部的软件开发。

（2）软件开发项目规模要求高。风险分析需要在保证项目利润的前提下进行，假如风险分析对项目利润影响过大，将导致此分析毫无意义。因此，螺旋模型只适用于大规模软件项目。

（3）软件开发人员能力要求高。要求开发人员必须擅长风险识别及分析，否则风险分析上的疏漏将会带来更大的项目风险。

螺旋模型的核心在于不需要在初期就把所有内容都定义得清晰、明确，而是定义最重要的功能并实现，收集意见后进入下一阶段，通过不断循环得到客户满意的最终产品。

3）实现的主要过程

（1）确定阶段目标、实现这些目标的可选项及其强制条件。

（2）从风险角度分析方案的开发策略，努力识别并化解各种潜在的风险，有时需要通过构建原型来完成。

（3）如果某些风险不能被排除，则该方案立即终止，否则进入下一个开发步骤。

（4）对阶段性结果进行评价，并设计下一阶段，确定进入下一阶段的方法和步骤。

3.演化模型

演化模型是一种全局的软件（或产品）生存周期模型，主要针对事先不能完整定义需求的软件开发。客户提供待开发系统的核心需求，在实现核心需求的基础上，及时有效地提供反馈信息，帮助实现系统的最终设计。软件开发人员根据客户的需求，通过快速分析构造出一个初始、可运行版本的核心系统。核心系统交付客户投入运行后，客户通过试用提出精化系统、增强系统的需求。软件开发人员根据客户的反馈，组织实施开发的迭代过程。迭代过程均由需求、设计、开发、测试、集成等阶段组成，每个迭代过程都是系统的一个可定义、可管理的子集。

演化模型采取分批循环开发的模式，每次循环开发的内容都成为产品原型的新增功能，进而不断地演化出新的系统。演化模型要求开发人员有能力把项目的需求，按照功能的重要性、对总体设计基础结构的影响，分解为不同批次，并按批次循环开发。

4.喷泉模型

喷泉模型是一种以用户需求为动力、以对象驱动的模型，主要用于描述面向对象的软件开发过程。喷泉模型具有更多的增量和迭代性质，项目生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。

5.智能模型

智能模型也称基于知识的软件开发模型，它拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件特性自动地生成源代码。这种方法需要第四代语言（4GL）的支持，但 4GL 目前主要限于事务信息系统的中小型应用程序的开发。

2.4.3 敏捷模式

随着计算机及网络技术的快速发展，以及市场和业务需求的变化，软件开发对及时响应的要求变得越来越高，需要新的开发方法来应对这种变化和要求。敏捷模式以其轻量级、简捷、快速响应、自发管理等特性，逐渐被人们广泛接受并在软件开发领域中越来越受欢迎。敏捷模式强调团队与业务专家的协作、面对面的沟通、频繁交付新的软件版本、紧凑且自我管理的组织型团队、拥抱变化并注重人的作用。因此，敏捷模式是以人为中心的软件开发方法。

1.敏捷模式的价值和原则

1）敏捷模式的价值

（1）以人为本，个体和互动高于流程和工具。

（2）目标导向，可运行的软件高于详尽的文档。

（3）客户为先，客户合作高于合同谈判。

（4）拥抱变化，响应变化高于遵循计划。

2）敏捷模式的原则

（1）最终目标是通过尽早和不断交付有价值的软件使客户满意。

（2）在开发周期中，拥抱变化、驾驭变化，保持客户的竞争优势。

（3）持续周期性交付可运行软件，周期越短越好。

（4）保持开发人员和业务人员的紧密联系，并贯穿于整个项目生命周期中。

（5）提供开发人员适宜的环境，给予开发人员完全的信任，保持开发人员的高昂斗志。

（6）开发小组要始终保持高效的信息传达方式，特别是面对面的沟通。

（7）项目进度的科学衡量标尺是可运行的软件。

（8）敏捷过程倡导可持续开发，出资人、开发人员和用户应该维持不变的节奏。

（9）敏捷性的提高来源于对技术和设计的不断追求。

（10）以人为本，精简工作量的管理技巧非常重要。

（11）最好的架构、需求和设计出自自我组织的团队。

（12）定期进行团队总结，探究如何提高效率，并根据对策采取行动。

由敏捷模式的价值与原则可以看出，敏捷模式更加关注客户价值。敏捷模式提倡紧跟市场潮流，通过自我组织的团队提高生产效率，对过程和产品进行持续改进和提升，更能保障交付。

2.敏捷模式的开发方法

敏捷模式的开发方法有Scrum、极限编程方法、精益开发方法、动态系统开发方法、特征驱动开发方法、水晶开发方法等。这些方法的内容将在知识篇中进行详细阐述。

3.敏捷模式的特征

（1）迭代开发。整个开发过程由几个迭代周期组成，每个迭代周期的时间一般比较短，通常为一个月左右。

（2）增量交付。产品在每个迭代周期结束时被逐步交付使用，每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

（3）测试驱动。开发团队和用户的测试与应用反馈推动产品开发，敏捷开发方法主张用户全程参与整个开发过程。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

（4）持续集成。新的功能或需求变化总是及时地被整合到产品中，有些是在每个迭代周期结束的时候集成，有些则每天保持集成。

（5）自我管理。人是敏捷开发的核心。敏捷开发是以人为中心建立开发的过程和机制，因此团队自我管理是实现以人为本的关键。

客户不断变化的需求是软件开发行业始终无法有效解决的问题，如在一个迭代周期内表现优异的瀑布模型，在面对变化的需求时就显得无能为力。敏捷模式主要通过持续迭代的办法，满足客户不断变化的需求。在每个迭代周期结束时，都能交付给客户一个可用的、可部署的系统，客户对该系统进行体验和全面试用，软件开发方收集试用过程中客户的真实反馈。这种模式可保证客户能够得到真正可投入使用的软件产品，大大降低了软件项目失败的风险，给客户和企业带来极大的好处。

4.敏捷模式的优势

（1）精确。敏捷方法能够准确定位交付优先级高、客户关注度高的需求并着重进行研发，在不断更新迭代中使其更加贴近客户的真实需求。

（2）质量可靠。敏捷方法对每次迭代的质量都有严格的要求。尤其是使用测试驱动开发的敏捷方法，先进行功能的测试代码开发，再进行正式功能代码的开发，为整个开发周期提供了可靠的质量保证。

（3）速度快。敏捷开发团队专注于最有价值的需求，较短的迭代周期能使团队成员迅速进入状态。

（4）丰厚的投资回报。在敏捷开发项目中，客户最需要、最有价值的功能始终保持最高的开发优先级，每个迭代周期交付的产品也保证核心功能的可用性，给客户带来丰厚的投资回报。

（5）高效的自我管理团队。敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，团队成员的技术能力、交流能力、社交能力、表达能力和领导能力都能得到提高。

5.敏捷模式的不足

（1）敏捷方法对团队成员之间的信任和合作能力有着较高的要求，但在实际的项目运作过程中存在比较多的问题。例如，团队成员能力不平均，团队内部存在竞争关系，团队成员之间不愿意做到毫无保留的沟通等。

（2）敏捷方法的不断迭代就决定了开发任务的繁重，也给团队成员造成了不小的压力。在这样的条件下，团队很难保持活力，人员的流动性较大。

2.4.4 微服务模式

微服务是一种开发模式，更是一种架构。它提倡将单体应用拆分成一组小的服务，这些服务互相配合，为用户提供最终价值。微服务模式的主要特征包括每个服务的构建都要对应具体业务，都有其单独运行的进程，服务的部署也能独立完成，服务之间采用轻量级通信机制等。

微服务模式既拆分又整合。拆分是指将一个完整的服务分解成粒度更小的微型服务集群，通过远程调用的方式解决依赖。整合是指所有的小服务组件形成一个按照集群化的方式设计的整体分布式系统，小服务之间能互相感知、自动化协作。

1.单体应用的不足

传统单体应用刚开始也是一个很成功的关键业务应用，随着时间的推移，慢慢变成一个巨大而复杂的怪物，表现为维护困难、应用无法扩展、可靠性很低。单体应用的不足表现在以下方面。

（1）因为单体应用太复杂，所以单个开发者不可能完全搞懂它，新人培养周期长。

（2）因为单体应用巨大而复杂，所以修改缺陷和正确添加新功能变得非常困难，可伸缩性差。

（3）单体应用巨大，降低了开发速度。应用越大，启动时间就越长。

（4）因为单体应用复杂而巨大，所以交付周期长，不便于小版本的频繁发布。

（5）单体应用在不同模块发生资源冲突时，扩展将会非常困难。

（6）单体应用可靠性差，所有模块都运行在一个进程中，任何一个模块中的一个缺陷都可能弄垮整个进程，影响整个应用。

（7）单体应用对新架构和新技术的融合非常困难，技术选型成本高。

对单体应用的上述不足，解决思路就是采用微服务模式，将单体应用分解为小的、互相连接的微服务。

2.微服务与SOA的区别

实际上，微服务并不是一个全新的概念。仔细分析SOA就会发现，它和我们今天所谈到的微服务的思想几乎一致。

微服务与SOA的区别见表2-2。

3.微服务模式的优势

（1）复杂度可控。通过应用分解，降低复杂度。微服务功能单一、接口定义清晰，由于量级小、复杂度低，微服务的可维护性和开发效率可由小规模开发团队自主把控。

（2）独立部署。微服务的独立进程决定了其独立部署的特性。单个微服务发生变更不会影响整个应用的编译、部署，这种模式使得发布更加高效，可降低对生产环境造成的风险，缩短交付周期。

（3）技术选型灵活。微服务架构的技术选型是去中心化的。开发团队根据服务需求和行业现状选择技术栈。在微服务模式下，对技术栈进行升级时所面临的风险会降低，甚至能以重构微服务的方式进行。

（4）容错。传统架构的单一进程出现故障时容易扩散，导致整个系统不能正常使用；而微服务架构使得故障被隔离在单个服务单元中，能实现应用层面的容错。

（5）扩展。微服务的灵活性体现在应用的不同组件上，在扩展需求上存在差异时，每个服务可以根据实际需求进行独立扩展。

2.4.5 App模式

App模式分为Native、Web App、Hybrid三种，每种模式都有其优、缺点，需要根据具体项目要求和业务应用场景，以满足交付目标为出发点，选择合适的开发模式。

1.Native模式

Native（原生态）模式是指原生程序，一般依托于操作系统，有很强的交互性和可拓展性，需要用户下载并安装使用。例如，基于智能手机本地操作系统如iOS、Android、黑莓等，采用原生程序编写运行的第三方应用程序，一般开发语言为Java、C++等。

Native模式通常由云服务器数据和App客户端两部分构成，所有的UI元素、数据内容、逻辑框架均安装在手机终端上。原生应用程序是某个移动平台（如iOS或Android）所特有的，使用相应平台支持的开发工具和语言开发，如 iOS 平台支持 Xcode 和Objective-C，Android平台支持Eclipse和Java。原生应用程序从外观和运行效果上来看是最佳的。

1）主要优点

（1）能够使用移动硬件设备的底层功能，如摄像头、重力加速器、GPS等。

（2）速度高，性能好，可线下使用，用户体验好。

（3）支持大量图形和动画。

（4）可以访问本地资源。

（5）容易发现，一些应用商店与市场会帮助用户寻找原生App。

（6）官方市场的应用审核流程能保证让用户得到高质量及安全的App。

（7）能够获得官方提供的开发工具或人工支持来帮助开发。

2）存在的不足

（1）开发成本高，尤其是需要多种移动设备来测试时，每种移动操作系统都需要独立的开发项目，针对不同平台提供不同体验。

（2）因为采用不同的开发语言，所以开发和维护成本高，维护困难。

（3）支持设备限制明显。

（4）应用商店发布审核周期长，严重影响发布进程和上线时间。

（5）发布新版本慢。下载是用户控制的，很多用户不愿意下载更新，用户体验差。

2.Web App模式

Web App模式是指采用HTML5语言开发的App，不需要下载安装。Web App模式是一种框架型 App 开发模式，该模式具有跨平台的优势，能够为移动设备提供特定功能的Internet应用程序，通常由HTML5云网站和App客户端两部分构成。App客户端只需安装应用的框架部分，而应用的数据则是每次打开App时去云端获取并呈现给手机用户的。

1）主要优点

（1）跨平台开发，用户不需要去应用市场下载安装App，具有较低的开发成本和较高的开发速度，任何时候都可以发布App。

（2）App开发速度快、成本低，可以适应多个平台。

（3）基于浏览器，可以跨平台使用，支持设备广泛。

（4）不需要安装包，可节约手机空间。可自动更新，无须用户手动更新，推送给用户的都是最新版本，更便于业务的开展。

2）存在的不足

（1）只能使用有限的移动硬件设备功能，无法使用很多移动硬件设备的独特功能。

（2）这种App很难被用户发现，同时受多种移动设备的浏览器影响。

（3）数据获取都在资源页面上异步完成，安全性相对较低，数据容易泄露或被劫持。

（4）对网络的要求比较高，在网速受到限制时容易出现卡顿或卡死现象。

（5）对图片和动画的支持度不高，页面跳转更加费力，不稳定感更强。

（6）导航不明显。

（7）动态交互效果受到限制，影响用户对一些页面场景、逻辑的理解。

3.Hybrid模式

Hybrid（混合态）模式是指半原生半 Web 的混合类 App，需要下载安装。该模式把HTML5应用程序嵌入原生容器里，集原生应用程序和HTML5应用程序的优点于一身。它必须部分在设备上运行，部分在Web上运行。

这种模式分为三种方案，第一种以 Web 架构为主，第二种编译转换方式，第三种以Native架构为主。其中，第三种方案是目前主流的方案。

混合态模式的三种方案优缺点的比较见表2-3。