软件工程讲义_第三章_敏捷开发.pdf

软件工程 第3章敏捷开发 主要内容 敏捷是什么 敏捷及变更的成本费用 敏捷过程 极限编程 其他敏捷过程模型  自适应软件开发  Scrum  动态系统开发方法  Crystal  特征驱动开发  精益软件开发  敏捷建模 敏捷过程工具集 小结 敏捷软件工程 敏捷软件工程是哲学理念和一系列开发指 南的综合。这种哲学理念推崇让客户满意 和软件尽早增量发布；小而高度自主的项 目团队；非正式的方法；最小化软件工程 工作产品以及整体精简开发。开发方法强 调超越设计和分析（尽管并不排斥这类活 动）的发布及开发人员和客户之间主动和 持续的沟通。 敏捷软件工程 软件工程师和其他项目共利益者共同组成 敏捷开发团队，这个团队是自我组织的并 掌握着自己的命运。一个敏捷团队能够培 养所有参与人员之间的交流与合作。 孕育了基于计算机系统和软件产品的现代 商业环境，正以飞快的节奏不断变化着， 敏捷软件工程提出了可用于特定类型软件 和软件项目的不同于传统软件工程的合理 方案。事实证明，这一方法可以快速交付 成功的系统。 敏捷软件工程 敏捷开发恰当的称呼应当是 “类软件工 程”，它保留了基本框架活动：客户沟通、 策划、建模、构建、交付和评估，但将其 缩减到一个推动项目组朝着构建和交付发 展的最小任务集（有人认为这是以牺牲问 题分析和方案设计为代价而实现的） 敏捷软件工程 接受敏捷理念的客户和软件工程师有共同 的观点：唯一真正重要的工作产品是在合 适时间提交给客户的可运行软件增量。 如果敏捷团队认为过程可行，开发出的可 交付软件增量能使客户满意，则表明敏捷 方法已经正确实施。 敏捷软件开发宣言 个人和这些个人之间的交流胜过开发过程 和工具 可运行的软件胜过宽泛的文档 客户合作胜过合同谈判 对变更的良好响应胜过了按部就班地遵循 计划 亦即，虽说上述右边的各项很有价值，但 我们认为左边的各项具有更大的价值 敏捷方法  本质上讲，敏捷方法是为了克服传 统软件工程中认识和实践的弱点开 发而成的。敏捷开发可以带来多方 面的好处，但它并不完全对立于传 统软件工程实践，也不能作为超越 一切的哲学理念而用于所有软件工 作。 敏捷方法  不确定性意味着变更，而变更意味 着付出昂贵的成本，特别是在其失 去控制或疏于管理的情况下。而敏 捷方法最具强制性的特点之一就是 它能够通过软件过程来降低由变更 所引起的代价。 惯例过程模型的主要缺陷(COC02a) 忘记了开发计算机软件的人员的弱点。软件工 程师在工作方式上有很大差别，在技能水平、主 动性、服从性、一致性和责任心方面也有巨大差 异。一部分人可以通过书面方式很好地沟通，而 有些人则不行。 过程模型可以 “利用纪律或者宽容来处理人的 这一共同弱点”，大多数惯例过程模型选择了纪 律， “不能一致连贯地做同一件事是人性的弱点， 因而高度纪律性的方法学非常脆弱。” 什么是敏捷 敏捷已经成为当今描述现代软件过程的时髦用 词。每个人都是敏捷的，敏捷团队是能够适当响 应变化的灵活团队。变化就是软件开发本身，软 件构建有变化、团队成员在变化、使用新技术会 带来变化，各种变化都会对开发的软件产品以及 项目本身造成影响。我们必须接受 “支持变化” 的思想，它应当根植于软件开发中的每一件事中， 因为这是软件的心脏与灵魂。敏捷团队意识到软 件是团队中所有人共同开发完成的，这些人的个 人技能和合作能力是项目成功的关键所在。 敏捷及变更的成本费用 软件开发的传统方法中变化的成本费用随 着计划的进展成非线性增长。这种方法在 软件开发团队收集需求时相对容易适应变 化。但是假设如果在进行确认测试的过程 中变更一个主要的功能。这一变更需要对 软件的体系结构设计进行修改，包括设计 和构建三个新组件，修改另外五个组件， 设计新的测试等，则费用会迅速上升。见 课本41页图3.1。 敏捷及变更的成本费用 敏捷的拥护者认为，一个设计良好的敏捷 过程 “拉平”了变更成本曲线，使软件开 发团队在没