敏捷开发全景视图(流程、方法和最佳实践)

目录

Contents

敏捷vs传统敏捷开发流程框架敏捷方法和最佳实践思考与答疑第一页，共99页。敏捷vs传统第二页，共99页。IT项目管理方法的发展历史196019701980199020002010SDLCWATERFALLRADPMBOKITILPRINCEZachmanDSDMRUPXPPRINCE2CRYSTALSCRUMAGILEMANIFESTOFEATOGAF8.0LEANKANBAN第三页，共99页。软件开发生命周期（SDLC）

第四页，共99页。传统软件开发模式传统瀑布式软件开发方式向迭代式软件开发方式转变（RUP框架）第五页，共99页。传统软件开发模式存在的问题传统软件件开发过程的常见症结交付周期长；害怕需求变更；中间过程不可控；测试周期被一缩再缩；最终结果差强人意与“唯快不破”的互联网经济格格不入第六页，共99页。敏捷软件开发模式由传统迭代式软件开发模式发展而来，Time-Boxed抛开传统软件开发模式的繁文缛节，强调产品价值、团队协作、客户参与、先期验证、简化流程、拥抱变化总结吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成前期有学习成本，后期会获益匪浅敏捷软件开发模式Source:ForresterResearch,Inc.第七页，共99页。趋势：敏捷开发逐渐成为主流模式2009Q32014Growth第八页，共99页。敏捷开发带来的好处TOP5reportedbenefits:Improvedquality(56%)Moreopportunitiesformid-coursecorrections(56%)Overallimprovedcustomerandbusinesssatisfaction(38%)Betterbusiness-ITalignment(37%)Improvedtimetomarket(32%)Alotmorethanvelocity质量改善利于中途修正总体改善客户和业务的满意度商业需求与IT实施更加匹配更快投入市场Source:2013ForresterResearch,Inc.第九页，共99页。敏捷开发宣言ManifestoforAgileSoftwareDevelopmentIndividualsandinteractionsoverprocessesandtools

人和交互重于过程和工具Workingsoftwareovercomprehensivedocumentation

可以工作的软件重于面面俱到的文档Customercollaborationovercontractnegotiation

客户合作重于合同谈判Respondingtochangeoverfollowingaplan

随时应对变化重于遵循计划虽然右边也有其价值，但我们认为左项更加重要第十页，共99页。敏捷原则(AgilePrinciples)SatisfytheCustomerWelcomeChangeDeliverFrequentlyWorkasaTeamMotivatePeopleCommunicateFace-to-FaceMeasureWorkingSoftwareMaintainConstantPaceExcelatQualityKeepitSimpleEvolveDesignsReflectRegularly第十一页，共99页。敏捷开发价值观专注：由于我们在一段时间内只专注于少数几件事情，所以我们可以很好地合作并获得优质的产出。我们能够更快地交付有价值的事项。公开：在团队合作中，大家都会表达我们做得如何，以及遇到的障碍。我们发现将担忧说出来是一件好事，因为只有这样才能让这些担忧及时得到解决。尊重：因为我们在一起工作，分享和成功失败，这有助于培养并加深互相之间的尊重，并帮助彼此成为值得尊重的人。承诺：由于对自己的命运有更大的掌握，我们会有更坚强的信念获得成功。勇气：因为我们不得单打独斗，我们能够感受到支持，而且掌握更多的资源。这一切赋予我们勇气去迎接更大的挑战。第十二页，共99页。从传统到敏捷：思维的转变形而上者谓之道，形而下者谓之器。

形而上者起于学、行于理、止于道，形而下者起于教、行于法、止于术。从重视“流程”到重视“原则”道本器末，不忘初心做正确的事比正确地做事更重要如何看待流程、方法、最佳实践在敏捷开发中的作用无其器则无其道，器和道一样重要上善若水，原则的“刚性”和流程的“柔性”第十三页，共99页。从传统到敏捷：认识误区第十四页，共99页。从传统到敏捷：阻碍和要点改变我们的商业文化采用敏捷技术实践改变我们的IT文化以一种敏捷的态度使用我们现有的工具采用新的敏捷开发工具采用敏捷管理实践第十五页，共99页。从传统到敏捷：关键因素改变我们的商业文化采用敏捷管理实践改变我们的IT文化采用敏捷技术实践采用新的敏捷开发工具以一种敏捷的态度使用我们现有的工具第十六页，共99页。敏捷开发流程框架第十七页，共99页。产品研发：一个持续的过程What？How？Managementisdoingthingsright;leadershipisdoingtherightthings.

