Scrum敏捷开发模式解PPT课件_第1页
Scrum敏捷开发模式解PPT课件_第2页
Scrum敏捷开发模式解PPT课件_第3页
Scrum敏捷开发模式解PPT课件_第4页
Scrum敏捷开发模式解PPT课件_第5页
已阅读5页,还剩68页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

. 1,2,Scrum敏捷,3,目录,Scrum的概要,Scrum的作用和重要原则,Scrum进程:企划,执行跟踪,回顾,几个应用主题(发表周期,大团队) WeNeedScrum?4、产品投入市场时间晚的项目失败的比例高,意味着异常的投资回报率低,经常失败对变化和变更的响应高,难易度高,成本高的客户体验和客户导向差的软件质量,无论生产率如何都需要大大提高员工的士气。 动力和责任感低是普遍的微观管理者的失速率特别高的必要很多企业面临的问题和挑战,越来越多的企业使用Scrum解决这些问题。 谷歌ibmnokiasiemensphilsaccenturesunubisobblemsap,microsoftinfosyswipromotorolayahoo! schneideragilentirdetodoubleclick,autodesktencentplenwaretrendcromoodysstaracite,6, 哪些类型的项目使用Scrum大型企业级软件项目商业软件产品消费者软件项目/大型网站应用于美国FDA认可的x射线和MRI的软件高可靠性系统(99.9999%以上) 财务支付系统智能家庭项目战斗机项目,大型数据库是嵌入式电信系统手机项目CMMI5级组织同时开发软件项目不是软件项目、7、Scrum是Yahoo! 的应用(查Scrum中文网),雅虎! 世界上有200多个团队(超过2千人)使用Scrum,是面向用户的重要基础设施项目分散项目的新产品开发维护型项目,这项调查的数据是Yahoo! 采用Scrum后18个月采集,反映了80个队伍的情况,以匿名方式获得了84%的调查响应率。 12222222222222222222222222222222226与传统方法进行比较:交货质量,13,有多少人继续使用Scrum,14,下一部分,15,目录,Scrum概要,Scrum角色和重要原则,Scrum 、16、敏捷的价值观声明(同意下箭头、流程和工具完善的文件合同谈判侧重于计划,重点是与个人和可交互的软件客户合作应对变化,17、(轻量软件开发方法) 1.Scrum的项目开发周期包含几个小的转换期,每个小的转换期称为Sprint,每个Sprint推荐的长度为24周。 2 .使用产品Backlog管理产品或项目的需求。 产品Backlog是按商业价值排序的需求列表,列表项目的表现形式通常是用户故事。 3 .小组从产品的Backlog中选出最有商业价值的需求,需求在Sprint计划会议上经过分析、讨论和报价,获得Sprint的任务列表,将其称为Sprintbacklog。 4 .每次迭代结束后,Scrum团队将提供可提供的产品增量。Scrum框架的流程、19、Scrum框架的构成、3名角色产品负责人ScrumMaster团队、Sprint计划会议每日车站会Sprint审查会议、4 三个产品BacklogSprintBacklog的角色燃烧.20,Scrum使用的一些原则是,不同类型/背景的项目需要不同的管理方法,重视项目的成果,评价项目的成功,评价项目成果的超过预算、延期、遵循计划,不仅要遵守20/80法则,最大限度地满足相关人员的核心需要,及时让相关人员参加,尽早表现项目的进展和成功,结果,及时调整,使交货业务价值最大化21、和Scrum的特点是简洁有效,适合在高不确定性环境下开发复杂的产品- -容易学习和掌握- -可以在开发过程中继续检查和进行适当的调整,项目信息迅速发现对所有相关人员非常透明的问题, 容易持续改进和改进团队和组织.22,Scrum角色,ScrumMaster,项目经理? 教练? QA? ProductOwner,产品经理? 团队,团队构成,7人,or-2,稍小一点比较合适,-应该反复投入-100%坐在一起,角色交叉- -阶段性地开发产品所需的所有技能、开发、测试、UI设计、技术文件团队在“职场”中24、团队管理模式、自我管理和自我组织团队决定完成的工作量,合作进行任务管理和执行,实现约定的目标。 只有团队失败,没有个人失败的原则。 分析、和Scrum软件项目的优点。 你可以使用五个月,你必须提供五个特性,每个月给你100人日的每个可用特性,20人日的设计,40人日的开发,20人日的测试,20人日的重做(错误解决,优化),业务价值40单位24单位20单位12单位特性F1F2F3F4F5合计,26、,传统的模型,根据第一页的信息,计算各阶段的时间长度(考虑到实际的团队状况,不完全),下图表示阶段划分。M1,M2,M3,M4,M5,27,、M4,m 5,27,、M1,M2,M2,M2,M3,M3,M3,M3,M4,M3,M3,M3,m scrum的作用和重要原则、scrum流程:网站、企划、审查、几个应用主题(公开周期、度量、大团队)、WeNeedScrum?30、ScrumMaster,sm帮助团队学习和应用实现业务价值,sm为团队成功而尽了最大努力,服务团队-保护团队,scrum并不是团队的“上司”, 不负责给团队分配任务不做团队决策团队不负责及时完成工作,22222000000,服务团队,帮助团队消除故障和问题(“绊倒的原因”)团队内、团队和ProductOwner 促进合作,包括保护团队- -保护团队,防止外部干扰和威胁- -帮助团队和PO提高工作的有效性- -帮助团队和PO面临和解决困难和问题,引导Scrum的有效应用- -引导Scrum参加团队, 告诉PO和整个公司确保所有的标准scrum实践都得到遵守,选择32、ScrumMaster的高效SM的特征,-,是对团队的成功有高度责任感的人,良好的沟通技能敏感,好的听众积极专职SM有最好的成果如果不是专职的,必须有成员负责不让团队的行政管理员创建SM。 22222222222222222222222222220652,确定明确、一致的愿景和目标,并明确实现最大业务价值所需的内容创建按优先级列出特性和功能的需求表积极参加重复计划和重复审查会议, 在迭代过程中支持团队根据日常观察和学习,持续精炼和优化PB,对PB优先级有最终决策权,34, Scrum给团队管理者带来了什么样的变化,第一步骤:列举管理者过去负责的事项的列表,(尽可能的全部),第二步骤:与列表中的:scrum发生冲突, scrum中不需要,对团队实现自我管理有负面影响.35,管理员2.0,第三步骤:帮助管理员按照以上步骤整理新工作的说明,第四步骤:与管理员上司联系HR,获得理解和支持.36,反复中允许更改禁止更改交付件和交付件的日期- -如果团队同意,不允许更改交付件- -如果发生重大变化,PO可以中止重复,-在重复过程中出现“分解”和“明确”,但不允许追加或新工作,或者对现有工作“实质变更”、“变更”和“明确”。在我们的实际应用中,排除低级需求。37 .变更的影响在重复期间,如果订单增加,只需要少量工作的工作项目增加,或者替换了一部分工作项目,会有什么影响?当前迭代、今后迭代、团队订单满足承诺度项目的能力、团队对交付件的承诺、PO不变的自主性、PO写PB的规则、团队遵循其他团队接受的ScrumScrum内容的规则的注意自律性、38、PO用户故事、 用户故事是写PB的好方法之一,用户故事是简单明确的功能说明,是根据用户的价值和用户的需要而制定的。,39,迭代计划会议,小组决定在迭代结束时,多少pb可以完成两个星期的迭代项目,会议通常花3-4小时,分两部分(同一天内,连续),第一部分(PS召开需求审查会):小组审查PO需要的东西审查PO和“完成”的定义,第2部分(团队分割需求,扑克):团队决定如何实现承诺,以及如何实现承诺。40,反复企划的第一部分,PO介绍了PB中最优先的PB项目的详细情况,小组提出了问题提案,确认了关于疑问对PB必要的修正后进行了协商,团队主导项目增加到Pb粒度大的项目的分割,其他的精制和优化, 小组和Bo审查基准的“完成定义”都就修订达成了一致. “完成”的定义是在反复结束时“完成”的功能,必须完成下一个步骤: 1开发规格书、2开发规格书审查3开发完成4代码的讨论、5单元测试完成6测试用例完成7测试用例审查8测试执行报告书9提交给测试整合、#缺陷基准: P3缺陷不到3个,42,“完成”,达到了更好的方法,44,反复企划第二部分,小组开始将PB项目分解为工作任务。 然后,估计必要的时间,按照团队可利用的资源,团队承诺本反复完成量,确保工作量,所有的团队成员参加会议和讨论,不管经验多少和能力高低,都.45,计划卡,46,燃烧尽图.47,每天Scrum会议保持团队内部的协调,明确彼此的进展每天暴露困难和障碍,如何开展,而不是团队监督:task白板上每天举行,团队全体参加(会议时间到了,不等待其他成员,团队定制处罚措施) )围绕圆,向圆的中心(而不是sm )避开。 -每人报告的三件事(也可以调整) -会议上不允许讨论(如果确实需要,简洁的话),48,每天Scrum会议,Master任务:记录跟踪问题,现场回答。 更新燃尽图。 团队个人(每个人用13分钟说话,对团队说话),昨天完成的Task。 今天收到的任务。 需要帮助解决的问题。49、白板、50、反复审查(审查会议)、反复审查的目的:产品检查和适应、参加者:团队、PO、SM、各职能组领导、其他相关人员; 参考方式:演示产品,验证反复期间约定的完成内容。 相关人员一起讨论产品和“完成标准”的偏差。,小组在PO中与产品相关的议题,或在迭代中遇到的问题(例如,下一次迭代中应解决的技术问题),po在团队中与产品相关的议题,或在迭代中遇到的问题(例如,市场变化,用户的新需求等),51, 反复总结(将总结报告上传到WIKI )统一管理)反复总结的目的:检查团队的工作方法和适应的参考方法:每次反复审查时召开,12小时团队、SM参加管理者和PO应该参加,但只有部分时间参加,团队需要内部对话时间邀请中立者作为会议的协调人讨论四个主题要做好什么需要改进(不太好)今后的尝试(通过今后的反复改善)要报告的问题(给管理者)、52、反复总结记录、53、下一章、54、目录、scrum的概要、scrum scrum流程:企划、执行跟踪、回顾、几个应用主题(发布周期、主题、大团队)、WeNeedScrum?55、Scrum中的分发周期、56、Scrum的分发周期、两种常用的方法:多次重复分发:57、顶层设计和结构调查、开发环境的设置、多次重复分发的方法之一分发前的SPRINT 最终发布稳定和分发准备、58、反复的一种方法是在项目接近结束时,缩短重复、缩短周期、更快地检查/适应、59、简档:Scrum和测量、60、Scrum和测量、Scrum -例如,个人燃烧图、测量的记录和报告可能需要资源。 -如果需要消耗团队资源的话,可以在估计时间时明确这些消费,或者作为PS和PS项目,61, 常用测量,比较进展的差异,必须以实际速

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论