第3章 敏捷开发

1、 第三章 敏捷(mnji)软件开发1Chapter 3 Agile software development共四十三页本章的目标是介绍敏捷软件开发的几种方法理解敏捷软件开发的基本原理，敏捷方法的内涵，以及和其它软件开发方法之间的差别；了解极限编程的主要做法，以及它是如何贯彻和遵循敏捷软件开发方法的一般性的原理的；理解敏捷项目管理的Scrum方法；了解在大型软件项目(xingm)开发过程中应用可伸缩敏捷方法时的事项和问题。共四十三页Topics covered敏捷软件开发方法(fngf) Agile methods计划驱动和敏捷驱动 Plan-driven and agile developme

2、nt极限编程 Extreme programming敏捷项目管理 Agile project management伸缩的敏捷开发方法Scaling agile methods3Chapter 3 Agile software development共四十三页对软件系统快速开发(kif)和交付经常是最重要的需求 当前业务都是处于一个全球性的、快速变化的环境中的。从市场、机遇、不断变化的经济条件、出现新的竞争产品和服务等方面，要求软件做出快速的开发；其次，用户对软件变更和新需求的要求，往往具有紧迫性，因此(ync)，对软件系统快速开发和交付经常是最重要的需求。4Chapter 3 Agile so

3、ftware development 如何才能快速开发软件？共四十三页快速(kui s)软件开发基本特征描述、设计、实现是项目交织在一起(yq)的系统通过一系列版本开发出来。最终用户和其他信息持有者参与对各个版本的评估。用户界面经常用IDE工具快速完成。共四十三页3.1 敏捷(mnji)方法敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个(y )大项

4、目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。6Chapter 3 Agile software development共四十三页敏捷(mnji)宣言 敏捷软件开发宣言个体和交互 胜过过程和工具工作的软件 胜过详尽的文档客户合作 胜过合同(h tong)谈判响应变化 胜过遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值Chapter 3 Agile software development7共四十三页“敏捷宣言(xunyn)”背后的12准则（1）：1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。为客户解决问题是软件开发的最

5、重要的目标。2. 欢迎对需求提出变更即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。问题可能随时会变化，软件开发是以问题提出者为中心解决问题提出者的问题，因此重要的是解决问题而不是限制变化。3. 要不断交付可用的软件，周期从几周到几个(j )月不等，且越短越好。检验适应是敏捷问题解决方式的核心方式，不断以客户可检验的方式交付可用的软件。共四十三页“敏捷(mnji)宣言”背后的12准则（2）：4. 项目过程中，业务人员与开发人员必须在一起工作。业务人员作为软件开发的问题提出者，需要与软件开发团队（问题解决者）密切配合，促进问题解决5. 要善于激励(jl)项目人员，给他们以所需要的

6、环境和支持，并相信他们能够完成任务。问题解决取决于人的投入程度与状态，激励项目人员，为他们创造环境和条件，能够有助于问题的解决。6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。敏捷问题解决方式推荐进行面对面的沟通与交流，这是人与人合作解决问题的最好沟通方式。共四十三页“敏捷宣言”背后(bihu)的12准则（3）：7. 可用的软件是衡量进度的主要指标。只以单位问题的解决结果也就是完成作为进度衡量的指标8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。在敏捷问题解决方式中，良好设计的迭代与稳定的迭代进度是最有效的和最可预测的问题解决方式。问题提出者

7、与问题解决者所组成的团队是解决问题的最佳组合，发挥团队的力量解决问题远胜于不明情况的指手划脚。9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。不断追求更高效(o xio)的解决问题，技术与设计是解决软件问题的重要手段。共四十三页“敏捷宣言”背后(bihu)的12准则（4）：10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。问题的解决不取决于解决方案的复杂性，而是源自于对问题提出者和问题本身的深刻理解。当然，问题解决方式本身也是重要的。11.最佳的架构、需求和设计出自于自组织的团队。 团队成员共同(gngtng)解决项目中所有问题12.团队要定期反省如何能够做到更有效，并相

