【文档说明】软件工程敏捷软件开发课件.ppt，共(47)页，3.131 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50500.html

以下为本文档部分文字说明：

软件工程第5章敏捷软件开发软件工程内容摘要•敏捷软件开发概述•极限编程（XP）方法•相关敏捷过程模型–Scrum方法–动态系统开发方法–敏捷建模–敏捷统一过程2软件工程敏捷软件开发的产生背景•软件开发的新挑战快速的市场进入时间，要求高生产率快速变化的需求快速发展的技术•传统的软件开发方

法强调过程和文档对变化的适应能力偏弱3提高对变化的适应能力•MartinFowler认为：–提前预测需求是困难的。同样，对项目进行过程中客户需求优先级的变更进行预测也很困难–对很多项目来说，软件设计和构建是交错进行的。也就是说，设计需要通过实施构建来获得验证，而在构

建的过程中新获得的知识又可以帮助设计–从制定计划的角度来看，分析、设计、构建和测试活动并不容易预测软件工程4软件工程5敏捷方法的基本观点•强调适应性而不是可预测性–经典软件开发方法：通过控制变化实现软件开发的可预测性–敏捷软件开发方法：变化是不可避免的，应该通过改善管理实践和工程实践来更好

地适应变化•强调人在项目中的关键作用–敏捷软件开发认为人不是可以互相替换的“编程部件”，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性软件工程6软件工程•强调“刚刚好”（Justenough）–在

保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少7敏捷方法的产生•从20世纪90年代开始，逐渐产生了一大批敏捷软件开发方法其中比较有影响的包括：极

限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法（crystal）、自适应软件开发（adaptivesoftwaredevelopment，ASD）、动态系统开发方法（dynamicsystemdevelopmentm

ethod，DSDM）等软件工程8敏捷宣言•2001年2月，17位敏捷方法的先驱在美国犹他州召开了为期2天的会议，成立了敏捷软件开发联盟并发布了“敏捷宣言”•该宣言由四个价值观声明组成，并提炼出敏捷软件开

发方法必须遵循的12条原则软件工程9敏捷宣言我们正通过亲身或者协助他人进行软件开发实践来探索更好的软件开发方法。基于此，我们建立了如下的价值观：个体和交互重于过程和工具工作的软件重于详尽的文档客户合作重于合同谈判响应变

化重于遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值软件工程10软件工程个体和交互重于过程和工具•过程和工具是重要的，但是软件开发中人的作用和交流的作用更需要被进一步强调•软件是由人组成的团

队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件•如果光有定义良好的过程和先进的工具，而人员的技能很差，或者不能很好地交流和协作，软件是很难成功地开发的11软件工程工作的软件重于详尽的文档•可以工作的软件是软件开发工作的最终目标

•好的必要的文档能帮助我们理解软件做什么，怎么做以及如何使用，是有价值的。但是，软件开发的主要目标仍然是创建可运行的软件•敏捷软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以得到用户的认可12软件工

程客户合作重于合同谈判•只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变•由于软件开发的预测性的困难，想通过合同谈判的方式，将需求固定下来常常是困难的•敏捷软件开发强调与客户的协作，通过

与客户的交流和紧密合作来发现用户的需求13软件工程响应变化重于遵循计划•任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变•

因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化14敏捷宣言的12条原则⑴我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意⑵拥抱变化，即使是在项目开发的后期。敏

捷过程愿意为了客户的竞争优势而接纳变化⑶经常地交付可工作的软件，相隔几星期或一两个月，倾向于采用较短的周期⑷业务人员和开发人员必须在项目的整个阶段紧密合作⑸围绕着被激励的个体构建项目。为个体提供所需的环境和支持，给予信任，从而达成目标⑹在团队内和团队间沟通信息的最有效和最高效的

方式是面对面的交流软件工程15敏捷宣言的12条原则（续）⑺可工作的软件是进度的首要度量标准。⑻敏捷过程倡导可持续开发。项目发起者、开发人员和用户应该维持一个可持续的步调。⑼持续地追求技术卓越和良好设计，可以提高敏捷性

⑽以简洁为本，它是减少不必要工作的艺术。⑾最好的架构、需求和设计是从自组织的团队中涌现出来的。⑿团队定期地反思如何变得更加高效，并相应地调整自身的行为。软件工程16敏捷方法的公共特征•致力于降低变化带来的成本•强调价值•强调