(PeterDrucker)第十八页，共99页。敏捷开发流程框架：Scrum注：Scrum是最为流行的敏捷开发流程框架之一What？How？第十九页，共99页。Scrum框架：简介

Scrum是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprintbacklog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。要素：周期：ProductRelease<=Time-BoxedSprint<=DailyContinousDelivery团队：ProductOwner，ScrumMaster，DevTeam(Cross-Functional)工件：ProductBacklog，SprintBacklog，ProductIncrement活动：SprintPlanningMeeting/ReviewMeeting/RetrospectiveMeeting，DailyScrumMeeting，ProductBacklogRefinement度量：Burndown图、Burnup图、Velocity第二十页，共99页。Scrum（一）：迭代周期框架迭代周期框架：

ProductRelease<=Time-BoxedSprint<=DailyContinousDelivery业务战略传递：Strategy=>Portfolio=>Product=>Release=>Sprint=>DailyWorkingWhat？How？第二十一页，共99页。Scrum（二）：团队BuildTheRightThingBuildTheThingRightBuildItFastScrumTeamAchievement-orientedCustomer-orientedCommittedMotivatedSelf-organizedEmpoweredSkilled第二十二页，共99页。Scrum团队：团队文化共赢的文化团队成功个人发展立足现实挑战极限第二十三页，共99页。Scrum团队：角色分工概览第二十四页，共99页。Scrum团队：ProductOwner职责主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权利接受或拒绝开发团队的工作成果PO在Scrum中承担了多项职责产品经理：愿景和方向，结果负责需求分析：业务分析和需求分析需求管理：维护、终止和变更项目管理：优先级排序和项目状态跟踪质量保障：检查产品结果客户代表：产品体验/接受拒绝PO对外承担了与产品干系人交流沟通的职责老板、客户和用户、营销和销售、…第二十五页，共99页。Scrum团队：PO的职责关系http:///resources/the-strategic-role-of-product-management-when-development-goes-agile?p=0ProductOwner属于研发角色，但与战略、市场和销售等公司其它角色存在密切合作关系，需要掌握跨界知识和语言表达。图示表现了产品管理四种角色之间的关系和分工定义，但根据项目规模不同，某一成员可能身兼数职。第二十六页，共99页。Scrum团队：PO能力要求业务分析能力（BusinessAnalysis）工程技术能力（Engineering）领导和协调能力（Leadership&Coordination）第二十七页，共99页。BusinessAnalysisCapabilities

HelpingorganizationsdevelopthecapabilitiestoachieveEnterpriseAgilityUnderstandNeedsoftheCustomerDevelopProductStrategyManageProductPortfolioAchieveCustomerAcceptanceDefineBusinessRequirementsProductStrategySolutionRequirementsDevelopProductLaunchProductOperateandSupportProductDefineProductBacklogEstablishProductVisionDefineProductRoadmapPlanLaunchEngageStakeholdersPlanningCoordinateLaunchEstablishDevelopmentEnvironmentManageSuppliersEnsureProcessAdherenceIdentifyandRemoveImpedimentsEnsureInternalCommunicationMaintainWorkEnvironmentDevelopTeamSupportOperationsProvideCustomerSupportSupportImplementationCoordinateWorkMaintainArchitectureUnderstandRequirementsMaintainProductQualityDesignandEngineerSolutionDeployProductIntegrationTestingLearnfromOutsideSourcesCommitToAgilityManageRisksProvideJobTrainingEveryoneEnvironmentPerformMaintenanceandCustomizationsProductDevelopment第二十八页，共99页。EngineeringCapabilities

