《精编》敏捷开发培训

《《精编》敏捷开发培训》由会员分享，可在线阅读，更多相关《《精编》敏捷开发培训（60页珍藏版）》请在金锄头文库上搜索。

1、2020 5 20 1 AgileDevelopment敏捷开发 JackDing jack w ding 09 28 2010 2020 5 20 2 Content AgileDevelopment介绍RUPXPScrum 2020 5 20 3 AgileProcess 敏捷的开发流程 AgileProcess 敏捷的开发流程 是一种软件开发流程的泛称 几项共通的特性 客户与开发人员形成密切合作的团队 因为客户无法于初期定义完整的规格 而开发人员于开发过程中也常常无法知悉外在环境或业务的变动 所以需要两者密切合作方能开发适用的软件 项目最终的目标是可执行的程序 因此所有的中间产品必须经过

2、审慎评估 确认有助于最终目标 才需要制作中间产品 采用Iterative与Incremental方式分阶段进行 密集review是否符合需求 流程可以简单 但规划与执行必须严谨 强调团队合作 赋予高度的责任 团队有自主权得以因应变化做调整 2020 5 20 4 AgileDevelopment 敏捷开发是一种以人为核心 迭代 循序渐进的开发方法在敏捷开发中 项目的构建被切分成多个子项目 各个子项目的成果都经过测试 具备集成和可运行的特征 2020 5 20 5 敏捷开发核心价值 CoreValue Individualsandinteractionsoverprocessesandtools

3、个人和交流重于过程和工具Workingsoftwareovercomprehensivedocumentation正在运行的软件本身重于复杂的文档Customercollaborationovercontractnegotiation与客户的沟通和交流重于使用合同约束客户Respondingtochangeoverfollowingaplan对变化的快速响应重于跟随计划 2020 5 20 6 敏捷开发原则 Principles 最高目标是通过快速的和经常的发布软件满足客户的需要提交软件的周期为几个星期到几个月产生正确的软件是衡量进度的首要标准主动接受需求的改变而不是拒绝商务人员和开发人员工作

4、在一起个人必须有动力 要创造环境支持他们的要求 信任他们最有效的交流方法是面对面的交流最好的结构 需求和设计来自于自组织的团队 self organizingteam 允许任何人提出想法和建议持续改进设计和编码鼓励正常工作 减少长时间加班保持简单 减少不必要的部分 认识到简单的设计比复杂的设计更难 simpledesignishardertoproduce 定期调整过程 获得更高效率 2020 5 20 7 敏捷开发的设计原则 SRP单一职责原则SRP SingleResponsibilityPrincipleOCP开放封闭原则OCP Open ClosePrincipleLSPLiskov替

5、换原则LSP LiskovSubstitutionPrincipleDIP依赖倒置原则DIP DependencyInvertionPrincipleISP接口隔离原则ISP InterfaceSeparatePrinciple 2020 5 20 8 敏捷开发 迭代计划 最新版本 验收测试 发布计划 迭代计划 开发 项目周期 2020 5 20 9 敏捷开发 迭代计划 2020 5 20 10 名词解释 2020 5 20 11 名词解释 2020 5 20 12 名词解释 2020 5 20 13 1 RUP 2 XP 3 Scrum 2020 5 20 14 RUP RationalUn

6、ifyProcess RUP为IBMRational提出的软件开发流程内容含盖Businessmodeling RequirementModeling LogicalDesign Implementation Testing Deployment等软件开发生命周期的直接工作与ProjectManagement Change ConfigurationManagement Environmentsupport等支持性工作 2020 5 20 15 RUP的主要精神 项目进行采用Iterative程序分阶段渐进地完成项目功能 广泛使用VisualModeling于商业需求分析 系统分析与系统设计

7、强调架构设计 对每项工作所需要的技术 工具 做法 模板 检查项目均有详细的定义 架构完备且具有可调整的弹性 2020 5 20 16 1 RUP 2 XP 3 Scrum 2020 5 20 17 XP eXtremeProgramming 极限编程 最轻量级的开发流程 其最主要的精神是 在客户有系统需求时 给予及时满意的可执行程序 所以最适合需求快速变动的项目强调客户所要的是workable的执行码 所以把与撰写程序无关的工作降至最低 并要求客户与开发人员最好以side by side的方式一起工作 2020 5 20 18 XP强调4个因素 交流 communication XP要求程序员

8、之间以及和用户之间有大量而迅速的交流简单 simplicity XP要求设计和实现简单和干净反馈 feedback 通过测试得到反馈 尽快提交软件并根据反馈修改勇气 courage 勇敢的面对需求和技术上的变化 2020 5 20 19 XP开发流程 开发人员随时可以和客户进行有效沟通 撰写userstories以确认需求 简易快速的系统设计 撰写独立的验证程序以解决特殊困难的问题 找出算法即可丢弃验证程序 规划多次小型阶段的项目计划 以最快速度完成每一阶段的程序交付客户 客户负责Acceptancetests Coding前必须完成UnitTest与Acceptancetests程序 所有模