人的作用•使用增量和迭代的开发方法软件工程17软件工程内容摘要•敏捷软件开发概述•极限编程（XP）方法•相关敏捷过程模型–Scrum方法–动态系统开发方法–敏捷建模–敏捷统一过程18软件工程XP(eXtremeP

rogramming)方法•1996年，KentBeck等人在Chrysler的C3项目的开发过程中逐步产生了极限编程的基本概念•1999年，KentBeck撰写了《解析极限编程：拥抱变化》，对极限编程的价值观、原则和实践进行了阐述19极限编程过程软件工程20XP方法•XP策划–开始于倾听，倾听产

生一系列―用户故事‖。–团队成员评估每一个故事，并给出以开发周数为度量单位的成本。–团队共同决定如何将故事分组，并置于将要开发的下一个软件增量中。–给出对下一个发布版本的基本承诺（就包括的故事、交付日期和其他项目事项）–项目的第一个发行版本（也

称为一个软件增量）交付之后，XP团队计算项目的速度，用于帮助估计后续发行版本的发布日期和进度安排。软件工程21XP方法•XP设计–严格遵循KIS（KeepItSimple，保持简洁）原则。–鼓励使用CRC卡。–如果在设计中碰到困难，推荐使用“Spike解决方案”–鼓励

“重构”—以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。•XP编程–推荐在编码开始之前建立单元测试。–鼓励“结对编程”。•XP测试–所有单元测试应当使用一个可以自动实施的框架。–“验收测试”由客户规定技术条件，并且着眼于客户可见的

系统级特征和功能。22结对编程•结对编程提高了设计的可靠性和质量•在做任何设计的时候，都有两个程序员一起思考，可以汇集两个程序员的设计思想•在代码编写完成的时候同时也通过了代码审查•这种方式有助于减少程序中的错误，降低测

试时间和测试成本软件工程23软件工程XP核心实践：用户故事•故事是对团队应该完成的工作的陈述。极限编程通过故事来体现价值观中的“沟通”的原则。好的用户故事应该能够触发客户和开发团队之间的沟通•作为和客户的良好沟通的成果，故事拥有清楚

的完成标准。一种常见的策略是，从用户的角度描述一组验收测试用例，开发团队使用该验收测试用例来验证是否已经完成了某个故事24软件工程XP核心实践：估算•估算是极限编程中隐含的实践，很多应用极限编程的团队使用估算来帮助沟通、制定迭

代和发布计划•估算不仅仅是帮助确定故事的规模，更重要的是通过对故事点的讨论，团队可以发现需求或实现中可能存在的问题25软件工程XP核心实践：简单设计•完成了定义的功能,能通过所有的测试•该设计描述了程序员的重要意图，便于理解和沟

通；设计和实现没有冗余、没有重复的逻辑•在满足以上条件的前提下，没有多余的类和方法26软件工程XP核心实践：重构•重构是在不改变代码的外部行为的情况下，通过调整内部的结构，来持续保持代码的可理解、可维护特征27软件工程XP核心实践：测试驱动开发测试驱动

开发的3个快速循环的步骤：⑴编写一个测试该测试试图发现代码中有一处功能没有实现，或者代码中存在一个需要修复的问题⑵编写代码使用尽可能快的方式编写产品代码，使这个测试得以通过⑶对代码进行重构28软件工程XP核心实践：结对编程•结对编程提高了

设计的可靠性和质量•在做任何设计的时候，都有两个程序员一起思考，可以汇集两个程序员的设计思想•在代码编写完成的时候同时也通过了代码审查•这种方式有助于减少程序中的错误，降低测试时间和测试成本29•瀑布模式：–

重型开发方式，每个阶段都要求完美，无法适应变更•迭代开发–不要求每个阶段的任务都完美，逐步完善•螺旋开发–风险驱动的开发方式•敏捷开发–相比迭代，开发周期更短，并强调沟通合作软件工程30极限编程的核心价值•沟通•简单•反馈•勇气•谦逊•强调把列出的每个方法和思想做到极限软件工程31软

件工程内容摘要•敏捷软件开发概述•极限编程（XP）方法•相关敏捷过程模型–Scrum方法–动态系统开发方法–敏捷建模–敏捷统一过程32敏捷开发的本质•以人为中心、迭代、循序渐进的开发方法•不以文档作为驱动，

强调人与人之间的面对面的沟通交流•迭代：把复杂并且开发周期长的开发任务，分解成很多小周期可完成的任务，这样的每个小周期就是一个迭代过程，每次迭代都产生一个可交付的产品•快速迭代拥抱变化•敏捷是一种指导思想，Scrum和XP就是具体的开发方式了，Scrum偏重于过程，

