




已阅读5页,还剩96页未读, 继续免费阅读
版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
.,敏捷开发全景视图(流程、方法和最佳实践),钟玮军2016-02-25,目录Contents,敏捷vs传统敏捷开发流程框架敏捷方法和最佳实践思考与答疑,敏捷vs传统,IT项目管理方法的发展历史,1960,1970,1980,1990,2000,2010,SDLC,WATERFALL,RAD,PMBOKITILPRINCEZachman,DSDM,RUPXPPRINCE2CRYSTAL,SCRUMAGILEMANIFESTOFEATOGAF8.0,LEAN,KANBAN,软件开发生命周期(SDLC),/wiki/Systems_development_life_cycle,传统软件开发模式,传统瀑布式软件开发方式,向迭代式软件开发方式转变(RUP框架),传统软件开发模式存在的问题,传统软件件开发过程的常见症结交付周期长;害怕需求变更;中间过程不可控;测试周期被一缩再缩;最终结果差强人意与“唯快不破”的互联网经济格格不入,敏捷软件开发模式由传统迭代式软件开发模式发展而来,Time-Boxed抛开传统软件开发模式的繁文缛节,强调产品价值、团队协作、客户参与、先期验证、简化流程、拥抱变化总结吸收成功软件项目研发的最佳实践;与现代管理思想相辅相成前期有学习成本,后期会获益匪浅,敏捷软件开发模式,Source:ForresterResearch,Inc.,趋势:敏捷开发逐渐成为主流模式,2009Q3,2014,Growth,敏捷开发带来的好处,TOP5reportedbenefits:,Improvedquality(56%),Moreopportunitiesformid-coursecorrections(56%),Overallimprovedcustomerandbusinesssatisfaction(38%),Betterbusiness-ITalignment(37%),Improvedtimetomarket(32%),Alotmorethanvelocity,质量改善,利于中途修正,总体改善客户和业务的满意度,商业需求与IT实施更加匹配,更快投入市场,Source:2013ForresterResearch,Inc.,敏捷开发宣言,ManifestoforAgileSoftwareDevelopmentIndividualsandinteractionsoverprocessesandtools人和交互重于过程和工具Workingsoftwareovercomprehensivedocumentation可以工作的软件重于面面俱到的文档Customercollaborationovercontractnegotiation客户合作重于合同谈判Respondingtochangeoverfollowingaplan随时应对变化重于遵循计划虽然右边也有其价值,但我们认为左项更加重要,敏捷原则(AgilePrinciples),SatisfytheCustomerWelcomeChangeDeliverFrequentlyWorkasaTeamMotivatePeopleCommunicateFace-to-Face,MeasureWorkingSoftwareMaintainConstantPaceExcelatQualityKeepitSimpleEvolveDesignsReflectRegularly,敏捷开发价值观,专注:由于我们在一段时间内只专注于少数几件事情,所以我们可以很好地合作并获得优质的产出。我们能够更快地交付有价值的事项。公开:在团队合作中,大家都会表达我们做得如何,以及遇到的障碍。我们发现将担忧说出来是一件好事,因为只有这样才能让这些担忧及时得到解决。尊重:因为我们在一起工作,分享和成功失败,这有助于培养并加深互相之间的尊重,并帮助彼此成为值得尊重的人。承诺:由于对自己的命运有更大的掌握,我们会有更坚强的信念获得成功。勇气:因为我们不得单打独斗,我们能够感受到支持,而且掌握更多的资源。这一切赋予我们勇气去迎接更大的挑战。,从传统到敏捷:思维的转变,形而上者谓之道,形而下者谓之器。形而上者起于学、行于理、止于道,形而下者起于教、行于法、止于术。,从重视“流程”到重视“原则”道本器末,不忘初心做正确的事比正确地做事更重要如何看待流程、方法、最佳实践在敏捷开发中的作用无其器则无其道,器和道一样重要上善若水,原则的“刚性”和流程的“柔性”,从传统到敏捷:认识误区,从传统到敏捷:阻碍和要点,改变我们的商业文化,采用敏捷技术实践,改变我们的IT文化,以一种敏捷的态度使用我们现有的工具,采用新的敏捷开发工具,采用敏捷管理实践,从传统到敏捷:关键因素,改变我们的商业文化,采用敏捷管理实践,改变我们的IT文化,采用敏捷技术实践,采用新的敏捷开发工具,以一种敏捷的态度使用我们现有的工具,敏捷开发流程框架,产品研发:一个持续的过程,What?,How?,Managementisdoingthingsright;leadershipisdoingtherightthings.(PeterDrucker),敏捷开发流程框架:Scrum,注:Scrum是最为流行的敏捷开发流程框架之一,What?,How?,Scrum框架:简介,Scrum是一个用于开发和维持复杂产品的框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprintbacklog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。要素:周期:ProductReleaseRelease=Sprint=DailyWorking,What?,How?,Scrum(二):团队,BuildTheRightThing,BuildTheThingRight,BuildItFast,ScrumTeamAchievement-orientedCustomer-orientedCommittedMotivatedSelf-organizedEmpoweredSkilled,Scrum团队:团队文化,共赢的文化团队成功个人发展立足现实挑战极限,Scrum团队:角色分工概览,Scrum团队:ProductOwner职责,主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权利接受或拒绝开发团队的工作成果PO在Scrum中承担了多项职责产品经理:愿景和方向,结果负责需求分析:业务分析和需求分析需求管理:维护、终止和变更项目管理:优先级排序和项目状态跟踪质量保障:检查产品结果客户代表:产品体验/接受拒绝PO对外承担了与产品干系人交流沟通的职责老板、客户和用户、营销和销售、,Scrum团队:PO的职责关系,ProductOwner属于研发角色,但与战略、市场和销售等公司其它角色存在密切合作关系,需要掌握跨界知识和语言表达。,图示表现了产品管理四种角色之间的关系和分工定义,但根据项目规模不同,某一成员可能身兼数职。,Scrum团队:PO能力要求,业务分析能力(BusinessAnalysis)工程技术能力(Engineering)领导和协调能力(Leadership&Coordination),BusinessAnalysisCapabilitiesHelpingorganizationsdevelopthecapabilitiestoachieveEnterpriseAgility,UnderstandNeedsoftheCustomer,DevelopProductStrategy,ManageProductPortfolio,AchieveCustomerAcceptance,DefineBusinessRequirements,ProductStrategy,SolutionRequirements,DevelopProduct,LaunchProduct,OperateandSupportProduct,DefineProductBacklog,EstablishProductVision,DefineProductRoadmap,PlanLaunch,EngageStakeholders,Planning,CoordinateLaunch,EstablishDevelopmentEnvironment,ManageSuppliers,EnsureProcessAdherence,IdentifyandRemoveImpediments,EnsureInternalCommunication,MaintainWorkEnvironment,DevelopTeam,SupportOperations,ProvideCustomerSupport,SupportImplementation,CoordinateWork,MaintainArchitecture,UnderstandRequirements,MaintainProductQuality,DesignandEngineerSolution,DeployProduct,IntegrationTesting,LearnfromOutsideSources,CommitToAgility,ManageRisks,ProvideJobTraining,Everyone,Environment,PerformMaintenanceandCustomizations,ProductDevelopment,EngineeringCapabilitiesHelpingorganizationsdevelopthecapabilitiestoachieveEnterpriseAgility,UnderstandNeedsoftheCustomer,DevelopProductStrategy,ManageProductPortfolio,AchieveCustomerAcceptance,DefineBusinessRequirements,ProductStrategy,SolutionRequirements,DevelopProduct,LaunchProduct,OperateandSupportProduct,DefineProductBacklog,EstablishProductVision,DefineProductRoadmap,PlanLaunch,EngageStakeholders,Planning,CoordinateLaunch,EstablishDevelopmentEnvironment,ManageSuppliers,EnsureProcessAdherence,IdentifyandRemoveImpediments,EnsureInternalCommunication,MaintainWorkEnvironment,DevelopTeam,SupportOperations,ProvideCustomerSupport,SupportImplementation,CoordinateWork,MaintainArchitecture,UnderstandRequirements,MaintainProductQuality,DesignandEngineerSolution,DeployProduct,IntegrationTesting,LearnfromOutsideSources,CommitToAgility,ManageRisks,ProvideJobTraining,Everyone,Environment,PerformMaintenanceandCustomizations,ProductDevelopment,Leadership&CoordinationCapabilitiesHelpingorganizationsdevelopthecapabilitiestoachieveEnterpriseAgility,UnderstandNeedsoftheCustomer,DevelopProductStrategy,ManageProductPortfolio,AchieveCustomerAcceptance,DefineBusinessRequirements,ProductStrategy,SolutionRequirements,DevelopProduct,LaunchProduct,OperateandSupportProduct,DefineProductBacklog,EstablishProductVision,DefineProductRoadmap,PlanLaunch,EngageStakeholders,Planning,CoordinateLaunch,EstablishDevelopmentEnvironment,ManageSuppliers,EnsureProcessAdherence,IdentifyandRemoveImpediments,EnsureInternalCommunication,MaintainWorkEnvironment,DevelopTeam,SupportOperations,ProvideCustomerSupport,SupportImplementation,CoordinateWork,MaintainArchitecture,UnderstandRequirements,MaintainProductQuality,DesignandEngineerSolution,DeployProduct,IntegrationTesting,LearnfromOutsideSources,CommitToAgility,ManageRisks,ProvideJobTraining,Everyone,Environment,PerformMaintenanceandCustomizations,ProductDevelopment,Scrum团队:ScrumMaster职责,/community/articles/2014/may/what-it-is-that-a-scrum-master-does-all-day-long,主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。,Scrum团队:ScrumMaster能力要求,出色的沟通和决策能力能及时、清楚、明确地传播信息;知道什么时候做出决定,不必要再做分析;平衡短期和长期目标,快速在团队和ProductOwner之间达成一个共同的愿景;促进团队合作的能力能够促进和培养团队合作的能力,能够诊断、理解和帮助团队的日常变化;持续衡量团队工作状况,并推动必要的行动,以改进团队的工作;鼓舞和激励能力促进团队活力,鼓舞、表扬和奖励团队中做得最好的人,宣扬突出的行为、技能和成就;伟大的工作态度,总是寻找方法来改变工作,而不是认同为什么做出改变是不可能的;抗压能力在压力环境下仍能保持镇定,出色工作解决冲突能力促进建设性的辩论,使得产生更好的决策和共同愿景建设性地解决分歧和冲突,知道什么时候让其他人也参与进来在所有交往中,体现出情感成熟度(周到、客观、正直、可靠)即使在他/她不同意的时候,也会支持哪些已经做出的决定敏捷开发实践能力Backlog跟踪,burndown图,会议组织,计划能力,进度跟踪,风险管理,组织变革、团队成长,敏捷开发实践,持续集成/交付/部署,.,参考:/community/articles/2007/april/the-right-skill-set-the-right-mind-set-the-right,Scrum团队:ScrumMaster特质,专注并细心确保团队行为始终与验收标准和项目目标(愿景)保持一致;通过良好的组织方法分配工作任务,减少失误;团队合作者勇于承担任何能够帮助团队的任务,并以身作责(比如,团队决定加班来完成Sprint目标,ScrumMaster应该和团队在一起)善于解决问题的能力是一个能快速获取信息去解决问题的老手;帮助团队识别冲突的优先级,并表达并逐级向上反应不能快速的问题;值得信赖信守承诺,说到做到亲近平易近人,风度翩翩高度的决心和毅力这是成功的关键性因素。因为,对于推动队员思维模式的转变是非常困难的,更不用提整个组织的转变了,特别是在看到组织内部有失败案例的时候;你必须有足够的耐心来帮助团队一步一步地转变,因为要想看到积极的趋势是会花很多时间和精力的。在出现“信任危机”的时候(非常可能出现),你必须要有足够的耐心来说服他人、影响他人;既要理解标准化的Scrum模式,又要根据自己组织的固有特点来实际地运用它这是成功的决定性因素。因为没有任何两家公司是相同的;这也要求你要比较温和的推进转变。记住:欲速则不达;ScrumMaster需要制定一个比较长远的推进计划,然后步步为营,直到团队自己找到基于Scrum框架和思维模式的最佳工作方法;准备好挑战他人并接受他人的挑战向管理层寻求帮助固然有用,但通常比较困难。因此在适当的时候记得去挑战你的老板。很多成功的变革通常是由下至上发起的,不要一味地依赖老板的指示;若在实施过程中受到外界的挑战和动摇,一定要对自己、对团队、对组织有坚定的信心。如果外界的动摇具有10分的摧毁力,那么你自己的动摇则具有100分;持续改进自我的愿望这点不仅适用于团队成员,更是适用于ScrumMaster自身。因为通过自我的持续改进,你才能有效的影响团队成员,让大家积极的凝聚在一起,直到找到最高效的工作方法这一终极目标。,Scrum团队:DevTeam职责,主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在510人左右,每个成员可能负责不同的技术方面,但要求每个成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。主要职责定义(分解)工作任务评估工作量开发产品确保质量完善过程,Scrum团队:DevTeam(1)跨职能团队,Scrum团队:DevTeam(2)特性团队,ComponentTeam,FeatureTeam,VS.,ComponentTeam的组织方式会导致瀑布式的开发流程,以便协调团队间的工作任务。,FeatureTeam组织方式的成功依赖于团队能力,以及团队对于重构、持续集成、自动化测试等敏捷开发工具和实践的使用。,Scrum团队:DevTeam成员能力拓展,成就全栈工程师,瀑布式:团队成员专司一职,难以获得横向拓展,SCRUM:人们可能主要技能不尽相同,如有人擅长开发而另外的人擅长测试,但是,在Scrum团队里,我们鼓励团队成员学习新的领域技能,尝试在新的领域工作,团队成员跨领域互相帮助完成一项产品特性。比如,一个“架构师”可能要写自动化测试代码,而一个“测试人员”则可能要分析业务。,SCRUM(三):SCRUM工件,SCRUM工件核心工件:ProductBacklog,SprintBacklog,ShippableProductIncrement;其它工件:Dependencies/Blockerlist;,SCRUM工件:ProductBacklog,ProductBacklog是条目化/量化的用户需求,它将需求文档中需要实际开发的需求(包括功能性和非功能性需求)条目化地表达出来。ProductOwner维护,用场景描述的用户需求(Story)列表经过优先级排序和工作量评估的优先级越高的条目,UserStory描述粒度越细反映了业务的计划,SCRUM工件:PB(1)Items,Myprimaryruleforincludinganyitemintheproductbacklogisthattheworkmustbesomethingtheproductownercanunderstandandcanreasonablyprioritizeagainstfeatures.SoifyoudochoosetoincludePBIsoftypetechnicalwork,youwillneedtomakethevalueoftheitemcleartotheproductowner.,SCRUM工件:PB(2)UserStory描述,Asa,IwantaSothatIcanget.,基于目标和场景驱动,体现业务价值,SCRUM工件:PB(3)UserStory粒度,按照业务优先级次序,将大粒度的用户故事拆解为小粒度的用户故事,并依次经过评估后安排进入Release计划和Sprint计划,SCRUM工件:PB(4)UserStory优先级,SCRUM工件:PB(5)UserStory评估,用户故事INVEST模式Independent:减少依赖,便于计划Negotiable:通过协作添加细节Valuable:对客户有价值Estimable:太大或太模糊的用户故事,无法评估Small:可以在由一个团队在一周内完成Testable:有好的验收原则评估用户故事的大小StoryPointsAnchorStory,相对值评估斐波那契数列和扑克牌游戏贴墙技术衡量团队Velocity用46个Sprint来确定速率,SCRUM工件:PB(6)非功能性需求描述,Nonfunctionalrequirementsrepresentimportantsystem-levelconstraintsthataffectthedesignandtestingofmostorallitemsintheproductbacklog.Nonfunctionalrequirementsareusedtospecifyvariouscharacteristicssuchassystemperformance,accuracy,portability,reusability,maintainability,interoperability,capacity,platformfan-out,andsoon.以UserStory方式描述NFR,有助于理解部分技术决策背后的原因,如:Asacustomer,IwanttobeabletorunyourproductonallversionsofWindowsfromWindows95on.AstheCTO,Iwantthesystemtouseourexistingordersdatabaseratherthancreateanewone,sothatwedonthaveonemoredatabasetomaintain.Asauser,Iwantthesitetobeavailable99.999percentofthetimeItrytoaccessit,sothatIdontgetfrustratedandfindanothersitetouse.AssomeonewhospeaksaLatin-basedlanguage,Imightwanttorunyoursoftwaresomeday.Asauser,Iwantthedrivingdirectionstobethebest90percentofthetime,andreasonable99percentofthetime.参考,SCRUM工件:SprintBacklog,确保考虑到工作中所有细节:编码、测试、代码评审、会议、学习新技术、编写文档Sprinttasks需要评估到小时如果任务需时超过一天,尝试分割成几个小任务如果团队认为SprintBacklog项目过多或过少,和产品负责人一起调整问题数量团队确认Sprint目标如果工作不清晰,可以先建一个粗粒度的SprintBacklog,然后再分解所有任务项都分配给团队成员每日更新剩余工作评估团队成员对任务的DoD(Definitionof“Done”)应该有共同的理解只计算全力以赴完成所需要的时间,剩下的交给燃尽(Burndown)图解决,SprintBacklog是Scrum团队在SprintPlanning会议中确认的待办任务列表,映射到传统项目管理理论中就是WBS,而且是典型的采用面向交付物的任务分解方法得到的WBS。,SCRUM工件:ImpedimentsList(1),Impediments(障碍)是指任何阻止团队有效工作的事或物。部分障碍可以由团队自己解决,其中一些障碍的跟踪最好能对全团队可见。部分障碍超出团队能够解决的范围,需要ScrumMaster找出相关的干系人来一起解决也有一些小而重要的障碍,可能是公司组织所固有的,任何一个团队无法独立解决,需要公司层面企业文化、组织架构的变革来解决,这需要ScrumMaster推动管理层完成。,SCRUM工件:ImpedimentsList(2),10大典型障碍会议规则没能被遵循产品远景和Sprint目标不清晰没有产品负责人负责回答提问产品Backlog未能按商业价值区分优先级并不是所有负责交付产品的人员都是团队里的成员ScrumMaster还要处理其他任务,不能集中精力团队人数过多(多于7个开发人员)团队没有能坐在一起工作的空间团队的SprintBacklog混乱以障碍Backlog方式管理障碍把所有已知的障碍加入到障碍Backlog的“新事项”栏中按优先级顺序排列“新事项”栏中的障碍问题每当您开始着手解决一个障碍问题时,将它移至“正在处理事项”栏中尽快解决这个障碍障碍得到解决时,将它移到“已完成”事项栏中在Scrum每日例会和Sprint回顾会议中收集新的障碍问题,Scrum工件:Definitionof“Done”,对于Scrum工件中的条目,团队一起定义“Done”(“完成”)的真实内在含义,以免在评估项目时发生误解和分歧。“Done”的几个例子:Design,coding,unittesting,integratedStaticanalysis,refactoredAcceptancetested,deployable,/community/articles/2008/september/definition-of-done-a-reference,Scrum(四):Scrum活动,Scrum活动:ReleasePlanning(1),Who:ScrumCoach,ProductOwner,ScrumTeam,ScrumMaster,KeyStakeholdersWhen:beforereleasen+1begins(.5-2days)How/Topic(s):POpresentsthevision,strategyandgoals.POpresentkeydatesandmilestones.POpresentsdraftoftheprioritizedbacklog.Discussiontounderstanduserstories.Reviewroughestimates+prioritizedfeatures.AgreementonSprintlength(inweeks)andtargetreleasedates.ReleasePlanisorganizedbyscope(functionality)ortime(releaseeveryNsprints).ContinualPlanning.Theinitialreleaseplanisablueprinttogetstartedandwillberevised.,Selectedstoriesfortherelease,ProductVision,Highlevelprioritizedgoals&roadmap,Keyrisksandassumptions,Stakeholderconsensus,Prioritizedproductbacklog,Goal:Establishtheoverallreleasescheduleanddetermineinwhatsprintstorieswilllikelybedelivered.,ProductBacklog(prioritydraft),ReleasePlan,RoughEstimates,产品负责人和团队一起对整个产品Backlog进行评估,提出划分发行版本和Sprint计划的主要依据。,Scrum活动:ReleasePlanning(2),一个企业级ReleasePlanning会议活动日程安排的示例:,Scrum活动:SprintPlanning(1),Who:ScrumCoach,ProductOwner,ScrumTeam,ScrumMaster.When:beforeSprintn+1begins(2-3hrs).How/Topic(s):POpresentsthebacklogitemsinpriorityorderforreview.Storieswithfailedacceptancetestsfrompriorsprintsareadded*.Discussstorycreationfordefectsfrompriorsprints*.Reviewandclarifyuserstories.Breakdownlargerstoriesandeachstoryintotasksandacceptancecriteria.Tasksareestimatedinhours.1developerandtesterassignedtobeonpointperstory.Processcontinuesuntilallavailablehoursareusedforthesprint.,Selectedstoriesforthesprint,SprintPlan,Prioritizedproductbacklog,Teamscapabilities(hours),Keyrisksandassumptions,Stakeholderconsensus,Goal:Teamtoplanandagreeonbacklogitemstheycancompleteandconfirmthetasksrequiredtosupportacceptance.,Schedulerisks/Businessconditions,ReleasePlan,PriorVelocity,StoryEffortEstimation,Scrum活动:SprintPlanning(2),一个分两阶段议程Spring计划会议的例子:Sprint计划会议1:产品负责人和团队一起,在先前评估的成果基础上,定出Sprint目标和既定产品Backlog。Sprint计划会议2:团队将既定产品Backlog中的每一项细化成多个任务,每个任务完成的时间限定在一天内。,Scrum活动:DailyMeeting,每日例会:有助于团队进行自我组织。这是项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在15分钟内。与会者:团队所有成员,ScrumMaster,产品负责人(可选),相关人员(可选)三个重要问题:上次会议后我完成了什么?到下次会议开始我准备做什么?有什么障碍阻止了我的工作进度?更新SprintBacklog,包括增减任务项、更新任务进度和状态会议控制:如果展开了一个问题的讨论,提醒团队成员们注意把注意力集中在回答关键问题上如果相关人员想发表些言论,礼貌地提醒他,该会议只允许让小组成员讨论。,Scrum活动:SprintReviewMeeting,评审会议:在每个Sprint结束后,将这个Sprint的工作成果演示给ProductOwner和其他相关的人员。团队按照Backlog中的问题,逐个地介绍这次Sprint的结果,和演示新功能如果产品负责人想要改变功能,添加一个新问题到产品Backlog中如果对功能有一个新的想法,添加一个新问题到产品Backlog中如果小组报告项目遇到阻碍现在还没能解决,把该障碍加入到障碍Backlog团队达成对这次Sprint的结果和整个产品的开发状态的共识,Scrum活动:SprintRetroMeeting,回顾会议:在每个Sprint结束后,对于当前的迭代周期做一个阶段性的总结,包括好的方面和不好的方面,帮助团队在下一个迭代中扬长避短,对于一个团队的健康发展很有好处。主要指导原则:不管我们现在发现了什么问题,我们必须懂得并坚信每个人通过他们当时所知的,他所拥有的技能和可得到的资源,在限定的环境下,都尽其所能做出了最好的成绩在画板上写上“我们的成功经验是什么(WellDone)”、“有什么能够改进(NeedsImprovement)”针对以上总结,制定团队完善的ActionItems(可以合并到ImpedimentsList),指定负责人和完成时间,ScrumMaster带领团队尽可能落实一般可以从以下方面来进行回顾:开发团队效率如何开发团队合作如何项目进展曲线是否平稳开发团队前端和后端的分工如何测试团队的缺陷报告率如何开发周期中有没有被严重Block的因素有没有需求方面的不明确导致Rework在任务分配方面有没有不均衡,导致个别人太忙或者太闲,Scrum(五):度量,燃尽图是在项目完成之前,对需要完成的工作的一种可视化表示。燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下,该图表是一个向下的曲线,随着剩余工作的完成,“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。速度(Velocity)表示每一个团队每一次迭代所产生的故事点的数量。,Scrum回顾:全景视图,Scrum回顾:要素,思考:Scrum流程框架的问题,产品上线后的运营,是一种事件驱动的模式,每天都有问题需要优先处理,不适合开发人员与运营人员合一的小型公司/小型团队无法事先计划不被打扰的固定周期太短的周期也不行,有的任务会超过一个周期UX/UI设计跟程序设计开发的周期搭配问题不同平台(iOS,Android,Web)开发周期搭配问题AppStore审核时间不一定两周的开发迭代周期公司仍不满意,可不可以更快,做到极致?,流程框架演进:KanbanBoard,最轻量的流程管理方法WIP限制(TOC限制理论)限制每个状态的最多项目关注CycleTime(平均每个条目的完成时间)流程状态(列)可自行裁剪,适用于大小项目,Kanban:vsScrum,Kanban工作流程(一),http:/blog.crisp.se/2009/06/26/henrikkniberg/1246053060000,Kanban工作流程(二),http:/blog.crisp.se/2009/06/26/henrikkniberg/1246053060000,更多流程框架比较,(更规范),(更灵活),每种方法都有一定的局限性不要限制自己只使用某一种工具!,流程框架的组合使用示例,StoryBacklog,TaskBacklog,InProcess,TaskDone,StoryBacklog,Analysis,Design,Build,Test,Deploy,Inception,Elaboration,Construction,Transition,Tier1-Scrum,Tier2-Kanban,Tier3-Kanban,Epic,Feature,UserStory,大型项目流程框架:ScrumofScrums,AgendaThreequestionsWhathasmyteamdonesincewelastmetthatmightaffectotherteams?Whatwillmyteamdobeforewemeetagainthatmightaffectotherteams?Whatproblemsaremyteamhavingthatotherteamsmightbeabletohelpwith?DiscussionDiscussitemskeptonanOpenIssuesBacklog,企业级项目流程框架:SAFe,敏捷方法和最佳实践,敏捷方法和最佳实践概览,战略:-机会画布方法-商业模式画布方法-精益画布方法-价值主张画布-企业架构方法,需求:-需求捕获技术-需求建模技术-需求UserStory描述方法-需求优先级评估方法-UserStory切分技术-UserStoryMapping-UML用例建模技术,反馈:-数字化评估方法,实现:-敏捷架构设计方法-产品交互体验设计方法-模型驱动开发技术-持续交付技术,组织:-组织结构-打造领导力驱动型团队-研发过程管理规范体系建设,战略:机会画布方法,探寻机会的思维方式:移情:理解你的用户定义:识别问题构思:头脑风暴,形成思路原型:用线框图或代码快速搭建原型验证:验证并优化,战略:商业模式画布方法,商业模式描述了企业如何创造价值、传递价值和获取价值的基本原理。商业模式画布是一种用来描述商业模式、可视化商业模式、评估商业模式以及改变商业模式的通用语言。参考:商业模式新生代,战略:精益画布(LeanCanvas)方法,精益画布是从商业模式画布改编而来的,具有制作迅速、内容紧凑、方便携带的特点,便于创业者记录和交流自己的商业模式。我们可以把新产品开发当作一次创业来看待。参考:精益创业实战,战略:产品精益画布扩展版本,精益画布扩展版本涉及更多编写商业计划书所需要考虑的内容。来源:,战略:SocialLeanCanvas,战略:价值主张画布,战略:商业模式画布方法概览,战略:企业架构方法,企业架构和敏捷架构:企业架构关注于整个企业的IT架构规划,而敏捷架构关注于项目交付层面;企业架构是着重于企业的未来,而敏捷架构是着眼于项目的当下;企业架构是自顶向下的架构方法,而敏捷架构更偏向于自下而上的架构方法,两者相辅相成,可以互为补充。可参考架构模型:TMForum-eTOM/SID/TAM/TNANRF-ARTS,需求:需求工程,source-,敏捷需求管理的目标:关注用户价值强调用户参与适应需求变化快速迭代实现,需求:需求捕获,需求捕获指南,需求捕获是软件项目的基础部分,对后继的分析设计及开发实施有重大影响。如果做的好,会减少需求变更和返工。此外,需求捕获过程的质量也将决定客户对需求的完整性、正确性的认可。因为这个阶段的困难性和影响力,按一个理想的模式来完成需求捕获过程就非常重要。需求捕获可定义为:需求捕获是两个有关团体相互沟通,识别需要的过程。两个团体通过这个过程提取、定义需求,来约束两个团队。需求捕获既涉及技术问题,也涉及社会交往问题。参考:需求捕获指南,sourc
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 麻风防治课件
- 二零二五年度城市更新项目二手房产全款交易协议
- 二零二五年度木屑生物质能项目合作与采购合同
- 2025版高层住宅楼防水保温工程承包合同
- 二零二五年度文化创意园区场地租赁安全合作协议
- 二零二五年度房屋拆除与智能家居系统安装合同
- 二零二五年度医疗影像技术合作开发合同范本
- 2025年度汽车美容店经营权整体转让合同范本
- 二零二五年电杆运输安全设备维护合同样本
- 二零二五年度电力线路施工与安装工程监理合同
- GB/T 18233.4-2024信息技术用户建筑群通用布缆第4部分:住宅
- 2024届广西南宁市三中高三第一次适应性考试历史试题及答案
- 山东卷2025届高三物理上学期12月一轮复习联考试题四
- 刨削刀头产品技术要求deyidamei
- 《三国志曹操传》完整攻略(包括单挑、宝物、对话选择)
- 2021-2022年度广东省职业院校学生专业技能大赛信息网络布线赛项规程
- 2024-2030年中国聚乳酸纤维行业销售格局与供需平衡现状调研研究报告
- 自行车安全要求 第2部分:城市和旅行用自行车、青少年自行车、山地自行车与竞赛自行车的要求
- 新版译林英语五年级上第一二单元测试含听力文本和答案
- 丽江古城导游词标准版本
- 教育教学设备采购合同
评论
0/150
提交评论