敏捷开发流程与方法ppt课件_第1页
敏捷开发流程与方法ppt课件_第2页
敏捷开发流程与方法ppt课件_第3页
敏捷开发流程与方法ppt课件_第4页
敏捷开发流程与方法ppt课件_第5页
已阅读5页,还剩53页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、矫捷开发流程与方法Strictly Private and ConfidentialBGCN交付管理部目录1.1矫捷的来源2矫捷系列1.2矫捷方法体系1矫捷开发简介3 矫捷开发的误区1.3矫捷宣言1.4为什么要矫捷? 矫捷开发的来源上个世纪90年代2001年2004年以后萌芽-产生矫捷方法矫捷方法是从上个世纪90年代开场开展起来的一组方法学的总称,包括极限编程等等。这些方法学之间有一些差别,但是差别不是特别大正规成立矫捷联盟每种方法学的指点人共同起草了矫捷软件开发宣言,总结出方法之间的共同点,最终就是价值,并且用矫捷这个词给这种方法学一个统称开展开场广为流行500强公司中众多公司运用矫捷;如H

2、P,Microsoft,IBM等 什么是矫捷开发?矫捷开发Agile Development是一种以人为中心、迭代、循序渐进的开发方法。子工程特征 - 各个子工程的成果都经过测试 - 具备集成和可运转的特征 - 小工程相互联络 目录1.1矫捷的来源1.2矫捷方法体系1矫捷开发简介1.3矫捷宣言1.4为什么要矫捷?2矫捷系列3 矫捷开发的误区 矫捷方法XP -eXtreme Programing极限编程:思想源自Kent Beck和Ward Cunningham在软件工程中的协作阅历。SCRUM:是一种迭代的增量化过程,用于产品开发或任务管理 。水晶方法Crystal:由Alistair Coc

3、kburn在1990年代末提出。把不同类型的工程采用不同的方法。 FDD特性驱动 Feature Driven Development,由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发,是一套针对中小型软件开发工程的开发方式。它强调的是简化、适用、 易于被开发团队接受,适用于需求经常变动的工程。 DSDM-Dynamic System Development Methodology,它倡导以业务为中心,快速而有效地进展系统开发, 在英国等欧洲国家比较流行。ASD-Adaptive Software Development,由Jim Highsmith在19

4、99年正式提出。ASD强调开发方法的顺应性Adaptive 矫捷开发特点 矫捷开发包括很多方法,例如XP和FDD,同分量级的文档驱动的开发过程相比较,矫捷方法在灵敏性等方面更有吸引力。这个方法的开创人强调了在软件实际过程中的变卦而不是孤立的进展一些实际。 很多方法很难独立的运用。如:测试驱动的开发,结对开发,方案调整周期以及继续改良,不过,后来的结果证明,这些方法都获得了胜利。 运用这些方法并不能保证一定胜利。开发者的阅历和技术仍旧是影响开发结果的最主要要素。对于适宜的人,基于矫捷原那么的开发方法可以产生更好的结果,同时构成一个愉快地、有热情的任务环境目录1.1矫捷的来源1.2矫捷方法体系1矫

5、捷开发简介1.3矫捷宣言1.4为什么要矫捷?2矫捷系列3 矫捷开发的误区 矫捷宣言中心思念:顺应和以人为本客户协作胜过合同谈判呼应变化胜过遵照方案可以任务的软件胜过面面俱到的文档个体和交互胜过过程和工具矫捷规那么最高目的是能继续地、及早地向客户交付软件;拥抱变化;频繁地发布可运转的软件;客户和开发人员在一同任务;以人为本;最重要的衡量开发过程的手段,是可任务的软件;稳定的开发速度;矫捷高效的设计;简单有效;注重Teamwork;积极的调整。 目录1.1矫捷的来源1.2矫捷方法体系1矫捷开发简介1.3矫捷宣言1.4为什么要矫捷?2矫捷系列3 矫捷开发的误区 我们为什么需求矫捷项目为什么失败?软件

