敏捷开发培训(AgileDevelopment)

2019/9/161AgileDevelopment敏捷开发JackDing(jack.w.ding@gmail.com)09/28/20102019/9/162ContentAgileDevelopment介绍RUPXPScrum2019/9/163AgileProcess-敏捷的开发流程AgileProcess(敏捷的开发流程)是一种软件开发流程的泛称，几项共通的特性：1.客户与开发人员形成密切合作的团队，因为客户无法于初期定义完整的规格，而开发人员于开发过程中也常常无法知悉外在环境或业务的变动，所以需要两者密切合作方能开发适用的软件。2.项目最终的目标是可执行的程序，因此所有的中间产品必须经过审慎评估，确认有助于最终目标，才需要制作中间产品。3.采用Iterative与Incremental方式分阶段进行，密集review是否符合需求。4.流程可以简单，但规划与执行必须严谨。5.强调团队合作，赋予高度的责任，团队有自主权得以因应变化做调整2019/9/164AgileDevelopment敏捷开发是一种以人为核心、迭代、循序渐进的开发方法在敏捷开发中，项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。2019/9/165敏捷开发核心价值(CoreValue)Individualsandinteractionsoverprocessesandtools个人和交流重于过程和工具Workingsoftwareovercomprehensivedocumentation正在运行的软件本身重于复杂的文档Customercollaborationovercontractnegotiation与客户的沟通和交流重于使用合同约束客户Respondingtochangeoverfollowingaplan对变化的快速响应重于跟随计划2019/9/166敏捷开发原则(Principles)1.最高目标是通过快速的和经常的发布软件满足客户的需要2.提交软件的周期为几个星期到几个月3.产生正确的软件是衡量进度的首要标准4.主动接受需求的改变而不是拒绝5.商务人员和开发人员工作在一起6.个人必须有动力，要创造环境支持他们的要求，信任他们7.最有效的交流方法是面对面的交流8.最好的结构，需求和设计来自于自组织的团队（self-organizingteam），允许任何人提出想法和建议9.持续改进设计和编码10.鼓励正常工作，减少长时间加班11.保持简单，减少不必要的部分，认识到简单的设计比复杂的设计更难（simpledesignishardertoproduce）12.定期调整过程，获得更高效率2019/9/167敏捷开发的设计原则SRP单一职责原则SRP：SingleResponsibilityPrincipleOCP开放封闭原则OCP：Open－ClosePrincipleLSPLiskov替换原则LSP：LiskovSubstitutionPrincipleDIP依赖倒置原则DIP：DependencyInvertionPrincipleISP接口隔离原则ISP：InterfaceSeparatePrinciple2019/9/168敏捷开发-迭代计划最新版本验收测试发布计划迭代计划开发项目周期2019/9/169敏捷开发-迭代计划2019/9/1610名词解释故事故事是客户想要系统做的事情，适合在一至两个迭代内完成，并且是可测试的，他不一定是商业价值的直接体现。迭代迭代是一个周期在2-4周，能够完成当前团队所能实现的，最具商业价值的功能，并可以提供一个可工作的小版本供发布。VelocityVelocity翻译为项目周转时间。代表团队在给定周期内能够完成多少商业价值，以便用于衡量将来该团队能够提供的商业价值。也即昨天的天气。2019/9/1611名词解释优先级优先级主要考虑商业价值，同时兼顾市场风险、商业风险、技术风险等因素在内的一个衡量数字，优先级越高通常意味着其商业价值越高风险系数风险系数综合商业环境、项目资源、技术以及项目环境等等因素在内的一个衡量数字，它是优先级的重要衡量指标之一。它通常出现在故事中。风险系数较大意味着优先级也较大。负载因子负载因子是综合项目成员的技术能力、技能集、精神状态等等因素，对于团队成员的一个负载系数。2019/9/1612名词解释理想时间理想时间排除一切可能的外界干扰，同时排除自身的精神状态，职业态度等等因素，完成某项工作所需要的时间。实际时间实际时间理想时间乘上负载因子任务任务分配到项目成员，从故事切分的出来。通常任务时间不应该超过10个实际工作日。2019/9/16131.RUP2.XP3.Scrum2019/9/1614RUP-RationalUnifyProcessRUP为IBMRational提出的软件开发流程内容含盖Businessmodeling,RequirementModeling,LogicalDesign,Implementation,Testing,Deployment等软件开发生命周期的直接工作与ProjectManagement,Change&ConfigurationManagement，Environmentsupport等支持性工作。2019/9/1615RUP的主要精神1.项目进行采用Iterative程序分阶段渐进地完成项目功能；2.广泛使用VisualModeling于商业需求分析、系统分析与系统设计；3.强调架构设计；4.对每项工作所需要的技术、工具、做法、模板、检查项目均有详细的定义，架构完备且具有可调整的弹性。2019/9/16161.RUP2.XP3.Scrum2019/9/1617XP-eXtremeProgramming极限编程，最轻量级的开发流程，其最主要的精神是『在客户有系统需求时，给予及时满意的可执行程序』，所以最适合需求快速变动的项目强调客户所要的是workable的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作2019/9/1618XP强调4个因素交流(communication)，XP要求程序员之间以及和用户之间有大量而迅速的交流简单（simplicity），XP要求设计和实现简单和干净反馈（feedback）通过测试得到反馈，尽快提交软件并根据反馈修改勇气（courage）。勇敢的面对需求和技术上的变化2019/9/1619XP开发流程开发人员随时可以和客户进行有效沟通，撰写userstories以确认需求。简易快速的系统设计，撰写独立的验证程序以解决特殊困难的问题，找出算法即可丢弃验证程序。规划多次小型阶段的项目计划，以最快速度完成每一阶段的程序交付客户，客户负责Acceptancetests；Coding前必须完成UnitTest与Acceptancetests程序，所有模块整合前都须经过UnitTests；开发人员必须快速响应Bug与需求变更；要求二人一组使用一台计算机设计程序，当一人coding时，另一人负责思考与设计；程序必须符合程序规范，并常做程序的重构(Refactoring)。2019/9/1620XP原则和实践-Planning-userstoriesuserstoriesUserstories类似usecase，描述用户所见的系统功能，但避免使用大量的文档，userstories由用户编写（不仅限于描述用户界面）。Userstories使用用户的语言编写，不使用技术性的语言，每个userstories限于几句话。Userstories用于在releaseplan会议上对开发时间进行评估，也用于产生验收测试（acceptancetest），必须使用可以自动进行的验收测试保证软件的正确性。Userstories与传统的用户需求的区别在于详细的程度，userstories并不会确定需求的每个细节，它只是用来简单的描述系统功能，供开发人员进行估计开发进度，在开发过程中开发人员和用户会不断的交流以讨论细节问题。Userstory应该专注于功能，不应该过分注重用户界面等细节。一般一个userstoriy在1-3周的时间完成，如果估计超过3周，说明userstory太大了，需要细分.2019/9/1621XP原则和实践-Planning-releaseplanreleaseplan召开一个releaseplan会议，产生releaseplan。Releaseplan将用于指定每个iteration的计划。开发人员对每个userstory估计开发时间（在不被打断，无其他工作情况下的开发时间，包括测试），用户对userstories给出优先级，releaseplan会议并不制订每个iteration的计划。Releaseplan要用户，开发人员和管理者都同意，在完成功能范围（scope），使用资源（resource）,时间（time）和质量(quality)上达成一致（一般质量是不能改变的）2019/9/1622XP原则和实践-Planning-smallreleasesmallreleaseoftenandsmallrelease是XP的一个原则，每个release完成一些用户有意义的功能集合，尽快的提交给用户以获得反馈，及时调整，提交的越晚，调整越困难。2019/9/1623XP原则和实践-Planning-projectvelocityprojectvelocity团队在开发过程中要收集数据，以便于对自己的开发速度进行评估，用于以后的releazseplan2019/9/1624XP原则和实践-Planning-iterationiteration每个smallrelease的周期称为iteration，每个iteration约为1-3周，在一个项目中保持每个iteration的时间相等，不要超前制定计划，每个iteration的计划在iteration的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要注重每个iteration的时间限制，当团队觉得不能按时完成iteration时，召开一次iterationplan会议，重新评估，减少一些userstories。2019/9/1625XP原则和实践-Planning-iterationplaniterationplan在每个iteration开始的时候召开会议，从releaseplan中选择还没有实现的用户最迫切需要的userstories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实践调整团队速度。Userstories和失败的测试被分解成programmingtask，task使用技术语言编写，作为iterationplan的详细描述。程序员主动领取task并估计完成时间，每个task应该在1-3天内完成，超过3天的task应该被细分。如果整个团队需要的时间多于或少于规定的iteration时间，调整userstories。2019/9/1626XP原则和实践-Planning-movepeoplearoundmovepeoplearound不要使每个开发人员局限于一项工作，不要使某项工作依赖于一个开发人员，增加知识共享，减少信息孤岛，多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的，鼓励开发人员在不同iteration中开发不同的模块。2019/9/1627XP原则和实践-Planning-stand-upmeetingstand-upmeeting每天工作开始之前，开5-10分钟的stand-up会议（站立会议），站立的目的是为了强迫节省时间，会议的目的是交流，提出存在的问题，但不要在会议上解决问题。开一个所有人员参加的