8、应地调整团队的行为。检验适应是敏捷问题解决方式的核心。共四十三页敏捷方法的基本(jbn)原则 原则(yunz)描述客户参与 客户应该在开发过程中始终紧密参与其中，他们的作用是提供新系统的需求，对需求排序，并评估系统的迭代。增量式交付软件以增量的形式开发，客户指定在每个增量中包含的需求。人非过程团队开发的技巧应该被承认和发扬，保持他们各自的工作风格，不落俗套。接受变更预料系统需求的变更，并设计系统使之适应这些变更保持简单性关注软件开发和软件过程的简洁性，无论如何，积极地消除系统中的复杂性。12Chapter 3 Agile software development共四十三页敏捷(mnji)方法的

9、适应性 以下情况适合于采用敏捷方法(fngf)进行软件开发：（1）软件公司正在开发准备出售的小项目或中等规模的项目（2）属于机构内部定制系统的开发，客户有一个参与开发的明确的承诺，且没有太多的来自外部的规则和法律的影响。因为它致力于小型的、紧密结合的团队，将它扩展到大型系统的开发中会有很多问题。Chapter 3 Agile software development13共四十三页敏捷(mnji)方法的适应性 敏捷(mnji)方法适用于需求不确定并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；共四十三页敏捷(mnji)方法在实践中的问题客户可能很难保证全

10、程参与到项目的开发中。团队成员可能不适应高强度的投入。而这又是敏捷方法的特征。在不同信息持有者之间，需求的优先级变更困难。维护简单性需要额为的工作(gngzu)。公司不适应新系统带来的工作变更。当产品出现问题时，容易出现互相推诿的情况。15Chapter 3 Agile software development共四十三页敏捷(mnji)方法和软件维护两个问题：由于开发过程强调正式文档的最小化，用敏捷方法开发系统是否具有可维护性？敏捷方法是否能够有效(yuxio)用于系统进化，以响应系统变更的需求？Chapter 3 Agile software development16敏捷开发和系统具有较好

11、的维护性是一对矛盾。增量交付，面向变更的维护可能遇到的问题就是保持用户的持续参与和开发团队的持续性。在系统维护上，关键是需求文档！共四十三页3.2 计划(jhu)驱动和敏捷开发计划驱动计划驱动开发起源于系统工程和质量规范，建立系统工程的原则，协调大量需要精确协同工作的组件。通过从需求到已完成的代码等一系列代表物来推动软件开发的过程，计划驱动开发非常精确地依赖于明确的步骤。敏捷(mnji)驱动 敏捷开发的过程中需求分析、软件设计、软件开发过程相互交织在一起。强调软件开发的快速性和需求变化的快速适应性。文档的最小化。17Chapter 3 Agile software development共四十

12、三页表 1 敏捷开发、计划驱动(q dn)软件开发比较有要求(yoqi)无，少10系统是否受制于外部的法规？需大量系统分析一般9开发的系统是什么样类型的？要求低水平高8开发团队的设计人员和编码人员的能力如何？有影响无要求7有没有可能影响系统开发的文化问题？团队分散，有软件外包团队之间开发6 开发团队是怎么组织的？不依赖IDE有好的IDE5有什么样的技术支持开发？长周期短周期4预想的系统的寿命有多长？大小，且在同一地点3开发系统的规模有对大？否是2增量交付策略，即软件交付给用户并快速的取得反馈，切实么？是否1 系统开始前，非常详细的描述和设计很重要吗？计划驱动敏捷方法问题共四十三页 多数软件的开

13、发均可用计划驱动和敏捷方法(fngf)完成。选用何种方法(fngf)，参见上一页的内容。敏捷方法是一种思想，不是具体的实现过程。目前，列入敏捷方法的有10多种。共四十三页目前(mqin)列入敏捷方法软件开发之韵，Software Development Rhythms敏捷数据库技术，AD/Agile Database Techniques敏捷建模，AM/Agile Modeling自适应软件开发，ASD/Adaptive Software Development水晶方法，Crystal特性驱动开发，FDD/Feature Driven Development动态系统开发方法，DSDM/Dyna

