敏捷开发.ppt
《敏捷开发.ppt》由会员分享,可在线阅读,更多相关《敏捷开发.ppt(62页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、AgileIntroductionAgendaAgileProcessAgilevs.waterfallmodelProductbacklogSprintbacklogDailyScrumSprintReview&retrospectiveScrumteamsreferenceshttp:/en.wikipedia.org/wiki/Agile_software_developmenthttp:/en.wikipedia.org/wiki/Scrum_(development)AgileSoftwareDevelopmentprinciples,Patterns,andPractices硝烟中
2、的Scrum和XPtermsAgileSprintScrumTDDTestDrivenDevelopmentXPeXtremeProgrammingProductbacklogSprintbacklogBurndownchartAgileProcessWaterfall(1)Waterfall(2)瀑布模型(WaterfallModel)的特点:1.需求分析-概要设计-详细设计-开发-测试-交付2.阶段间具有顺序性和依赖性必须等前一阶段的工作完成之后,才能开始后一阶段的工作;前一阶段的输出文档就是后一阶段的输入文档,因此,只有前一阶段的输出文档正确,后一阶段的工作才能获得正确的结果。3.质量保
3、证的观点每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介,也是运行时期对软件进行维护的重要依据。每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误。事实上,越是早期阶段犯下的错误,暴露出来的时间就越晚,排除故障改正错误所需付出的代价也越高。因此,及时审查,是保证软件质量,降低软件成本的重要措施。传统的瀑布模型过于理想化了,事实上,人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档中的错误,而设计上的缺陷或错误可能在实现过程中显现出来,在综合测试阶段将发现需求分析、设计或编码阶段
4、的许多错误。4.瀑布模型很大程度上是一种文档驱动的模型。遵守瀑布模型的文档约束,将使软件维护变得比较容易一些。Waterfall(3)瀑布模型的缺点:1.在项目开始的时候,用户常常难以清楚地给出所有需求;用户与开发人员对需求理解存在差异。2.缺乏灵活性。因为瀑布模型确定了需求分析的绝对重要性,但是在实践中要想获得完善的需求说明是非常困难的,导致“阻塞状态”。反馈信息慢,开发周期长。3.各个阶段的划分完全固定,阶段之间产生大量的文档,增加了工作量;4.风险主要集中在中后期。由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果。因此早期的错误可能要等到开发后期的测试阶段才能发现,进而带
5、来严重的后果。Agile(1)敏捷软件开发又称敏捷开发,是一种从九十年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发流程。敏捷软件开发宣言(价值观):个体和交互胜过过程和工具可以工作的软件胜过面面具到的文档可户合作胜过合同谈判响应变化胜过遵循计划敏捷开发集成了新型开发模式的共同特点,它重点强调:1.客户与开发者的关系是协作,不是合约。2.以人为本,注重编程中人的自我特长发挥。3.面对面的沟通(认为比书面的文档更有效)。4.迭代-频繁交付新的软件版本。5.紧凑而自我组织型的团队。6.强调软件开发的产品是软件,而不是文档。文档是为软件开发服务的,而不是开发的主
6、体。7.设计周密是为了最终软件的质量,但不表明设计比实现更重要,要适应客户需求的不断变化,设计也要不断根据环境的变化,修改自己的设计。Agile(2)Agile is about being open about what were capable of doing,and then doing it Kent BeckAgile(3)Agile(4)12条原则1。我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。3。经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。4
7、。在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。5。围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。6。在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。7。工作的软件是首要进度度量标准。8。敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。9。不断地关注优秀的技能和好的设计会增强敏捷能力。10。简单-使未完成的工作最大化的艺术-是根本的。11。最好的构架、需求和设计出自于自组织的团队。12。每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。A
8、gile(5)运用敏捷要注意的问题敏捷对人员的素质要求比较高传统的分工基本上是每人负责一个模块,敏捷要求代码共有;敏捷要求结对编程,这是对dev沟通能力的一个考验;敏捷要求TDD,对开发人员能力要求比较高;持续的代码重构组织文化必须支持谈判人员彼此信任人少但是精干开发人员所作的决定得到认可环境设施满足成员间快速沟通之需要最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,因此敏捷方法更适用于较小的队伍。XP(1)极限编程极限编程(英语:Extremeprogramming,缩写为XP),是一种软件工程方法学,是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学,极限编程和
9、传统方法学的本质不同在于它更强调可适应性而不是可预测性强调可适应性而不是可预测性。XP的支持者认为软件需求的不断变化是很自然的现象,是软件项目开发中不可避免的、也是应该欣然接受的现象;他们相信,和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比,有能力在项目周期的任何阶段去适应变化,将是更加现实更加有效的方法。XP(2)价值沟通:在一些正式的软件开发方法中,这一任务是通过文档来完成的。极限编程支持设计、抽象、还有用户-程序员间交流的简单化,鼓励经常性的口头交流与回馈。简单:极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于,
10、它只关注于对当前的需求来进行设计、编码,而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的,即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。回馈:来自系统的反馈、来自客户的反馈、来自小组的反馈勇气:“只为今天的需求设计以及编码,不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。尊重:尊重的价值体现在很多方面。在极限编程中,团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试案例失败、或者以其他方式导致工作延期。XP(3)原则快速反馈:快速反馈:当反馈能做到及时、迅速,
11、将发挥极大的作用。假设简单:假设简单:假设简单认为任何问题都可以极度简单地解决。传统的系统开发方法要考虑未来的变化,要考虑代码的可重用性。极限编程拒绝这样做。增量变化:增量变化:罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。包容变化:包容变化:“包容变化”这一原则就是强调不要对变化采取反抗的态度,而应该包容它们。XP(4)方法XP(5)争议极限编程也有其被争论的一面:没有书面的详细的规格说明书客户代表被安排在专案中程序员以结对的方式工作测试驱动的开发绝大多数设计活动都匆匆而过,并渐进式的,开始一个“最简单的可能工作的东西”并当其需要时(测试失败)才增加复杂
12、性。单元测试促成为了设计纪律。AgileManifestoIndividualsandinteractionsoverprocessesandtoolsWorkingsoftwareovercomprehensivedocumentationCustomercollaborationovercontractnegotiationRespondingtochangeoverfollowingaplanThatis,whilethereisvalueintheitemsontheright,wevaluetheitemsontheleftmore.Productbacklog产品backlog是一
13、切的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序。它里面包含的是客户想要的东西,并用客户的术语加以描述。我们叫它故事(story),有时候也叫做Productbacklog条目。故事包括这样一些字段:1.ID-统一标识符,就是个自增长的数字而已。2.Name(名称)-简短的、描述性的故事名。3.Priority(优先级)4.Initialestimate(初始估算)-最小的单位是故事点(storypoint),一般大致相当于一个“理想的人天(man-day)”。5.Howtodemo(如何做演示)它大略描述了这个故事应该如何在sprint演示上进行示
14、范,本质就是一个简单的测试规范。“先这样做,然后那样做,就应该得到的结果”。6.Notes(注解)相关信息、解释说明和对其它资料的引用等等。一般都非常简短。Sprintbacklog(1)Sprint计划会议非常关键,应该算是Scrum中最重要的活动。举办Sprint计划会议,是为了让团队获得足够的信息,能够在几个星期内不受干扰地工作。Sprint计划会议会产生一些实实在在的成果:sprint目标。团队成员名单(以及他们的投入程度,如果不是100%的话)。sprintbacklog(即sprint中包括的故事列表)。确定好sprint演示日期。确定好时间地点,供举行每日scrum会议。Spri
15、ntbacklog(2)确定sprint目标Sprint目标需要回答这个根本的问题,“我们为什么要进行这个sprint?为什么我们不直接放假算了?”Sprint目标应该是尚未达成的。“打动CEO”这个目标不错,可如果这个系统已经给他留下了深刻印象,那就算了。这种状况下大家都可以放假回家,sprint目标依然能完成。制定sprint计划的时候,这个目标在sprint中常常会被用到。保证公司所有人(不只是顶级管理层)知道团队在干什么,目的又是什么!Sprintbacklog(3)决定sprint要包含的故事Sprintbacklog(4)Sprintbacklog(5)在sprint中包含多少故事
16、由团队决定,而不是产品负责人或其他人。WorkTimeEstimation:如果投入最适合的人员来完成这个故事,锁到一个屋子里,有很多食物,在完全没有打扰的情况下工作,那么需要多久,才能给出一个经过测试验证,可以交付的完整实现呢?Sprintvelocity生产率计算-投入程度(focusfactor)投入程度用来估算团队会在sprint中投入多少精力。投入程度低,就表示团队估计会受到很大干扰,或者他们觉得自己的时间估算太过理想化。看看团队的历史。看看他们在过去几个sprint里面的生产率是多少,然后假定在下一个sprint里面生产率差不多不变。这项技术也被叫做“昨日天气(yesterdays
17、 weather)”。一般为0.60.8Sprintbacklog(6)产品负责人如何对sprint放哪些故事产生影响?1.他可以重新设置优先级。2.其次,他可以更改范围缩小故事A的范围,直到团队相信故事A能在这个sprint里完成为止。3.他还可以拆分故事。产品负责人判断出故事A中某些方面实际并不重要,所以他把A分成两个故事A1和A2,赋给它们不同的重要级别。SprintbacklogFAQ(1)为什么产品负责人必须参加:“嘿,小伙子们,我想要的东西已经列下来了,我没时间参加你们的计划会议。”范围(scope)和重要性(importance)由产品负责人设置。估算(estimate)由团队设
18、置。在sprint计划会议上,经过团队和产品负责人面对面的对话,这三个变量会逐步得到调整优化。团队对故事做出的时间估算,跟产品负责人的想法不太一样。这可能会让他调整故事的重要性;或者修改故事的范围,导致团队重新估算,然后一连串诸如此类的后续反应。SprintbacklogFAQ(2)产品负责人还是坚持没时间参加怎么办?试着让产品负责人理解,为什么他的直接参与事关项目成败,希望他可以改变念头。试着在团队中找到某个人,让他在会议中充当产品负责人的代表。告诉产品负责人,“既然你没法来开会,我们这次会让Jeff代表你参加。他会替你在会议中行使权利,改变故事的优先级和范围。我建议,你最好在会议开始前尽可
19、能跟他沟通到位。如果你不喜欢Jeff当代表,也可以推荐其他人,只要他能全程参加我们的会议就行。”试着说服管理团队为我们分配新的产品负责人。推迟sprint的启动日期,直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情。SprintbacklogFAQ(3)为什么不能在质量上让步:假设产品负责人这样说,“好吧,你们把它估算成6个故事点也行。但我相信:一定能够找到些临时方案,节省一半时间。你们只要稍稍动下脑子就行。”不管什么时候,团队都要保证系统质量,这一点毋庸置疑,也没有折扣可讲。现在如此、将来如此、一直如此,直到永远。内部质量和外部质量分开。外部质量是
20、系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣;内部质量一般指用户看不到的要素,它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等;一般来说,系统内部质量优秀,外部质量仍有可能很差。而内部质量差的系统,外部质量肯定也不怎么样。产品负责人想把内部质量当作变量来处理。经验告诉我:牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间,接下来的日子里你就要一直为它付出代价。一旦我们放松要求,允许代码库中暗藏问题,后面就很难恢复质量了。碰到这种状况,我就会试着把话题转回到范围上来。“既然你想尽早得到这个特性,那我们能不能把范围缩小一点?这
21、样实现时间就能缩短。也许我们可以简化错误处理的功能,把“高级错误处理”当作一个单独的故事,放到以后再实现。或者也可以降低其他故事的优先级,好让我们集中处理这一个。”一旦产品负责人弄清楚内部质量是不可能让步的,他一般都会处理好其他变量。SprintbacklogFAQ(4)无休止的sprint计划会议在sprint计划会议中最困难的事情是:1)人们认为他们花不了多长时间2)但他们会的!假如sprint计划会议接近尾声,但仍然没有得出sprint目标或者sprintbacklog,这时该怎么办?我们要打断它么?还是再延期一个小时?或者到时间就结束会议,然后明天继续?这种事情会一再发生,尤其是在新团
22、队身上。通常会直接打断会议,中止它,让这个sprint给大家点儿罪受吧。具体一点,我会告诉团队和产品负责人:“这个会议要在10分钟以后结束。我们到目前为止还没有一个真正的sprint计划。是按照已经得出的结论去执行,还是明早8点再开个4小时的会?”我也试过让会议延续下去。但一般都没啥效果,因为大家都很累了。如果他们在2到8个小时内都没整理出一个还说得过去的sprint计划,再来一个小时他们仍然得不出结论。我们也可以明天再安排一次会议但大家都已经耐心耗尽,只想启动这个sprint,不想再花一个小时做计划。所以我会打断会议。是的,这个sprint让大家不太好过。但我们应该看到它的正面影响,整个团队
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 开发
限制150内