第3章 敏捷开发

1、 第三章第三章 敏捷软件开发敏捷软件开发1Chapter 3 Agile software development本章的目标是介绍敏捷软件开发的几种方法本章的目标是介绍敏捷软件开发的几种方法1.1. 理解敏捷软件开发的基本原理，敏捷方法的内涵，以及和其它理解敏捷软件开发的基本原理，敏捷方法的内涵，以及和其它软件开发方法之间的差别；软件开发方法之间的差别；2.2. 了解极限编程的主要做法，以及它是如何贯彻和遵循敏捷软件了解极限编程的主要做法，以及它是如何贯彻和遵循敏捷软件开发方法的一般性的原理的；开发方法的一般性的原理的；3.3. 理解敏捷项目管理的理解敏捷项目管理的ScrumScrum方法；方

2、法；4.4. 了解在大型软件项目开发过程中应用可伸缩敏捷方法时的事项了解在大型软件项目开发过程中应用可伸缩敏捷方法时的事项和问题。和问题。Topics covered 敏捷软件开发方法 Agile methods 计划驱动和敏捷驱动 Plan-driven and agile development 极限编程 Extreme programming 敏捷项目管理 Agile project management 伸缩的敏捷开发方法Scaling agile methods3Chapter 3 Agile software development对软件系统快速开发和交付经常是最重要的需求对软件系

3、统快速开发和交付经常是最重要的需求 当前业务都是处于一个全球性的、快速变化的环境中的。从市场、机遇、不断变化的经济条件、出现新的竞争产品和服务等方面，要求软件做出快速的开发；其次，用户对软件变更和新需求的要求，往往具有紧迫性，因此，对软件系统快速开发和交付经常是最重要的需求。4Chapter 3 Agile software development 如何才能快速开发软件？快速软件开发基本特征快速软件开发基本特征 描述、设计、实现是项目交织在一起的 系统通过一系列版本开发出来。最终用户和其他信息持有者参与对各个版本的评估。 用户界面经常用IDE工具快速完成。3.1 敏捷方法敏捷方法 敏捷方法是一

4、种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。6Chapter 3 Agile software development敏捷宣言敏捷宣言 敏捷软件开发宣言个体和交互个体和交互 胜过过程和工具胜过过程和工具工作的软件工作的软件 胜过详尽的文档胜过详尽的文档客户合作客户合

5、作 胜过合同谈判胜过合同谈判响应变化响应变化 胜过遵循计划胜过遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值也就是说，尽管右项有其价值，我们更重视左项的价值Chapter 3 Agile software development7“敏捷宣言敏捷宣言”背后的背后的1212准则（准则（1 1）：）： 1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 为客户解决问题是软件开发的最重要的目标。 2. 欢迎对需求提出变更即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 问题可能随时会变化，软件开发是以问题提出者为中心解决问题提出者的问题，因此重要的是解决问题

6、而不是限制变化。 3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 检验适应是敏捷问题解决方式的核心方式，不断以客户可检验的方式交付可用的软件。“敏捷宣言敏捷宣言”背后的背后的1212准则（准则（2 2）：）： 4. 项目过程中，业务人员与开发人员必须在一起工作。 业务人员作为软件开发的问题提出者，需要与软件开发团队（问题解决者）密切配合，促进问题解决 5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 问题解决取决于人的投入程度与状态，激励项目人员，为他们创造环境和条件，能够有助于问题的解决。 6. 无论是团队内还是团队间，最有效的沟通方法是面对面

7、的交谈。 敏捷问题解决方式推荐进行面对面的沟通与交流，这是人与人合作解决问题的最好沟通方式。“敏捷宣言敏捷宣言”背后的背后的1212准则（准则（3 3）：）： 7. 可用的软件是衡量进度的主要指标。 只以单位问题的解决结果也就是完成作为进度衡量的指标 8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 在敏捷问题解决方式中，良好设计的迭代与稳定的迭代进度是最有效的和最可预测的问题解决方式。 问题提出者与问题解决者所组成的团队是解决问题的最佳组合，发挥团队的力量解决问题远胜于不明情况的指手划脚。 9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。 不断追

