经验敏捷开发流程.ppt

1、,敏捷开发流程介绍,目录,?什么是软件开发方法,?什么是敏捷开发方法,?我们该采用什么方法,什,么,是,软,件,开发,方法,软,件,开发,定,义,根据用,户,需求建造出,软,件系,统,的,产,品,开发过,程。包括需,求,获,取、,开发规划,、需求分,析和,设计,、,编,程,实现,、,软,件,测试,、版本控制。,-,维,基百科,常,见种类,瀑布式,开发,迭代式,开发,敏捷式,开发,瀑布式开,发,最典型的,预见,性方法，,严,格遵循,预,先,计划,按照需求分析、,设计,、,编,码,、集成、,测试,、,维护,的,步,骤顺,序,进,行。,步,骤,成果用以衡量,进,度，,例如需求,规,格，,设计,文,档

2、,，,测试计划,等，方便定,义,里程碑,主要,问题,是,严,格分,级导,致,自由度降低，早期承,诺导,迭代式开,发,弥,补传统开发,方式的一些,弱点，具有更高的成功率,和生,产,率,开发,被分,为,一系列的小的,、固定,长,度的小,项,目，,称,为,一系列的迭代。每次都,包括需求分析、,设计,、,实,现与测试,。,开发,工作可在需求被完全,确定前,启动,，,并,在一次迭,代中完成部分功能。再通,Agile software dev,elopment,什,么,是敏捷,开发,方法,主要原,则,：,?,个,体和互,动,：高于,流程和工具,?,工作的,软,件：高于,详尽,的文,档,?,客,户,合作：高

3、于合,同,谈,判,?,响应变,化：高于遵,循,计划,vs,迭代：,都强,调,在短的,开发,周,期提交,软,件，敏捷的,周期可能更短，更强,调,人的高度,协,作,vs,瀑布：,敏捷强,调尽,早,将,小的,可用功能交付使用，,在,项,目周期中持,续,改,善，自由度高,主要方法：,?,极,限,编,程,?,测试驱动开发,?,Scrum,机制,?,看板文化,极限,编程,Extreme programming,，,缩写为,XP,，,强,调,可适,应,性而不是可,预测,性,认为软,件需求,变,化是自然,现,象,在,项,目周期的任何,阶,段去适,应变,化，,降低因需求,变,更而,带来,的成本,快速反,馈,：,

4、对,客,户,反,馈,做到及,时,、迅速，重,视单,元,测试,假,设简单,：,认为,任何,问题,都可以“,极,度,简单,”地解,决,，拒,绝预测,需求，拒,绝为,了未,来,而考,虑,重用,增量,变,化：一次完成大的改造是不可能的，采用增量,变,化，小步,前,进,测试驱动,开发,Test-Driven Development,，,简称,TDD,。,它,要求在,编写,代,码,之,前先,写测试,代,码,，只,编写,使,测试,通,过,的功能代,码,，通,过测试来,推,动,整,个开发,的,进,行。,编写简洁,可用和高,质,量的代,码,，,并,加速,开发过,程。,（,FDD, DDD,）,根据客,户,需求,

5、编写测试,用例，,从,使,用者角度,设计,代,码,易,测试,和,测试独,立性的要求使,设计,松耦合,频,繁地,运,行,测试,，,尽,早地,发现错误,，提高代,码质,量,持,续,的回,归测试,，持,续,地跟踪整,个,系,统,的,状态,主要角色：,Scrum Master,：,Scrum,教练,和,团队带头,人，确保,团队,合理的,运,作,Scrum,产,品,负责,人（,Product Owner,）,:,确定,产,品方向，定,义产,品,内,容、,优,先,级,及交付,时间,一,种,迭代式增量,软,件,开,发过,程，包括了一系列,实践,和,预,定,义,角色的,过,程骨架，通常用于敏捷,软,件,开发,

6、。英,语,是橄,榄,球中,争,球的意思,Scru,m,Scrum,过,程总览,Scrum,阶段,1,：制定产品,Bac,klog,?,产品,backlog,是,Scrum,的,核心,?,由需求或特性等组成的列表,?,用客户的术语加以描述,?,按照重要性的级别进行排序,?,backlog,条目称为故事（,stor,y,）,每个故事包括如下字段：,?,ID(,统一标识符,),?,Name,（名称）,?,Importance,（重要性）,?,Initial estimate,（初始估算工作量）,?,How to demo,（如何做演示）,?,Notes,（注解）,?,Bug tracking ID,