14、mic Systems Development Method精益软件开发，Lean Software DevelopmentAUP（Agile Unified Process）ScrumXBreed极限(jxin)编程，XP eXtreme Programming探索性测试共四十三页XP 方法对敏捷(mnji)基本原理的支持增量式开发是通过小的、频繁的版本来支持的。客户的参与是采用全时雇佣到开发团队的形式。人、而不是过程，通过结对编程、对系统代码的集体拥有、可持续的开发过程而无需超额的工作时间来运作的。对变更的支持是通过经常性的版本发布，、测试优先开发、重构以避免代码退化以及连续的集成新功能来

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

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

17、集体所有制的一个主要优势是提升了开发程序的速度，因为一旦程式码中出现错误，任何程序设计师都能修正它。25Chapter 3 Agile software development（6）结对编程（7）集体所有共四十三页极限(jxin)编程实践 (4)（8）连续集成任务一完成，就集成到系统中。并进行单元测试（9）可持续的节奏大量超时是不能接受的的，因为它的后果就是降低代码的质量和平均生产率。（10）在场客户在极限编程中，“客户”并不是为系统付帐的人，而是真正使用该系统的人。极限编程认为客户应该时刻在现场解决问题。例如：在团队开发一个财务管理系统时，开发小组内应包含一位财务管理人员。共四十三页XP需求

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

19、e development共四十三页举例：开处方(chfng)的任务卡 （P42 图3-6 ）29Chapter 3 Agile software development共四十三页XP测试(csh)Xp中的测试(csh)的关键特性：测试优先开发；来自脚本的增量式测试开发；用户参与测试开发；自动测试系统的使用；Xp强调先写测试程序，再写代码，测试超前于代码的编写。可以对任务卡设计测试的用例描述。共四十三页测试案例(n l)：剂量检测描述（P43 图3-7） 31Chapter 3 Agile software development共四十三页结对编程Pair programming 结对编程(P

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

21、且常常令人疲劳的活动，但是能够创造出经过深思熟虑的高质量代码。 Laurie Williams &Steve Hayes 32Chapter 3 Agile software development共四十三页结对编程的好处(ho chu)支持共同(gngtng)拥有软件和共同(gngtng)对系统负责担当了非正式的复查过程有助于支持重构Chapter 3 Agile software development33共四十三页3.4 敏捷(mnji)项目管理敏捷方法(fngf)的倡导者经常发现：在应用开发中，对动态变更很难得到管理方面的支持。这些方法需要开发者、管理者和用户都改变他们工作和思考的方式

22、。例如，XP实践中的结对编程、测试优先的开发、持续集成以及在场客户等是很难让人接受的。而且，这些方法论更倾向于以开发者为中心，似乎并不太重视管理角色。实践证明，加强管理是敏捷方法被成功采纳并应用的关键而传统项目管理方法学和工具与这些新的敏捷方法缺少关联34Chapter 3 Agile software development共四十三页ScrumScrum是一个通用的敏捷方法(fngf)，但它主要注重迭代开发的管理，而不是管理敏捷软件工程的专门的技术方法(fngf)。Chapter 3 Agile software development35共四十三页Scrum 管理(gunl)过程图36Ch

23、apter 3 Agile software developmentScrum的三个阶段：1 规划纲要：建立大致的目标，设计软件体系结构2 冲刺循环：每个循环开发出一个增量3 项目(xingm)结束阶段总结项目(xingm)：完善项目(xingm)文档，如系统帮助，用户手册，总结项目(xingm)开发经验共四十三页Scrum过程-冲刺(chngc)循环在每一次冲刺(chngc)（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的功能来自产品订单（product backlog）。产品订单是按照优先级排列的要完成的工作的概要

24、的需求，哪些订单项会被加入一次冲刺将由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。共四十三页Scrum会议(huy)在冲刺中，每一天都会举行项目状况(zhungkung)会议，被称为 “每日站立会议”，15min，内容包括：说明工作进度遇到的问题接下来一天的工作计划 共四十三页可扩展的敏捷(mnji)方法 Scaling agile methods 尽管公司实施大型敏捷项目已经许多年了，但是“敏捷方法只适用于小型项目”这样的话依旧是新手所面临的普遍障碍，并且成为制定敏捷标准的战斗口号。 对于(duy)大型软件系统，快速发布、使之更贴近用户需求的方法，也适合于所有大型系统。39Chapter 3 Agile