软件工程第10章-敏捷软件开发

《软件工程第10章-敏捷软件开发》由会员分享，可在线阅读，更多相关《软件工程第10章-敏捷软件开发（61页珍藏版）》请在金锄头文库上搜索。

1、软件工程,第10章 敏捷软件开发,复旦大学计算机科学技术学院 软件工程（第二版）,内容摘要,敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法,2,复旦大学计算机科学技术学院 软件工程（第二版）,敏捷软件开发的产生背景,软件开发的新挑战 快速的市场进入时间，要求高生产率 快速变化的需求 快速发展的技术 传统的软件开发方法 强调过程和文档 对变化的适应能力偏弱,3,提高对变化的适应能力,Martin Fowler认为： 提前预测需求是困难的。同样，对项目进行过程中客户需求优先级的变更进行预测也很困难 对很多项目来说，软件设计和构建是交错进行的。也就是说，设计需要通过实施构建来获得验

2、证，而在构建的过程中新获得的知识又可以帮助设计 从制定计划的角度来看，分析、设计、构建和测试活动并不容易预测,复旦大学计算机科学技术学院 软件工程（第二版）,4,敏捷方法的基本观点,强调适应性而不是可预测性 经典软件开发方法：通过控制变化实现软件开发的可预测性 敏捷软件开发方法：变化是不可避免的，应该通过改善管理实践和工程实践来更好地适应变化 强调人在项目中的关键作用 敏捷软件开发认为人不是可以互相替换的“编程部件”，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性,复旦大学计算机科学技术学院 软件工程（第二版）,5,复旦大学计算机科学技术学院 软件工程（第二版）,强调“刚刚好”（

3、Just enough） 在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少,6,敏捷方法的产生,从20世纪90年代开始，逐渐产生了一大批敏捷软件开发方法 其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法（crystal）、自适应软件开发（adaptive software development，ASD）、动态系统开发方法（dynamic system development method，DSDM）等,复旦大学计算机科学技术学院 软件工程（第二版）,7,敏捷宣言,2001年2月，17位敏捷

4、方法的先驱在美国犹他州召开了为期2天的会议，成立了敏捷软件开发联盟 并发布了“敏捷宣言” 该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的12条原则,复旦大学计算机科学技术学院 软件工程（第二版）,8,敏捷宣言,我们正通过亲身或者协助他人进行软件开发实践来 探索更好的软件开发方法。 基于此，我们建立了如下的价值观： 个体和交互 重于 过程和工具 工作的软件 重于 详尽的文档 客户合作 重于 合同谈判 响应变化 重于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值,复旦大学计算机科学技术学院 软件工程（第二版）,9,复旦大学计算机科学技术学院 软件工程（第二版）,个体

5、和交互 重于 过程和工具,过程和工具是重要的，但是软件开发中人的作用和交流的作用更需要被进一步强调 软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件 如果光有定义良好的过程和先进的工具，而人员的技能很差，或者不能很好地交流和协作，软件是很难成功地开发的,10,复旦大学计算机科学技术学院 软件工程（第二版）,工作的软件 重于 详尽的文档,可以工作的软件是软件开发工作的最终目标 好的必要的文档能帮助我们理解软件做什么，怎么做以及如何使用，是有价值的。但是，软件开发的主要目标仍然是创建可运行的软件 敏捷软件开发强调不断地快速地向用户

6、提交可运行的软件（不一定是完整的软件），以得到用户的认可,11,复旦大学计算机科学技术学院 软件工程（第二版）,客户合作 重于 合同谈判,只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变 由于软件开发的预测性的困难，想通过合同谈判的方式，将需求固定下来常常是困难的 敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现用户的需求,12,复旦大学计算机科学技术学院 软件工程（第二版）,响应变化 重于 遵循计划,任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然

7、而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变 因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化,13,敏捷宣言的12条原则, 我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意 拥抱变化，即使是在项目开发的后期。敏捷过程愿意为了客户的竞争优势而接纳变化 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期 业务人员和开发人员必须在项目的整个阶段紧密合作 围绕着被激励的个体构建项目。为个体提供所需的环境和支持，给予信任，从而达成目标 在团队内和团队间沟通信息的最有效和最高效的

8、方式是面对面的交流,复旦大学计算机科学技术学院 软件工程（第二版）,14,敏捷宣言的12条原则（续）, 可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。项目发起者、开发人员和用户应该维持一个可持续的步调。 持续地追求技术卓越和良好设计，可以提高敏捷性 以简洁为本，它是减少不必要工作的艺术。 最好的架构、需求和设计是从自组织的团队中涌现出来的。 团队定期地反思如何变得更加高效，并相应地调整自身的行为。,复旦大学计算机科学技术学院 软件工程（第二版）,15,精益思想的5条原则,识别价值 价值是客户愿意购买产品的原因，也是产品开发的根本价值所在。“是否有助于增加价值”是精益方法衡量过程活

9、动的准则 定义价值流 价值流描述了组织为了交付价值所采取的一系列有增值的活动 保持价值流的流动 良好的系统应该让价值迅速流动，从而用较低的成本生产出正确的产品,复旦大学计算机科学技术学院 软件工程（第二版）,16,精益思想的5条原则（续）,拉动系统 拉动系统是基于当前客户的需求，向上游环节逐级反馈，每个环节都基于下一个环节的需求而进行生产 持续改善 持续改善是精益思想的最重要支柱。精益思想的核心就是不断进行改善从而最大化价值,复旦大学计算机科学技术学院 软件工程（第二版）,17,敏捷方法的公共特征,致力于降低变化的成本 价值导向 充分发挥人的积极性 基于增量和迭代的开发方法,复旦大学计算机科学

