理顺软件开发各个环节-2（开发模式选取）

目录

3 开发模式选取

　　3.1 瀑布式开发模式

　　3.2 迭代式开发模式

　　3.3 螺旋式开发模式

　　3.4 敏捷开发模式

　　3.5 随意模式

　　3.6 开发模式选取探讨

 

3 开发模式选取

　　开发模式主流有瀑布式开发模式、迭代式开发模式、螺旋式开发模式和敏捷开发模式，还有实际上大部分研发团队使用的随意模式。

　　正确认识不同开发模式的优劣，选取合适的开发模式，是软件项目成功的基础。

　　何谓项目成功？我认为，最低程度是产品的各个Roadmap节点都能很好地交付且被大量或正式使用；更高的层面，是产品能在应付意外需求变更或未知的需求时，仍能有较好适应性，并且有较长的生命期。某天，项目团队成员如果谈到某个软件项目，是兴奋和自豪，说明这个项目是成功的。

　　下文中的瀑布式开发模式、迭代式开发模式、螺旋式开发模式和敏捷开发模式章节内容，大部分取自网上，再加上我自己的一点观点。

3.1 瀑布式开发模式

　　瀑布式开发模式（Waterfall）是早期比较流行的模式，其特点如下：

• 注重软件开发的各个阶段：需求分析、系统设计、编程实现、软件测试、软件维护，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开；为项目提供了按阶段划分的检查点；

• 强调文档输出，文档的重要性高于代码；

• 瀑布模型把每个开发阶段都定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，不需要关注其他阶段的工作。

 

　　普遍认为，瀑布开发模式有如下缺点：

• 不适应需求变更，特别是需求不确定的项目；

• 文档量过重，在需求变动时，文档一致性维护成本过高；

• 开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而大大增加了开发风险；

• 如果需求与用户的设想出现了偏离，这种错误将会贯穿整个项目周期，设计受需求的影响，代码受设计的影响，直到项目接近完成，将产品交付给用户使用测试时，错误才被用户提出，这时项目已处于尾声，为时已晚。

 

3.2 迭代式开发模式

　　迭代式开发模式也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

　　迭代式开发，每次只设计和实现这个产品的一部分，逐步逐步完成的方法叫迭代开发，每次设计和实现一个阶段叫做一个迭代。

　　在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如2~4周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

　　迭代式开发的优点：

• 降低风险；

• 得到早期用户反馈；

• 持续的测试和集成；

• 使用变更；

• 提高复用性。

 

　　迭代式开发模式的不足之处：

　　如果对需求没有整体把握时就开始迭代开发，可能无法避免结构性风险，如新增的某个需求导致整个结构或系统设计不可用或需要大幅度调整。

 

3.3 螺旋式开发模式

　　螺旋式开发模式兼顾了快速原型的迭代特征及瀑布模型的系统化和严格监控，其最大的特点是引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失。同时，在每个迭代阶段构建原型是螺旋模型用来减少风险的方法。

　　螺旋模型更适合大型的昂贵的系统级的软件开发，一开始应用的规模很小，当项目被定义得更好、更稳定时逐渐展开。其核心在于不需要在刚开始时就把所有事情都定义清楚，可以先定义最重要的功能去实现它，然后听取客户的意见，再进入下一个阶段，入此不断循环、重复，直到得到满意的产品。螺旋模型在很大程度上是一种风险驱动的方法体系，因为在每个阶段及经常发生的循环之前，都必须先进行风险评估。强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

　　螺旋式开发有如下特点：

• 制定计划：确定软件目标，选定实施方案，弄清楚项目开发的限制条件；

• 风险分析：分析、评估所选方案，考虑如何识别和消除风险；

• 实施工程：实施软件开发和验证；

• 客户评估：评价开发工作，提出修正建议，制定下一步计划。

 

　　螺旋式开发模式也有不足之处：

• 很难让用户确信这种演化方法的结果是可以控制的；

• 建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

 

3.4 敏捷开发模式

　　敏捷开发模式，是当前最流行的开发模式。