6、工程试图解决这些问题:对用户需求理解得不清楚,甚至有错误;用户需求变化;软件很难维护或扩展;在项目后期阶段发现很严重的设计缺陷;软件质量或性能不合格;Test - Build - Release过程的可操作性、可维护性很差;人员流动; 为了规范化开发过程,引进传统工程的概念(瀑布型);为了理解需求,提出原型法;为了提高设计开发的效率和扩展性,提出重用和面向对象等思想;为了让开发过程更灵活,提出了开发框架的概念;为了降低风险,提出了风险评估、成本控制和增量开发等思想; 我们为什么需求矫捷部门: 1) 培育团队协作精神,稳定开发队伍; 2) 提高开发人员的程度; 3) 提高工程胜利率,降低开发本钱

7、,提升软件开发效率工程经理: 1) 更好地和用户沟通,更明晰地了解用户需求; 2) 更充分地运用资源,更科学地调配资源,更准确地掌握开发进度。系统分析设计: 1) 设计更加完善; 2) 更有效地更新知识,得到其他成员更多的尊重。程序员: 1) 学习系统设计和工程管理; 2) 提高学习和任务效率,遭到注重,减少加班时间,任务更高效 谁在用矫捷Fortune 500 公司中胜利运用XP的公司包括Ford,Daimler-Chrysler,First Union National Bank,IBM,HP等等。通讯业NS,Ericsson, Alcatel等都号称在转向矫捷更多是小规模开发队伍小规模开

8、发队伍 小规模工程越来越多的公司开场运用矫捷开发过程矫捷开发胜利的要素知识和技艺文化和气氛自组织团队开放的心态 目录2.1XP -eXtreme Programing2矫捷系列2.2SCRUM1矫捷开发简介3 矫捷开发的误区 矫捷实际在矫捷的两个门派:XP、Scrum中,整理归纳了很多可以用于协助软件开发的实际,后面统称为矫捷实际。 什么是XPXP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing re

9、quirements. - Kent Beck.Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries于2000年创建XP是软件开发过程中的纪律,它规定他:必需在编程前些测试,必需两个人一同编程,必需遵守编程规范。XP是把最好的实际阅历提取出来,构成了一个崭新的开发方法。Extreme Programming 什么是XPExtreme Programming极限的含义:软件开发中的优点发扬到极致(Kent Beck).XP:给程序员提供了明确的方法,使得程序员虽然面对需求的改动,却可以从容应对,即使着重变化发生在工程的后期,依然可以编出代

10、码。XP中心:沟通、简明、反响和勇气 XP注重沟通,客户、开发人员、管理者共同组成团队。XP是一个实际系统13个实际XP方法的奉献以拥抱变化的思想,协作的团队,简单的规那么等为原那么的13个详细实际是知名度最高的矫捷开发方法 XP的方案/反响循环 XP开发任务流 XP的关键实际:编程方法交付和管理小组实际 XP的关键实际结对编程测试驱动开发重构简单设计代码集体一切编码规范稳定高速的步伐继续集成隐喻现场客户完好的团队小规模发布方案游戏编程方法小组实际交付和管理交付和管理 交付和管理1:完好的团队(Whole Team)ProductManager/ProjectmanagerCoachTeaml

11、eadDevelopersTrackerTester(On-Site) Customers一切的小组成员应在同一个任务地点任务。成员中必需有一个用户代表On-site User,由他/她来提出需求,确定开发优先级,把握开发的动向。通常还设一个教练Coach角色,来指点XP方法的实施及与外部的沟通协调等。小组每个成员都应围绕用户代表,充分奉献本人的技艺。 交付和管理2: 方案游戏(Planning Game)添加/改动需求产生和评价User Story发布方案迭代方案1迭代方案2迭代方案n实施迭代1实施迭代2实施迭代n1.N个发布探求阶段方案阶段调整阶段调整开发速度 / 内容 交付和管理3:现场

12、客户(On-Site Customer) 客户是Team成员,在开发现场和开发人员一同任务。 传统的客户义务普通是讲解需求,运转验收测试,接纳发布的系统。XP新添加的义务: (1) 写User Story (2) 评价User Story的商业优先级 (3) 为每个User Story定义验收测试 (4) 方案开发内容 (5) 调控开发过程 (6) 建立商业模型,把隐藏在客户需求下的原那么教授给开发人员 (8) 程序员分担义务的过程支解了对他们商业模型的了解 (9) 参与设计过程 (10)和程序员一同找出Metaphor,导引设计方向 (11)在Metaphor的协助下,定义更有效更实践的功能

