敏捷开发培训(Agile-Development)

AgileDevelopment

矫捷开发JackDing(jack.w.ding@gmail)09/28/2021ContentAgileDevelopment引见RUPXPScrumAgileProcess-矫捷的开发流程AgileProcess(矫捷的开发流程)是一种软件开发流程的泛称，几项共通的特性：客户与开发人员构成亲密协作的团队，由于客户无法于初期定义完好的规格，而开发人员于开发过程中也经常无法知悉外在环境或业务的变动，所以需求两者亲密协作方能开发适用的软件。工程最终的目的是可执行的程序，因此一切的中间产品必需经过谨慎评价，确认有助于最终目的，才需求制造中间产品。采用Iterative与Incremental方式分阶段进展，密集review能否符合需求。流程可以简单，但规划与执行必需严谨。强调团队协作，赋予高度的责任，团队有自主权得以因应变化做调整AgileDevelopment矫捷开发是一种以人为中心、迭代、循序渐进的开发方法在矫捷开发中，工程的构建被切分成多个子工程，各个子工程的成果都经过测试，具备集成和可运转的特征。矫捷开发中心价值(CoreValue)Individualsandinteractionsoverprocessesandtools

个人和交流重于过程和工具

Workingsoftwareovercomprehensivedocumentation

正在运转的软件本身重于复杂的文档

Customercollaborationovercontractnegotiation

与客户的沟通和交流重于运用合同约束客户

Respondingtochangeoverfollowingaplan

