敏捷开发2.0

在了解敏捷开发2.0之前，先来了解常用的4种开发模式

常用的4种开发模式

1.瀑布式开发

瀑布式开发是由WW.Royce 在1970年提出的软件开发模型，是一种比较老的计算机软件开发模式，也是典型的预见性的开发模式。在瀑布式开发中，开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行，步骤的成果作为衡量进度的方法，例如需求规格、设计文档、测试计划和代码审阅等。 瀑布式开发最早强调系统开发应有完整的周期，且必须完整地经历每个周期内的每个开发阶段，井系统化地考量分析所涉及的技术、时间与资源 投入等。
瀑布式开发的主要问题是它的严格分级导致自由度降低，项目早期即作出承诺会导致对后 期需求的变化难以调整且代价很大，这在需求不明晰并且在项目进行过程中可能有变化的情况 下基本上是不可行的。

2.迭代式开发

法代式开发也被称为迭代增量式开发，是一种与传统的瀑布式开发相反的软件开发过程， 它弥补了传统开发方式的一些弱点，有更高的成功率。在迭代式开发中，整个开发工作被组织 为一系列短小的、固定长度的小项目，每次选代都包括需求分析、设计、实现与测试。采用迭 代式开发时， 工作可以在需求被完整地确定之前启动， 并在一次选代中完成系统的一部分功能 或业务，再通过客户的反馈来细化需求，并开始新一轮的迭代。

特点：

• 每次只设计和实现产品的一部分。
• 一步一步地完成。
• 每次设计和实现一个阶段，这叫作一个迭代。

3.螺旋式开发

螺旋式开发是由巴利 · 玻姆 CBa町 Boehm）在 1988 年正式发表的软件系统开发模型，它 兼顾了快速原型的法代特征及瀑布模型的系统化和严格监控，其最大的特点是引入了其他模型 不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失。 同时，在每个法 代阶段构建原型是螺旋模型用来减少风险的方法。 螺旋模型更适合大型的昂贵的系统级的软件 开发， 一开始应用的规模很小，当项目被定义得更好、更稳定时逐渐展开。其核心在于不需要 在刚开始时就把所有事情都定义清楚，可以先定义最重要的功能去实现它，然后听取客户的意 见，再进入下一个阶段，如此不断循环、重复，直到得到满意的产品。螺旋模型在很大程度上 是一种风险驱动的方法体系，因为在每个阶段及经常发生的循环之前，都必须先进行风险评估。

特点：

• 制定计划：确定软件目标，选定实施方案，弄清楚项目开发的限制条件。
• 风险分析： 分析、评估所选方案，考虑如何识别和消除风险。
• 实施工程：实施软件开发和验证。
• 客户评估：评价开发工作，提出修正建议，制定下一步计划。

4.敏捷开发

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

特点：

• 首要任务是尽早地、持续地交付可评价的软件，以使客户满意。
• 乐于接受需求变更，即使在开发后期也是如此。敏捷软件开发能够驾驭需求的变化，从
  而为客户赢得竞争优势。
• 频繁交付可使用的软件，交付的间隔越短越好，可以从几个月缩减到几个星期。
• 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
• 围绕那些有推动力的人们来构建项目，给予他们所需的环境和支持，并且相信他们能够
  把工作做好。
• 开发团队及在开发团队内部进行最快速、有效的传递信息的方法是面对面交谈。
• 可使用的软件是进度的主要衡量指标。
• 提倡可持续发展。出资人、开发人员及使用者应该共同维持稳定的开发速度。
• 为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。
• 简洁，最小化那些没有必要投入的工作量是至关重要的。
• 最好的架构、需求和设计都源于自我组织的团队。
• 团队定期反思如何变得更有战斗力，然后相应地转变井调整其行为。

总结瀑布式开发：

对比以上4种开发模式，总结如下：

