敏捷开发培训Agile Development.pptx
《敏捷开发培训Agile Development.pptx》由会员分享,可在线阅读,更多相关《敏捷开发培训Agile Development.pptx(60页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、2023/3/171Content Agile Development介绍RUPXPScrum第1页/共60页2023/3/172Agile Process-敏捷的开发流程Agile Process(敏捷的开发流程)是一种软件开发流程的泛称,几项共通的特性:1.客户与开发人员形成密切合作的团队,因为客户无法于初期定义完整的规格,而开发人员于开发过程中也常常无法知悉外在环境或业务的变动,所以需要两者密切合作方能开发适用的软件。2.项目最终的目标是可执行的程序,因此所有的中间产品必须经过审慎评估,确认有助于最终目标,才需要制作中间产品。3.采用 Iterative 与 Incremental 方式
2、分阶段进行,密集 review 是否符合需求。4.流程可以简单,但规划与执行必须严谨。5.强调团队合作,赋予高度的责任,团队有自主权得以因应变化做调整第2页/共60页2023/3/173Agile Development敏捷开发是一种以人为核心、迭代、循序渐进的开发方法 在敏捷开发中,项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。第3页/共60页2023/3/174敏捷开发核心价值(Core Value)Individuals and interactions over processes and tools 个人和交流重于过程和工具Working soft
3、ware over comprehensive documentation 正在运行的软件本身重于复杂的文档Customer collaboration over contract negotiation 与客户的沟通和交流重于使用合同约束客户Responding to change over following a plan对变化的快速响应重于跟随计划第4页/共60页2023/3/175敏捷开发原则(Principles)1.最高目标是通过快速的和经常的发布软件满足客户的需要2.提交软件的周期为几个星期到几个月3.产生正确的软件是衡量进度的首要标准4.主动接受需求的改变而不是拒绝5.商务人员
4、和开发人员工作在一起6.个人必须有动力,要创造环境支持他们的要求,信任他们7.最有效的交流方法是面对面的交流8.最好的结构,需求和设计来自于自组织的团队(self-organizing team),允许任何人提出想法和建议9.持续改进设计和编码10.鼓励正常工作,减少长时间加班11.保持简单,减少不必要的部分,认识到简单的设计比复杂的设计更难(simple design is harder to produce)12.定期调整过程,获得更高效率第5页/共60页2023/3/176敏捷开发的设计原则 SRP单一职责原则SRP:Single Responsibility Principle OCP
5、开放封闭原则OCP:OpenClose Principle LSPLiskov替换原则LSP:Liskov Substitution Principle DIP依赖倒置原则DIP:Dependency Invertion Principle ISP接口隔离原则ISP:Interface Separate Principle 第6页/共60页2023/3/177敏捷开发-迭代计划最新版本验收测试发布计划迭代计划开发项目周期第7页/共60页2023/3/178敏捷开发-迭代计划第8页/共60页2023/3/179名词解释故事故事故事 是客户想要系统做的事情,适合在一至两个迭代内完成,并且是可测试的
6、,他不一定是商业价值的直接体现。迭代迭代迭代 是一个周期在2-4周,能够完成当前团队所能实现的,最具商业价值的功能,并可以提供一个可工作的小版本供发布。VelocityVelocityVelocity 翻译为项目周转时间。代表团队在给定周期内能够完成多少商业价值,以便用于衡量将来该团队能够提供的商业价值。也即昨天的天气。第9页/共60页2023/3/1710名词解释优先级优先级优先级 主要考虑商业价值,同时兼顾市场风险、商业风险、技术风险等因素在内的一个衡量数字,优先级越高通常意味着其商业价值越高风险系数风险系数 综合商业环境、项目资源、技术以及项目环境等等因素在内的一个衡量数字,它是优先级的
7、重要衡量指标之一。它通常出现在故事中。风险系数较大意味着优先级也较大。负载因子负载因子 是综合项目成员的技术能力、技能集、精神状态等等因素,对于团队成员的一个负载系数。第10页/共60页2023/3/1711名词解释理想时间理想时间理想时间 排除一切可能的外界干扰,同时排除自身的精神状态,职业态度等等因素,完成某项工作所需要的时间。实际时间实际时间实际时间 理想时间乘上负载因子任务任务 分配到项目成员,从故事切分的出来。通常任务时间不应该超过10个实际工作日。第11页/共60页2023/3/17121.RUP2.XP3.Scrum第12页/共60页2023/3/1713RUP-Rational
8、 Unify ProcessRUP 为 IBM Rational 提出的软件开发流程内容含盖 Business modeling,Requirement Modeling,Logical Design,Implementation,Testing,Deployment 等软件开发生命周期的直接工作与 Project Management,Change&Configuration Management,Environment support 等支持性工作。第13页/共60页2023/3/1714RUP 的主要精神 1.项目进行采用 Iterative 程序分阶段渐进地完成项目功能;2.广泛使用
9、Visual Modeling 于商业需求分析、系统分析与系统设计;3.强调架构设计;4.对每项工作所需要的技术、工具、做法、模板、检查项目均有详细的定义,架构完备且具有可调整的弹性。第14页/共60页2023/3/17151.RUP2.XP3.Scrum第15页/共60页2023/3/1716XP-eXtreme Programming极限编程,最轻量级的开发流程,其最主要的精神是在客户有系统需求时,给予及时满意的可执行程序,所以最适合需求快速变动的项目 强调客户所要的是 workable 的执行码,所以把与撰写程序无关的工作降至最低,并要求客户与开发人员最好以 side-by-side 的
10、方式一起工作 第16页/共60页2023/3/1717XP强调4个因素交流(communication),XP要求程序员之间以及和用户之间有大量而迅速的交流简单(simplicity),XP要求设计和实现简单和干净反馈(feedback)通过测试得到反馈,尽快提交软件并根据反馈修改勇气(courage)。勇敢的面对需求和技术上的变化第17页/共60页2023/3/1718XP 开发流程 开发人员随时可以和客户进行有效沟通,撰写 user stories 以确认需求。简易快速的系统设计,撰写独立的验证程序以解决特殊困难的问题,找出算法即可丢弃验证程序。规划多次小型阶段的项目计划,以最快速度完成每
11、一阶段的程序交付客户,客户负责 Acceptance tests;Coding 前必须完成 Unit Test 与 Acceptance tests 程序,所有模块整合前都须经过 Unit Tests;开发人员必须快速响应 Bug 与需求变更;要求二人一组使用一台计算机设计程序,当一人 coding 时,另一人负责思考与设计;程序必须符合程序规范,并常做程序的重构(Refactoring)。第18页/共60页2023/3/1719XP原则和实践-Planning-user storiesuser stories User stories类似use case,描述用户所见的系统功能,但避免使用大
12、量的文档,user stories由用户编写(不仅限于描述用户界面)。User stories使用用户的语言编写,不使用技术性的语言,每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估,也用于产生验收测试(acceptance test),必须使用可以自动进行的验收测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度,user stories并不会确定需求的每个细节,它只是用来简单的描述系统功能,供开发人员进行估计开发进度,在开发过程中开发人员和用户会不断的交流以讨论细 节问题。User stor
13、y应该专注于功能,不应该过分注重用户界面等细节。一般一个user storiy在1-3周的时间完成,如果估计超过3周,说明user story太大了,需要细分.第19页/共60页2023/3/1720XP原则和实践-Planning-release planrelease plan 召开一个 release plan会议,产生release plan。Release plan将用于指定每个iteration的计划。开发人员对每个user story估计开发时间(在不被打断,无其他工作情况下的开发时间,包括测试),用户对user stories给出优先级,release plan会议并不制订每个
14、iteration的计划。Release plan要用户,开发人员和管理者都同意,在完成功能范围(scope),使用资源(resource),时间(time)和质量(quality)上达 成一致(一般质量是不能改变的)第20页/共60页2023/3/1721XP原则和实践-Planning-small releasesmall releaseoften and small release是XP的一个原则,每个release完成一些用户有意义的功能集合,尽快的提交给用户以获得反馈,及时调整,提交的越晚,调整越困难。第21页/共60页2023/3/1722XP原则和实践-Planning-proj
15、ect velocityproject velocity 团队在开发过程中要收集数据,以便于对自己的开发速度进行评估,用于以后的releazse plan第22页/共60页2023/3/1723XP原则和实践-Planning-iterationiteration 每个small release的周期称为iteration,每个iteration约为1-3周,在一个项目中保持每个iteration的时间相等,不要超前制定计 划,每个iteration的计划在iteration的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要 注重每个iteration
16、的时间限制,当团队觉得不能按时完成iteration时,召开一次iteration plan会议,重新评估,减少一些user stories。第23页/共60页2023/3/1724XP原则和实践-Planning-iteration planiteration plan 在每个 iteration开始的时候召开会议,从release plan中选择还没有实现的用户最迫切需要的user stories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实践调整团 队速度。User stories和失败的测试被分解成progra
17、mming task,task使用技术语言编写,作为iteration plan的详细描述。程序员主动领取task并估计完成时间,每个task应该在1-3天内完成,超过3天的task应该被细分。如果整个团队需要的时间 多于或少于规定的iteration时间,调整user stories。第24页/共60页2023/3/1725XP原则和实践-Planning-move people aroundmove people around 不要使每个开发人员局限于一项工作,不要使某项工作依赖于一个开发人员,增加知识共享,减少信息孤岛,多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是
18、效率最高的,鼓励开发人员在不同iteration中开发不同的模块。第25页/共60页2023/3/1726XP原则和实践-Planning-stand-up meetingstand-up meeting 每天工作 开始之前,开5-10分钟的stand-up会议(站立会议),站立的目的是为了强迫节省时间,会议的目的是交流,提出存在的问题,但不要在会议上解决问 题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决,这个少数人参加的会议如果涉及到代码,可以在计算机前讨论。第26页/共60页2023/3/1727XP原则和实践-Planning-fix
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷开发培训Agile Development 敏捷 开发 培训 Agile
限制150内