《软件工程敏捷软件开发.ppt》由会员分享，可在线阅读，更多相关《软件工程敏捷软件开发.ppt（47页珍藏版）》请在课桌文档上搜索。
1、软件工程,第5章 敏捷软件开发,软件工程,内容摘要,敏捷软件开发概述极限编程（XP）方法相关敏捷过程模型Scrum方法动态系统开发方法敏捷建模敏捷统一过程,2,软件工程,敏捷软件开发的产生背景,软件开发的新挑战快速的市场进入时间，要求高生产率快速变化的需求快速发展的技术传统的软件开发方法强调过程和文档对变化的适应能力偏弱,3,提高对变化的适应能力,Martin Fowler认为：提前预测需求是困难的。同样，对项目进行过程中客户需求优先级的变更进行预测也很困难对很多项目来说，软件设计和构建是交错进行的。也就是说，设计需要通过实施构建来获得验证，而在构建的过程中新获得的知识又可以帮助设计从制定计划
2、的角度来看，分析、设计、构建和测试活动并不容易预测,软件工程,4,软件工程,5,敏捷方法的基本观点,强调适应性而不是可预测性经典软件开发方法：通过控制变化实现软件开发的可预测性敏捷软件开发方法：变化是不可避免的，应该通过改善管理实践和工程实践来更好地适应变化强调人在项目中的关键作用敏捷软件开发认为人不是可以互相替换的“编程部件”，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性,软件工程,6,软件工程,强调“刚刚好”（Just enough）在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少,7,敏捷方法的产生,从20世
3、纪90年代开始，逐渐产生了一大批敏捷软件开发方法其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法（crystal）、自适应软件开发（adaptive software development，ASD）、动态系统开发方法（dynamic system development method，DSDM）等,软件工程,8,敏捷宣言,2001年2月，17位敏捷方法的先驱在美国犹他州召开了为期2天的会议，成立了敏捷软件开发联盟 并发布了“敏捷宣言”该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的12条原则,软件工程,9,敏捷宣言,我们正通过亲身或者协助
4、他人进行软件开发实践来探索更好的软件开发方法。基于此，我们建立了如下的价值观：个体和交互 重于 过程和工具工作的软件 重于 详尽的文档客户合作 重于 合同谈判响应变化 重于 遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值,软件工程,10,软件工程,个体和交互 重于 过程和工具,过程和工具是重要的，但是软件开发中人的作用和交流的作用更需要被进一步强调软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件如果光有定义良好的过程和先进的工具，而人员的技能很差，或者不能很好地交流和协作，软件是很难成功地开发的,11,软件工程,工作
5、的软件 重于 详尽的文档,可以工作的软件是软件开发工作的最终目标好的必要的文档能帮助我们理解软件做什么，怎么做以及如何使用，是有价值的。但是，软件开发的主要目标仍然是创建可运行的软件敏捷软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以得到用户的认可,12,软件工程,客户合作 重于 合同谈判,只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变由于软件开发的预测性的困难，想通过合同谈判的方式，将需求固定下来常常是困难的敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现
6、用户的需求,13,软件工程,响应变化 重于 遵循计划,任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化,14,敏捷宣言的12条原则,我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意 拥抱变化，即使是在项目开发的后期。敏捷过程愿意为了客户的竞争优势而接纳变化 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采用较短的周期 业务人员和开发人员必须在项目的整个阶段
7、紧密合作 围绕着被激励的个体构建项目。为个体提供所需的环境和支持，给予信任，从而达成目标 在团队内和团队间沟通信息的最有效和最高效的方式是面对面的交流,软件工程,15,敏捷宣言的12条原则（续）,可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。项目发起者、开发人员和用户应该维持一个可持续的步调。持续地追求技术卓越和良好设计，可以提高敏捷性 以简洁为本，它是减少不必要工作的艺术。最好的架构、需求和设计是从自组织的团队中涌现出来的。团队定期地反思如何变得更加高效，并相应地调整自身的行为。,软件工程,16,敏捷方法的公共特征,致力于降低变化带来的成本强调价值强调人的作用使用增量和迭代的开发
8、方法,软件工程,17,软件工程,内容摘要,敏捷软件开发概述极限编程（XP）方法相关敏捷过程模型Scrum方法动态系统开发方法敏捷建模敏捷统一过程,18,软件工程,XP(eXtreme Programming)方法,1996年，Kent Beck等人在Chrysler的C3项目的开发过程中逐步产生了极限编程的基本概念1999年，Kent Beck撰写了解析极限编程：拥抱变化，对极限编程的价值观、原则和实践进行了阐述,19,极限编程过程,软件工程,20,XP方法,XP 策划开始于倾听，倾听产生一系列“用户故事”。团队成员评估每一个故事，并给出以开发周数为度量单位的成本。团队共同决定如何将故事分组，
9、并置于将要开发的下一个软件增量中。给出对下一个发布版本的基本承诺（就包括的故事、交付日期和其他项目事项）项目的第一个发行版本（也称为一个软件增量）交付之后，XP团队计算项目的速度，用于帮助估计后续发行版本的发布日期和进度安排。,软件工程,21,XP方法,XP设计严格遵循KIS（Keep It Simple，保持简洁）原则。鼓励使用CRC卡。如果在设计中碰到困难，推荐使用“Spike解决方案”鼓励“重构”以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。XP编程推荐在编码开始之前建立单元测试。鼓励“结对编程”。XP测试所有单元测试应当使用一个可以自动实施的框架。“验收测试”由客户规
10、定技术条件，并且着眼于客户可见的系统级特征和功能。,22,结对编程,结对编程提高了设计的可靠性和质量在做任何设计的时候，都有两个程序员一起思考，可以汇集两个程序员的设计思想在代码编写完成的时候同时也通过了代码审查这种方式有助于减少程序中的错误，降低测试时间和测试成本,软件工程,23,软件工程,XP核心实践：用户故事,故事是对团队应该完成的工作的陈述。极限编程通过故事来体现价值观中的“沟通”的原则。好的用户故事应该能够触发客户和开发团队之间的沟通作为和客户的良好沟通的成果，故事拥有清楚的完成标准。一种常见的策略是，从用户的角度描述一组验收测试用例，开发团队使用该验收测试用例来验证是否已经完成了某
11、个故事,24,软件工程,XP核心实践：估算,估算是极限编程中隐含的实践，很多应用极限编程的团队使用估算来帮助沟通、制定迭代和发布计划估算不仅仅是帮助确定故事的规模，更重要的是通过对故事点的讨论，团队可以发现需求或实现中可能存在的问题,25,软件工程,XP核心实践：简单设计,完成了定义的功能,能通过所有的测试该设计描述了程序员的重要意图，便于理解和沟通；设计和实现没有冗余、没有重复的逻辑在满足以上条件的前提下，没有多余的类和方法,26,软件工程,XP核心实践：重构,重构是在不改变代码的外部行为的情况下，通过调整内部的结构，来持续保持代码的可理解、可维护特征,27,软件工程,XP核心实践：测试驱动
12、开发,测试驱动开发的3个快速循环的步骤：编写一个测试该测试试图发现代码中有一处功能没有实现，或者代码中存在一个需要修复的问题 编写代码使用尽可能快的方式编写产品代码，使这个测试得以通过 对代码进行重构,28,软件工程,XP核心实践：结对编程,结对编程提高了设计的可靠性和质量在做任何设计的时候，都有两个程序员一起思考，可以汇集两个程序员的设计思想在代码编写完成的时候同时也通过了代码审查这种方式有助于减少程序中的错误，降低测试时间和测试成本,29,瀑布模式：重型开发方式，每个阶段都要求完美，无法适应变更迭代开发不要求每个阶段的任务都完美，逐步完善螺旋开发风险驱动的开发方式敏捷开发相比迭代，开发周期
13、更短，并强调沟通合作,软件工程,30,极限编程的核心价值,沟通简单反馈勇气谦逊强调把列出的每个方法和思想做到极限,软件工程,31,软件工程,内容摘要,敏捷软件开发概述极限编程（XP）方法相关敏捷过程模型Scrum方法动态系统开发方法敏捷建模敏捷统一过程,32,敏捷开发的本质,以人为中心、迭代、循序渐进的开发方法不以文档作为驱动，强调人与人之间的面对面的沟通交流迭代：把复杂并且开发周期长的开发任务，分解成很多小周期可完成的任务，这样的每个小周期就是一个迭代过程，每次迭代都产生一个可交付的产品快速迭代 拥抱变化敏捷是一种指导思想，Scrum和XP就是具体的开发方式了，Scrum偏重于过程，而XP重
14、在实践Scrum,橄榄球运动的专业术语，表示“争球”动作，,软件工程,33,Scrum方法,Scrum90年代中期，敏捷过程模型Scrum 橄榄球比赛；Sprint 比赛中的冲刺框架性过程活动需求分析设计演化交付,软件工程,34,过程流,35,Scrum开发过程,软件工程,36,软件工程,37,Scrum开发过程,确定Product Backlog（按优先顺序排列的一个产品需求列表；Scrum Team根据Product Backlog列表，做工作量的预估和安排；根据Product Backlog列表，通过 Sprint Planning Meeting来从中挑选出一个Story作为本次迭代完
15、成的目标，该目标的时间周期是14个星期，然后把这个Story进行细化，形成一个Sprint Backlog；Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；,软件工程,38,在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前
16、更新自己的Sprint burn down（Sprint燃尽图）每日集成，每天都要有一个可以成功编译、并且可以演示的版本(自动工具实现)当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，要进行Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加每一个Scrum Team的成员都要向他们演示自己完成的软件产品Sprint RetrospectiveMeeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；,软件工程,39,软件工程
17、,40,Scrum的3355,3个角色Product Owner：产品负责人，清楚的知道产品的愿景，需要对产品待办列表的梳理，优化，优先级排序等负责。决定团队每个冲刺要完成哪些任务，负责产品的功能和达到要求的标准，指定软件的发布日期和交付内容Scrum Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍，负责流程在项目中的顺利实施和进行Team是开发团队，能够交付一个端到端的真正对客户有价值的产品,软件工程,41,3个工件Product Backlog：是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。Sprint Backlo
18、g：每个迭代的功能开发列表，PO会根据团队的能力并按照产品待办列表中的优先级来选取每个冲刺要做的事情。团队可以专注在每个迭冲刺要走的事情上而不被打断。Burn down chart:燃尽图，在每个迭代显示剩余工作时间和任务完成情况,软件工程,42,5种活动,Sprint:冲刺,一个固定的时间周期（通常为2w-4w）,团队要尽可能在这个周期内交付可以工作的软件给客户sprint planning meeting:冲刺开始的时候，PO会和团队一起从PB中选择本次要做的任务/故事，并且会对团队提出的疑问进行解释和澄清。同时团队会估算故事并分解成任务，最后会形成本次的Sprint Backlog.da
19、ily standup meeting:每日站会，scrum为了加强团队沟通，每天团队都要选择一个时间站在一起，互相交流彼此的进展和问题,以便及时解决出现的问题，同时也能让团队随时了解我们离冲刺目标还有多远。sprint review:在sprint周期最后，需要进行一次评审会议，让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。retrospective meeting:回顾会议，通
20、常在reivew会议之后开始，有团队成员在冲刺结束之后对上个迭代进行总结，同时提出一些改进方案，这是一个持续改进的过程,软件工程,43,5个价值观,承诺 愿意对目标做出承诺专注 把你的心思和能力都用到你承诺的工作上去开放 Scrum 把项目中的一切开放给每个人看尊重 每个人都有他独特的背景和经验勇气 有勇气做出承诺，履行承诺，接受别人的尊重,软件工程,44,45,动态系统开发方法(DSDM),在可控项目环境中使用增量原型开发模式以完全满足对时间有约束的系统的构建和维护是一种过程框架，使用迭代软件过程，Pareto原则(20%的时间完成80%的功能)三个迭代周期功能模型迭代设计和构建迭代实现 增量不需要100%完成,46,敏捷建模,对于大型，业务关键型系统，传统建模以及文档：完美 庞大 难以维护由Scott Ambler提出，以轻量级方式对待软件建模的标准、原则和实践敏捷建模原则有目的的建模使用多个模型，不同模型表达系统不同方面轻装上阵，只保留能提供长期价值的模型内容重于表述形式；理解模型及工具；建模方法适应本地团队需要,47,敏捷统一过程(AUP),Agile Unified Process,在大型上连续，在小型上迭代采用经典UP阶段活动：起始、细化、构建和转换每个活动中，迭代使用敏捷，尽快交付软件增量每个AUP迭代执行以下活动：建模实现测试部署配置及项目管理环境管理,
