20xx年国内外敏捷软件开发发展现状与展望

20xx年国内外敏捷软件开发发展现状与展望内容摘要：

责人（ Product Owner） 2. Scrum Master 3. Scrum 团队  六个时间箱 1. Sprint 14 2. 发布计划会议（ Release Planning Meeting） 可选 3. Sprint 计划会议（ Sprint Planning Meeting） 4. 每日站会（ Daily Scrum Meeting） 5. Sprint 评审会议（ Sprint Review Meeting） 6. Sprint 回顾会议（ Sprint Retrospective Meeting）  四个工件 1. 产品 Backlog（ Product Backlog） 2. 发布燃尽图（ Release Burndown Chart） 可选 3. SprintBacklog 4. Sprint 燃尽图（ Sprint Burndown Chart） Scrum 最早由 Jeff Sutherland 在 1993 年提出， Ken Schwaber 在 1995 年OOPSLA 会议上形式化了 Scrum 开发过程，并向业界公布。 目前 Scrum 是应用最为广泛的敏捷方法之一 SCRUM 理论基础 Scrum 是以经验过程控制理论作为理论基础，通过迭代、增量的方法来增强产品开发的可预见性，并控制风险。 Scrum 经验过程控制理论的实施由三大支柱支撑： 第一：透明 性 （ Transparency） 透明 度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。 管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。 也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成 的 定义。 第二：检验（ Inspection） 开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。 在确定检验频率 时，需要考虑到检验会引起所有过程发生变化。 当规 15 定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。 幸运的是，软件开发并不会出现这种情况。 另一个因素就是检验工作成果人员的技能水平和积极性。 第三：适应（ Adaptation） 如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么 便需要 对过程或是材料进行调整。 调整工作必须尽快实施 ， 以减少进一步的偏差。 Scrum 中通过三个活动进行检验和适应：每日 例 会检验 Sprint 目标的进展，做出 调整 ，从而 优化次日的工作价值 ； Sprint 评审和计划会议检验发布目标的进展， 做出 调整 ，从而 优化下一个 Sprint 的工作价值 ； Sprint 回顾会议是用来回顾 已经完成的 Sprint，并且确定做出什么样的改善可以使接下来的 Sprint 更加高效、更加令人满意，并且工作更快乐。 精益软件开发（ Lean Software Development） 精益思想源自丰田公司的产品开发方法。 它主要包括两个部分：一部分是核心思想及原则，另外一部分由一些在相应的工具构成。 2020 年， Mary Poppendieck和 Tom Poppendieck 的书籍《 Lean Software Development: An Agile Toolkit》出版，这标志着精益原则开始用于软件开发。 精益思想的核心思想是查明和消除浪费。 在软件开发过程中，错误（ bugs），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。 浪费及其源头必须被分析查明，然后设法消除。 精益开发的其它原则包括 :  强调学习。 软件开发过程是一个不断学习的过程。 每个团队成员都需要从日常的失败，互动，交流以及信息反馈中学习，不断改进所开发的产品和开发效率。  在最后时刻做决定。 这样可以避免在可能改变的事情 上做无谓的努力，从而有效的避免浪费。  用最快的速度交付用户。 较短的迭代周期能够加速产品的开发及交付，加快交流，提高生产力。 16  给团队自主权。 激励团队并让所有团队成员自我管理始终是所有敏捷方法获得成功的基本因素之一。  诚信。 确保整个系统正常工作，真正满足客户的需求是整个团队需要努力坚持的诚信和和对用户的承诺。  全局观。 精益开发强调整体优化的系统。 无论开发的组织还是被开发的产品， 从整体上考虑优化比从各个局部去优化更高效。 对于上述的每个原则，都有一些相应的实现工具。 这些工具包括价值流图（ Value Stream Mapping），基于集合的开发（ setbased development），拉系统（ pull system），排队论（ queuing theory），等等。 和其它敏捷方法相比，精益软件更重要的是不断完善开发过程的一种思维方式。 因此，将精益模式与其他敏捷开发模式一起使用将会取得很好的效果。 其它敏捷方法 动态系统开发方法（ DSDM）是由快速应用程序开发（ RAD）方法演变而来的敏捷开发模式。 DSDM 在普遍的敏捷价值和原则的基础上，定义了更加详细的流程，以涵盖更完整的项目生命周期。 它们包括项目前期活 动（ preproject activities），项目可行性研究，功能建模，设计和开发，实施或部署，项目后期维护（ postproject maintenance），等等。 同时，每个过程都定义了诸如如何将每个功能模型转化为实际代码，如何将原型交付最终用户使用并审查，如何处理反馈信息等的详细步骤。 因此， DSDM 相比于其它敏捷方法在过程上显得比较繁重。 特性驱动开发（ FDD）是将用户的功能需求划分成更小的功能特征，然后逐步地在每个迭代周期中开发实现这些产品特征。 与 DSDM 方式一样， FDD 仍然会在项目初期 对整个项目做较大的规划和建模，以获得对该系统的全面了解。 但是相比 DSDM 来说， FDD 在这些方面简捷了一些。 Crystal 方法集 更专注于人。 相比于其他的敏捷方法，它可使人获得更大的解放。 据称这种方法更适合于较小规模的开发小组（由 28 个人组成）和非关键项目。 Crystal 方法集 定义了七种属性。 前 3 个属性 频繁的交付（ frequent delivery），渗透交流（ osmotic munication），反思提高（ reflective 17 improvement） 反映出基本的敏捷开发做法和价值 ，如周期较短的迭代式开发，自我管理的开发团队和反馈带动增量发展等等。 另外的 4 个属性分别是：个人安全（ personal safety），集中（ focus），容易接触专家用户（ easy access to expert users）和技术环境（ technical environment）。 其中，容易接触专家用户实际就是敏捷方法中提到的客户持续参与，但 Crystal 方法集 对此要求比较宽松。 Crystal 方法集 也提供了一些通用的做法，比如，它提供了三种回顾分析的方法：访谈，问卷调查和工作组。 Crystal 方法集 的过程也是相当简单，其中涉及短的迭代周期，日常会议及持续集成等。 还有其他一些敏捷方法如敏捷统一过程（ Agile Unified Process），上下文驱动开发（ Context Driven Development）， Getting Real 等。 这些方法都是增量和迭代开发过程，并且重视人多过于整个过程。 而各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。 理解这些方法可以帮助我们从多个角度理解敏捷开发，并且了解更多的最佳应用。 2. 敏捷与 CMMI 等等其它体系的关系 CMMI 模型是由美国的 SEI 开发的，目前包 括了 3 个模型，但一般单提 CMMI时，指的只是 CMMI for DEV，而与敏捷关联最密切的就是 CMMI for DEV，因此本文下文的 CMMI 指的就是 CMMI for DEV。 自 2020 年左右引入我国，经过近 8 年的实施，目前已 经有大量 软件企业 按照 CMMI 开展过程改进。 截止到 2020 年 5 月，国内已有 48 家软件企业达到 CMMI 5 级，全球 349 家组织通过 CMMI5。 近年来，随着敏捷软件开发（ Agile Software Development， ASD）在国内外大行其道， CMMI 模型是否兼容敏捷， ASD 是否满 足 CMMI 实施 /评估要求等问题，在业界一直是有争论，备受人们关注。 CMMI 简要回顾 CMMI 的全称为： Capability Maturity Model Integration，即能力成熟度模型集成。 CMMI 是 CMM 模型的最新版本。 早期的 CMMI（ CMMISE/SW/IPPD） 版本是应用于软件业项目的管理方法， SEI 在部分国家和地区开始推广和试用。 18 随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。 自从 1994 年 SEI 正式发布软件 CMM 以来，相继又开发出了系统工程、软件 采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。 虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。 CMMI 为组织提供了实现高效的 软件交付 过程所需 要 的基本元素 ，关注于通过切实改进过程域的成熟度，实现过程改进的目标。 它可以用来指导一个项目、一个部门甚至整个组织的过程改进。 CMMI 能帮助我们整合以往各自为政的组织功能，建立过程改进的目标与优先级，指导我们进行质量改进，还提供了评价现有过程的参照点。 ISO9000 简要回顾 近年来，国际上影响最为深远的质量管理标准当属国际标准化组织于 1987年公布的 ISO9000 系列标准，这一国际标准发源于欧洲经济共同体，但很快就波及美国、日本及世界各国。 到目前为止，已有 70 多个国家在它们的企业中采用和实施这一系列标准。 我国对此也十分重视，也采取了积极态度。 近期，国际标准化组织 积极促进软件质量的制度化，提出了如下 ISO9000 软件标准系列：ISO900 ISO9000 ISO9004 ISO9004 ISO9002。 这一系列现已成为全球的软件质量标准。 目前 业界对于 ISO 和敏捷的关系和争议较少，因此本文不再讨论，重点分析敏捷和 CMMI 的关系。 有人认为 CMMI 和敏捷是存在矛盾的 站在部分 CMMI 拥护者的角度看 敏捷 ，他们认为，两者的差距如下： CMMI 敏捷 √ 成体系的过程方法和最佳实践集 零碎的实践 √ 文档化的可重复的过程 靠个人和团队能力维系过程和项目的成败 √ 量化控制 缺乏必要的度量 √ 完善的监控体系 缺乏过程透明度 19 √ 支持多特征的项目管理 仅适用于小型项目 同 时，一些敏捷 的拥护者对 CMMI 这样的 重量级 过程也有着种 种意见，他们认为： 敏捷 CMMI √ 轻量级的过程 重量级的过程 √ 以客户为导向 计划驱动， 客户反馈响应周期长 √ 逐步完善的计划，及时响应变更 线性控制， 变更成本高 √ 自律，高效 流程代价较高 √ 持续交付可用软件 强调过程规范性 √ 团队自组织 命令与控制 有人认为两者的理论基础是不同的，很难把基于两种不同模型的方法论硬揉在一起。 CMMI 的理论基础是一种 预定义。