如何理解敏捷开发
目录
什么是敏捷开发 2.0
常用的 4 种开发模式
瀑布式开发
瀑布式开发是由 WW.Royce 在 1970 年提出的软件开发模型，是一种比较老的计算机软件开发模式， 也是典型的预见性的开发模式。在瀑布式开发中，开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行，步骤的成果作为衡量进度的方法，例如需求规格、设计文档、测试计划和代码审阅等。 瀑布式开发最早强调系统开发应有完整的周期，且 必须完整地经历每个周期内的每个开发阶段，井系统化地考量分析所涉及的技术、时间与资源投入等。
瀑布式开发的主要问题是它的严格分级导致自由度降低，项目早期即作出承诺会导致对后 期需求的变化难以调整且代价很大，这在需求不明晰并且在项目进行过程中可能有变化的情况 下基本上是不可行的。瀑布式开发如图所示：
迭代式开发
法代式开发也被称为迭代增量式开发，是一种与传统的瀑布式开发相反的软件开发过程， 它弥补了传统开发方式的一些弱点，有更高的成功率。在迭代式开发中，整个开发工作被组织 为一系列短小的、固定长度的小项目，每次选代都包括需求分析、设计、实现与测试。采用迭代式开发时， 工作可以在需求被完整地确定之前启动， 并在一次选代中完成系统的一部分功能 或业务，再通过客户的反馈来细化需求，并开始新一轮的迭代。迭代式开发如图所示：
代式开发有如下特点：
- 每次只设计和实现产品的一部分；
- 一步一步地完成；
- 每次设计和实现一个阶段，这叫作一个迭代。
螺旋式开发
螺旋式开发是由巴利 · 玻姆在 1988 年正式发表的软件系统开发模型，它兼顾了快速原型的法代特征及瀑布模型的系统化和严格监控，其最大的特点是引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失。 同时，在每个法 代阶段构建原型是螺旋模型用来减少风险的方法。 螺旋模型更适合大型的昂贵的系统级的软件开发， 一开始应用的规模很小，当项目被定义得更好、更稳定时逐渐展开。其核心在于不需要 在刚开始时就把所有事情都定义清楚，可以先定义最重要的功能去实现它，然后听取客户的意 见，再进入下一个阶段，如此不断循环、重复，直到得到满意的产品。螺旋模型在很大程度上 是一种风险驱动的方法体系，因为在每个阶段及经常发生的循环之前，都必须先进行风险评估。 螺旋式开发如图所示：
特点：
- 制定计划：确定软件目标，选定实施方案，弄清楚项目开发的限制条件。
- 风险分析： 分析、评估所选方案，考虑如何识别和消除风险。
- 实施工程：实施软件开发和验证。
- 客户评估：评价开发工作，提出修正建议，制定下一步计划。
敏捷软件开发
敏捷软件开发又被称为敏捷开发，是一种从 1990 年开始逐渐引起人们的广泛关注的新型软 件开发方式，具有应对快速变化的需求的软件开发能力。它的具体名称、理念、过程、 术语都 不尽相同，相对于非敏捷开发，更强调程序员团队与业务专家之间的紧密协作及面对面沟通， 比单纯通过书面文档沟通更有效，能更频繁地交付新的软件版本，使自我组织、自我约束的团 队能够更好地适应需求的变化，也更注重软件开发过程中人的作用。 如图所示：
敏捷软件开发特点：
- 首要任务是尽早地、持续地交付可评价的软件，以使客户满意。
- 乐于接受需求变更，即使在开发后期也是如此。敏捷软件开发能够驾驭需求的变化，从 而为客户赢得竞争优势。
- 频繁交付可使用的软件，交付的间隔越短越好，可以从几个月缩减到几个星期。
- 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
- 围绕那些有推动力的人们来构建项目，给予他们所需的环境和支持，并且相信他们能够把工作做好。
- 开发团队及在开发团队内部进行最快速、有效的传递信息的方法是面对面交谈。
- 可使用的软件是进度的主要衡量指标。
- 提倡可持续发展。出资人、开发人员及使用者应该共同维持稳定的开发速度。
- 为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。
- 简洁，最小化那些没有必要投入的工作量是至关重要的。
- 最好的架构、需求和设计都源于自我组织的团队。
- 团队定期反思如何变得更有战斗力，然后相应地转变井调整其行为。
4 种开发模式总结
瀑布式开发：
在从需求到设计、从设计到编码、从编码到测试、从测试到提交的每个开发阶段都要做到最好，特别是在前期阶段设计得越完美，提交后的损失就越少。然而现在的系统很复杂且多变，所以很难在现实中应用瀑布式开发。
迭代式开发：
不要求每个阶段的任务都做到最好，可以容忍一些不足，先不去完善它， 将主要功能先搭建起来，以最短的时间及最少的损失完成一个不完美的成果直至提交， 然后通过客户或用户的反馈信息，在这个不完美的成果上逐步进行完善。
螺旋开发：
在很大程度上是一种风险驱动的方法体系，因为在每个阶段及经常发生的循环之前，都必须先进行风险评估。
敏捷开发：
和迭代式开发相比，两者都强调在较短的开发周期内提交软件，但是，敏捷开发的周期可能更短且更强调队伍中的高度协作。敏捷方法有时被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性，适应性的方法主要用于快速适应需求的变化。当项 目的需求有变化时，团队能够迅速应对新的需求。
在一般的公司里，采用敏捷开发和不断迭代开发的方式较多，而且效率高、效果明显。因 为之前做的系统业务单一、逻辑简单、用户量少，项目团队的规模一般在 10～30 人。现在的系 统要面对不同用户的定制化的推荐，互联网连接着人与人、人与物及物与物，业务也变得越来越复杂，功能越来越多，如果整个系统糯合在一起，则必定会牵一发而动全身，导致系统维护 起来相当困难，同时每个公司又面临着人员的频繁流动、系统文档的不完善或多次转手丢失等 情况，以至于新来的人员很难快速了解和熟悉系统。因而，人们开始思考如何更高效地解决复 杂的大型系统的开发模式，在此姑且称之为“敏捷开发 2.0"，在介绍敏捷开发 2.0 的概念之前， 先介绍时下热门的 DevOps。
什么是 DevOps
目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流。
DevOps 是通过自动化的基本设施、自动化的工作流程和持续可测量的应用性能，来整合开 发团队和运维团队，以达到更高的合作效率和生产率。
然而笔者认为 DevOps 不仅仅局限在开发者和运维之间，更是一种文化的改变和鼓励沟通、 交流、合作的行动，目的在于更加快速稳定地构建高质量的应用系统，这恰好体现了精益管理 的原则。我们也可以把 DevOps 看作一种能力。
如何获得这种能力呢？
关键有两点：
一是全局观，要从软件交付的全局出发， 加强各角色之间的合作；
二是自动化，人机交互就意味着手工操作，应选择那些支持脚本化、无须人机交互界面的强大管理工具，比如各种受版本控制的脚本，以及类似于 Zabbix 这样的基础设施监控工具和类似于 SaltStack、 Ansible 这样的基础设施配置管理工具等。
DevOps 可以用一个公式表达：
文化观念的改变 + 自动化工具 = 不断适应快速变化的市场
其核心价值在于以下两点：
1.更快速的交付，响应市场的变化；
2.更多地关注业务的改进与提升；
精益管理的7个原则
- 消除浪费；
- 增强学习；
- 延迟决策；
- 快速交付；
- 团队授权；
- 内置完整性（完整性是为了让客户对产品的体验具备平滑性和一致性）；
- 考虑全局；
DevOps的开发流程
提交
工程师将程序在本地测试后，提交到版本控制系统如Git等；
编译
持续整合系统（如 Jenkins CI)，在检测到版本更新时，便自动从 Git 仓库里拉取 最新的程序，进行编译、构建。
单元测试
Jenkins 完成编译构建后，会自动执行指定的单元测试代码。
部署到测试环境中
在完成单元测试后， Jenkins 可将程序部署到与生产环境相近的测试环境中进行测试。
预生产测试
在预生产测试环境里，可以进行一些最后的自动化测试，例如 Selenium 测试及与实际情况类似的测试，可由开发人员或客户手动进行。
部署到生产环境
通过所有测试后，便可将最新的版本部署到实际生产环境里。
如图所示：
从流程中可以看到，借助 Jenkins 等工具，提交程序之后的步骤几乎都可以自动化完成， 这节省了工程师的大量手动操作时间。由于每次提交程序后都会自动进行编译与测试等流程， 所以一旦有问题就可以马上发现并处理 CJenkins 会自动通知），这样也保证了程序的质量。
上图有一个很重要的角色： SaltStack。 SaltStack 是一个架构管理系统，可以批量地修改 Server 的设定或执行指令，也可以通过配置管理使得开发环境、测试环境及应用环境最大可能 地保持一致。 SaltStack 使得管理大量 Server 变得更轻松，这方便了运维工作。 与 SaltStack 类似 的工具还有 Puppet、 Chef、 Ansible 等。
敏捷开发 2.0 解决的问题
敏捷开发 2.0 是相对于敏捷开发而言的，敏捷开发意味着让我们全面拥抱需求的变化， 但 是对于瞬息万变的市场反馈还远远不足以应对，因此为了更加快速地发现问题和得到市场的快 速反馈，引入了持续集成（Continuous Integration, CI）和持续交付（Continuous Delivery, CD), 来更加高效地进行敏捷开发，即敏捷开发 2.0。
持续集成
是一种软件开发实践，要求团队成员经常集成其工作，每个人至少每天集成 一次会导致每天有多个集成。 集成是通过自动化的构建进行验证的，这些构建运行回 归测试，以尽快检测集成中的错误。团队慢慢会发现，这种方法有利于集成问题的大 幅减少，更快地实现有凝聚力的软件开发方式。
持续交付
是在持续集成的基础上，将集成后的代码部署到更贴近真实的运行环境的预 生产环境中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环 境中进行测试。如果代码没有任何问题，则可以继续部署到生产环境中 。
持续部署
是持续交付的更高级阶段，即所有通过了自动化测试的改动都自动地部署到生产环境中。大多数公司如果没有受制度的约束或其他条件的影响，则都应该以持续部署为目标。 在很多业务场景里， 一种业务需要等待其他功能完成了才能上线， 这使得持续部署不可能实现。虽然可以使用功能转换解决很多这样的问题，但并不是每次都会这样。 所以，持续部署是否适合某个公司是基于该公司的业务需求的，而不是技术限制。
总结
DevOps 不能只关注开发及运维，还应该关注产品、开发、测试、运维， 甚至对客户的需求 也要有了解。而敏捷开发 2.0 要求将大而全的项目拆分成小的相对独立的服务， 从一开始就不 仅仅只关注自动化部署，还要关注整个项目是否具备自动化的、可快速扩展的、完善的容错机 制，以及零岩机和便捷的监控管理。为了实现敏捷开发 2.0， 我们需要采用持续部署、 微服务和 容器这三种技术方案。
- 持续部署：能够持续自动反馈应用程序的提交状态，减少错误等； 同时为产品的交付提 供了质量保证，能快速投入市场。
- 微服务：使技术选型、构架系统更自由：开发更快速、周期更短： 服务更容易扩展。
- 容器： 使部署成百上千的微服务更加容易，系统更加稳定。
文章转载于：《分布式服务架构：原理、设计与实战》本文仅供参考，交流，学习，如侵联删