10、技术学院 软件工程（第二版）,18,复旦大学计算机科学技术学院 软件工程（第二版）,内容摘要,敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法,19,Scrum的产生历史,1986年，竹内弘高和野中郁次郎在哈佛商业评论上发表了The New New Product Development Game，首次使用Scrum来描述产品开发中的一种新方法 1993年，Jeffery Sutherland和Ken Schwaber将该方法引入软件开发领域，并于1995年在OOPSLA会议上发表了相关论文,复旦大学计算机科学技术学院 软件工程（第二版）,20,Scrum的核心概念,尽量在早期

11、暴露软件开发中的问题，进行及时的调整，从而使得软件开发团队在充满不确定的研发领域成功地工作,复旦大学计算机科学技术学院 软件工程（第二版）,透明,检验,适应,21,方法框架,复旦大学计算机科学技术学院 软件工程（第二版）,24小时,2-4周,每日会议,潜在可交付的 产品增量,产品Backlog,团队成员划分的 Backlog任务,22,时间盒,时间盒（time-box）是一个固定的时间段，为软件开发提供了一个节奏 时间盒在Scrum中称为Sprint 在每个Sprint中，都包含完整的需求分析、计划、开发、测试等各个环节。 一般情况下，每个Sprint都应该产生可发布的产品增量。每个Sprin

12、t的开发时间是固定的，一般是一个月或者更短的时间,复旦大学计算机科学技术学院 软件工程（第二版）,23,Scrum团队,Scrum团队是自组织、跨职能部门的，其核心目标是提高灵活性和生产能力。 每个Scrum团队都包括三种角色：Scrum Master、产品负责人和开发团队。 Scrum Master负责保证Scrum团队的成员理解并且遵循Scrum框架； 产品负责人指明团队的开发方向，最大化Scrum团队的工作价值； 开发团队负责具体的开发工作，在每个Sprint结束之前将产品负责人的需求转化成为潜在可交付的产品模块。,复旦大学计算机科学技术学院 软件工程（第二版）,24,制品,潜在可交付的

13、产品增量 在每个Sprint的结束，Scrum团队都应该能够产生一个新的、可交付的产品增量，这部分和既有的已开发产品一起形成一个整体，随时准备交付给客户。 产品Backlog 产品负责人对软件开发团队的需求的列表 Sprint的Backlog 开发团队成员为了实现一个Sprint的开发目标而定义的开发任务,复旦大学计算机科学技术学院 软件工程（第二版）,25,完成标准（Definition of Done）,Scrum的规则要求开发团队在每个Sprint的交付物都应该达到“完成”（done） “完成”标准由开发团队定义，并且进行了清晰的描述 只有达到了“完成”标准，开发团队在Sprint的输出

14、才能被看做是合格的交付物，才可以声称完成了某个产品增量,复旦大学计算机科学技术学院 软件工程（第二版）,26,需求管理,复旦大学计算机科学技术学院 软件工程（第二版）,需求是逐步细化的 需求可能在项目中间发生变化 需求应当被估算并指定优先级,27,Sprint计划会议,第1部分 产品负责人介绍产品Backlog中的高优先级的条目 团队基于历史速率，从高到低按照优先级选择将要开发的条目 第2部分 团队分析选择的条目，结合交付标准，讨论需要完成哪些工作,复旦大学计算机科学技术学院 软件工程（第二版）,28,任务墙,复旦大学计算机科学技术学院 软件工程（第二版）,29,燃尽图,复旦大学计算机科学技术

15、学院 软件工程（第二版）,30,每日例会,Scrum团队每天召开的短会，保证团队能够了解和分享全局的项目信息。 每日例会的参加者是开发团队成员和Scrum Master，产品负责人可以根据需要决定是否参加。 团队成员在每日例会上回答3个问题： 上次例会后做了什么？ 遇到了哪些困难？ 计划在下次例会前做些什么？,复旦大学计算机科学技术学院 软件工程（第二版）,31,Sprint评审,Scrum要求开发团队在每个Sprint结束时都对本Sprint完成的功能进行演示.其基本目标是反馈和适应。 Scrum鼓励各种各样的角色参加 演示，而不仅仅局限于客户、产品负责人和开发团队成员。 Scrum建议Sp

16、rint评审尽量使用非正式的方式进行。,复旦大学计算机科学技术学院 软件工程（第二版）,32,Sprint回顾,参加者： 开发团队、产品负责人和Scrum Master 步骤 准备 数据收集 问题分析 确定方案 结束,复旦大学计算机科学技术学院 软件工程（第二版）,33,复旦大学计算机科学技术学院 软件工程（第二版）,内容摘要,敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法,34,复旦大学计算机科学技术学院 软件工程（第二版）,XP方法,1996年，Kent Beck等人在Chrysler的C3项目的开发过程中逐步产生了极限编程的基本概念 1999年，Kent Beck撰写了解析极限编程：拥抱变化，对极限编程的价值观、原则和实践进行了阐述,35,复旦大学计算机科学技术学院 软件工程（第二版）,XP方法的开发过程,36,复旦大学计算机科学技术学院 软件工程（第二版）,探索阶段 探索阶段的主要工作是开发初始的用户故事（User Stories ）和体系结构骨架（architecture spike） 用户故事描述了系统高层的需求，它是制订发布计划的输入 在探索阶段，试探找到系统中固定不变的部分（体系结构骨架），并找出一种形象的比喻，这种比喻描述了你打算如何构建系统，起到概念框架的作用 探索阶段还应根据用户故事编制相应的测试用例，供以后验收测试时使用,