8、求更高效的解决问题，技术与设计是解决软件问题的重要手段。“敏捷宣言敏捷宣言”背后的背后的1212准则（准则（4 4）：）： 10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 问题的解决不取决于解决方案的复杂性，而是源自于对问题提出者和问题本身的深刻理解。当然，问题解决方式本身也是重要的。 11.最佳的架构、需求和设计出自于自组织的团队。 团队成员共同解决项目中所有问题 12.团队要定期反省如何能够做到更有效，并相应地调整团队的行为。 检验适应是敏捷问题解决方式的核心。敏捷方法的基本原敏捷方法的基本原则则 原原则则描述描述客客户户参与参与 客客户应该户应该在开在开发过发过程中始程

9、中始终紧终紧密参与其中，他密参与其中，他们们的的作用是提供新系作用是提供新系统统的需求，的需求，对对需求排序，并需求排序，并评评估系估系统统的迭代。的迭代。增量式交付增量式交付 软软件以增量的形式开件以增量的形式开发发，客，客户户指定在每个增量中包指定在每个增量中包含的需求。含的需求。人非人非过过程程团队团队开开发发的技巧的技巧应该应该被承被承认认和和发扬发扬，保持他，保持他们们各自各自的工作的工作风风格，不落俗套。格，不落俗套。接受接受变变更更预预料系料系统统需求的需求的变变更，并更，并设计设计系系统统使之适使之适应这应这些些变变更更保持保持简单简单性性 关注关注软软件开件开发发和和软软件件

10、过过程的程的简洁简洁性，无性，无论论如何，如何，积积极地消除系极地消除系统统中的复中的复杂杂性。性。 12Chapter 3 Agile software development敏捷方法的适应性敏捷方法的适应性 以下情况适合于采用敏捷方法进行软件开发： （1）软件公司正在开发准备出售的小项目或中等规模的项目 （2）属于机构内部定制系统的开发，客户有一个参与开发的明确的承诺，且没有太多的来自外部的规则和法律的影响。因为它致力于小型的、紧密结合的团队，将它扩展到大型系统的开发中会有很多问题。Chapter 3 Agile software development13敏捷方法的适应性敏捷方法的适应性

11、 敏捷方法适用于需求不确定并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；敏捷方法在实践中的问题 客户可能很难保证全程参与到项目的开发中。 团队成员可能不适应高强度的投入。而这又是敏捷方法的特征。 在不同信息持有者之间，需求的优先级变更困难。 维护简单性需要额为的工作。 公司不适应新系统带来的工作变更。 当产品出现问题时，容易出现互相推诿的情况。15Chapter 3 Agile software development敏捷方法和敏捷方法和软软件件维护维护两个问题： 由于开发过程强调正式文档的最小化，用敏捷方法开发系统是否具有可维护性？ 敏捷方法是否能

12、够有效用于系统进化，以响应系统变更的需求？Chapter 3 Agile software development16敏捷开发和系统具有较好的维护性是一对矛盾。敏捷开发和系统具有较好的维护性是一对矛盾。增量交付，面向变更的维护可能遇到的问题就是增量交付，面向变更的维护可能遇到的问题就是保持用户的持续参与和开发团队的持续性。保持用户的持续参与和开发团队的持续性。在系统维护上，关键是在系统维护上，关键是需求文档需求文档！3.2 3.2 计划驱动和敏捷开发计划驱动和敏捷开发 计划驱动计划驱动开发起源于系统工程和质量规范，建立系统计划驱动开发起源于系统工程和质量规范，建立系统工程的原则，协调大量需要精

13、确协同工作的组件。通过从工程的原则，协调大量需要精确协同工作的组件。通过从需求到已完成的代码等一系列代表物来推动软件开发的过需求到已完成的代码等一系列代表物来推动软件开发的过程，计划驱动开发非常精确地依赖于明确的步骤。程，计划驱动开发非常精确地依赖于明确的步骤。 敏捷驱动 敏捷开发的过程中需求分析、软件设计、软件开发过敏捷开发的过程中需求分析、软件设计、软件开发过程相互交织在一起。强调软件开发的快速性和需求变化的程相互交织在一起。强调软件开发的快速性和需求变化的快速适应性。文档的最小化。快速适应性。文档的最小化。17Chapter 3 Agile software development表表

14、1 1 敏捷开发、计划驱动软件开发比较敏捷开发、计划驱动软件开发比较有要求有要求无，少无，少1010系统是否受制于外部的法规？系统是否受制于外部的法规？需大量系统分析需大量系统分析一般一般9 9开发的系统是什么样类型的？开发的系统是什么样类型的？要求低要求低水平高水平高8 8开发团队的设计人员和编码人员的能力如何？开发团队的设计人员和编码人员的能力如何？有影响有影响无要求无要求7 7有没有可能影响系统开发的文化问题？有没有可能影响系统开发的文化问题？团队分散，有软团队分散，有软件外包件外包团队之间开团队之间开发发6 6 开发团队是怎么组织的？开发团队是怎么组织的？不依赖不依赖IDEIDE有好的