HelpingorganizationsdevelopthecapabilitiestoachieveEnterpriseAgilityUnderstandNeedsoftheCustomerDevelopProductStrategyManageProductPortfolioAchieveCustomerAcceptanceDefineBusinessRequirementsProductStrategySolutionRequirementsDevelopProductLaunchProductOperateandSupportProductDefineProductBacklogEstablishProductVisionDefineProductRoadmapPlanLaunchEngageStakeholdersPlanningCoordinateLaunchEstablishDevelopmentEnvironmentManageSuppliersEnsureProcessAdherenceIdentifyandRemoveImpedimentsEnsureInternalCommunicationMaintainWorkEnvironmentDevelopTeamSupportOperationsProvideCustomerSupportSupportImplementationCoordinateWorkMaintainArchitectureUnderstandRequirementsMaintainProductQualityDesignandEngineerSolutionDeployProductIntegrationTestingLearnfromOutsideSourcesCommitToAgilityManageRisksProvideJobTrainingEveryoneEnvironmentPerformMaintenanceandCustomizationsProductDevelopment第二十九页，共99页。Leadership&CoordinationCapabilities

HelpingorganizationsdevelopthecapabilitiestoachieveEnterpriseAgilityUnderstandNeedsoftheCustomerDevelopProductStrategyManageProductPortfolioAchieveCustomerAcceptanceDefineBusinessRequirementsProductStrategySolutionRequirementsDevelopProductLaunchProductOperateandSupportProductDefineProductBacklogEstablishProductVisionDefineProductRoadmapPlanLaunchEngageStakeholdersPlanningCoordinateLaunchEstablishDevelopmentEnvironmentManageSuppliersEnsureProcessAdherenceIdentifyandRemoveImpedimentsEnsureInternalCommunicationMaintainWorkEnvironmentDevelopTeamSupportOperationsProvideCustomerSupportSupportImplementationCoordinateWorkMaintainArchitectureUnderstandRequirementsMaintainProductQualityDesignandEngineerSolutionDeployProductIntegrationTestingLearnfromOutsideSourcesCommitToAgilityManageRisksProvideJobTrainingEveryoneEnvironmentPerformMaintenanceandCustomizationsProductDevelopment第三十页，共99页。Scrum团队：ScrumMaster职责主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。第三十一页，共99页。Scrum团队：ScrumMaster能力要求出色的沟通和决策能力能及时、清楚、明确地传播信息；知道什么时候做出决定，不必要再做分析；平衡短期和长期目标，快速在团队和ProductOwner之间达成一个共同的愿景；促进团队合作的能力能够促进和培养团队合作的能力，能够诊断、理解和帮助团队的日常变化；持续衡量团队工作状况，并推动必要的行动，以改进团队的工作；鼓舞和激励能力促进团队活力，鼓舞、表扬和奖励团队中做得最好的人，宣扬突出的行为、技能和成就；伟大的工作态度，总是寻找方法来改变工作，而不是认同为什么做出改变是不可能的；抗压能力在压力环境下仍能保持镇定，出色工作解决冲突能力促进建设性的辩论，使得产生更好的决策和共同愿景建设性地解决分歧和冲突，知道什么时候让其他人也参与进来在所有交往中，体现出情感成熟度（周到、客观、正直、可靠）即使在他/她不同意的时候，也会支持哪些已经做出的决定敏捷开发实践能力Backlog跟踪，burndown图，会议组织，计划能力，进度跟踪，风险管理，组织变革、团队成长，敏捷开发实践，持续集成/交付/部署，...参考：https第三十二页，共99页。Scrum团队：ScrumMaster特质专注并细心确保团队行为始终与验收标准和项目目标（愿景）保持一致；通过良好的组织方法分配工作任务，减少失误；团队合作者勇于承担任何能够帮助团队的任务，并以身作责（比如，团队决定加班来完成Sprint目标，ScrumMaster应该和团队在一起）善于解决问题的能力是一个能快速获取信息去解决问题的老手；帮助团队识别冲突的优先级，并表达并逐级向上反应不能快速的问题；值得信赖信守承诺，说到做到亲近平易近人，风度翩翩高度的决心和毅力这是成功的关键性因素。因为，对于推动队员思维模式的转变是非常困难的，更不用提整个组织的转变了，特别是在看到组织内部有失败案例的时候；你必须有足够的耐心来帮助团队一步一步地转变，因为要想看到积极的趋势是会花很多时间和精力的。在出现“信任危机”的时候（非常可能出现），你必须要有足够的耐心来说服他人、影响他人；既要理解标准化的Scrum模式，又要根据自己组织的固有特点来实际地运用它这是成功的决定性因素。因为没有任何两家公司是相同的；这也要求你要比较温和的推进转变。记住：欲速则不达；ScrumMaster需要制定一个比较长远的推进计划，然后步步为营，直到团队自己找到基于Scrum框架和思维模式的最佳工作方法；准备好挑战他人并接受他人的挑战向管理层寻求帮助固然有用，但通常比较困难。因此在适当的时候记得去挑战你的老板。很多成功的变革通常是由下至上发起的，不要一味地依赖老板的指示；若在实施过程中受到外界的挑战和动摇，一定要对自己、对团队、对组织有坚定的信心。如果外界的动摇具有10分的摧毁力，那么你自己的动摇则具有100分；持续改进自我的愿望这点不仅适用于团队成员，更是适用于ScrumMaster自身。因为通过自我的持续改进，你才能有效的影响团队成员，让大家积极的凝聚在一起，直到找到最高效的工作方法这一终极目标。第三十三页，共99页。Scrum团队：DevTeam职责主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。主要职责定义（分解）工作任务评估工作量开发产品确保质量完善过程第三十四页，共99页。Scrum团队：DevTeam(1)跨职能团队第三十五页，共99页。Scrum团队：DevTeam(2)特性团队ComponentTeamFeatureTeamVS.ComponentTeam的组织方式会导致瀑布式的开发流程，以便协调团队间的工作任务。FeatureTeam组织方式的成功依赖于团队能力，以及团队对于重构、持续集成、自动化测试等敏捷开发工具和实践的使用。第三十六页，共99页。Scrum团队：DevTeam成员能力拓展成就全栈工程师瀑布式：团队成员专司一职，难以获得横向拓展SCRUM：人们可能主要技能不尽相同，如有人擅长开发而另外的人擅长测试，但是，在Scrum团队里，我们鼓励团队成员学习新的领域技能，尝试在新的领域工作，团队成员跨领域互相帮助完成一项产品特性。比如，一个“架构师”可能要写自动化测试代码，而一个“测试人员”则可能要分析业务。。第三十七页，共99页。SCRUM（三）：SCRUM工件SCRUM工件核心工件：ProductBacklog，SprintBacklog，ShippableProductIncrement；其它工件：Dependencies/Blockerlist；第三十八页，共99页。SCRUM工件：ProductBacklogProductBacklog是条目化/量化的用户需求，它将需求文档中需要实际开发的需求（包括功能性和非功能性需求）条目化地表达出来。ProductOwner维护，用场景描述的用户需求(Story)列表经过优先级排序和工作量评估的优先级越高的条目，UserStory描述粒度越细反映了业务的计划第三十九页，共99页。SCRUM工件：PB(1)ItemsMyprimaryruleforincludinganyitemintheproductbacklogisthattheworkmustbesomethingtheproductownercanunderstandandcanreasonablyprioritizeagainstfeatures.