7、（,Bug,跟踪,ID,）,产品,BACKLOG,（示例）,ID,Name,Imp,Est,How to demo,Notes,1,存款,30,5,登录，打开存,款界,面，存入,10,欧,元，,转到我的账户,余额,界面，检查我,的余,额增加了,10,欧,元。,需要,UML,顺,序图。目,前不,需要考虑,加,密的问题。,2,查看自己,的,交易明细,10,8,登录，点击,“,交,易,”,，,存入一笔款项。,返,回交易页面，,看到,新的存款显示,在页,面上。,使用分页,技,术避免大,规,模的数据,库,查询。和,查看,用户列表,的,设计相似。,?,独立,?,基本相当于一个,fe,ature,?,对客户

8、有价值,?,易于评估时间和难,度,?,不易太大或太小,?,可测试,Story,的准,则,-,+,+,+,Value,Risk,Low,High,High,优,先,级评,估,工作量的估,算,?,最小单位为一个故事点（,story point,），相当于一个理想的人天,?,投入最适合的人员，完全没有打扰，需要几天给出一个经过验证，可以交付,的完整实现,?,不需要绝对无误，保证相对准确（即,:,两个点的时间应该是四个点的一半）,?,估算全部工作，而不只是自己的部分,?,把故事分拆成更小的故事以达到更精确,?,最小值是,0.5,，太小的任务要么被移除，要么就给,0.5,Scrum,阶段,2:,制定,S

9、pr,int Backlog,?,sprint,目标,?,团队成员名单（以及投入程度）,?,确定,sprint backlog,（即,故事列,表）,?,确定好,sprint,演示日期,?,确定每日,scrum,会议时间地点,?,协商,sprint,的时间长度,召开,Sprint,会议,Sprint,计划会议：,13:00,17:00,（每小时休息,10,分钟）,13:00,13:30,产品负责人对,sprint,目标进行总体介绍，概,括产品,backlog,。定下演,示的时间地点。,13:30,15:00,团队估算时间，在必要的情况下拆分,backlog,条目。产品负责人在必要时,修改重要性评

10、分。理清每个条,目的含义。所有重要性高的,backlog,条目都要填,写“如何演,示”。,15:00,16:00,团队选择要放入,sprint,中的故事。计算生产率，用作核查工作安排的基础,。,16:00,17:00,为每日,scrum,会议安排固定的时间地点，把故事进一步拆分成任务。,确定,Sprint,生,产力,如果,没,有,参,考,怎么,办,？,随,便猜一,个,，只,会,在第一,个,sprint,里,面使用，以后有了,历,史,数,据然后做改,进,。,新,团队,中使用的“,默,认,”投入程度通,常是,70%,，大多,数,团队,都能,达,到的,数,值,。,Scrum,阶段,3,：每,天站会,

11、看板和站,会,?,用户体验比投影仪好，大家保持清醒，并留心会议进,展，更多的参与感,?,多个故事可以同时编辑,?,重新划分优先级变得易如反掌挪动索引卡就行,?,互相看到,所有人都可以看到彼此，都能看到任务板,?,例会结束时算出剩余工作量之和，在,sprint,燃尽图,上画上一个新的点,?,处理迟到，惩罚机制,看板,燃尽,图,Scrum,阶段,4,：,Sprin,t,演示,?,清晰阐述,sprint,目标,?,不要花太多时间准备演示，集中精力演示实际工作的代码,?,节奏要快，保持演示的快节奏,?,关注业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“,我们怎么做的”,?,可能的话，让观众自己试一下产品,?,不要演示一大堆细碎的,bug,修复和微不足道的特性,Scrum,阶段,5,：,Sprin,t,总结,?,设定时间为,1,至,3,个小时,?,参与者：产品负责人，整个团队,?,向大家展示,sprint backlog,，对,sprint,做总结,?,每个人轮流发言，讲出自己的想法，什么是好