15、有好的IDEIDE5 5有什么样的技术支持开发？有什么样的技术支持开发？长周期长周期短周期短周期4 4预想的系统的寿命有多长？预想的系统的寿命有多长？大大小，且在同小，且在同一地点一地点3 3开发系统的规模有对大？开发系统的规模有对大？否否是是2 2增量交付策略，即软件交付给用户并快速的取得增量交付策略，即软件交付给用户并快速的取得反馈，切实么？反馈，切实么？是是否否1 1 系统开始前，非常详细的描述和设计很重要吗？系统开始前，非常详细的描述和设计很重要吗？计划驱动计划驱动敏捷方法敏捷方法问题问题 多数软件的开发均可用计划驱动和敏捷方法完成。选用何种方法，参见上一页的内容。敏捷方法是一种思想，

16、不是具体的实现过程。目前，列入敏捷方法的有10多种。目前列入敏捷方法目前列入敏捷方法 软件开发之韵，Software Development Rhythms 敏捷数据库技术，AD/Agile Database Techniques 敏捷建模，AM/Agile Modeling 自适应软件开发，ASD/Adaptive Software Development 水晶方法，Crystal 特性驱动开发，FDD/Feature Driven Development 动态系统开发方法，DSDM/Dynamic Systems Development Method 精益软件开发，Lean Softwar

17、e Development AUP（Agile Unified Process） ScrumScrum XBreed 极限编程，极限编程，XP XP eXtremeeXtreme Programming Programming 探索性测试XP XP 方法对敏捷基本原理的支持方法对敏捷基本原理的支持 增量式开发是通过小的、频繁的版本来支持的。 客户的参与是采用全时雇佣到开发团队的形式。 人、而不是过程，通过结对编程、对系统代码的集体拥有、可持续的开发过程而无需超额的工作时间来运作的。 对变更的支持是通过经常性的版本发布，、测试优先开发、重构以避免代码退化以及连续的集成新功能来实现的。 对简单性的

18、维护通过持续的重构来改善代码的质量、使用简单的设计以减少系统将来的变更方式来支持的。21Chapter 3 Agile software development极限极限编编程的版本循程的版本循环环 22Chapter 3 Agile software development极限极限编编程程实实践践 (1) 原则或实践原则或实践描述描述（1）增量式规划需求记录在脚本卡片上，包含在版本中的故事情节可以决定可用的时间和它们的相对优先级。开发者将这些脚本分解为开发的“任务”（2）小版本发布首先开发一个小版本的能提供业务价值的有用的最小集合，不断的增量式的开发和发布23Chapter 3 Agile s

19、oftware development极限编程实践 (2)期待所有的开发人员能连续地对代码重构，只要是发现可能改善的代码就去做，这样能保持代码简单性和可维护性（5）重构在功能本身实现之前，采用一个自动单元测试框架来编写对此新功能的测试（4）测试优先不追求太多，只满足当前需求设计的功能。（3）简单设计极限极限编编程程实实践践(3) 开开发发人人员员成成对对工作，工作，检查检查彼此的工作并提供支持彼此的工作并提供支持圆满圆满完成任完成任务务集体所有制意味着每个人都集体所有制意味着每个人都对对所有的程式所有的程式码负责码负责； ；这这一点，反一点，反过过来又来又意味着每个人都可以更改程序意味着每个人

20、都可以更改程序码码的任意部分。集体所有制的一个主的任意部分。集体所有制的一个主要要优势优势是提升了开是提升了开发发程序的速度，因程序的速度，因为为一旦程式一旦程式码码中出中出现错误现错误，任，任何程序何程序设计师设计师都能修正它。都能修正它。25Chapter 3 Agile software development（6）结对编程结对编程（7）集体所有集体所有极限极限编编程程实实践践 (4)（8）连续集成）连续集成任务一完成，就集成到系统中。并进行单元测试任务一完成，就集成到系统中。并进行单元测试（ （9）可持）可持续续的的节节奏奏大量超时是不能接受的的，因为它的后果就是降低大量超时是不能接受