SoifyoudochoosetoincludePBIsoftype

technicalwork,youwillneedtomakethevalueoftheitemcleartotheproductowner.http第四十页，共99页。SCRUM工件：PB(2)UserStory描述Asa<USERROLE>,Iwanta<FUNCTIONALITY>SothatIcanget<BUSINESSVALUE>.基于目标和场景驱动，体现业务价值第四十一页，共99页。SCRUM工件：PB(3)UserStory粒度按照业务优先级次序，将大粒度的用户故事拆解为小粒度的用户故事，并依次经过评估后安排进入Release计划和Sprint计划第四十二页，共99页。SCRUM工件：PB(4)UserStory优先级第四十三页，共99页。SCRUM工件：PB(5)UserStory评估用户故事INVEST模式Independent:减少依赖，便于计划Negotiable:通过协作添加细节Valuable:对客户有价值Estimable:太大或太模糊的用户故事，无法评估Small:可以在由一个团队在一周内完成Testable:有好的验收原则评估用户故事的大小StoryPointsAnchorStory，相对值评估斐波那契数列和扑克牌游戏贴墙技术衡量团队Velocity用4~6个Sprint来确定速率第四十四页，共99页。SCRUM工件：PB(6)非功能性需求描述Nonfunctionalrequirements

representimportantsystem-levelconstraintsthataffectthedesignandtestingofmostorallitemsintheproductbacklog.Nonfunctionalrequirementsareusedtospecifyvariouscharacteristicssuchassystemperformance,accuracy,portability,reusability,maintainability,interoperability,capacity,platformfan-out,andsoon.以UserStory方式描述NFR，有助于理解部分技术决策背后的原因，如：Asacustomer,IwanttobeabletorunyourproductonallversionsofWindowsfromWindows95on.AstheCTO,Iwantthesystemtouseourexistingordersdatabaseratherthancreateanewone,sothatwedon'thaveonemoredatabasetomaintain.Asauser,Iwantthesitetobeavailable99.999percentofthetimeItrytoaccessit,sothatIdon'tgetfrustratedandfindanothersitetouse.AssomeonewhospeaksaLatin-basedlanguage,Imightwanttorunyoursoftwaresomeday.Asauser,Iwantthedrivingdirectionstobethebest90percentofthetime,andreasonable99percentofthetime.参考http:///nonfunctional-requirements/第四十五页，共99页。SCRUM工件：SprintBacklog确保考虑到工作中所有细节：编码、测试、代码评审、会议、学习新技术、编写文档…Sprint

