Chapter3：Agile Software Development

3.1 Outline

• 内容覆盖：
  

• 敏捷方法：

  是一种具体的软件开发模式，比前面我们讲的通用的模型更加具体。

  本质上是带有增量式交付和开发特点的过程活动的具体体现。

• 极限编程 ：

  从经典通用的过程模型，到敏捷方法，到极限编程，实际上是越来越具体，越来越接近实际应用。

• 管理敏捷方法：

• 扩大敏捷方法的适用范围：

  从中小型系统到大型系统

3.2 Agile method 敏捷方法

3.2.1 What is Agile methods ？

• 聚焦于代码而不是设计。计划驱动的软件开发过程不一样（如瀑布模型，分析以后就是设计）

• 基于迭代的方式。应该有：反馈，再开发，这样的一个回路。（在增量式开发，增量式交付、RUP都能看到这样一个迭代的过程）

• 能够快速交付软件，能快速进化来满足需求的变化。

总体目标：减少软件过程中的一些额外的负担。能够迅速地响应变更的需求（如：简化文档）。

3.2.2 Agile manifesto 敏捷宣言

• 敏捷宣言是：敏捷方法的价值体现。
  

• 建立在过程和工具之上的，个体和协作。

  • 软件工程三要素：过程、方法、工具。
  • 过程：软件过程。
  • 方法：建模设计测试管理各样地能帮助我们软件开发的各类方法。
  • 工具：一些计算机软件，能够在软件过程中帮助建模测试文档等。

• 软件开发工作建立在可理解的文档工作之上

  • 能够帮助我们理解整个软件工作就好，不需要太多。

• 与客户的合作是通过合作协商来进行的。

• 对软件的变化响应式通过制定一些计划。

3.2.3 The principles of agile methods 敏捷开发的原则

列出了敏捷方法的几项原则：

1. 客户是紧密合作的

2. 增量式交付

3. 不是在开发团队中的人，不要涉及其中，让开发团队自己来工作

4. 能够预期到能够系统发生的改变，来适应这些改变

5. 要使得：开发过程中，和已经开发好的软件，都具有简单性。在构建系统的活动中，尽量消除系统的复杂性：比如代码格式要规范，程序单元不应该太大。
   

3.2.4 Agile method applicability 适用范围

• 适用于中小规模的软件系统。

• 因为聚焦于小型的紧密合作的团队，所以扩展到大型系统的时候，会遇到一些问题。【3.5 Scaling agile methods 就是解决这个问题】

*详见ppt

3.2.5 Agile methods and software maintenance 软件可维护性

• 良好的敏捷开发需要支持：

  1. 好的可维护性 maintenance

  2. 原始开发 original development

• 关键因素：

  1. 因为文档的简化，那么系统开发出来是否是可维护的？

  2. 敏捷开发能否支持有效的响应客户需求的改变？

• 如果原始的开发团队没有能够解决好，那么问题就会恶化。
  

3.2.6 Plan-driven vs. agile development

• 计划驱动：

  1. 基于分离的开发阶段。

  2. 计划驱动：不仅仅是瀑布模型，增量式开发也可。

     【因为增量式开发是一个整体的项目的交付，每个版本的活动都是分离的。】

• 敏捷开发：

  1. 敏捷方法的需求定义设计测试都是交替进行的，活动之间会有叠加。

     【RUP类似。比如需求定义的同时可能还会有设计活动，一部分增量可能在测试，另外一部分增量可能已经交付】

  2. 敏捷方法依赖于好的工具，保持对设计的优化。

     【敏捷开发融合了增量式开发和增量式交付的一些特点。这样的开发方法可能会使得可维护性受到影响，比如结构、代码规范、文档等；；那么我们就需要用一些好的工具，能够不断地让程序结构和代码不断优化，使得3.2.5的两个问题得到改善。能使得软件的维护变得相对简单，使得系统的复杂性降低。

---

• Plan-driven and agile specification 敏捷方法和驱动式开发的,开发方法的区别。
  

• 关键区别：在计划驱动的方法里面，有Requirements Specification文档。

• 这个文档是需求工程产生一个正式的有关需求的定义，有这定义之后，我们才开始进行设计开发，如果需求发生了变更，我们需要重新开始需求工程，再产生一个需求定义。