9、块整合前都须经过UnitTests 开发人员必须快速响应Bug与需求变更 要求二人一组使用一台计算机设计程序 当一人coding时 另一人负责思考与设计 程序必须符合程序规范 并常做程序的重构 Refactoring 2020 5 20 20 XP原则和实践 Planning userstories userstoriesUserstories类似usecase 描述用户所见的系统功能 但避免使用大量的文档 userstories由用户编写 不仅限于描述用户界面 Userstories使用用户的语言编写 不使用技术性的语言 每个userstories限于几句话 Userstories用于在re

10、leaseplan会议上对开发时间进行评估 也用于产生验收测试 acceptancetest 必须使用可以自动进行的验收测试保证软件的正确性 Userstories与传统的用户需求的区别在于详细的程度 userstories并不会确定需求的每个细节 它只是用来简单的描述系统功能 供开发人员进行估计开发进度 在开发过程中开发人员和用户会不断的交流以讨论细节问题 Userstory应该专注于功能 不应该过分注重用户界面等细节 一般一个userstoriy在1 3周的时间完成 如果估计超过3周 说明userstory太大了 需要细分 2020 5 20 21 XP原则和实践 Planning rel

11、easeplan releaseplan召开一个releaseplan会议 产生releaseplan Releaseplan将用于指定每个iteration的计划 开发人员对每个userstory估计开发时间 在不被打断 无其他工作情况下的开发时间 包括测试 用户对userstories给出优先级 releaseplan会议并不制订每个iteration的计划 Releaseplan要用户 开发人员和管理者都同意 在完成功能范围 scope 使用资源 resource 时间 time 和质量 quality 上达成一致 一般质量是不能改变的 2020 5 20 22 XP原则和实践 Plan

12、ning smallrelease smallreleaseoftenandsmallrelease是XP的一个原则 每个release完成一些用户有意义的功能集合 尽快的提交给用户以获得反馈 及时调整 提交的越晚 调整越困难 2020 5 20 23 XP原则和实践 Planning projectvelocity projectvelocity团队在开发过程中要收集数据 以便于对自己的开发速度进行评估 用于以后的releazseplan 2020 5 20 24 XP原则和实践 Planning iteration iteration每个smallrelease的周期称为iteration

13、 每个iteration约为1 3周 在一个项目中保持每个iteration的时间相等 不要超前制定计划 每个iteration的计划在iteration的开始时制定 这样能够更灵活的应付变化 不要急于完成本次iteration没有包括的功能 要注重每个iteration的时间限制 当团队觉得不能按时完成iteration时 召开一次iterationplan会议 重新评估 减少一些userstories 2020 5 20 25 XP原则和实践 Planning iterationplan iterationplan在每个iteration开始的时候召开会议 从releaseplan中选择还

14、没有实现的用户最迫切需要的userstories 上一个iteration中没有通过验收测试的功能也要在这个iteration中实现 可以根据上一个iteration的实践调整团队速度 Userstories和失败的测试被分解成programmingtask task使用技术语言编写 作为iterationplan的详细描述 程序员主动领取task并估计完成时间 每个task应该在1 3天内完成 超过3天的task应该被细分 如果整个团队需要的时间多于或少于规定的iteration时间 调整userstories 2020 5 20 26 XP原则和实践 Planning movepeople

15、around movepeoplearound不要使每个开发人员局限于一项工作 不要使某项工作依赖于一个开发人员 增加知识共享 减少信息孤岛 多进行交流和培训 当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的 鼓励开发人员在不同iteration中开发不同的模块 2020 5 20 27 XP原则和实践 Planning stand upmeeting stand upmeeting每天工作开始之前 开5 10分钟的stand up会议 站立会议 站立的目的是为了强迫节省时间 会议的目的是交流 提出存在的问题 但不要在会议上解决问题 开一个所有人员参加的短会比多个个别人员参加的会议

16、要高效 在会议上提出的问题可以由少数人讨论解决 这个少数人参加的会议如果涉及到代码 可以在计算机前讨论 2020 5 20 28 XP原则和实践 Planning fixXPwhenitbreaks fixXPwhenitbreaksXP并不是一成不变的 当团队觉得需要修改的时候 可以根据自己的情况进行修改 任何修改都要经过整个团队的讨论和达成一致 2020 5 20 29 XP原则和实践 Designing 1 Simplicity保持简单的设计 在完成同样的功能的情况下 选择简单的设计 不要急于设计没有计划的功能 应该认识到 keepingadesignsimpleishardworkSystemmetaphor使用统一的术语描述系统 在用户 管理者和开发人员之间使用统一的术语 这将使交流清晰 CRCcard使用CRC Class Responsibilities andCollaboration card进行系统设计 鼓励更多的人参加设计 每个CRC卡片表示系统中一个对象 写上对象的名字 责任和每个责任需要交互的其他对象 可以模拟对象之间的交互 CRC卡片是易于理解的 但是是非正