tasks需要评估到小时如果任务需时超过一天，尝试分割成几个小任务如果团队认为SprintBacklog项目过多或过少，和产品负责人一起调整问题数量团队确认Sprint目标如果工作不清晰，可以先建一个粗粒度的SprintBacklog，然后再分解所有任务项都分配给团队成员每日更新剩余工作评估团队成员对任务的DoD(Definitionof“Done”)应该有共同的理解只计算全力以赴完成所需要的时间，剩下的…交给燃尽(Burndown)图解决SprintBacklog是Scrum团队在SprintPlanning会议中确认的待办任务列表，映射到传统项目管理理论中就是WBS，而且是典型的采用面向交付物的任务分解方法得到的WBS。第四十六页，共99页。SCRUM工件：ImpedimentsList(1)Impediments（障碍）是指任何阻止团队有效工作的事或物。部分障碍可以由团队自己解决，其中一些障碍的跟踪最好能对全团队可见。部分障碍超出团队能够解决的范围，需要ScrumMaster找出相关的干系人来一起解决也有一些小而重要的障碍，可能是公司组织所固有的，任何一个团队无法独立解决，需要公司层面企业文化、组织架构的变革来解决，这需要ScrumMaster推动管理层完成。第四十七页，共99页。SCRUM工件：ImpedimentsList(2)10大典型障碍会议规则没能被遵循产品远景和Sprint目标不清晰没有产品负责人负责回答提问产品Backlog未能按商业价值区分优先级并不是所有负责交付产品的人员都是团队里的成员ScrumMaster还要处理其他任务，不能集中精力团队人数过多（多于7个开发人员）团队没有能坐在一起工作的空间团队的SprintBacklog混乱以障碍Backlog方式管理障碍把所有已知的障碍加入到障碍Backlog的“新事项”栏中按优先级顺序排列“新事项”栏中的障碍问题每当您开始着手解决一个障碍问题时，将它移至“正在处理事项”栏中尽快解决这个障碍障碍得到解决时，将它移到“已完成”事项栏中在Scrum每日例会和Sprint回顾会议中收集新的障碍问题第四十八页，共99页。Scrum工件：Definitionof“Done”对于Scrum工件中的条目，团队一起定义“Done”（“完成”）的真实内在含义，以免在评估项目时发生误解和分歧。“Done”的几个例子：Design,coding,unittesting,integratedStaticanalysis,refactoredAcceptancetested,deployable第四十九页，共99页。Scrum（四）：Scrum活动第五十页，共99页。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.Theinitialreleaseplanisa‘blueprint’togetstartedandwillberevised.SelectedstoriesforthereleaseProductVisionHighlevelprioritizedgoals&roadmapKeyrisksandassumptionsStakeholderconsensusPrioritizedproductbacklogGoal:Establishtheoverallreleasescheduleanddetermineinwhatsprintstorieswilllikelybedelivered.ProductBacklog(prioritydraft)ReleasePlanRoughEstimates产品负责人和团队一起对整个产品Backlog进行评估，提出划分发行版本和Sprint计划的主要依据。第五十一页，共99页。Scrum活动：ReleasePlanning(2)一个企业级ReleasePlanning会议活动日程安排的示例：第五十二页，共99页。Scrum活动：SprintPlanning(1)Who:ScrumCoach,ProductOwner,ScrumTeam,ScrumMaster.When:beforeSprintn+1begins(2-3hrs).How/Topic(s):POpresentsthebacklogitemsinpriorityorderforreview.Storieswithfailedacceptancetestsfrompriorsprintsareadded*.Discussstorycreationfordefectsfrompriorsprints*.Reviewandclarifyuserstories.Breakdownlargerstoriesandeachstoryintotasksandacceptancecriteria.Tasksareestimatedinhours.1developerandtesterassignedtobeonpointperstory.Processcontinuesuntilallavailablehoursareusedforthesprint.SelectedstoriesforthesprintSprintPlanPrioritizedproductbacklogTeamscapabilities(hours)KeyrisksandassumptionsStakeholderconsensusGoal:Teamtoplanandagreeonbacklogitemstheycancompleteandconfirmthetasksrequiredtosupportacceptance.Schedulerisks/BusinessconditionsReleasePlanPriorVelocityStoryEffortEstimation第五十三页，共99页。Scrum活动：SprintPlanning(2)一个分两阶段议程Spring计划会议的例子：Sprint计划会议1：产品负责人和团队一起，在先前评估的成果基础上，定出Sprint目标和既定产品Backlog。Sprint计划会议2：团队将既定产品Backlog中的每一项细化成多个任务，每个任务完成的时间限定在一天内。第五十四页，共99页。Scrum活动：DailyMeeting每日例会：有助于团队进行自我组织。这是项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在15分钟内。与会者：团队所有成员，ScrumMaster，产品负责人（可选），相关人员（可选）三个重要问题：上次会议后我完成了什么？到下次会议开始我准备做什么？有什么障碍阻止了我的工作进度？更新SprintBacklog，包括增减任务项、更新任务进度和状态会议控制：如果展开了一个问题的讨论，提醒团队成员们注意把注意力集中在回答关键问题上如果相关人员想发表些言论，礼貌地提醒他，该会议只允许让小组成员讨论。第五十五页，共99页。Scrum活动：SprintReviewMeeting评审会议：在每个Sprint结束后，将这个Sprint的工作成果演示给ProductOwner和其他相关的人员。团队按照Backlog中的问题，逐个地介绍这次Sprint的结果，和演示新功能如果产品负责人想要改变功能，添加一个新问题到产品Backlog中如果对功能有一个新的想法，添加一个新问题到产品Backlog中如果小组报告项目遇到阻碍现在还没能解决，把该障碍加入到障碍Backlog团队达成对这次Sprint的结果和整个产品的开发状态的共识第五十六页，共99页。Scrum活动：SprintRetroMeeting回顾会议：在每个Sprint结束后，对于当前的迭代周期做一个阶段性的总结，包括好的方面和不好的方面，帮助团队在下一个迭代中扬长避短，对于一个团队的健康发展很有好处。主要指导原则：不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩在画板上写上“我们的成功经验是什么（WellDone）”、“有什么能够改进（NeedsImprovement）”针对以上总结，制定团队完善的ActionItems（可以合并到ImpedimentsList），指定负责人和完成时间，ScrumMaster带领团队尽可能落实一般可以从以下方面来进行回顾：开发团队效率如何开发团队合作如何项目进展曲线是否平稳开发团队前端和后端的分工如何测试团队的缺陷报告率如何开发周期中有没有被严重Block的因素有没有需求方面的不明确导致Rework在任务分配方面有没有不均衡，导致个别人太忙或者太闲第五十七页，共99页。Scrum（五）：度量燃尽图是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。速度(Velocity)表示每一个团队每一次迭代所产生的故事点的数量。第五十八页，共99页。Scrum回顾：全景视图第五十九页，共99页。Scrum回顾：要素第六十页，共99页。思考：Scrum流程框架的问题产品上线后的运营，是一种事件驱动的模式，每天都有问题需要优先处理，不适合开发人员与运营人员合一的小型公司/小型团队无法事先计划不被打扰的固定周期太短的周期也不行，有的任务会超过一个周期UX/UI设计跟程序设计开发的周期搭配问题不同平台（iOS，Android，Web）开发周期搭配问题AppStore审核时间不一定两周的开发迭代周期公司仍不满意，可不可以更快，做到极致？第六十一页，共99页。流程框架演进：KanbanBoard最轻量的流程管理方法WIP限制（TOC限制理论）限制每个状态的最多项目关注CycleTime（平均每个条目的完成时间）流程状态（列）可自行裁剪，适用于大小项目第六十二页，共99页。Kanban:vsScrumScrumKanban相同点都是敏捷开发流程框架(LeanThinking,Agile)；都是经验性的，团队需要具体情况（过往经验）进行调整和裁剪；都基于自组织(self-organizing)团队；不同点指定了明确的角色没有明确的角色定义timeboxed，固定迭代周期并不要求timeboxed限制每个迭代的WIP限制每个工作流状态的WIP不欢迎在一个迭代内做出变更并不拒绝Scrumboard在每个迭代之间清空Kanbanboard在项目过程中一直有东西指定要cross-functional的团队并不要求规定了“estimation”和“velocity”并无规定，有很多好的实践第六十三页，共99页。Kanban工作流程（一）第六十四页，共99页。Kanban工作流程（二）第六十五页，共99页。更多流程框架比较（更规范）（更灵活）每种方法都有一定的局限性不要限制自己只使用某一种工具！第六十六页，共99页。流程框架的组合使用示例StoryBacklogTaskBacklogInProcessTaskDoneStoryBacklogAnalysisDesignBuild Test Deploy

