敏捷开发流程与方法PPT文档格式.ppt

上传人:b****1 文档编号:14646815 上传时间:2022-10-23 格式:PPT 页数:58 大小:3.08MB
下载 相关 举报
敏捷开发流程与方法PPT文档格式.ppt_第1页
第1页 / 共58页
敏捷开发流程与方法PPT文档格式.ppt_第2页
第2页 / 共58页
敏捷开发流程与方法PPT文档格式.ppt_第3页
第3页 / 共58页
敏捷开发流程与方法PPT文档格式.ppt_第4页
第4页 / 共58页
敏捷开发流程与方法PPT文档格式.ppt_第5页
第5页 / 共58页
点击查看更多>>
下载资源
资源描述

敏捷开发流程与方法PPT文档格式.ppt

《敏捷开发流程与方法PPT文档格式.ppt》由会员分享,可在线阅读,更多相关《敏捷开发流程与方法PPT文档格式.ppt(58页珍藏版)》请在冰豆网上搜索。

敏捷开发流程与方法PPT文档格式.ppt

由AlistairCockburn在1990年代末提出。

把不同类型的项目采用不同的方法。

FDD特性驱动FeatureDrivenDevelopment,由PeterCoad、JeffdeLuca、EricLefebvre共同开发,是一套针对中小型软件开发项目的开发模式。

它强调的是简化、实用、易于被开发团队接受,适用于需求经常变动的项目。

DSDM-DynamicSystemDevelopmentMethodology,它倡导以业务为核心,快速而有效地进行系统开发,在英国等欧洲国家比较流行。

ASD-AdaptiveSoftwareDevelopment,由JimHighsmith在1999年正式提出。

ASD强调开发方法的适应性(Adaptive),敏捷开发特点,敏捷开发包括很多方法,例如XP和FDD,同重量级的文档驱动的开发过程相比较,敏捷方法在灵活性等方面更有吸引力。

这个方法的创始人强调了在软件实践过程中的变更而不是孤立的进行一些实践。

很多方法很难独立的使用。

如:

测试驱动的开发,结对开发,计划调整周期以及持续改进,不过,后来的结果证实,这些方法都取得了成功。

使用这些方法并不能保证一定成功。

开发者的经验和技术仍旧是影响开发结果的最主要因素。

对于合适的人,基于敏捷原则的开发方法可以产生更好的结果,同时形成一个愉快地、有激情的工作环境,目录,1.1,敏捷的起源,1.2,敏捷方法体系,1,敏捷开发简介,1.3,敏捷宣言,1.4,为什么要敏捷?

2,敏捷系列,3,敏捷开发的误区,敏捷宣言,核心理念:

适应和以人为本,客户合作胜过合同谈判,响应变化胜过遵循计划,可以工作的软件胜过面面俱到的文档,个体和交互胜过过程和工具,敏捷规则,最高目标是能持续地、及早地向客户交付软件;

拥抱变化;

频繁地发布可运行的软件;

客户和开发人员在一起工作;

以人为本;

最重要的衡量开发过程的手段,是可工作的软件;

稳定的开发速度;

敏捷高效的设计;

简单有效;

重视Teamwork;

积极的调整。

2,敏捷系列,3,敏捷开发的误区,我们为什么需要敏捷,我们为什么需要敏捷,部门:

1)培养团队合作精神,稳定开发队伍;

2)提高开发人员的水平;

3)提高项目成功率,降低开发成本,提升软件开发效率项目经理:

1)更好地和用户沟通,更清晰地理解用户需求;

2)更充分地使用资源,更科学地调配资源,更精确地掌握开发进度。

系统分析设计:

1)设计更加完善;

2)更有效地更新知识,得到其他成员更多的尊重。

程序员:

1)学习系统设计和项目管理;

2)提高学习和工作效率,受到重视,减少加班时间,工作更高效,谁在用敏捷,Fortune500公司中成功应用XP的公司包括Ford,Daimler-Chrysler,FirstUnionNationalBank,IBM,HP等等。

通信业NS,Ericsson,Alcatel等都号称在转向敏捷更多是小规模开发队伍(小规模开发队伍小规模项目)越来越多的公司开始使用敏捷开发过程,敏捷开发成功的因素,知识和技能,文化和氛围,自组织团队,开放的心态,目录,2.1,XP-eXtremePrograming,2,敏捷系列,2.2,SCRUM,1,敏捷开发简介,3,敏捷开发的误区,敏捷实践,在敏捷的两个门派:

XP、Scrum中,整理归纳了很多可以用于协助软件开发的实践,后面统称为敏捷实践。

什么是XP,XPisalightweightmethodologyforsmalltomediumsizedteamsdevelopingsoftwareinthefaceofvagueorrapidlychangingrequirements.-KentBeck.KentBeck,WardCunningham,MartinFowler,RonJeffries于2000年创立XP是软件开发过程中的纪律,它规定你:

必须在编程前些测试,必须两个人一起编程,必须遵守编程规范。

XP是把最好的实践经验提取出来,形成了一个崭新的开发方法。

什么是XP,极限的含义:

软件开发中的优点发挥到极致(KentBeck).XP:

给程序员提供了明确的方法,使得程序员尽管面对需求的改变,却能够从容应对,即使着重变化发生在项目的后期,仍然能够编出代码。

XP核心:

沟通、简明、反馈和勇气XP重视沟通,客户、开发人员、管理者共同组成团队。