• 而对于敏捷开发来讲，需求和实现是交替进行的，没有明显界限。

---

• Technical, human, organizational issues
  

• 项目选择：计划驱动 or 敏捷开发，取决于以下几点：

  1. 如果在编码实现之前需要详细地需求定义和设计：

  2. 如果要增量式交付，快速响应用户反馈：

  3. 团队小且交流方便（非正式）

  ​ 【Communicate formally：正式交流一般会有书面的文档和邮件，比如瀑布模型里就有。大项目往往分为多个团队，根据正式文档就可以直接开工。而小团队只能用敏捷开发】

3.3 Extreme programming 极限编程 XP

3.3.1 What is Extreme programming ？

• 使用在敏捷方法中的，最流行的一种实现模式。

• 使用极限的方法来迭代开发。

  1. 每天都要数次来构建一个新的版本。

  2. 每两周就要交付增量给客户。

  3. 每一次构建都要经过测试，并且，仅当测试成功以后才能够接受这次构建。

     【build就是建立了一个新的版本系统，比如我增加了一部分工作完成了一个task，增加到现有的里面，就产生了一个新的版本。每天都会有这种多次的新的版本，每两周一次交付。

• 极限编程意味着：

  快速的成果形成和快速的产品交付。

  再次细化了敏捷方法的具体实施和策略。

3.3.2 XP and agile principles

• XP如何体现敏捷方法的几项原则？【对比3.2.3】
  

1. 小的频繁的系统版本

2. 团队里有客户参与

3. 配对编程、所有权共享、避免长时间工作：两人一组，共同开发，彼此都知道对方的工作、并且互相进行校验。这就意味着是有一个紧密的小团体进行开发，无关人员是不会进行到里面的。

4. 对于系统变化的响应，是通过定时的发布系统版本，那就可以正常的搜到系统的反馈信息。

5. 维护简单性：通过持久地代码的重构：代码的改善。在整个软件过程中有持续的代码改善的意识，不断地改善代码的结构和可能性，使得维护比较简单。

3.3.3 The extreme programming release cycle 发布周期

极限编程发布版本的周期：

1. 为这个版本的程序选择：用户story。

   ​ story是需求的一个描述。体现的不是一个完整的系统，而是把一个系统分成若干个story。

2. 把1个story变成n个task

   ​ 1个story相当于1个增量，不是很大，可分为若干tasks。

3. 为story制作开发计划

4. 开发实现并测试增量

5. 发布版本

6. 评价整个系统

   ​ 因为把这个增量加到系统里面去了

3.3.4 Extreme programming practices 实现XP

*详解见ppt

• 对极限编程的具体实现活动进行了详细地描述。
  

3.3.5 Requirements scenarios 需求脚本

1. What is Requirements scenarios ?

   • 在极限编程中：我们把需求变成一个个的story记录在卡片上。

   • Requirements scenarios 需求脚本，同样是一种需求描述的方式。

   开发团队会分解成一个个task，task的分解是由进度和成本估算来确定的。客户可以根据进度和优先级来选择，下一个版本中要开发的story .

2. Example—— ‘ prescribing medication’ story

   开处方功能需求描述。
   
   *详见ppt

3. Example——task cards for prescribing medication

   把上面的story分成若干个task
   

3.3.6 Refactoring 重构

1. What is refactoring ?

   软件重构：改善软件的可理解性，从而降低对于软件文档的要求。【可理解性】

   由于代码结构好，且清晰，那么对于软件的变更就比较容易。【应对变化】

   有些情况下需要体系结构重构，那么这样代价就比较大。

2. Examples of refactoring

   • 对类的继承结构重新组织，可以去除重复代码。

   • 对属性和方法的命名重新组织。

   • 将某些代码替换成调用程序库中方法。

3.3.7 Testing in XP 测试

​ *详见ppt

1. 极限编程是以测试为中心的【test-driven】
   
2. Test-first development
   
3. Test case description for dose checking Pair programming
   

3.3.8 Pair programming 配对编程

​ 配对坐在一起开发代码，共享开发知识