13、测试,给程序员的设计制定了规范 交付和管理4:小规模发布降低开发风险。 保证客户有足够的根据调控开发过程(添加、删除或改动User Story)。客户运用发布的系统,可以保证频繁地反响和交流。 发布过程应该尽能够地自动化、规范化。不断地发布可用的系统可以通知客户他在做正确的事情。低风险智能化顺应调整频繁交流知会客户频繁发布经过验证 随着开发的推进,发布越来越频繁。 一切的发布都要经过功能测试。小规模发布小组实际 小组实际1:继续集成(Continuous integration)继续集成指不断地把完成的功能模块整合在一同。目的在于不断获得客户反响以及尽早发现BUG。随时整合,越频繁越好;集成及

14、测试过程的自动化程度越高越好。“A Test a day ,takes the bugs away-Siemens失败经过时间功 能 测 试 小组实际1:继续集成(Continuous integration)1自动化编译质量度量23自动化测试继续反响 团队实际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/Su

15、b-Domain Model,Design/Sub-Design Model以及一些关键概念等等笼统化为比喻。经过这些比喻,加强客户和程序员之间的相互了解,消化积累知识,指点设计开发的方向。 例:Market 发布/阅读,价钱洽谈,生成和履行合同;String,Tree,Package,Chartroom,Spider,Robot ;电影后期制造 邮递 电影院播放电影。 小组实际2:隐喻(System Metaphor)Metaphor的构成过程,是客户建立并笼统商业模型和商业概念的过程,是程序员建立并笼统设计模型和设计概念的过程。Metaphor使客户和程序员用共通的模型和言语进展交流 “O

16、ne Team, one language。 Metaphor可以协助减少“知识泄露和“支解知识。Metaphor是设计过程的航标 真正灵敏有效的设计是针对商业原那么的设计,而不是针对商业原那么表现方式的设计,更不是脱离商业需求目的的学术设计。随着开发的继续,Team会找到更好的Metaphor。这是知识细化、深化的结果,是“继续学习(Continuous learning)的过程;是对商业模型和设计模型的继续重构。 小组实际3:编码规范(Coding standards)编码规范的目的: 防止团队被一些无关紧要的愚笨争论搞得不知所措。不要预先破费太多时间目的应该是团队中没有人识别各自的代码以

17、团队为单位对某一规范达成协议,然后遵守这一规范不是事无巨细的规那么列表,而是确保代码可交流的指点方针七个原那么编码规范开场时应很简单,然后根据团队阅历逐渐进化创建可以任务的最简单规范,然后逐渐开展只制定适宜本团队的 小组实际4:集体拥有代码“我们的代码,而不是“我的代码。任何人可以改动任何一段代码,但改动后的代码必需经过一切相关的测试。简单设计,编码规范和结对编程,使阅读和修正Team内其他人的代码变得实践可行。思索:同公司信息平安能够有冲突?在一定范围内进展集体拥有代码还是可行的 小组实际5:稳定高速的步伐(40-Hour Week)“每天早晨都感到有活力有热情,每天晚上都感到疲惫而满足。

18、- Kent Beck 8:00 AM Standup MeetingPair UpTester自我测试编码重构集成并纳入CI 验证5:30PM 终了测试用例编程方法 编程方法1:测试驱动开发(TDD)失败经过时间单元测试 100% 经过设计先写单元测试重构运转单元测试编程发现BUG集成先写功能测试User Story运转功能测试 编程方法2:重构(Refactoring )减少反复设计,优化设计构造,提高技术上的重用性和可扩展性。重构和编程前的方案型设计(Planned Design)结合,使XP的简单设计可行有效。XP提倡毫不留情的重构(Refactor mercilessly)。任何人可

19、以重构任何代码,前提是重构后的代码一定要经过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 desi

20、gn和Refactoring之间找到新的平衡。需求 分析 设计 编码 测试 集成 运用和维护PlannedDesignXP Design变化导致的本钱添加软件研发异动曲线 编程方法3:简单设计 规范(依重要性):经过一切测试,可读性高的代码,防止反复,最少数量的类别或方法。System Metaphor给设计提供了指引,加强Team对设计的了解;第一个迭代搭建了根本的系统框架。以后的迭代过程,是在反响和编程的根底上做交互式设计,减少了设计的投机性。迭代过程中的CRC卡协助Team交流设计思想,简化了设计文档。构对设计进展优化。 XP 以为设计非常重要,因此应该是一个继续的事务。我们总是先尝试运