21、的的，因为它的后果就是降低代码的质量和平均生产率。代码的质量和平均生产率。（ （10）在）在场场客客户户在极限在极限编编程中，程中，“ “客客户户” ”并不是并不是为为系系统统付付帐帐的人，而是的人，而是真正使用真正使用该该系系统统的人。极限的人。极限编编程程认为认为客客户应该时户应该时刻刻在在现场现场解决解决问题问题。例如：在。例如：在团队团队开开发发一个一个财务财务管理系管理系统时统时，开，开发发小小组组内内应应包含一位包含一位财务财务管理人管理人员员。 。XPXP需求脚本制作（需求脚本制作（Requirements scenariosRequirements scenarios）1.在X

22、P中，由XP团队成员中的客户或用户负责需求的确定；2.用户将需求采用场景或者故事的形式表述；将需求脚本写到卡片上，然后，开发人员将这些需求分解成软件实现任务（记录到任务卡上），这些待实现任务是成本和进度估计的基础；3.基于需求优先级和软件实现的进度估计，客户在下一个版本实施前，选择好优先级高的需求进行开发（选择自己描述的场景或故事）。27Chapter 3 Agile software development开处方的脚本（开处方的脚本（P41 P41 图图3-5 ）28Chapter 3 Agile software development举例：开处方的任务卡举例：开处方的任务卡 （P42 P

23、42 图图3-6 ）29Chapter 3 Agile software developmentXPXP测试测试Xp中的测试的关键特性：1. 测试优先开发；2. 来自脚本的增量式测试开发；3. 用户参与测试开发；4. 自动测试系统的使用；Xp强调先写测试程序，再写代码，测试超前于代码的编写。可以对任务卡设计测试的用例描述。测试测试案例：案例：剂剂量量检测检测描述（描述（P43 图图3-7） ） 31Chapter 3 Agile software development结对编结对编程程Pair programming 结对编程(Pair Programming)是一个编程模式(Programm

24、ing pattern)。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试例子，一起编码，一起单元测试，一起集成测试，一起写文档等。基本上所有的开发环节都一齐肩并肩地，平等地，互补地进行开发工作。 结对编程不是一个人简单地看着另一个在做什么在卓有成效的配对工作里，这两个合作伙伴常常工作在不同抽象层次，一个人关注的是为实现眼前目标而编写的代码的细节，而另一个人考虑的是更大的前景和下一步要做的事情，这两个人的角色频繁进行更换。这是一项高强度的、严密的，且常常令人疲劳的活动，但是能够创造出经过深思熟虑的高质量代码。 Laurie

25、Williams &Steve Hayes 32Chapter 3 Agile software development结对编结对编程的好程的好处处1. 支持共同拥有软件和共同对系统负责2. 担当了非正式的复查过程3. 有助于支持重构Chapter 3 Agile software development333.4 敏捷敏捷项项目管理目管理 敏捷方法的倡导者经常发现：在应用开发中，对动态变更很难得到管理方面的支持。这些方法需要开发者、管理者和用户都改变他们工作和思考的方式。例如，XP实践中的结对编程、测试优先的开发、持续集成以及在场客户等是很难让人接受的。而且，这些方法论更倾向于以开发者为中心

26、，似乎并不太重视管理角色。 实践证明，加强管理是敏捷方法被成功采纳并应用的关键 而传统项目管理方法学和工具与这些新的敏捷方法缺少关联34Chapter 3 Agile software developmentScrumScrum是一个通用的敏捷方法，但它主要注重迭代开发的管理，而不是管理敏捷软件工程的专门的技术方法。Chapter 3 Agile software development35Scrum 管理管理过过程程图图36Chapter 3 Agile software developmentScrum的三个阶段：1 规划纲要：建立大致的目标，设计软件体系结构2 冲刺循环：每个循环开发出一

27、个增量3 项目结束阶段总结项目：完善项目文档，如系统帮助，用户手册，总结项目开发经验Scrum过过程程-冲刺循冲刺循环环在每一次冲刺（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的功能来自产品订单（product backlog）。产品订单是按照优先级排列的要完成的工作的概要的需求，哪些订单项会被加入一次冲刺将由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。Scrum会会议议 在冲刺中，每一天都会举行项目状况会议，被称为 “每日站立会议”，15min，内容包括： 说明工作进度 遇到的问题 接下来一天的工作计划 可可扩扩展的敏捷方法