scrum介绍(全).ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,Scrum,1,Scrum,Scrum,基本知识,Scrum,过程,用户故事,敏捷计划,敏捷日常跟进,敏捷绩效考核,2,S,3,Scrum,概述,Scrum,是一种兼顾计划性不灵活性的敏捷开发过程，原词来自二橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划,安排的过程，但冲刺开始后则由队员在原计划的基础上随机应发。,不同于瀑布模型将开収过程划分为需求、设计、编码、测试等阶段，,Scrum,将整个开发过程分为多次迭代（称为,Sprint,，冲刺），一般为,期,2,4,周。,4,Scrum,是什么？,带球过人需要计划！,带球过人需要灵活应变！,5,6,一分钟扫盲,产品负责人建立条目化的产品待开发项，并进行优先级排序,在迭代计划会上，产品负责人讲解本迭代要开发的条目，团队进行估算并放入下一个迭代,团队在迭代内完成所列需求，每天都开每日“立”会，沟通进度问题。,在迭代重点的迭代评审会上，团队向产品负责人等战士开发成果,7,Scrum,敏捷方法中的工作产品,产品待开发项,Product Backlog,是从客,户价值角度理解的产品功能列表。,冲刺待开发项,Sprint Backlog,是从,开发技术角度理解的迭代开发任,务。,可工作软件,Working Software,是可交付,的软件产品。,8,Scrum,敏捷方法中的角色,Product Owner,（产品负责人）负责产,品需求的提炼、条目化、优先级排序。,Scrum Master,（,Scrum“,大师”）负责,维护,Scrum,方法的秩序，并协劣览决非,技术问题,Team,（团队）以“自组织”的相对扁,平方式进行管理，负责完成开发工,作,9,10,Scrum,过程,创建和维护产品待开发项（,Product Backlog,）,迭代计划会（,Sprint Planning Meeting,）,办公环境,每日立会（,Standup Meeting,）,评审会（,Review Meeting,）,反思会（,Retrospective Meeting,）,11,创建和维护产品待开发项,产品功能列表（,Product Backlog,）,是一组条目化需求。产品功能列表必须从客户价值角度描述，并按优先级排序。典型的描述方法，就是极限编程中提到的用户故事（,User Story,）。,12,迭代计划会（,Sprint Planning Meeting,）,迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。产品负责人逐条讲解最重要的产品功能。开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。产品负责人参不讨论并回答不需求相关的问题，但不干扰估算结果。,13,迭代计划会（,Sprint Planning Meeting,）,产品负责人准本什么？讲解什么？,团队怎么估算（扑克牌估算）,14,扑克牌估算,每人各自估算后独立出暗牉，听口令一起开牉。,数值最大者不最小者,PK,，其他人旁听也可参不。,认论结束后重新出牌和开牌。,重复上述过程，直到结果比较接近。,15,办公环境,16,每日立会（,Standup Meeting,）,队员认领任务（或由组长协商分发），独立或与别人一起完成任务；团队内部利用每日立会来沟通进度；开发团队利用燃烧图来展示整体进度；如无特殊原因，迭代期内无变更,17,评审会（,Review Meeting,）,小组向产品负责人展示迭代工,作结果。,产品负责人给出评价和反,馈。,以用户故事是否能成功交付,来评价任务完成情况。,18,反思会（,Retrospective Meeting,）,在每个迭代后召开简短的反思,会。,总结哪些事情做的好，哪些,事情做的不好。,制定改进计划。,19,用户故事,I,：何为用户故事,按,“,作为一个,，可以,，以便,”,样弅和思路写成的用户需求，就是用户故事。,这种样式是技法层面的东西，它保证了无需太多思考，用户故事中即可全面包含角色、功能、价值这三个要素。,20,用户故事,II,：面向用户价值编写故事,21,用户故事,III,：用户建模,22,用户故事,V,：用户故事的分类,用户故事一般被按尺度分为史诗故事和普通用户故事。若要更精细化地管理，则可能包含颗粒度和可见性等更多维度，并因此而产生出更多的分类。,23,用户故事,VI,：产生于组织结构,24,敏捷计划总流程,25,敏捷计划,I,：可用时间计算,一个人月到底能完成多少工作量？“当然是,22,天了！”,那么，计划会、评审会、中途处理突发任务？写文档？做设计、帮劣徒弟,中午打瞌睡的时间算不算？,以及一个经常问到的问题：估算的时候要留余量吗？,为了览决这些复杂的问题，前人已经找到了较为成熟的方法，步骤如下,先减去,Scrum,会议的时间，一般是计划会,-1,天，评审会,-1,天,再减去确定无疑的出差、培讦、请假,的时间，加上确定无疑的加班时间,剩下的时间，新团队,50老团队,70%,，得到预计可用时间,估算故事时，不再留任何余量，按全时工作计算。所有需要在迭代交付时以,PO,指定的标准完成用户故事的事情都计算在内。,26,敏捷计划,II,：迭代计划,Product Backlog,里边有干不完的活,每个迭代（,Sprint,）挑出最重要的部分,一个迭代连着一个迭代,仅仅这样工作，尽管团队现在总是有活干，但是产品未来究竟会如何，却是看不清楚的。因此需要一个迭代计划来支撑对未来的预见。,为每个迭代起一个简短的标题外加设定一个面向客户价值的目标是非常好的实践。,27,敏捷计划,III,：迭代意向表,在迭代计划会前，产品负责人一般会从众多故事中选择其中一些形成一个迭代意向表（,Sprint Willing List,），作为计划会讲解的备选故事。,意向表一般并非“当前最重要的用户故事”组成的乌合之众，而往往是一些相关性强，完成后具备相对完整的业务功能的一组故事，称为“故事群”（一般比传统的史诗故事规模模更大）。,28,敏捷计划,IV,：故事讲解与估算,在迭代计划会上，产品负责人逐个讲解用户故事，团队逐个进行估算。,讲解顺序应先业务后技术，先总体后细节，先过去后未来，帮劣团队系统地把握产品功能。,J,团队应简要记录需求详情，有些团队在问答环节甚至能当场形成基本的测试用例雏形。,J,在估算之前，不应该事先指定开发负责人，以便提升整个团队对估算的积极参与。,29,敏捷日常跟进,I,：故事板（看板）,30,敏捷日常跟进,II,：燃尽图,31,敏捷日常跟进,III,：跟进图与渐进评审,32,敏捷日常跟进,IV,：跟进表,33,敏捷绩效管理,-,考核对象的变化,34,