对变化的快速呼应重于跟随方案矫捷开发原那么(Principles)最高目的是经过快速的和经常的发布软件满足客户的需求提交软件的周期为几个星期到几个月产生正确的软件是衡量进度的首要规范自动接受需求的改动而不是回绝商务人员和开发人员任务在一同个人必需有动力，要发明环境支持他们的要求，信任他们最有效的交流方法是面对面的交流最好的构造，需求和设计来自于自组织的团队〔self-organizingteam〕，允许任何人提出想法和建议继续改良设计和编码鼓励正常任务，减少长时间加班坚持简单，减少不用要的部分，认识到简单的设计比复杂的设计更难〔simpledesignishardertoproduce〕定期调整过程，获得更高效率矫捷开发的设计原那么SRP单一职责原那么SRP：SingleResponsibilityPrincipleOCP开放封锁原那么OCP：Open－ClosePrincipleLSPLiskov交换原那么LSP：LiskovSubstitutionPrincipleDIP依赖倒置原那么DIP：DependencyInvertionPrincipleISP接口隔离原那么ISP：InterfaceSeparatePrinciple矫捷开发-迭代方案最新版本验收测试发布方案迭代方案开发工程周期矫捷开发-迭代方案名词解释故事故事是客户想要系统做的事情，适宜在一至两个迭代内完成，并且是可测试的，他不一定是商业价值的直接表达。迭代迭代是一个周期在2-4周，可以完成当前团队所能实现的，最具商业价值的功能，并可以提供一个可任务的小版本供发布。VelocityVelocity翻译为工程周转时间。代表团队在给定周期内可以完成多少商业价值，以便用于衡量未来该团队可以提供的商业价值。也即昨天的天气。名词解释优先级优先级主要思索商业价值，同时兼顾市场风险、商业风险、技术风险等要素在内的一个衡量数字，优先级越高通常意味着其商业价值越高风险系数风险系数综合商业环境、工程资源、技术以及工程环境等等要素在内的一个衡量数字，它是优先级的重要衡量目的之一。它通常出如今故事中。风险系数较大意味着优先级也较大。负载因子负载因子是综合工程成员的技术才干、技艺集、精神形状等等要素，对于团队成员的一个负载系数。名词解释理想时间理想时间排除一切能够的外界干扰，同时排除本身的精神形状，职业态度等等要素，完成某项任务所需求的时间。实践时间实践时间理想时间乘上负载因子义务义务分配到工程成员，从故事切分的出来。通常义务时间不应该超越10个实践任务日。1.RUP2.XP3.ScrumRUP-RationalUnifyProcessRUP为IBMRational提出的软件开发流程内容含盖Businessmodeling,RequirementModeling,LogicalDesign,Implementation,Testing,Deployment等软件开发生命周期的直接任务与ProjectManagement,Change&ConfigurationManagement，Environmentsupport等支持性任务。RUP的主要精神工程进展采用Iterative程序分阶段渐进地完成工程功能；广泛运用VisualModeling于商业需求分析、系统分析与系统设计；强调架构设计；对每项任务所需求的技术、工具、做法、模板、检查工程均有详细的定义，架构完备且具有可调整的弹性。1.RUP2.XP3.ScrumXP-eXtremeProgramming极限编程，最轻量级的开发流程，其最主要的精神是『在客户有系统需求时，给予及时称心的可执行程序』，所以最适宜需求快速变动的工程强调客户所要的是workable的执行码，所以把与撰写程序无关的任务降至最低，并要求客户与开发人员最好以side-by-side的方式一同任务XP强调4个要素交流(communication)，XP要求程序员之间以及和用户之间有大量而迅速的交流简单〔simplicity〕，XP要求设计和实现简单和干净反响〔feedback〕经过测试得到反响，尽快提交软件并根据反响修正勇气〔courage〕。英勇的面对需求和技术上的变化XP开发流程开发人员随时可以和客户进展有效沟通，撰写userstories以确认需求。简易快速的系统设计，撰写独立的验证程序以处理特殊困难的问题，找出算法即可丢弃验证程序。规划多次小型阶段的工程方案，以最快速度完成每一阶段的程序交付客户，客户担任Acceptancetests；Coding前必需完成UnitTest与Acceptancetests程序，一切模块整合前都须经过UnitTests；开发人员必需快速呼应Bug与需求变卦；要求二人一组运用一台计算机设计程序，当一人coding时，另一人担任思索与设计；程序必需符合程序规范，并常做程序的重构(Refactoring)。XP原那么和实际-Planning-userstoriesuserstoriesUserstories类似usecase，描画用户所见的系统功能，但防止运用大量的文档，userstories由用户编写〔不仅限于描画用户界面〕。Userstories运用用户的言语编写，不运用技术性的言语，每个userstories限于几句话。Userstories用于在releaseplan会议上对开发时间进展评价，也用于产生验收测试〔acceptancetest〕，必需运用可以自动进展的验收测试保证软件的正确性。Userstories与传统的用户需求的区别在于详细的程度，userstories并不会确定需求的每个细节，它只是用来简单的描画系统功能，供开发人员进展估计开发进度，在开发过程中开发人员和用户会不断的交流以讨论细节问题。Userstory应该专注于功能，不应该过分注重用户界面等细节。普通一个userstoriy在1-3周的时间完成，假设估计超越3周，阐明userstory太大了，需求细分.XP原那么和实际-Planning-releaseplanreleaseplan召开一个releaseplan会议，产生releaseplan。Releaseplan将用于指定每个iteration的方案。开发人员对每个userstory估计开发时间〔在不被打断，无其他任务情况下的开发时间，包括测试〕，用户对userstories给出优先级，releaseplan会议并不制定每个iteration的方案。Releaseplan要用户，开发人员和管理者都赞同，在完胜利能范围〔scope〕，运用资源〔resource〕,时间〔time〕和质量(quality)上达成一致〔普通质量是不能改动的〕XP原那么和实际-Planning-smallreleasesmallreleaseoftenandsmallrelease是XP的一个原那么，每个release完成一些用户有意义的功能集合，尽快的提交给用户以获得反响，及时调整，提交的越晚，调整越困难。XP原那么和实际-Planning-projectvelocityprojectvelocity团队在开发过程中要搜集数据，以便于对本人的开发速度进展评价，用于以后的releazseplanXP原那么和实际-Planning-iterationiteration每个smallrelease的周期称为iteration，每个iteration约为1-3周，在一个工程中坚持每个iteration的时间相等，不要超前制定计划，每个iteration的方案在iteration的开场时制定。这样可以更灵敏的应付变化。不要急于完本钱次iteration没有包括的功能。要注重每个iteration的时间限制，当团队觉得不能按时完成iteration时，召开一次iterationplan会议，重新评价，减少一些userstories。XP原那么和实际-Planning-iterationplaniterationplan在每个iteration开场的时候召开会议，从releaseplan中选择还没有实现的用户最迫切需求的userstories。上一个iteration中没有经过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实际调整团队速度。Userstories和失败的测试被分解成programmingtask，task运用技术言语编写，作为iterationplan的详细描画。程序员自动领取task并估计完成时间，每个task应该在1-3天内完成，超越3天的task应该被细分。假设整个团队需求的时间多于或少于规定的iteration时间，调整userstories。XP原那么和实际-Planning-movepeoplearoundmovepeoplearound不要使每个开发人员局限于一项任务，不要使某项任务依赖于一个开发人员，添加知识共享，减少信息孤岛，多进展交流和培训。当工程中的一切人对一切模块都了解并可以进展开发时是效率最高的，鼓励开发人员在不同iteration中开发不同的模块。XP原那么和实际-Planning-stand-upmeetingstand-upmeeting每天任务开场之前，开5-10分钟的stand-up会议〔站立会议〕，站立的目的是为了强迫节省时间，会议的目的是交流，提出存在的问题，但不要在会议上处理问题。开一个一切人员参与的短会比多个个他人员参与的会议要高效。在会议上提出的问题可以由少数人讨论处理，这个少数人参与的会议假设涉及到代码，可以在计算机前讨论。XP原那么和实际-Planning-fixXPwhenitbreaksfixXPwhenitbreaksXP并不是一成不变的，当团队觉得需求修正的时候，可以根据本人的情况进展修正，任何修正都要经过整个团队的讨论和达成一致XP原那么和实际-Designing-1Simplicity坚持简单的设计，在完成同样的功能的情况下，选择简单的设计，不要急于设计没有方案的功能，应该认识到：keepingadesignsimpleishardworkSystemmetaphor运用一致的术语描画系统，在用户，管理者和开发人员之间运用一致的术语。这将使交流明晰。CRCcard运用CRC(Class,Responsibilities,andCollaboration)card进展系统设计，鼓励更多的人参与设计。每个CRC卡片表示系统中一个对象，写上对象的名字，责任和每个责任需求交互的其他对象。可以模拟对象之间的交互。CRC卡片是易于了解的，但是是非正式的，假设需求正式的文档，要将卡片转换为相应的文档。spikesolutionneveraddfunctionearlyrefactoringwheneverandwhereverXP原那么和实际-Designing-2spikesolution运用spikesolution减低风险，当遇到技术难题或设计问题时，运用简单的程序进展测试，找出问题，在不同的处理方法之间进展评价。在早期进展实验可以有效的降低风险。neveraddfunctionearly不要过早的设计没有方案的功能，在一个需求经常变化的环境中，过早的设计经常是没有用的。refactoringwheneverandwhereverXP鼓励对设计和代码经常进展重构〔Refactoring〕，目的是去除冗余，提高质量，坚持设计简单。重构必需以完全测试为检验条件XP原那么和实际-Coding-1customerisalawaysavailable用户是工程组的成员之一，用户的参与贯穿整个开发过程，用户与开发人员之间的交流是重要的codingstandard运用一致的编码规范，这是坚持代码整洁和共享代码的根底codingunittestfirsttestfirst是XP的一个特点，在编写代码之前先编写单元测试代码，单元测试代码和代码由同一个程序员完成。先编写测试代码可以使程序员更好的了解需求，防止直接编码呵斥的了解偏向，对需求的不明晰，可以在编写测试代码时就发现。测试代码也是检验程序能否完成的规范。编码任务应该是以下任务的循环：

