理顺软件开发各个环节-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格式的设计、分析文档归入基线管理。这样，文档与代码的基线版本就对齐了。