• 瀑布式开发：在从需求到设计、从设计到编码、从编码到测试、从测试到提交的每个开发阶段都要做到最好，特别是在前期阶段设计得越完美，提交后的损失就越少。然而现 在的系统很复杂且多变，所以很难在现实中应用瀑布式开发。
• 迭代式开发：不要求每个阶段的任务都做到最好，可以容忍一些不足，先不去完善它， 将主要功能先搭建起来，以最短的时间及最少的损失完成一个不完美的成果直至提交， 然后通过客户或用户的反馈信息，在这个不完美的成果上逐步进行完善。
• 螺旋开发：在很大程度上是一种风险驱动的方法体系，因为在每个阶段及经常发生的循 环之前，都必须先进行风险评估。
• 敏捷开发：和迭代式开发相比，两者都强调在较短的开发周期内提交软件，但是，敏捷 开发的周期可能更短且更强调队伍中的高度协作。敏捷方法有时被误认为是无计划性和 纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性，适应性的方法 主要用于快速适应需求的变化。当项 目的需求有变化时，团队能够迅速应对新的需求。

DevOps

目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：解决开发者与运维 者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流。
DevOps 是通过自动化的基本设施、自动化的工作流程和持续可测量的应用性能，来整合开 发团队和运维团队，以达到更高的合作效率和生产率。
精益管理的7个原则：

• 消除浪费
• 增强学习
• 延迟决策
• 快速交付
• 团队授权
• 内置完整性
• 考虑全局
  DevOps可以用一个公式表达：
  文化观念的改变+自动化工具=不断实应快速变化的市场
  核心价值：
• 更快速的交付，响应市场的变化。
• 更多地关注业务地改进与提升。
• 

敏捷开发2.0

敏捷开发2.0是相对于敏捷开发而言地，敏捷开发意味着让我们全面拥抱需求地变化，但是对于瞬息万变地市场反馈还远远不够足以应对，因此为了更加快速地发现问题和得到市场地快速反馈，引入了持续集成（Continuous Integration,CI）和持续交付（Continuous Delivery,CD）,来更加高效地进行敏捷开发，即敏捷开发2.0。

• 持续集成：是一种软件开发实践，要求团队成员经常集成其工作，每个人至少每天集成一次会导致每天有多个集成。集成是通过自动化的构建进行验证的，这些构建运行回归测试，以尽快检测集成中的错误。团队慢慢会发现，这种方法有利于集成问题的大幅减少，更快地实现有凝聚力的软件开发方式。
• 持续交付是在持续集成的基础上，将集成后的代码部署到更贴近真实的运行环境的预生产环境中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中进行测试。如果代码没有任何问题，则可以继续部署到生产环境中 。
• 持续部署：是持续交付的更高级阶段，即所有通过了自动化测试的改动都自动地部署到生产环境中。大多数公司如果没有受制度的约束或其他条件的影响，则都应该以持续部署为目标。 在很多业务场景里， 一种业务需要等待其他功能完成了才能上线， 这使得持 续部署不可能实现。虽然可以使用功能转换解决很多这样的问题，但并不是每次都会这样。 所以，持续部署是否适合某个公司是基于该公司的业务需求的，而不是技术限制。

敏捷开发 2.0 要求将大而全的项目拆分成小的相对独立的服务， 从一开始就不仅仅只关注自动化部署，还要关注整个项目是否具备自动化的、可快速扩展的、完善的容错机制，以及零宕机和便捷的监控管理。为了实现敏捷开发 2.0， 我们需要采用持续部署、 微服务和 容器这三种技术方案。

• 持续部署：能够持续自动反馈应用程序的提交状态，减少错误等； 同时为产品的交付提供了质量保证，能快速投入市场。
• 微服务：使技术选型、构架系统更自由；开发更快速、周期更短： 服务更容易扩展。
• 容器： 使部署成百上千的微服务更加容易，系统更加稳定。

敏捷开发2.0流程