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

敏捷开发全景视图 流程 方法和最佳实践 钟玮军2016 02 25 目录Contents 敏捷vs传统敏捷开发流程框架敏捷方法和最佳实践思考与答疑 敏捷vs传统 IT项目管理方法的发展历史 1960 1970 1980 1990 2000 2010 SDLC WATERFALL RAD PMBOKITILPRINCEZachman DSDM RUPXPPRINCE2CRYSTAL SCRUMAGILEMANIFESTOFEATOGAF8 0 LEAN KANBAN 软件开发生命周期 SDLC https en wikipedia org 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起源于软件开发项目 但它适用于任何复杂的或是创新性的项目 要素 周期 ProductRelease Time BoxedSprint DailyContinousDelivery团队 ProductOwner ScrumMaster DevTeam Cross Functional 工件 ProductBacklog SprintBacklog ProductIncrement活动 SprintPlanningMeeting ReviewMeeting RetrospectiveMeeting DailyScrumMeeting ProductBacklogRefinement度量 Burndown图 Burnup图 Velocity Scrum 一 迭代周期框架 迭代周期框架 ProductReleasePortfolio Product Release 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职责 https www scrumalliance org community articles 2014 may what it is that a scrum master does all day long 主要负责整个Scrum流程在项目中的顺利实施和进行 以及清除挡在客户和开发工作之间的沟通障碍 使得客户可以直接驱动开发 Scrum团队 ScrumMaster能力要求 出色的沟通和决策能力能及时 清楚 明确地传播信息 知道什么时候做出决定 不必要再做分析 平衡短期和长期目标 快速在团队和ProductOwner之间达成一个共同的愿景 促进团队合作的能力能够促进和培养团队合作的能力 能够诊断 理解和帮助团队的日常变化 持续衡量团队工作状况 并推动必要的行动 以改进团队的工作 鼓舞和激励能力促进团队活力 鼓舞 表扬和奖励团队中做得最好的人 宣扬突出的行为 技能和成就 伟大的工作态度 总是寻找方法来改变工作 而不是认同为什么做出改变是不可能的 抗压能力在压力环境下仍能保持镇定 出色工作解决冲突能力促进建设性的辩论 使得产生更好的决策和共同愿景建设性地解决分歧和冲突 知道什么时候让其他人也参与进来在所有交往中 体现出情感成熟度 周到 客观 正直 可靠 即使在他 她不同意的时候 也会支持哪些已经做出的决定敏捷开发实践能力Backlog跟踪 burndown图 会议组织 计划能力 进度跟踪 风险管理 组织变革 团队成长 敏捷开发实践 持续集成 交付 部署 参考 https www scrumalliance org 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规定流程下进行开发工作 人数控制在5 10人左右 每个成员可能负责不同的技术方面 但要求每个成员必须要有很强的自我管理能力 同时具有一定的表达能力 成员可以采用任何工作方式 只要能达到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用4 6个Sprint来确定速率 SCRUM工件 PB 6 非功能性需求描述 Nonfunctionalrequirementsrepresentimportantsystem 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 参考 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 https www scrumalliance org 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 Theinitialreleaseplanisa blueprint togetstartedandwillberevised 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 敏捷需求管理的目标 关注用户价值强调用户参与适应需求变化快速迭代实现 需求 需求捕获 需求捕获指南 需求捕获是软件项目的基础部分 对后继的分析设计及开发实施有重大影响 如果做的好 会减少需求变更和返工 此外 需求捕获过程的质量也将决定客户对需求的完整性 正确性的认可 因为这个阶段的困难性和影响力 按一个理想的模式来完成需求捕获过程就非常重要 需求捕获可定义为 需求