InceptionElaborationConstructionTransitionTier1-ScrumTier2-KanbanTier3-KanbanEpicFeatureUserStory/search/slideshow?searchfrom=header&q=Introduction+to+Agile+Planning+and+Project+Management第六十七页，共99页。大型项目流程框架：ScrumofScrumsAgendaThreequestionsWhathasmyteamdonesincewelastmetthatmightaffectotherteams?Whatwillmyteamdobeforewemeetagainthatmightaffectotherteams?Whatproblemsaremyteamhavingthatotherteamsmightbeabletohelpwith?DiscussionDiscussitemskeptonanOpenIssuesBacklog第六十八页，共99页。企业级项目流程框架：SAFe/第六十九页，共99页。敏捷方法和最佳实践第七十页，共99页。敏捷方法和最佳实践概览战略：-机会画布方法

-商业模式画布方法

-精益画布方法

-价值主张画布

-企业架构方法需求：

-需求捕获技术

-需求建模技术

-需求UserStory描述方法

-需求优先级评估方法

-UserStory切分技术

-UserStoryMapping

-UML用例建模技术反馈：

-数字化评估方法实现：-敏捷架构设计方法

-产品交互体验设计方法-模型驱动开发技术-持续交付技术

组织：-组织结构

-打造领导力驱动型团队

