Scrum敏捷开发模式解PPT课件.ppt

1.Scrum敏捷2.目录Scrum概览Scrum中的角色和关键原则Scrum流程：策划、执行跟踪、回顾几个应用主题（发布周期、度量、大团队）We Need Scrum?3.产品投放市场的时间太慢项目失败的比例高的离谱投资回报低，经常失败对变化与变更的响应，难度大且成本高客户体验及客户为导向很差软件质量不过关生产力需要大幅提高员工士气，动力及责任感很低需要普遍的微观管理人员流失率特别高.许多企业面临的问题与挑战4.越来越多的企业使用Scrum解决这些问题 GoogleIBMNokiaSiemensPhilipsAccentureSunUbisoBBleumSAPMicrosoftInfosysOracleWiproMotorolaYahoo!SchneiderAgilentIrdetoDoubleClickAutodeskTencentPlenwareTrendmicroMoodysStarCite5.哪些类型的项目已经在使用Scrum大型企业级软件项目商业软件产品消费者软件项目/大型网站美国FDA批准的应用于X射线和MRI的软件高可靠性系统（99.9999以上）财务支付系统智能家居项目战斗机项目大型数据库应用嵌入式电信系统手机项目CMMI5级的组织多地点同步开发支撑和维护项目非软件项目6.Scrum在Yahoo！的应用(引Scrum中文网)Yahoo!在全球有超过200个团队（超过两千人）使用Scrum面向用户的项目关键的基础设施项目分布式项目全新产品开发维护型项目这份调查的数据是在Yahoo!采纳Scrum后18个月时采集反映80个团队的情况采用匿名方式得到84%的调查响应率7.与传统方法的对比：团队生产力8.与传统方法的对比：士气9.与传统方法的对比：责任感与主人翁意识10.与传统方法的对比：协调与合作11.与传统方法的对比：交付质量12.有多少人愿意继续使用Scrum13.下一章节14.目录Scrum概览Scrum中的角色和关键原则Scrum流程：策划、执行跟踪、回顾几个应用主题（发布周期、度量、大团队）We Need Scrum?15.敏捷价值观之敏捷宣言（认同）过程和工具完备的文档合同谈判遵循计划重于重于重于重于个体与交互可用的软件客户协作响应变化16.什么是Scrum？（一个轻量级的软件开发方法）Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。1.Scrum中项目整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。2.使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事（UserStory）。3.团队从产品Backlog中挑选最有商业价值的需求，需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。4.在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。17.Scrum框架流程 18.Scrum框架组成 3三个角色产品负责人ScrumMaster团队Sprint计划会议每日站会Sprint评审会议Sprint回顾会议四个仪式3三个产物产品BacklogSprintBacklog个角色燃尽图19.Scrum使用的几个原则不同类型/背景的项目需要不同的管理方法以项目成果为导向而不是过程导向衡量项目成功与否，要看重项目成果的商业价值和ROI（投资回报），而非仅超支、延期、遵循计划20/80法则，最大可能满足涉众核心需要及时让涉众参与，并及早展现项目进展和成果，及时调整，确保交付商业价值最大化20.Scrum特点适于在不确定性高的环境中开发复杂产品；简洁但有效；易于学习和掌握；能够在开发进程中不断检查，并作出相应调整；项目信息对所有干系人高度透明；便于快速发现问题，促使团队和组织持续改进；21.Scrum中的角色ScrumMaster项目经理？教练？QA？ProductOwner产品经理？Team22.团队构成7人，+or-2偏小一些会更合适应100%投入到迭代中最好坐在一起角色交叉包含增量开发产品所需的所有技能开发、测试、UI设计、技术文档编写团队基于技能而不是“岗位”来认领工作23.团队管理模式自我管理和自我组织团队决定要完成的工作量，相互协作进行任务管理和执行，以实现承诺的目标只有团队失败而没有个人失败的原则24.Scrum软件项目分析，优点。你有5个月时间可用；你要交付5个特性；每个月，你有100人日可用每个特性需要20人日设计、40人日开发、20人日测试、20人日返工（解决bug、优化）商业价值40单位24单位20单位12单位4单位100单位特性F1F2F3F4F5总计25.传统模式根据第一页给出的信息，计算每个阶段的时间长度（考虑实际团队情况，不完整），在下图中标识出阶段划分。M1M2M3M4M526.Scrum模式根据第一页给出的信息，计划一下你的开发进度（团队拆分，细节把握，提高质量）M1M2M3M4M527.下一章节28.目录Scrum概览Scrum中的角色和关键原则Scrum流程：站会、策划和回顾几个应用主题（发布周期、度量、大团队）We Need Scrum?29.ScrumMasterSM帮助团队学习和应用Scrum来实现商业价值SM尽其所能帮助团队获得成功服务团队保护团队引导大家有效应用ScrumSM不是团队的“老板”不负责为团队分配任务不会帮团队做决定不对团队及时完成工作负责30.ScrumMaster做什么事情？服务团队帮助团队排除障碍和问题（“绊脚石”）促进协作，包括团队内、团队和ProductOwner间保护团队保护团队，使之免收外界干扰或威胁教导团队帮助团队和PO改进工作的有效性帮助团队和PO面对并解决困难和问题引导Scrum的有效应用把Scrum教给团队、PO和整个公司确保所有标准Scrum实践得到遵循31.ScrumMaster的选择高效SM的特征对团队的成功有高度的责任心良好的人缘、良好的沟通技能敏感、好的聆听者积极、乐于助人技术专家，会更有帮助但非必要专职SM会有最好的成果如果不能专职，必须有一位成员担当这个角色（相应降低他的原工作负担）避免让团队行政管理者做做SM因为大家会指望原管理者来作规划，也就很难做到自我管理32.ProductOwner负责最大化项目ROI（投资回报）实现手段：多方收集意见，充分了解机会和风险；确定清晰、一致的愿景及目标，明确为实现最大商业价值所需做的事情；制订一个需求表，按照优先级列出特性和功能；积极参加迭代计划和迭代回顾会议，在迭代中为团队提供支持；基于日常观察和学习，持续精炼和优化PB；对PB优先级有最终决策权33.Scrum给团队管理者带来哪些变化第1步：列出管理者过去负责的事项列表（尽可能列全）第2步：勾掉列表中：与Scrum冲突的；在Scrum中不必要的；对实现团队自我管理有不良影响的；34.管理者2.0第3步：帮助管理者按照以上步骤，梳理一份新的工作说明；第4步：与管理者的上级和HR沟通，争取理解和支持；35.迭代中不允许变更禁止变更交付件和交付日期一旦团队作出承诺，就不允许变更交付件如果发生重大变化，PO可以中止当次迭代在迭代中会出现“分解”和“澄清”，但是不允许添加新工作，或者对现有工作进行“实质变更”“变更”vs“澄清”如果存在争议，那么将其认定为变更，放到PB中，下一次迭代再考虑。在我们实际应用中，将较低级别的需求剔除掉。36.变更的影响在迭代期间，如果PO增加只需要少量工作的工作项，或替换部分工作项，会有什么影响？当前迭代今后的迭代团队交PO满付承诺意度项的能力团队对交付件的承诺PO不提变更的自律PO写PB的规则团队对团队遵其它团要交付循其它队遵循承诺内ScrumScrum容的关规则的规则的注度自律性自律性37.PO用户故事用户故事是写PB的好方法之一；用户故事是简短、明确的功能说明，按照用户价值和用户需要编写。38.迭代计划会议团队确定在迭代结束时，能完成多少PB对于2周迭代的项目，会议一般花3-4小时分两部分（同一天内，连续）第一部分（PO召开需求评审会）：团队评审PO想要的东西，然后与PO确认“完成”的定义第二部分(团队拆分需求，打扑克牌)：团队决定承诺完成多少，以及如何实现承诺。39.迭代策划第一部分PO介绍PB中最优先PB项的细节团队提出问题、建议，就疑问进行确认协商对PB需要做的修改团队驱动项增加到PB中大粒度项拆分任何其它提炼和优化团队和PO评审标准的“完成定义”，就所有修订达成一致40.“完成”定义在迭代结束时，要“完成”的功能，必须完成以下步骤：1开发规格说明书2开发规格说明书评审3开发完成4 代码review5单元测试完成6 测试用例完成7 测试用例评审8 测试执行报告9 已提交至测试集成缺陷标准：不允许P1P2缺陷，P3缺陷小于3个41.达到“完成”不太好的方式42.达到“完成”更好的方式43.迭代策划第二部分团队开始将PB项分解为工作任务，并且估计需要的时间对照团队可用资源，团队承诺本迭代完成量，确保工作量适当所有团队成员都参与会议和讨论，无论经验多少及能力高低44.计划纸牌45.燃尽图46.每日Scrum会议会议目的：保持团队内部协调顺畅，相互之间进展明晰每天暴露困难和障碍，非团队监管如何开展：在Task白板处，每个工作日举行，团队所有成员参加（开会时间到，不等待其他成员，小组自定义惩罚措施。）围成一个圈，面向圆心（而非SM）行政管理者最好回避每个人汇报3件事（也可以做一些调整）会议中不允许讨论（如果确实必要，简洁一点）47.每日Scrum会议Master任务：记录并现场解答跟踪问题。更新燃尽图。团队个人(每个人1-3分钟陈述，讲给团队)昨天完成的Task。今天将认领的Task。需要协助解决的问题。48.白板49.迭代回顾（回顾会议）迭代回顾的目的：产品检查和适应参与者：团队、PO、SM、各职能组leader、其他涉众；参考方式：演示产品，验证迭代期内的承诺完成内容。相关人员一起讨论产品与“完成标准”的偏差。团队向PO提出产品相关议题，或迭代中碰到的问题（例如：在后续迭代中需要解决的技术问题）PO向团队提出产品相关议题，或迭代中碰到的问题（例如：市场变化、用户新需求等）50.迭代总结(总结报告上传至WIKI,统一管理)迭代总结的目的：团队工作方式检查和自适应参考方式：每次迭代回顾后召开，1-2小时团队、SM参加管理者和PO应参加，但只部分时间参与，团队需要内部交谈时间通常会邀请一位中立人员来担当会议协调人讨论四个主题哪些做得好那些需要改善（不太好的）需要在以后尝试的事情（今后迭代中改善）要上报的问题（向管理者）51.迭代总结记录52.下一章节53.目录Scrum概览Scrum中的角色和关键原则Scrum流程：策划、执行跟踪、回顾几个应用主题（发布周期、度量、大团队）We Need Scrum?54.Scrum中的发布周期55.Scrum发布周期两种常见方法：多次迭代发布：每次迭代发布：56.顶层设计和架构调研，开发环境安装多次迭代发布方法之一发布前SPRINT最终稳定和发布准备57.多次迭代发布方法之一在项目接近结束时，缩短迭代期，以更快地检查/适应58.简介：Scrum和度量59.Scrum和度量Scrum不会阻止你跟踪或测量你所实施的开发过程；不过，你必须当心测量的可能不良后果比如：个人燃烧图测量的记录和汇报可能需要花费资源如果确实需要消耗团队资源，应该让这些消耗在任务时间估计时明确出来，或作为一个PB或SB项60.常用度量进度差异对比用实际速度比较估计速度；工作量差异对比任务汇总成本（跟踪本身的工作量，及可能引发的问题和数据作弊）；实际消耗时间vs预计消耗时间；挣得值（已实现商业价值）商业价值燃烧图61.简介：Scrum自适应-如何应用于不同规模组织62.Scrum自适应50人规模（分析师、设计师、开发、测试、文档等）63.Scrum自适应64.方法1：多团队共用一份PB65.方法2：多团队按照独立PB工作66.Scrum自适应67.Scrum自适应68.迭代期间每天/每周2-3次协调、相关性管理、问题暴露69.简介：Scrum和CMMI70.71.如何提高实施Scrum的成功率1、高质量的培训2、积极的管理层支持及随时关注3、清晰的高管层与组织层面的认可4、教练辅导与咨询；5、真正落实Scrum实施的纪律与承诺72.The End！73.