　　敏捷开发，英文是Agile Development，是一种以人为核心、迭代、循序渐进的开发方式，是一种软件开发的流程。它会指导开发人员用规定的环节去一步一步完成项目的开发。由于它采用迭代式开发，所以它主要的驱动核心是人，而不是像瀑布模型那样，以文档为核心。

　　敏捷开发模式，具有应对快速变化的需求的软件开发能力。它的具体名称、理念、过程、术语都不尽相同，相对于非敏捷开发，更强调程序员团队与业务专家之间的紧密协作及面对面沟通，比单纯通过书面文档沟通更有效，能更频繁地交付新的软件版本，使自我组织、自我约束的团队能够更好地适应需求的变化，也更注重软件开发过程中人的作用。

　　敏捷开发提出了以下的一些原则：

• 假设需求总是会变化的，并欢迎需求的变化，因为需求的变化可能意味着可以提升产品的商业价值；

• 设计是演进式的，并要保持简单设计和弹性设计，以便能快速响应需求的变化，而需求变化总是会引起设计的腐化，因此，经常性的对代码进行重构是必须的；

• 短期持续交付可运行的系统给用户，目的是尽早取得用户的反馈；

• 更多原则可参考相关敏捷开发的书籍和文章。

 

　　敏捷软件开发有如下特点：

• 首要任务是尽早地、持续地交付可评价的软件，以使客户满意；

• 乐于接受需求变更，即使在开发后期也是如此。敏捷软件开发能够驾驭需求的变化，从而赢得竞争优势；

• 频繁交付可使用的软件，交付的间隔越短越好，可以从几个月缩减到几个星期；

• 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起；

• 围绕那些有推动力的人们来构建项目，给予他们所需的环境和支持，并且相信他们能够把工作做好；

• 开发团队及在开发团队内部进行最快速、有效的传递信息的方法是面对面交谈；

• 可使用的软件是进度的主要衡量指标；

• 提倡可持续发现。出资人、开发人员及使用者应该共同维持稳定的开发速度；

• 为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计；

• 简洁，最小化那些没有必要投入的工作量是至关重要的；

• 最好的架构、需求和设计都源于自我组织的团队；

• 团队定期反思如何变得更有战斗力，然后相应地转变并调整其行为。

 

　　敏捷开发，有scrum、XP、crystal、FDD等方法，我之前采用的是scrum方法。

 

　　敏捷开发的缺点是，恰恰是它追求的，即人的因素：

• 对人员的素质要求较高，需要有较好的沟通能力；

• 彼此信任的基础是各自的能力，不能由于个别成员的能力拖累整体进度；

• 对人员的稳定性要求较高，在轻文档的思想下，人员流动导致后期维护问题较多。

 

3.5 随意模式

　　随意模式在不成熟的研发团队，是最常见的，上面四种模式都不像，可以称为“四不像”。但他们往往宣称采用的是敏捷开发模式。

　　随意模式，没有需求分析和系统设计的阶段，需求加入很随意，产品经理或市场人员整一个feature list，描述下功能要求，然后在白板或白纸上画几个框图，就开始编码实现了，也没有文档输出和积累。很多情况也没有软件质量保障体系，软件质量取决于开发人员的素质。

　　根据熵增原理，随着需求的不断加入，没有良好设计或重构的系统结构往往难以为继，软件产品背负越来越多的技术负债，开发人员苦不堪言，指望缝缝补补趟过去，或自己跳出泥潭，项目成功的几率往往很低。

3.6 开发模式选取探讨

　　在需求相对稳定的情况下，使用瀑布式开发模式，仍是可行的。

　　在敏捷开发大行其道之时，我们要尽量吸收敏捷开发的精髓。其次必要的文档还是需要的。

　　快速迭代仅仅是外部表征，每日站会也不能沦为形式，目的是充分沟通和消除风险。

　　我认为，这些开发模式并不是非此即彼、相互排斥的，可以相互参考，形成更为实用的开发模式。

 

　　我认可的合适的开发模式如下：

1. 全面了解产品需求，不能忽视性能和非功能性需求。