21、用可以任务的最简单的设计,然后随着现实的不断显现来更改它。 对简单设计的需求并不是说一切设计都很小,也不表示它们是无足轻重的。它们只不过需求尽能够简单,但是仍能任务。 编程方法4: 结对编程(Pair Programming)一切设计决策都牵涉到至少两个人。至少有两个人熟习系统的每一部分。几乎不能够出现两个人同时忽略测试或其它义务。改动各对的组合在可以在团队范围内传播知识。代码总是由至少一人复查。结对的编程比单独编程更有效。 XP中最有争议的实际之一 目录2.1XP -eXtreme Programing2矫捷系列2.2SCRUM1矫捷开发简介3矫捷与CMM4 矫捷开发的误区 SCRUMSCR

22、UM来源于橄榄球运动,指:“在橄榄球竞赛中,双方前锋站在一同严密相连,当球在他们之间投掷时他们奋力争球。 Scrum提供了一种阅历方法,它使得团队成员可以独立地,集中地在发明性的环境下任务。它发现了软件工程的社会意义。这一过程是迅速,有顺应性,自组织的,它代表了从顺序开发过程以来的艰苦变化。(Ken Schwaber)Scrum是一种灵敏的软件管理过程,它可以协助驾驭迭代、递增的软件开发过程。Scrum于1995年提出,并在2001年同其他方法论一同组成“矫捷联盟Agile Alliance 。Scrum这个轻量的过程可以作为包装器,也就是说他可以把Scrum与其它灵敏的过程框架组合起来。 S

23、CRUM的过程图 SCRUM实际 1. Scrum团队:5-7个人的小工程团队, 团队的担任人能够担负起Scrum Master的角色。2. Backlog: 急待完成的一系列义务,包括:未细化的产品功能要求、Bugs、缺陷、用户提出的改良、具竞争力的功能及技术晋级等,按优先级定义出来,这些义务能够不是完好的,甚至能够随时会更改或添加。3. Sprint(冲刺): 通常为30天的迭代时间,把Backlog中的每一项安排在Sprint中,由团队估算出所需求的时间按小时记。 每一次Sprint之后,一定要有可以交付运用的功能。4. Scrum会议: 这是与传统方式最大的区别,每天15-20分钟的S

24、crum会议,通常在每天的同一时间和同一个房间内举行。Scrum团队一切人都参与,也可以有旁听者但不允许旁听者指手划脚。 在这个15分钟的会议上,Scrum Master会讯问每个成员三个问题:a) 自上次Scrum会议后的1天里他做了什么?b) 从如今到下次Scrum会议的1天时间里他预备做什么?c) 他在任务中遇到了哪些困难?每个成员在Backlog条目上所破费的时间会被记录到Spring backlog中。 Scrum Master在会上对存在的问题提出即时的处理方案或指点,使团队不断向着目的前进。Scrum会议不同于工程会议,对团队来说,它起到了快速简报的作用。5. 经过Sprint

25、Backlog的分析,可以了解Backlog的进度,尽早的了解所发生的问题6. 管理者不在是工程或者团队的老板, 而是协助团队处理问题的协调者或是助手。7. 每一次Sprint之后要review,团队按照既定的Sprint Backlog目的来演示完成的内容。 Scrum中的3、3、3三种工件三种会议三种角色待开发义务列表(The Sprint Backlog)待修复缺陷列表(The defect backlog)进度图、燃尽图(Brun Down Chart)Product OwnerScrum Master团队成员(Scrum Team迭代方案会议(Sprint Planning Meeting)每日晨会(Daily Scrum Meeting)迭代回想会议(Sprint Review Meeting) Product Backlog SPRINT划分表示 Sprint会议根据Backlog,制定每次Sprint的方案 目录2矫捷系列1矫捷开发简介3 矫捷开发的误区讨论误区一:矫捷是一个过程误区二:矫捷仅是个软件过程误区三:矫捷是反文档的 误区四:为了矫捷而矫捷误区五:重做就是重构误区一:矫捷是一个过程矫捷不是一个过程,是一类过程的统称,它们有一个共性,就是符合矫捷价值观,遵照矫捷的原那么。误区二:矫捷仅是个软件过程矫捷相对以前的软件工

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论