1编写测试代码

2运转测试程序，确认失败

3编写实现这个测试程序要求功能的代码，不需求实现其他的功能，只需求实现刚刚满足测试程序的功能

4运转测试程序，确认胜利

实际证明，testfirst方式需求的编码实际少于先编码，后写测试代码XP原那么和实际-Coding-2PairProgrammingPairprogramming是XP的特征，它要求两个程序员在一台计算机上同时进展编程任务。共用鼠标和键盘，通常一个人进展战略上的思索，程序架构和函数，类之间的关系，一个人进展输入和战术上的思索，完成函数和类。两个人可以经常交换角色。sequentialintegration要保证源代码库的形状是可标识的，同一时间，只允许一个pair的程序进展整和和测试，这样可以减少问题产生的范围。不同的pair可以在本人的机器上随时进展整和和测试.integrateoften只需有能够就进展代码整合，周期可以在几个小时，最好不要超越一天。XP原那么和实际-Coding-3共同拥有代码鼓励每个人对工程中的任何人提出新的想法，任何开发人员对工程中的任何代码都可以进展添加功能，矫正错误和重构。优化任务放在最后先使系统可以正常任务，不要猜测系统的瓶颈，要实践丈量NOovertime不要长时间的加班，大多数加班并不能挽回已有的延迟，延续超越两个星期的加班阐明有问题存在。向一个曾经延迟的工程填加人员也不是一个好的选择。XP原那么和实际-Testing-1一切的代码都有单元测试单元测试是XP的基石，XP中的单元测试应该是可以自动进展的，所以可以很快的进展一切的单元测试，单元测试应该在编码之前创建。单元测试的代码和代码一同release，没有单元测试的代码不可以release。运用自动单元测试可以系统整合时节省大量的发现错误和矫正的时间。单元测试越完善，节省的时间越多。代码在release前必需经过一切的单元测试发现bug后，首先添加测试在实践运转中发现bug,首先添加acceptancetest，然后添加unittest，在添加完测试后在查找和修正代码，添加的测试保证同样的错误不会再出现acceptancetestacceptancetest根据userstories在iterationplan会议上创建，它也应该可以自动运转以便可以经常运转。1.RUP2.XP3.ScrumScrumScrumScrum特点自我管理的团队以“sprint〞为周期迭代的产品开发以一系列“产品Backlog〞记录了产品需求没有特定的工程实际惯例在以生成规那么发明的矫捷开发环境交付产品是其中一种“矫捷方法〞SCRUM开发流程SCRUM开发流程是AgileProcess的一种，以英式橄榄球争球队形(Scrum)为名，根本假设是『开发软件就像开发新产品，无法一开场就能定义FinalProduct的规程，过程中需求研发、创意、尝试错误，所以没有一种固定的流程可以保证工程胜利』。Scrum将软件开发团队比较成橄榄球队，有明确的最高目的，熟习开发流程中所需具备的最正确典范与技术，具有高度自主权，严密地沟通协作，以高度弹性处理各种挑战，碓保每天、每个阶段都朝向目的有明确的推进，因此SCRUM非常适用于产品开发工程。SCRUM开发流程(cont.)SCRUM开发流程通常以30天为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开场，开发团队与客户于每一个阶段开场时挑选该完成的规格部份，开发团队必需尽力于30天后交付成果，团队每天用15分钟开会检视每个成员的进度与方案，了解所遭遇的困难并设法排除，决议第二天的义务安排.SCRUM较为有特征的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，假设有问题，也会向管理层要求协助处理。Scrum总体骨架迭代每30天DailySCRUM每24小时高优先级可运转的软件任务项分解产品订单ProductBacklog迭代订单SprintBacklog新的功能增量迭代规划会议SprintPlan普通不超越8小时。前4个小时：产品担任人向团队展现最高优先级的产品，团队那么向他讯问产品Backlog的内容、目的、含义及意图。后4小时：团队方案本Sprint的安排迭代复审会议SprintReview普通4个小时，由团队成员向产品担任人额其他利益相关人展现Sprint周期内的产品开发情况迭代回想会议SprintRetrospective普通3个小时，ScrumMaster将鼓励团队在SCRUM过程框架和实际范围内，对开发过程做出修正，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议DailyScrumMeeting在简会上，每个成员主要回答三个问题;–自上次SCRUM简会后的一天了〔昨天〕，他做了什么?–从如今到下次SCRUM简会的一天里〔今天〕，他要做什么?–在实现SCRUM及工程目的的任务中，他遇到哪些困难吗?产品担任人Scrum主管开发团队顺序vs.重叠开发过程Scrum并非以一段时间集中完成一个过程...而是将一切过程中必需的每一部分集中在这段时间内完成需求设计代码测试Scrum构造框架产品一切者ScrumMaster团队职能迭代方案迭代验收迭代回想每天召开的scrum会议仪式产品backlog迭代backlog进度曲线图产出ScrumTeam自组织的团队跨功能团队没有角色区分最少2个,最多7个对任务交付担任只需交付任务需求,授权做任何事情.Scrum角色及职责火腿鸡蛋！三思过后我决议不和他开餐馆了。由于我全身心投入，而他只牵涉入内！Chickens&PigsPigs:ScrumTeam成员:他们承诺对迭代目的交付担任Chickens:工程组有关的成员,但并不专注于工程以察看者的方式参与ScrummeetingProductOwnerBacklog优先级制定开发的版本规划必需确保驱动开发的需求只需一份受管理层,客户等影响但仅PO有权调整Backlog与相关成员协同任务来确定ProductBacklog的items消除关于Backlog的疑惑,确保了解一致,消除干扰ScrumMasterScrumMaster职责确保SCRUM的胜利实施SCRUM实际和规定,维护团队以免受干扰工程管理的代表Sprint交付产品的固定的时间箱.建议2-3周迭代包括design,coding,testing,anddocumentation一旦迭代开场,仅ScrumTeam能添加或者删除Sprintbacklog中的items当迭代的目的变的没有意义的时候,才干终止迭代开发对于ProductBacklog,不允许迭代内的需求变卦：需求优先级调整仅存在于迭代之间如何定义Sprint团队本人从产品的backlog中选择一些他们可以完成的义务作为迭代的backlog迭代backlog被创建义务被确认并且每一义务估计任务量应该在1-16小时左右迭代的backlog