​ 可以视为一种非正式的评审过程【代码互相检查】

​ 鼓励代码重构【因为整个团队的人都能从中收益】

3.4 Agile project management

3.4.1 Definition

• 敏捷项目的管理
  
  ​ 通常来说，项目管理都是基于计划驱动的这种模式。

​ 但是，敏捷项目管理需要适应增量式开发的特点，以及敏捷开发的优势。

3.4.2 Scrum

1. XP vs. Scrum

   • XP——聚焦于：敏捷方法里面的具体的实现活动，侧重于：软件本身的实现活动，配对编程、测试驱动、小版本开发、不断集成、代码重构。
   • Scrum——是敏捷方法里面聚焦于：整个过程的管理，侧重于：如何将这些活动管理起来。

2. Scrum把活动分成三个阶段：

   • Initial：初始阶段：建立项目的主题目标并且设计软件整体的体系结构。

   • sprint：一系列的sprint cycles，每一个周期开发一个系统的增量。

   • closure：打包整个项目，完成所需要的文档，比如系统的帮助框架和手册，总结经验。
     

3. The Scrum process

   混合了其他模型的特点。
   
   软件版本两种描述：release、version。

   release是指：可以正式交付的（正式发布的）；version是值：内部版本号。

4. The Sprint cycle

   确定功能以后，进入这个阶段。
   
   ​ 在一个增量的开发期间，开发团队和客户隔离，所有的交流通过：Scrum master 进行。对于一个增量来讲，是封闭开发的。体现了 people not process这个原则。Scrum master 就是避免团队受到外界的影响。一般对应一个版本的开发周期。

   ​ stakeholder：项目的拥有人or参与者，可以认为是：客户or使用者。

   ​ 这之后开始开发下一个增量，即开始下一个 sprint cycle。
   

5. Teamwork in Scrum

   • **Scrum master：**负责安排每天会议，跟踪和评价backlog上的工作进展情况，记录一些决策，负责和团队外的客户以及管理人员进行沟通。

   • **整个team团队：**每天都会开一个短会，在这个短会上，所有成员会共享信息，描述进展，并计划接下来的步骤。

   Scrum管理模式图：
   

6. Scrum benefits
   

3.5 Scaling agile methods 扩展敏捷方法

3.5.1 What is Scaling agile methods ？

​ 敏捷方法适用于中小型、紧密合作的小型团队来开发。

​ 对于大型系统来讲，会有多个开发团队，在不同的工作地点。

​ 那么Scaling agile methods，就是解决：将敏捷开发用于大型系统。

3.5.2 Scaling out and scaling up

• Scaling up： 涉及到使用敏捷方法来开发大型的系统。

• Scaling out：涉及到敏捷方法能被引入到大型的开发机构中（此机构有很多年的软件开发经验）。

• 大兴系统和大兴机构中使用敏捷开发，就要适应一些规则。
  

3.5.3 Scaling up to large systems

• 敏捷方法聚焦于代码而不是设计。对于大型系统来讲，需要更多的预先设计和文档。

• 在敏捷开发中还需要考虑预先的设计、需要考虑团队之间的交流、定期进行各种电子会议、成员之间要经常更新彼此的进展。

• 对于敏捷开发倡导的持续集成，对于大型系统来讲，不可能每次发生变更就集成到整个系统，但是要保持经常的系统重构和定期的版本发布。

• 这些只是一些原则性建议，真正的投入使用还是要根据实际情况来决定。
  

3.6 Key points

• 敏捷方法是一种增量式开发方法，聚焦于：快速的开发、频繁的软件版本、构建、减少过程中的负担、产生高质量的代码。【这里的Incremental Development不要单纯的理解为通用的Incremental Development ，而是混合了Incremental Delivery的开发模式特点】

• 极限编程是众所周知的敏捷方法，包含了：频繁的版本构建、持续的软件改善、客户的参与。

• 极限编程的一个特别的优势在于：在程序实现之前就进行自动测试的方案的建立，

• 要把增量集成到系统里，前提是所有的测试必须执行完毕。

• Scrum是一种提供项目管理框架的敏捷方法，以sprint周期活动为周期，sprint是开发增量的相对固定的时间段。