2. 根据全面的产品需求，进行软件需求分析，某些产品需求，只需要了解其有无特别的技术要求或限制，无需详细展开；目的是消除结构性风险，免得系统设计考虑不全面。

3. 进行系统设计，并验证各产品需求点是否都可以在此架构中实现，以及对未来可能需求的扩展灵活性。

4. 抽取出MVP，即最小可行产品（Minimum Viable Product，简称MVP）。快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设。用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。（此处借鉴了螺旋式开发模式的思想）。

5. 使用敏捷开发模式，开发MVP。包括任务拆解，工作量评估，编码实现，单元测试，联调测试，集成测试等各个环节。

6. MVP开发过程输出下列文档：子系统或模块的概要设计文档；数据库设计文档；接口文档；重要功能的详细设计文档。（此处借鉴了瀑布式开发模式的思想）。

7. MVP验收或上线，项目复盘。

8. 然后下一次MVP迭代。

 

　　这种模式，有几个关键点，可以探讨：

　　1）全面了解产品需求，是基础。

　　问题是，产品经理说，有些模块或功能，需求暂时没法清楚地描述出来。

　　如对接外部系统，只知道对接，数据内容、格式和交互方式没法搞清楚，是一个黑盒子，不同外部系统对接方式也可能不同。

　　还有如某个功能模块，涉及一大块业务，业务逻辑还没理顺，想想头都要炸了，到时候做不做还两说呢。

　　怎么说呢，反正是朦胧派。

 

　　我的观点，如能了解，仅尽量多了解一点，反正还没开始开发，代价不大。然后将已知的信息记下来。

　　不全面的需求，对架构设计是一个考验，比如知道需要对接外部系统，不妨设立一个网关子系统，从而进行隔离；如果某个没法确定的模块，了解大概的业务特点，分析是否可以从本项目中剥离出来等等。

 

　　2）关于MVP迭代。

　　每次MVP迭代，首先对上个MVP进行检查，确定哪些需要修正。然后再确定哪些需求项是本次必须的，检查如果必须要砍需求，可砍掉哪个需求，会有什么后果？直到没法精减。

　　MVP开发采用伪敏捷开发模式，即不完全等同于敏捷开发，轻文档是总体指导思想，但必要的文档还是需要的。

　　数据库文档，可使用DDL文件；接口文档，可考虑YApi（或直接让代码支持swagger，然后将接口可视化）。

　　其它需求分析、设计文档可以使用MarkDown格式，用知识库管理，便于在线浏览和更新。

　　其它按照研发管理制度来执行即可，如遵循开发约定。

　　特别需要提及的一点，关于MVP的测试，在用户故事（敏捷开发的需求项）之处要约定验收标准，对初期的用户故事，测试往往只是一个正向用例，不同阶段的MVP，验收标准是不同的。

　　初期代码实现时，仍然需要考虑异常场景，但只需要预留处理接口，不必有具体实现代码，留待后期MVP完善时填充丰富。对于MVP简化处理的情况，也类似处理。

 

　　3）关于文档。

　　必要的文档是非常需要的，要知道软件产品，不仅是代码，还应包括相关文档。

　　计算机语言是表达思想的一种方式，代码不仅输入给编译器（或解析器）的，同时，也是呈现给软件工程师的。

　　由于IT行业人员的高流动性，以及业务扩展和变动带来的代码维护和变动需求，仅有代码无文档或文档稀少的情况给代码维护工作带来极大的困难，容易埋下更多的坑，此将大大缩短软件的生命期。

　　敏捷开发是轻文档，而不是没文档！但可惜现状是几乎没文档。开发人员也许干得很high，但后期维护人员却苦不堪言，在我看来，这就不是一个成功的产品，只能算是一次成功的项目实施。

 

　　4）关于配置管理。

　　在MVP迭代一个阶段完成后，进行项目复盘。此时要将数据库脚本和接口文档纳入git配置管理。接口文档（代码支持swagger，或从YApi导出），放入代码docs/api目录下；数据库脚本，放入docs/sql目录下；还可以考虑将markdown格式的设计、分析文档纳入基线管理。这样，文档与代码的基线版本就对齐了。