软件工程第10章讲述.ppt

第10章 敏捷软件开发 敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法 软件开发的新挑战 快速的市场进入时间，要求高生产率 快速变化的需求 快速发展的技术 传统的软件开发方法 强调过程和文档 对变化的适应能力偏弱 Martin Fowler认为： 提前预测需求是困难的。同样，对项目进行过程中客户需求优先级的变更进行预测也很困难 对很多项目来说，软件设计和构建是交错进行的。也就是说，设计需要通过实施构建来获得验证，而在构建的过程中新获得的知识又可以帮助设计 从制定计划的角度来看，分析、设计、构建和测试活动并不容易预测 强调适应性而不是可预测性 经典软件开发方法：通过控制变化实现软件开发的可预测性 敏捷软件开发方法：变化是不可避免的，应该通过改善管理实践和工程实践来更好地适应变化 强调人在项目中的关键作用 敏捷软件开发认为人不是可以互相替换的“编程部件”，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性 强调“刚刚好”（Just enough） 在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少 从20世纪90年代开始，逐渐产生了一大批敏捷软件开发方法其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法（crystal）、自适应软件开发（adaptive software development，ASD）、动态系统开发方法（dynamic system development method，DSDM）等 2001年2月，17位敏捷方法的先驱在美国犹他州召开了为期2天的会议，成立了敏捷软件开发联盟 并发布了“敏捷宣言” 该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的12条原则 我们正通过亲身或者协助他人进行软件开发实践来探索更好的软件开发方法。基于此，我们建立了如下的价值观：?? 个体和交互 重于 过程和工具 工作的软件 重于 详尽的文档 客户合作 重于 合同谈判 响应变化 重于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值 过程和工具是重要的，但是软件开发中人的作用和交流的作用更需要被进一步强调 软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件 如果光有定义良好的过程和先进的工具，而人员的技能很差，或者不能很好地交流和协作，软件是很难成功地开发的 可以工作的软件是软件开发工作的最终目标 好的必要的文档能帮助我们理解软件做什么，怎么做以及如何使用，是有价值的。但是，软件开发的主要目标仍然是创建可运行的软件 敏捷软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以得到用户的认可 只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变 由于软件开发的预测性的困难，想通过合同谈判的方式，将需求固定下来常常是困难的 敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现用户的需求 任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变 因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化 ⑴ 我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意 ⑵ 拥抱变化，即使是在项目开发的后期。敏捷过程愿意为了客户的竞争优势而接纳变化 ⑶ 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期 ⑷ 业务人员和开发人员必须在项目的整个阶段紧密合作 ⑸ 围绕着被激励的个体构建项目。为个体提供所需的环境和支持，给予信任，从而达成目标 ⑹ 在团队内和团队间沟通信息的最有效和最高效的方式是面对面的交流 ⑺ 可工作的软件是进度的首要度量标准。 ⑻ 敏捷过程倡导可持续开发。项目发起者、开发人员和用户应该维持一个可持续的步调。 ⑼ 持续地追求技术卓越和良好设计，可以提高敏捷性 ⑽ 以简洁为本，它是减少不必要工作的艺术。 ⑾ 最好的架构、需求和设计是从自组织的团队中涌现出来的。 ⑿ 团队定期地反思如何变得更加高效，并相应地调整自身的行为。 识别价值 价值是客户愿意购买产品的原因，也是产品开发的根本价值所在。“是否有助于增加价值”是精益方法衡量过程活动的准则 定义价值流 价值流描述了组织为了交付价值所采取的一系列有增值的活动 保持价值流的流动 良好的系统应该让价值迅速流动，从而用较低的成本生产出正确的产品 拉动系统 拉动系统是基于当前客户的需