敏捷开发流程与方法.ppt

Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Click to edit Master title style,*,HUAWEI TECHNOLOGIES CO.,LTD.,Page,*,单击此处编辑母版标题样式,Huawei Confidential,英文标题,:32-35pt,颜色,:R153 G0 B0,内部使用字体,:,FrutigerNext LT Medium,外部使用字体,:Arial,中文标题,:30-32pt,颜色,:R153 G0 B0,字体,:,黑体,英文正文,:20-22pt,子目录,(2-5,级,):18pt,颜色,:,黑色,内部使用字体,:,FrutigerNext LT Regular,外部使用字体,:Arial,中文正文,:18-20pt,子目录,(2-5,级,):18pt,颜色,:,黑色,字体,:,细黑体,配色参考方案：,建议同一页面内不超过四种颜色，以下是,13,组配色方案，同一页面内只选择一组使用。（仅供参考）,客户或者合作伙伴的标志放在右上角,.,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,敏捷开发流程与方法,Strictly Private and Confidential,BGCN,交付管理部,目录,1.1敏捷的起源,2,敏捷系列,1.2,敏捷方法体系,1,敏捷开发简介,3,敏捷开发的误区,1.3,敏捷宣言,1.4,为什么要敏捷,?,敏捷开发的起源,上个世纪,90,年代,2001,年,2004,年以后,萌芽,-,产生敏捷方法,敏捷方法是从上个世纪,90,年代开始发展起来的一组方法学的总称，包括极限编程等等。这些方法学之间有一些差异，但是差异不是特别大,正规,成立敏捷联盟,每种方法学的领导人共同起草了敏捷软件开发宣言，总结出方法之间的共同点，最终就是价值，并且用敏捷这个词给这种方法学一个统称,发展,开始广为流行,500,强公司中众多公司应用敏捷,;,如,HP,Microsoft,IBM,等,什么是敏捷开发？,敏捷开发（,A,gile,D,evelopment）是一种以人为核心、迭代、循序渐进的开发方法。,子项目特征,-,各个子项目的成果都经过测试,-,具备集成和可运行的特征,-,小项目相互联系,目录,1.1,敏捷的起源,1.2,敏捷方法体系,1,敏捷开发简介,1.3,敏捷宣言,1.4,为什么要敏捷,?,2,敏捷系列,3,敏捷开发的误区,敏捷方法,XP-eXtreme Programing,极限编程,:,思想源自,Kent Beck,和,Ward Cunningham,在软件项目中的合作经历。,SCRUM,：,是一种迭代的增量化过程，用于产品开发或工作管理。,水晶方法,Crystal:由,Alistair Cockburn,在,1990,年代末提出。把不同类型的项目采用不同的方法。,FDD,特性驱动,Feature Driven Development,，,由,Peter Coad,、,Jeff de Luca,、,Eric Lefebvre,共同开发，是一套针对中小型软件开发项目的开发模式。它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。,DSDM-Dynamic System Development Methodology,，,它倡导以业务为核心，快速而有效地进行系统开发，在英国等欧洲国家比较流行。,ASD-Adaptive Software Development,，,由,Jim Highsmith,在,1999,年正式提出。,ASD,强调开发方法的适应性（,Adaptive,）,敏捷开发特点,敏捷开发包括很多方法，例如,XP,和,FDD,，同重量级的文档驱动的开发过程相比较，敏捷方法在灵活性等方面更有吸引力。这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。,很多方法很难独立的使用。如,:,测试驱动的开发，结对开发，计划调整周期以及持续改进，不过，后来的结果证实，这些方法都取得了成功。,使用这些方法并不能保证一定成功。开发者的经验和技术仍旧是影响开发结果的最主要因素。对于合适的人，基于敏捷原则的开发方法可以产生更好的结果，同时形成一个愉快地、有激情的工作环境,目录,1.1,敏捷的起源,1.2,敏捷方法体系,1,敏捷开发简介,1.3,敏捷宣言,1.4,为什么要敏捷,?,2,敏捷系列,3,敏捷开发的误区,敏捷宣言,核心理念,：,适应和以人为本,客户合作胜过合同谈判,响应变化胜过遵循计划,可以工作的软件胜过面面俱到的文档,个体和交互,胜过过程和工具,敏捷规则,最高目标是能持续地、及早地向客户交付软件；,拥抱变化；,频繁地发布可运行的软件；,客户和开发人员在一起工作；,以人为本；,最重要的衡量开发过程的手段，是可工作的软件；,稳定的开发速度；,敏捷高效的设计；,简单有效；,重视,Teamwork,；,积极的调整。,目录,1.1,敏捷的起源,1.2,敏捷方法体系,1,敏捷开发简介,1.3,敏捷宣言,1.4,为什么要敏捷,?,2,敏捷系列,3,敏捷开发的误区,我们为什么需要敏捷,项目为什么失败？,软件工程试图解决这些问题：,对用户需求理解得不清楚，甚至有错误；,用户需求变化；,软件很难维护或扩展；,在项目后期阶段发现很严重的设计缺陷；,软件质量或性能不合格；,Test-Build-Release,过程的可操作性、可维护性很差；,人员流动；,为了,规范化开发过程，引进传统工程的概念（瀑布型）；,为了理解需求，提出原型法；,为了提高设计开发的效率和扩展性，提出重用和面向对象等思想；,为了让开发过程更灵活，提出了开发框架的概念；,为了降低风险，,提出了风险评估、成本控制和增量开发等思想；,我们为什么需要敏捷,部门,：,1),培养团队合作精神，稳定开发队伍；,2),提高开发人员的水平；,3),提高项目成功率，降低开发成本，,提升软件开发效率,项目经理,：,1),更好地和用户沟通，更清晰地理解用户需求；,2),更充分地使用资源，更科学地调配资源，更精确地掌握开发进度。,系统分析设计,：,1),设计更加完善；,2),更有效地更新知识，得到其他成员更多的尊重。,程序员,：,1),学习系统设计和项目管理；,2),提高学习和工作效率，受到重视，减少加班时间，工作更高效,谁在用敏捷,Fortune,500,公司中成功应用,XP,的公司包括,Ford,，,Daimler-Chrysler,，,First,Union,National Bank,，,IBM,，,HP,等等。,通信业,NS,，,Ericsson,Alcatel,等都号称在转向敏捷,更多是小规模开发队伍（小规模开发队伍 小规模项目）,越来越多的公司开始使用敏捷开发过程,敏捷开发成功的因素,知识和技能,文化和氛围,自组织团队,开放的心态,目录,2.1,XP-eXtreme Programing,2,敏捷系列,2.2,SCRUM,1,敏捷开发简介,3,敏捷开发的误区,敏捷实践,在敏捷的两个门派：,XP,、,Scrum,中，整理归纳了很多可以用于协助软件开发的实践，后面统称为敏捷实践。,什么是,XP,XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements.-Kent Beck.,Kent Beck,Ward Cunningham,Martin Fowler,Ron Jeffries,于,2000,年创立,XP,是软件开发过程中的纪律，它规定你：必须在编程前些测试，必须两个人一起编程，必须遵守编程规范,。,XP,是把最好的实践经验提取出来，形成了一个崭新的开发方法。,Extreme Programming,什么是,XP,Extreme Programming,极限的含义：,软件开发中的优点发挥到极致,(Kent Beck).,XP,：,给程序员提供了明确的方法，使得程序员尽管面对需求的改变，却能够从容应对，即使着重变化发生在项目的后期，仍然能够编出代码。,XP,核心：,沟通、简明、反馈和勇气,XP,重视沟通，客户、开发人员、管理者共同组成团队。,XP,是一个实践系统,13,个实践,XP方法的贡献,以拥抱变化的思想，协作的团队，简单的规则等为原则的,13,个具体实践,是知名度最高的敏捷开发方法,XP,的,计划/反馈循环,XP,开发工作流,XP,的关键实践,:,编程方法,交付和管理,小组实践,XP,的关键实践,结对编程,测试驱动开发,重构,简单设计,代码集体所有,编码标准,稳定高速的步伐,持续集成,隐喻,现场客户,完整的团队,小规模发布,计划游戏,编程方法,小组实践,交付和管理,交付和管理,交付和管理,1:,完整的团队,(Whole Team),ProductManager/Projectmanager,Coach,Teamlead,Developers,Tracker,Tester,(On-Site)Customers,所有的小组成员应在同一个工作地点工作。,成员中必须有一个用户代表（,On-site User,）,由他,/,她来提出需求，确定开发优先级，把握开发的动向。,通常还设一个教练（,Coach,）角色，来指导,XP,方法的实施及与外部的沟通协调等。,小组每个成员都应围绕用户代表，充分贡献自己的技能。,交付和管理,2:,计划游戏,(Planning Game),增加,/,改变,需求,产生和评估,User Story,发布计划,迭代计划,1,迭代计划,2,迭代计划,n,实施迭代,1,实施迭代,2,实施迭代,n,1.N,个发布,探索阶段,计划阶段,调整阶段,调整开发,速度,/,内容,交付和管理,3:,现场客户,(On-Site Customer),客户是,Team,成员，在开发现场和开发人员一起工作。传统的客户任务一般是讲解需求，运行验收测试，接收发布的系统。,XP,新增加的任务：,(1),写,User Story,(2),评估,User Story,的商业优先级,(3),为每个,User Story,定义验收测试,(4),计划开发内容,(5),调控开发过程,(6),建立商业模型，把隐藏在客户需求下的原则传授给开发人员,(8),程序员分担任务的过程支解了对他们商业模型的理解,(9),参加设计过程,(10),和程序员一起找出,Metaphor,，导引设计方向,(11),在,Metaphor,的帮助下，定义更有效更实际的功能测试，给程序员的设计制定了规范,交付和管理,4:,小规模发布,降低开发风险。,保证客户有足够的依据调控开发过程,(,增加、删除或改变,User Story),。,客户使用发布的系统，可以保证频繁地反馈和交流。,发布过程应该尽可能地自动化、规范化。,不断地发布可用的系统可以告诉客户你在做正确的事情。,低风险,智能化,适应调整,频繁交流,知会客户,频繁发布,经过验证,随着开发的推进，发布越来越频繁。,所有的发布都要经过功能测试。,小规模发布,小组实践,小组实践,1:,持续集成,(Continuous integration),持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现,BUG,。,随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。,“,A Test a day,takes the bugs away,”,-Siemens,失败,通过,时间,功 能 测 试,小组实践,1:,持续集成,(Continuous integration),1,自动化编译质量度量,2,3,自动化测试,持续反馈,团队实践,2:,隐喻,(System Metaphor),“,The system metaphor is a story that everyone-customers,programmers,and managers-,can tell about how the system works.,”,Kent Beck,Team,将,Domain/Sub-Domain Model,，,Design/Sub-Design Model,以及一些关键概念等等抽象化为比喻。通过这些比喻，加强客户和程序员之间的相互理解，消化积累知识，指导设计开发的方向。,例：,Market,发布,/,浏览，价格洽谈，生成和履行合同；,String,，,Tree,，,Package,，,Chartroom,，,Spider,，,Robot,；,电影后期制作,邮递,电影院播放电影。,小组实践,2:,隐喻,(System Metaphor),Metaphor,的形成过程，是客户建立并抽象商业模型和商业概念的过程，是程序员建立并抽象设计模型和设计概念的过程。,Metaphor,使客户和程序员用共通的模型和语言进行交流,“,One Team,one language,”,。,Metaphor,可以帮助减少,“,知识泄露,”,和,“,支解知识,”,。,Metaphor,是设计过程的航标,真正灵活有效的设计是针对商业原则的设计，而不是针对商业原则表现形式的设计，更不是脱离商业需求目的的学术设计。,随着开发的继续，,Team,会找到更好的,Metaphor,。这是知识细化、深化的结果，是,“,持续学习,”,(Continuous learning),的过程；是对商业模型和设计模型的持续重构。,小组实践,3:,编码标准,(Coding standards),编码标准的目的：防止团队被一些无关紧要的愚蠢争论搞得不知所措。,不要预先花费太多时间,目标应该是团队中没有人辨认各自的代码,以团队为单位对某一标准达成协议，然后遵守这一标准,不是事无巨细的规则列表，而是确保代码可交流的指导方针,七个原则,编码标准开始时应很简单，然后根据团队经验逐步进化,创建能够工作的最简单标准，然后逐步发展,只制订适合本团队的,小组实践,4:,集体拥有代码,“,我们,”,的代码，而不是,“,我,”,的代码。,任何人可以改动任何一段代码，但改动后的代码必须通过所有相关的测试。,简单设计，编码标准和结对编程，使阅读和修改,Team,内其他人的代码变得实际可行。,思考：同公司信息安全可能有冲突？,在一定范围内进行集体拥有代码还是可行的,小组实践,5:,稳定高速的步伐,(40-Hour Week),“,每天早晨都感到有活力有激情，每天晚上都感到疲惫而满足。,”,-Kent Beck,8:00 AM Standup Meeting,Pair Up,Tester,自我测试,编码,重构,集成并纳入,CI,验证,5:30PM,结束,测试用例,编程方法,编程方法,1:,测试驱动开发,(TDD),失败,通过,时间,单元测试,100%,通过,设计,先,写,单元测试,重构,运行,单元测试,编程,发现,BUG,集成,先,写,功能测试,User Story,运行,功能测试,编程方法,2:,重构,(Refactoring),减少重复设计，优化设计结构，提高技术上的重用性和可扩展性。,重构和编程前的计划型设计,(Planned Design),结合，使,XP,的简单设计可行有效。,XP,提倡毫不留情的重构,(Refactor mercilessly),。,任何人可以重构任何代码，前提是重构后的代码一定要通过,100%,测试单元测试后才能被,Check-in,。,可以根据需要，将一个迭代的全部目标定为重构。,不要太在意什么是最简单的设计,愿意在最后重构，比知道如何做简单的设计重要得多。,在,Metaphor,指引下的重构，是为商业模型服务的。不要把重构变成不断的盲目精简代码。,编程方法,3:,简单设计,简单设计,Do the simplest thing that could possibly work,；,You arent going to need it,如果没有它和众多惯例规则之间的耦合，,XP,的演化设计就蜕化成,CODE-FIX,。,XP,的演化设计是在,Up-front design,和,Refactoring,之间找到新的平衡。,需求 分析 设计 编码 测试 集成 使用和维护,Planned,Design,XP Design,变化导致的成本增加,软件研发,异动曲线,编程方法,3:,简单设计,标准,(,依重要性,),：通过所有测试，可读性高的代码，避免重复，最少数量的类别或方法。,System Metaphor,给设计提供了指引，加强,Team,对设计的理解；,第一个迭代搭建了基本的系统框架。,以后的迭代过程，是在反馈和编程的基础上做交互式设计，减少了设计的投机性。,迭代过程中的,CRC,卡帮助,Team,交流设计思想，简化了设计文档。,构对设计进行优化。,XP,认为设计非常重要，因此应该是一个持续的事务。我们总是先尝试使用能够工作的最简单的设计，然后随着现实的不断显现来更改它。对简单设计的需求并不是说所有设计都很小，也不表示它们是无足轻重的。它们只不过需要尽可能简单，但是仍能工作。,编程方法,4:,结对编程,(Pair Programming),所有设计决策都牵涉到至少两个人。,至少有两个人熟悉系统的每一部分。,几乎不可能出现两个人同时疏忽测试或其它任务。,改变各对的组合在可以在团队范围内传播知识。,代码总是由至少一人复查。,结对的编程比单独编程更有效。,XP,中最有争议的实践之一,目录,2.1,XP-eXtreme Programing,2,敏捷系列,2.2,SCRUM,1,敏捷开发简介,3,敏捷与,CMM,4,敏捷开发的误区,SCRUM,SCRUM,来源于橄榄球运动，指：,“,在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球。,”,Scrum,提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来的重大变化。,(Ken Schwaber),Scrum,是一种灵活的软件管理过程，它可以帮助驾驭迭代、递增的软件开发过程。,Scrum,于,1995,年提出，并在,2001,年同其他方法论一起组成,“,敏捷联盟（,Agile Alliance,）,”,。,Scrum,这个轻量的过程可以作为包装器，也就是说你可以把,Scrum,与其它灵活的过程框架组合起来。,SCRUM,的过程图,SCRUM,实践,1.Scrum,团队：,5-7,个人的小项目团队，团队的负责人可能担负起,Scrum Master,的角色。,2.Backlog:,急待完成的一系列任务，包括：未细化的产品功能要求、,Bugs,、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。,3.Sprint(,冲刺,):,通常为,30,天的迭代时间，把,Backlog,中的每一项安排在,Sprint,中，由团队估算出所需要的时间（按小时记）。每一次,Sprint,之后，一定要有可以交付使用的功能。,4.Scrum,会议,:,这是与传统方式最大的区别，每天,15-20,分钟的,Scrum,会议，通常在每天的同一时间和同一个房间内举行。,Scrum,团队所有人都参加，也可以有旁听者（但不允许旁听者指手划脚）。在这个,15,分钟的会议上，,Scrum Master,会询问每个成员三个问题,:a),自上次,Scrum,会议后的,1,天里你做了什么？,b),从现在到下次,Scrum,会议的,1,天时间里你准备做什么？,c),你在工作中遇到了哪些困难？每个成员在,Backlog,条目上所花费的时间会被记录到,Spring backlog,中。,Scrum Master,在会上对存在的问题提出即时的解决方案或指导，使团队不断向着目标前进。,Scrum,会议不同于项目会议，对团队来说，它起到了快速简报的作用。,5.,通过,Sprint Backlog,的分析，可以了解,Backlog,的进度，尽早的了解所发生的问题,6.,管理者不在是项目或者团队的,老板,而是帮助团队解决问题的,协调者,或是,助手,。,7.,每一次,Sprint,之后要,review,，团队按照既定的,Sprint Backlog,目标来演示完成的内容。,Scrum,中的,3,、,3,、,3,三种工件,三种会议,三种角色,待开发任务列表,(The Sprint Backlog),待修复缺陷列表,(The defect backlog),进度图、燃尽图,(Brun Down Chart),Product Owner,Scrum Master,团队成员,(Scrum Team,）,迭代计划会议,(Sprint Planning Meeting),每日晨会,(Daily Scrum Meeting),迭代回顾会议,(Sprint Review Meeting),Product Backlog,SPRINT,划分示意,Sprint,会议,根据,Backlog,，制定每次,Sprint,的计划,目录,2,敏捷系列,1,敏捷开发简介,3,敏捷开发的误区,讨论,误区一,:,敏捷是,一个,”,过程,误区二,:,敏捷仅是个软件过程,误区三,:,敏捷是反文档的,误区四,:,为了,敏捷而敏捷,误区五,:,重做就是重构,误区一,:,敏捷是,一个,”,过程,敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。,误区二,:,敏捷仅是个软件过程,敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。,涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：,把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。,把人的能动性调动起来，给动力而不是给压力。,要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。,没有绝对的权威，每个人都有可取之处。,文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题,?,难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。,应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价,(,特别是更新同步文档的代价,),。,因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。,文档不是目的，有效沟通才是目的。,误区三,:,敏捷是反文档的,“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：,Q,：“我们现有的过程很好，不知道怎么用敏捷改进,?”,A,：“既然很好，那就不要用敏捷”。,做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。,误区四,:,为了敏捷而敏捷,重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。,误区五,:,重做就是重构,谢谢,!,提升你的潜力,