第10章-敏捷软件开发

软件工程第10章敏捷软件开发内容摘要敏捷软件开发概述Scrum方法极限编程（XP）方法看板方法敏捷软件开发的产生背景软件开发的新挑战快速的市场进入时间，要求高生产率快速变化的需求快速发展的技术传统的软件开发方法强调过程和文档对变化的适应能力偏弱提高对变化的适应能力MartinFowler认为：提前预测需求是困难的。同样，对项目进行过程中客户需求优先级的变更进行预测也很困难对很多项目来说，软件设计和构建是交错进行的。也就是说，设计需要通过实施构建来获得验证，而在构建的过程中新获得的知识又可以帮助设计从制定计划的角度来看，分析、设计、构建和测试活动并不容易预测敏捷方法的基本观点强调适应性而不是可预测性经典软件开发方法：通过控制变化实现软件开发的可预测性敏捷软件开发方法：变化是不可避免的，应该通过改善管理实践和工程实践来更好地适应变化强调人在项目中的关键作用敏捷软件开发认为人不是可以互相替换的“编程部件”，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性强调“刚刚好”（Justenough）在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少敏捷方法的产生从20世纪90年代开始，逐渐产生了一大批敏捷软件开发方法其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法（crystal）、自适应软件开发（adaptivesoftwaredevelopment，ASD）、动态系统开发方法（dynamicsystemdevelopmentmethod，DSDM）等敏捷宣言2001年2月，17位敏捷方法的先驱在美国犹他州召开了为期2天的会议，成立了敏捷软件开发联盟并发布了“敏捷宣言”该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的12条原则敏捷宣言我们正通过亲身或者协助他人进行软件开发实践来探索更好的软件开发方法。基于此，我们建立了如下的价值观：个体和交互重于过程和工具工作的软件重于详尽的文档客户合作重于合同谈判响应变化重于遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值个体和交互重于过程和工具过程和工具是重要的，但是软件开发中人的作用和交流的作用更需要被进一步强调软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件如果光有定义良好的过程和先进的工具，而人员的技能很差，或者不能很好地交流和协作，软件是很难成功地开发的工作的软件重于详尽的文档可以工作的软件是软件开发工作的最终目标好的必要的文档能帮助我们理解软件做什么，怎么做以及如何使用，是有价值的。但是，软件开发的主要目标仍然是创建可运行的软件敏捷软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以得到用户的认可客户合作重于合同谈判只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变由于软件开发的预测性的困难，想通过合同谈判的方式，将需求固定下来常常是困难的敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现用户的需求响应变化重于遵循计划任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化敏捷宣言的12条原则⑴我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意⑵拥抱变化，即使是在项目开发的后期。敏捷过程愿意为了客户的竞争优势而接纳变化⑶经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期⑷业务人员和开发人员必须在项目的整个阶段紧密合作⑸围绕着被激励的个体构建项目。为个体提供所需的环境和支持，给予信任，从而达成目标⑹在团队内和团队间沟通信息的最有效和最高效的方式是面对面的交流敏捷宣言的12条原则（续）⑺可工作的软件是进度的首要度量标准。⑻敏捷过程倡导可持续开发。项目发起者、开发人员和用户应该维持一个可持续的步调。⑼持续地追求技术卓越和良好设计，可以提高敏捷性⑽以简洁为本，它是减少不必要工作的艺术。⑾最好的架构、需求和设计是从自组织的团队中涌现出来的。⑿团队定期地反思如何变得更加高效，并相应地调整自身的行为。精益思想的5条原则识别价值价值是客户愿意购买产品的原因，也是产品开发的根本价值所在。“是否有助于增加价值”是精益方法衡量过程活动的准则定义价值流价值流描述了组织为了交付价值所采取的一系列有增值的活动保持价值流的流动良好的系统应该让价值迅速流动，从而用较低的成本生产出正确的产品精益思想的5条原则（续）拉动系统拉动系统是基于当前客户的需求，向上游环节逐级反馈，每个环节都基于下一个环节的需求而进行生产持续改善持续改善是精益思想的最重要支柱。精益思想的核心就是不断进行改善从而最大化价值敏捷方法的公共特征致力于降低变化的成本价值导向充分发挥人的积极性基于增量和迭代的开发方法内容摘要敏捷软件开发概述Scrum方法极限编程（XP）方法看板方法SCRUM的产生历史1986年，竹内弘高和野中郁次郎在《哈佛商业评论》上发表了TheNewNewProductDevelopmentGame，首次使用Scrum来描述产品开发中的一种新方法1993年，JefferySutherland和KenSchwaber将该方法引入软件开发领域，并于1995年在OOPSLA会议上发表了相关论文SCRUM的核心概念尽量在早期暴露软件开发中的问题，进行及时的调整，从而使得软件开发团队在充满不确定的研发领域成功地工作·透明·检验·适应方法框架24小时2-4周每日会议潜在可交付的产品增量产品Backlog团队成员划分的Backlog任务时间盒时间盒（time-box）是一个固定的时间段，为软件开发提供了一个节奏时间盒在Scrum中称为Sprint在每个Sprint中，都包含完整的需求分析、计划、开发、测试等各个环节。一般情况下，每个Sprint都应该产生可发布的产品增量。每个Sprint的开发时间是固定的，一般是一个月或者更短的时间SCRUM团队Scrum团队是自组织、跨职能部门的，其核心目标是提高灵活性和生产能力。每个Scrum团队都包括三种角色：ScrumMaster、产品负责人和开发团队。ScrumMaster负责保证Scrum团队的成员理解并且遵循Scrum框架；产品负责人指明团队的开发方向，最大化Scrum团队的工作价值；开发团队负责具体的开发工作，在每个Sprint结束之前将产品负责人的需求转化成为潜在可交付的产品模块。制品潜在可交付的产品增量在每个Sprint的结束，Scrum团队都应该能够产生一个新的、可交付的产品增量，这部分和既有的已开发产品一起形成一个整体，随时准备交付给客户。产品Backlog产品负责人对软件开发团队的需求的列表Sprint的Backlog开发团队成员为了实现一个Sprint的开发目标而定义的开发任务完成标准（DEFINITIONOFDONE）Scrum的规则要求开发团队在每个Sprint的交付物都应该达到“完成”（done）“完成”标准由开发团队定义，并且进行了清晰的描述只有达到了“完成”标准，开发团队在Sprint的输出才能被看做是合格的交付物，才可以声称完成了某个产品增量需求管理需求是逐步细化的需求可能在项目中间发生变化需求应当被估算并指定优先级SPRINT计划会议第1部分产品负责人介绍产品Backlog中的高优先级的条目团队基于历史速率，从高到低按照优先级选择将要开发的条目第2部分团队分析选择的条目，结合交付标准，讨论需要完成哪些工作任务墙燃尽图每日例会Scrum团队每天召开的短会，保证团队能够了解和分享全局的项目信息。每日例会的参加者是开发团队成员和ScrumMaster，产品负责人可以根据需要决定是否参加。团队成员在每日例会上回答3个问题：上次例会后做了什么？遇到了哪些困难？计划在下次例会前做些什么？SPRINT评审Scrum要求开发团队在每个Sprint结束时都对本Sprint完成的功能进行演示.其基本目标是反馈和适应。Scrum鼓励各种各样的角色参加演示，而不仅仅局限于客户、产品负责人和开发团队成员。Scrum建议Sprint评审尽量使用非正式的方式进行。SPRINT回顾参加者：开发团队、产品负责人和ScrumMaster步骤准备数据收集问题分析确定方案结束内容摘要敏捷软件开发概述Scrum方法极限编程（XP）方法看板方法XP方法1996年，KentBeck等人在Chrysler的C3项目的开发过程中逐步产生了极限编程的基本概念1999年，KentBeck撰写了《解析极限编程：拥抱变化》，对极限编程的价值观、原则和实践进行了阐述XP方法的开发过程最新版本发布计划用户认可用户故事(userstories)下一迭代Bugs新用户故事测试用例迭代开发体系结构骨架(spike)系统比喻制订交付计划验收测试小发布需求不确定的估计确定的估计难点骨架探索阶段计划阶段迭代与发布阶段产品化阶段维护阶段探索阶段探索阶段的主要工作是开发初始的用户故事（UserStories）和体系结构骨架（architecturespike）用户故事描述了系统高层的需求，它是制订发布计划的输入在探索阶段，试探找到系统中固定不变的部分（体系结构骨架），并找出一种形象的比喻，这种比喻描述了你打算如何构建系统，起到概念框架的作用探索阶段还应根据用户故事编制相应的测试用例，供以后验收测试时使用计划阶段计划阶段的任务是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计划和发布计划使用你最熟悉的形式为用户故事建模，这个模型描述了用户故事的任务以及这些任务之间的关系通常图形方式（可以是草图）比文字描述更直观尽可能精确地估算工作量，这是制订计划的重要依据。对于那些不能确切估算其工作量的难点部分，要进一步作分析，直至能确定其工作量估算迭代到发布阶段迭代到发布阶段根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版本根据在探索阶段编写的测试用例，进行验收测试。一旦发现错误或者通过验收测试想进入下一轮迭代时，就重复迭代开发的工作在这一阶段当客户提出新的用户故事，或者根据项目的进展情况认为有必要时，可以回到计划阶段，对迭代和发布计划做出修改或调整产品化阶段产品化阶段的工作主要是确认迭代开发的软件已经做好进入产品化的准备在此阶段可进行更多的测试，如系统测试、负载测试、安装测试等另一个工作就是整理文档。虽然敏捷软件开发的价值观中强调“可运行软件高于详尽的文档”，但是，必要的文档仍是需要的维护阶段维护阶段涵盖了计划阶段、迭代到发布阶段和产品化阶段通常这个阶段主要包括面向产品的活动，如系统的运行和支持XP方法的价值观交流（Communication）实践表明，项目失败的重要原因之一是交流不畅，使得客户的需求不能准确地传递给开发人员，造成开发人员不能充分理解需求；模型或设计的变动未能及时告知相关人员，造成系统的不一致和集成的困难所有项目相关人员之间充分的有效的交流是软件开发成功所必不可少的XP方法提倡面对面的交流，这是一种有效的也是效率最高的交流方式简单（Simplicity）指在确保得到客户满意的软件的前提下，做最简洁的工作（简单的过程、模型、文档、设计和实现）在开发中不断优化设计，时刻保持代码简洁、无冗余体现了敏捷开发的“刚刚好(Justenough)”思想，即开发中的活动及制