XP是一个实践系统13个实践XP方法的贡献以拥抱变化的思想,协作的团队,简单的规则等为原则的13个具体实践是知名度最高的敏捷开发方法,XP的计划/反馈循环,XP开发工作流,XP的关键实践:

编程方法,交付和管理,小组实践,XP的关键实践,结对编程,测试驱动开发,重构,简单设计,代码集体所有,编码标准,稳定高速的步伐,持续集成,隐喻,现场客户,完整的团队,小规模发布,计划游戏,编程方法,小组实践,交付和管理,交付和管理,交付和管理1:

完整的团队(WholeTeam),ProductManager/ProjectmanagerCoachTeamleadDevelopersTrackerTester(On-Site)Customers,所有的小组成员应在同一个工作地点工作。

成员中必须有一个用户代表(On-siteUser),由他/她来提出需求,确定开发优先级,把握开发的动向。

通常还设一个教练(Coach)角色,来指导XP方法的实施及与外部的沟通协调等。

小组每个成员都应围绕用户代表,充分贡献自己的技能。

交付和管理2:

计划游戏(PlanningGame),交付和管理3:

现场客户(On-SiteCustomer),客户是Team成员,在开发现场和开发人员一起工作。

传统的客户任务一般是讲解需求,运行验收测试,接收发布的系统。

XP新增加的任务:

(1)写UserStory

(2)评估UserStory的商业优先级(3)为每个UserStory定义验收测试(4)计划开发内容(5)调控开发过程(6)建立商业模型,把隐藏在客户需求下的原则传授给开发人员(8)程序员分担任务的过程支解了对他们商业模型的理解(9)参加设计过程(10)和程序员一起找出Metaphor,导引设计方向(11)在Metaphor的帮助下,定义更有效更实际的功能测试,给程序员的设计制定了规范,交付和管理4:

小规模发布,降低开发风险。

保证客户有足够的依据调控开发过程(增加、删除或改变UserStory)。

客户使用发布的系统,可以保证频繁地反馈和交流。

发布过程应该尽可能地自动化、规范化。

不断地发布可用的系统可以告诉客户你在做正确的事情。

低风险,智能化,适应调整,频繁交流,知会客户,频繁发布,经过验证,随着开发的推进,发布越来越频繁。

所有的发布都要经过功能测试。

小规模发布,小组实践,小组实践1:

持续集成(Continuousintegration),持续集成指不断地把完成的功能模块整合在一起。

目的在于不断获得客户反馈以及尽早发现BUG。

随时整合,越频繁越好;

集成及测试过程的自动化程度越高越好。

“ATestaday,takesthebugsaway”-Siemens,小组实践1:

持续集成(Continuousintegration),1,自动化编译质量度量,2,3,自动化测试,持续反馈,团队实践2:

隐喻(SystemMetaphor),“Thesystemmetaphorisastorythateveryone-customers,programmers,andmanagers-cantellabouthowthesystemworks.”KentBeckTeam将Domain/Sub-DomainModel,Design/Sub-DesignModel以及一些关键概念等等抽象化为比喻。

通过这些比喻,加强客户和程序员之间的相互理解,消化积累知识,指导设计开发的方向。

例:

Market发布/浏览,价格洽谈,生成和履行合同;

String,Tree,Package,Chartroom,Spider,Robot;

电影后期制作邮递电影院播放电影。

小组实践2:

隐喻(SystemMetaphor),Metaphor的形成过程,是客户建立并抽象商业模型和商业概念的过程,是程序员建立并抽象设计模型和设计概念的过程。

Metaphor使客户和程序员用共通的模型和语言进行交流“OneTeam,onelanguage”。

Metaphor可以帮助减少“知识泄露”和“支解知识”。

Metaphor是设计过程的航标真正灵活有效的设计是针对商业原则的设计,而不是针对商业原则表现形式的设计,更不是脱离商业需求目的的学术设计。

随着开发的继续,Team会找到更好的Metaphor。

这是知识细化、深化的结果,是“持续学习”(Continuouslearning)的过程;

是对商业模型和设计模型的持续重构。

小组实践3:

编码标准(Codingstandards),编码标准的目的:

防止团队被一些无关紧要的愚蠢争论搞得不知所措。

不要预先花费太多时间,目标应该是团队中没有人辨认各自的代码,以团队为单位对某一标准达成协议,然后遵守这一标准,不是事无巨细的规则列表,而是确保代码可交流的指导方针,七个原则,编码标准开始时应很简单,然后根据团队经验逐步进化,创建能够工作的最简单标准,然后逐步发展,只制订适合本团队的,小组实践4:

集体拥有代码,“我们”的代码,而不是“我”的代码。

任何人可以改动任何一段代码,但改动后的代码必须通过所有相关的测试。

简单设计,编码标准和结对编程,使阅读和修改Team内其他人的代码变得实际可行。

思考:

同公司信息安全可能有冲突?

在一定范围内进行集体拥有代码还是可行的,小组实践5:

稳定高速的步伐(40-HourWeek),“每天早晨都感到有活力有激情,每天晚上都感到疲惫而满足。

”-KentBeck,编程方法,编程方法1:

测试驱动开发(TDD),编程方法2:

重构(Refactoring),减少重复设计,优化设计结构,提高技术上的重用性和可扩展性。

重构和编程前的计划型设计(PlannedDesign)结合,使XP的简单设计可行有效。

XP提倡毫不留情的重构(Refactormercilessly)。

任何人可以重构任何代码,前提是重构后的代码一定要通过100%测试单元测试后才能被Check-in。

可以根据需要,将一个迭代的全部目标定为重构。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工程科技 > 电力水利

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1