跳到主要内容

敏捷开发

来源书籍 “Agile! The Good, the Hype and the Ugly”,

学习好处​

  • 它以严格客观的视角看待敏捷流程，使你能够保留最佳的敏捷原则和实践。

  • 通过深入分析敏捷流程并展示如何从中受益，它将使你成为更优秀的开发人员，具备应对大型软件项目挑战的能力。

  • 这门课程并不是宣扬某种方法 而是强调软件质量和软件生产力

敏捷方法​

A number of agile methods They share the basics but differ in their goals and emphases

XP​

出现于 90 年代。

XP（极限编程）是对当时软件工程圈内盛行的文化（流程、计划、图表）的反应。 ➢ 例如，UML（统一建模语言）或 CMMI（能力成熟度模型集成，即定义软件开发最佳实践的标准）。

强调最终真正重要的是程序，当然还有编程和程序员。

XP 通过重振程序员的工作，将程序和编程置于软件开发的中心，做出了重大贡献。

协商范围合同​

“为软件开发撰写合同，固定时间、成本和质量，但要求对系统的具体范围持续协商。通过签署一系列短期合同而不是一个长期合同来降低风险。”

“您可以朝着协商范围的方向发展。大的、长期的合同可以分成两半或三分之一，只有在双方同意的情况下才执行可选部分。对于变更请求成本较高的合同，可以在前期固定较少的范围，并降低变更成本。”

Lean​

精益软件

  • 尝试将一些在其他工程领域（特别是汽车行业）中已证明其价值的理念和原则应用于软件。

  • 这是一套由日本丰田公司特别开发的著名实践，不仅在汽车行业，而且在整个工业界，尤其是制造实物的行业中产生了很大影响。

  • Poppendiecks 将这些理念应用于软件，特别强调需要消除他们所谓的浪费。

  • Poppendiecks 声称我们也应该在软件中寻找浪费，并去除例如无用的文档等被视为浪费的东西，以便专注于实际交付给客户的内容。

Crystal​

  • 结合了敏捷理念和更传统的理念。

  • Crystal 实际上是指一套方法，这些方法以管理过程中不同程度的重要性为特征。

  • 开发 Crystal 方法集的 Alistair Coburn 试图将敏捷的优点与更注重流程的方法的优点结合起来。

Scrum​

  • 近年来主导了这一领域。

  • 技术性较少，不像 XP 那样专注于软件。

  • 一种管理方法，强调自组织团队的重要性，而不是由经理密切管理的团队，以及一种被称为 Sprints 的短期发布迭代的重要性。

  • 需要注意的是，如今在实践中，当我们谈论敏捷时，我们实际上是在谈论 Scrum。

    • 这种观点并不完全准确……很多来自其他方法的理念，特别是 XP。

敏捷价值观​

Agile values A New, reduced role for manager 新，管理者的角色占比减少 B No “Big Upfront” steps 没有“大前期”步骤 C Iterative development 迭代开发 D Limited, negotiated scope 有限的、协商的范围 E Focus on quality, achieved through testing 通过测试实现的质量关注

敏捷原则​

Organizational​

  • 1 Put the customer at the center 将客户置于中心

  • 2 Accept change 接受变化

  • 3 Let the team self-organize 让团队自我组织

  • 4 Maintain a sustainable pace 保持可持续的节奏

  • 5 Produce minimal software 生产最少的软件

    • 5.1 Produce minimal functionality 生产最小化的功能
    • 5.2 Produce only the product requested 只生产所需的产品
    • 5.3 Develop only code and tests 仅开发代码和测试

Technical 技术方面​

  • 6 Develop iteratively 迭代开发 • 6.1 Produce frequent working iterations 频繁产生可工作的迭代 • 7.2 Freeze requirements during iterations 在迭代期间冻结需求

  • 7 Treat tests as a key resource: 将测试视为关键资源 • 7.1 Do not start any new development until all tests pass 在所有测试通过之前，不开始任何新的开发 • 7.2 Test first 先测试

  • 8 Express requirements through scenarios 通过场景表达需求

Life cycle model 解决 The enemy: Big Upfront Anything​

Scope: describe the set of processes involved in the production of software systems, and their sequencing

范围：描述软件系统生产中涉及的一系列过程及其顺序

瀑布模型​

瀑布模型的流程，分为几个阶段：

  • Decide（决策）：

    Business Case（商业案例）：确定项目的商业目标和理由。 User Requirements（用户需求）：收集和定义用户的需求。

  • Design（设计）：

    System Specification（系统规格）：详细描述系统的功能和特性。 System Design（系统设计）：规划系统的整体架构。 Component Design（组件设计）：设计系统的各个组件。

  • Develop（开发）：

    Construct Component（构建组件）：实际开发和构建系统组件。

  • Demonstrate（演示）： Test（测试）：对系统进行测试，确保其符合需求和规格。

瀑布模型的问题​

  • 实际代码出现得晚 Late appearance of actual code

  • 缺乏对需求变更的支持——更普遍地说，缺乏对可扩展性和可重用性的支持 Lack of support for requirements change

  • 缺乏对维护活动的支持（软件成本的 70%？） maintenance activity

  • 劳动力分工妨碍全面质量管理 Division of labor hampering Total Quality Management

  • 阻抗不匹配 Impedance mismatches

  • 高度同步的模型 Highly synchronous model

对需求的两种敏捷批评​

  • 变更批评
  • 浪费批评