而XP重在实践•Scrum,橄榄球运动的专业术语，表示“争球”动作，软件工程33Scrum方法•Scrum—90年代中期，敏捷过程模型•Scrum橄榄球比赛；Sprint比赛中的冲刺•框架性过程活动–需求–分析–设计–演化–交付软件工程34过程流

35Scrum开发过程软件工程36软件工程37Scrum开发过程•确定ProductBacklog（按优先顺序排列的一个产品需求列表；•ScrumTeam根据ProductBacklog列表，做工作量的预估和安排；•根据Pro

ductBacklog列表，通过SprintPlanningMeeting来从中挑选出一个Story作为本次迭代完成的目标，该目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个SprintBacklog；•Spri

ntBacklog是由ScrumTeam去完成的，每个成员根据SprintBacklog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；软件工程38•在ScrumTeam完成计划会议上选出的SprintBacklog过程中，需要进行DailyScrumMeeting（每日站

立会议），每次会议控制在15分钟左右，每个人向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的Sprintburndown（Sprint燃尽图）•每日集成，每天都要有一

个可以成功编译、并且可以演示的版本(自动工具实现)•当一个Story完成，也就是SprintBacklog被完成，也就表示一次Sprint完成，要进行SrpintReviewMeeting（演示会议），也称为评审会议，产品负责人和客户都要参加每一个ScrumTeam的成员都要向他

们演示自己完成的软件产品•SprintRetrospectiveMeeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；软件工程39软件工程40Sc

rum的3355•3个角色•ProductOwner：产品负责人，清楚的知道产品的愿景，需要对产品待办列表的梳理，优化，优先级排序等负责。决定团队每个冲刺要完成哪些任务，负责产品的功能和达到要求的标准，指定软件的发布日期和交付内容•Scrum

Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍，负责流程在项目中的顺利实施和进行•Team是开发团队，能够交付一个端到端的真正对客户有价值的产品软件工程4

1•3个工件•ProductBacklog：是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。•SprintBacklog：每个迭代的功能开发列表，PO会根据团队的能力并按照产品待办列表中的优先级来选取每个冲刺要做的事情。团队可以专注在每个迭冲刺要走的

事情上而不被打断。•Burndownchart:燃尽图，在每个迭代显示剩余工作时间和任务完成情况软件工程425种活动•Sprint:冲刺,一个固定的时间周期（通常为2w-4w）,团队要尽可能在这个周期内交付可以工作的软件给客户•sprintplann

ingmeeting:冲刺开始的时候，PO会和团队一起从PB中选择本次要做的任务/故事，并且会对团队提出的疑问进行解释和澄清。同时团队会估算故事并分解成任务，最后会形成本次的SprintBacklog.•dailys

tandupmeeting:每日站会，scrum为了加强团队沟通，每天团队都要选择一个时间站在一起，互相交流彼此的进展和问题,以便及时解决出现的问题，同时也能让团队随时了解我们离冲刺目标还有多远。•sprintreview:在sprint周期最后，需要进行一次评审会

议，让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，并得到重要反馈。做演示也会迫使开发团队真正

完成一些工作。•retrospectivemeeting:回顾会议，通常在reivew会议之后开始，有团队成员在冲刺结束之后对上个迭代进行总结，同时提出一些改进方案，这是一个持续改进的过程软件工程435个价值观•承诺–愿意对目标做出承诺•专注–把你的心思和能力都用到你承

诺的工作上去•开放–Scrum把项目中的一切开放给每个人看•尊重–每个人都有他独特的背景和经验•勇气–有勇气做出承诺，履行承诺，接受别人的尊重软件工程4445动态系统开发方法(DSDM)•在可控项目环境中使用增

量原型开发模式以完全满足对时间有约束的系统的构建和维护•是一种过程框架，使用迭代软件过程，Pareto原则(20%的时间完成80%的功能)•三个迭代周期–功能模型迭代–设计和构建迭代–实现增量不需要100%完成46敏捷建模•对于大型，业务关键型系统，传统建模以及文档：完美庞大难以维护•由Scott

Ambler提出，以轻量级方式对待软件建模的标准、原则和实践•敏捷建模原则–有目的的建模–使用多个模型，不同模型表达系统不同方面–轻装上阵，只保留能提供长期价值的模型–内容重于表述形式；–理解模型及工具；建模方法适应本地团队需要47敏捷统一过程(AUP)•AgileUnif

iedProcess,在大型上连续，在小型上迭代–采用经典UP阶段活动：起始、细化、构建和转换–每个活动中，迭代使用敏捷，尽快交付软件增量•每个AUP迭代执行以下活动：–建模–实现–测试–部署–配置及项目管理–环境管理