-研发过程管理规范体系建设第七十一页，共99页。战略：机会画布方法探寻机会的思维方式：移情：理解你的用户定义：识别问题构思：头脑风暴，形成思路原型：用线框图或代码快速搭建原型验证：验证并优化第七十二页，共99页。战略：商业模式画布方法商业模式描述了企业如何创造价值、传递价值和获取价值的基本原理。商业模式画布是一种用来描述商业模式、可视化商业模式、评估商业模式以及改变商业模式的通用语言。参考：《商业模式新生代》第七十三页，共99页。战略：精益画布（LeanCanvas）方法精益画布是从商业模式画布改编而来的，具有制作迅速、内容紧凑、方便携带的特点，便于创业者记录和交流自己的商业模式。我们可以把新产品开发当作一次创业来看待。参考：《精益创业实战》第七十四页，共99页。战略：产品精益画布扩展版本精益画布扩展版本涉及更多编写商业计划书所需要考虑的内容。来源：第七十五页，共99页。战略：SocialLeanCanvas/the-canvas/第七十六页，共99页。战略：价值主张画布/books/value-proposition-design第七十七页，共99页。战略：商业模式画布方法概览第七十八页，共99页。战略：企业架构方法企业架构和敏捷架构：企业架构关注于整个企业的IT架构规划，而敏捷架构关注于项目交付层面；企业架构是着重于企业的未来，而敏捷架构是着眼于项目的当下；企业架构是自顶向下的架构方法，而敏捷架构更偏向于自下而上的架构方法，两者相辅相成，可以互为补充。可参考架构模型：TMForum-eTOM/SID/TAM/TNANRF-ARTS第七十九页，共99页。需求：需求工程source-http:///requirements-engineering-process敏捷需求管理的目标：关注用户价值强调用户参与适应需求变化快速迭代实现第八十页，共99页。需求:需求捕获《需求捕获指南》需求捕获是软件项目的基础部分，对后继的分析设计及开发实施有重大影响。如果做的好，会减少需求变更和返工。此外，需求捕获过程的质量也将决定客户对需求的完整性、正确性的认可