Scrum流程个人整理版精.docx

1、Scrum流程个人整理版精Sprint 计划会议1:原始需求者、产品负责人及团队一起,确定任务优先级,定出Sprint 目标和既定产品Backlog。Sprint 计划会议2:团队将既定产品Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。Scrum 每日例会:项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在15 分钟内。Sprint 验收会议:由原始需求者或产品负责人断定实际所发布的功能是否与既定的Sprint 目标一致。Sprint 回顾会议:项目团队分析Sprint中的成功经验和所遇到的障碍。整个Sprint的周期(时间盒确定为10天

2、(两周,具体的时间安排为:Sprint会议(0.5天开发(8天验收&总结(0.5天技术提升日(1天,自主学习技术1、需求收集1.1 需求的分类需求可与分为业务团队的,也可以包括团度内部的,比如性能优化。1.2 需求提交模板 任务可用性问题(Bug性能问题概念想法注意:即使是概念性的想法,目前技术上无法实现的想法都可以收集。优先级可从以下五种情况中选择特别的严重非常重要很重要普通低注意:切忌将所有的任务的优先级都设置的非常的高,这里不提供非常紧急这样的表述。我们只会根据重要程度去执行任务,所以紧急的任务需要业务部门及需求方尽早的提出。需求类型可以是两种类型详细需求毛坯需求注意:我们的需求并不是要

3、求一定要完整的,及时是一些非常毛坯的需求,也可以提交过来,毛坯的需求由产品负责人进行分析和梳理,暂不清楚的可选择搁置。需求标题有自己进行书写,但是需要遵守的规范是采用动宾短语格式。比如:导出+CN酒店每天的PV、UV等流量数据注意:这里的需求内容一定是站长使用者角度是提出的,切勿出现专业的程序方面的表述:如添加一个导出的按钮。还有需要注意的是动词切忌使用大而宽泛的词,比如管理,类似管理关键词这样的需求是严格避免的,这样会使得要开发的内容变得没有清晰的边界。详细描述需要按照用户故事的格式进行书写。具体用户故事格式的要求如下:用户故事是从用户的角度来描述用户渴望得到的功能。需要注意的是用户故事不能

4、够使用技术语言来描述,要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素:角色:谁要使用这个功能。活动:需要完成什么样的功能。商业价值:为什么需要这个功能,这个功能带来什么样的价值。用户故事通常按照如下的格式来表达:作为一个, 我想要, 以便于比如:作为一名酒店前端开发人员,我期望查看所有酒店页面的页面打开时间,以便了解哪些页面需要进行技能优化。一个好的用户故事同时要符合INVEST原则,INVEST原则分别是:独立性(Independent: 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用

5、户故事和分解用户故事来减少依赖性。可协商性(Negotiable: 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事带有了太多的细节,实际上限制了和用户的沟通。有价值(Valuable: 每个故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。可以估算性(Estimable:开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自

6、:对于领域知识的缺乏(这种情况下需要更多的沟通,或者故事太大了(这时需要把故事切分成小些的。短小(Small: 一个好的故事在工作量上要尽量短小,最好不要超过8个人/天的工作量,至少要确保的是在一个迭代能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。可测试性(Testable: 一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。注意:角色的范围不能过大,比如是作为一名用户,这样是的不被接受的。商业价值也不能大而宽泛,比如,能为公司创造业绩。如果要写也一定要对业绩做初步估算,比如,预期会给公司带来每月1万张订

7、单。验收条件是开发完成后检验的标准,所以一定要认真填写,否则可能开发出来的东西与预期不达标。以上面的导出+CN酒店每天的PV、UV等流量数据为例,它的验收条件可以为:1 可以为每个用户设置是否拥有此导出权限2 导出的时间可以细化的天。即可导出每天的流量。3 导出数据的最大时间跨度为31天4 对于导出数据做好日志记录,后期可查是谁进行了导出。5 导出的字段包括:PV、UV、跳出率、新访客占比。价值验证说明如何跟踪上线后的效果2、Sprint 计划会议1目标:定出Sprint 目标和既定产品Backlog。2.1 会议准备所有会议资源都已预订会议室投影仪笔记本在会议前一天确定议程,将目标和议程发送

8、给所有与会者原始需求人(可选择不来产品负责人 Scrum Master开发团队已按优先级排列产品Backlog整理完毕 Sprint 时间表已经安排 Sprint 计划会议1 的时间安排 Sprint 计划会议2 的时间安排 Sprint 的第一天已确定 Sprint 的最后一天已确定 Scrum 每日例会的时间安排 Sprint 验收会议的时间安排 Sprint 回顾会议的时间安排2.2 会议议程把Sprint 时间表公开给所有人产品负责人向团队产品阐述需求(用户故事开发人员对用户故事不清楚的点可以及时提出。产品负责人或者原始需求者负责解答不清楚的故事点。如果讨论现场发现有遗漏的需求,可由产

9、品负责人添加至产品Backlog。如果对需求的优先级存在异议,可会上讨论,确定最终的执行顺序。产品负责人& 需求方和小组成员相互认可这Sprint 目标和既定产品Backlog2.3 会议结果为Sprint 计划会议2的进行准备好既定产品Backlog2.4 补充内容产品Backlog模板(基本同需求模板 等待处理正在进行已经完成不予处理暂时搁置需要讨论3、Sprint 计划会议2目标:确定所有任务,生成Sprint Backlog,确认Sprint 目标3.1 会议准备要求原始需求者离开会议,参会人员为产品负责人 Scrum Master开发团队在Sprint 计划会议1后10分钟举行 Sp

10、rint 计划会议1中整理的既定产品Backlog任务估时牌(按1,2,3,5,8,13估算3.2 会议进程团队成员按顺序分析既定产品Backlog的讨论实现细节编码测试代码审核学习新技术编写文档部署上传可看情况确定是否使用扑克估时任务超过一天时,需要拆成多个小任务如果团队评估下来任务过多,可和产品负责人一起删减任务如果团队评估下来任务过少,可和产品负责人一起从产品Blaclog中引入新的需求。3.3 会议结果将最终确认的可完成的需求清单邮件至原始需求人产品负责人 Scrum Master开发团队将最终确认的任务列表邮件至产品负责人 Scrum Master开发团队3.4 补充内容Sprint

11、 Backlog模板 务可以是程序类描述,如数据数据库设计4、Scrum 每日例会目标:团队成员间工作进度的沟通和协调4.1 会议准备邀请与会者外部团队协助人员(如有有需要的话原始需求人(只有选择是否参加,过程中不可发言在Sprint Backlog 上的所有任务都是可以增删修改,可重排序的一台电脑,中间标识任务的状态,可设为待处理,正在处理,已完成的。4.2 会议进程注意:会议限定在15分钟内团队里的每个成员都必须回答以下三个问题,并考虑其相关的行动。上次会议时的任务哪些已经完成?把任务从正在处理状态转为已完成状态下一次会议之前,你计划完成什么任务?如果任务状态为待处理:转为正在处理状态如果

12、任务不在Sprint Backlog 上:添加这个任务如果任务不能在一天内完成:把这任务细分成多个任务如果任务可以在一天内完成:把任务状态设为正在处理如果任务状态已经是正在处理:询问是否存在阻碍任务完成得问题有什么问题阻碍了你的开发如果有阻碍你开发进度的问题:把该障碍加入到障碍Backlog 中,Scrum Master负责记录如果展开了一个问题的讨论提醒团队的成员们注意把精力集中在回答关键问题上如果相关人员想发表些言论礼貌地提醒他,该会议只允许让小组成员讨论4.3 会议结果得到最新的障碍Backlog得到最新的Sprint Backlog最新的工作进度图(燃尽图第一次的例会创建一封邮件,由S

13、crum Master会议后将例会内容回复此邮件。4.4 障碍Backlog障碍Backlog 列举了所有团队内部和团队相关的和阻碍项目进度的问题。Scrum Master 需要确保所有的障碍Backlog 中的问题都已分配并可以得到解决。10 大典型障碍会议规则没能被遵循产品远景和Sprint 目标不清晰没有产品负责人负责回答提问产品Backlog 未能按商业价值区分优先级并不是所有负责交付产品的人员都是团队里的成员Scrum Master 还要处理其他任务,不能集中精力团队人数过多团队没有能坐在一起工作的空间团队的Sprint Backlog 混乱中间遇到了技术难题5、Sprint 验收会

14、议目标:根据团队这次Sprint 所发布的版本,评审相关的Backlog 中的问题,检查是否已达到Sprint 的目标。5.1 会议准备所有会议资源都已预订会议室投影仪笔记本在会议前一天确定议程,将目标和议程发送给所有与会者原始需求人(可选择不来产品负责人 Scrum Master开发团队对于每个人来说Sprint 目标都是公开的对每个人来说既定产品Backlog 是公开的,可获取的5.2 会议进程团队按Backlog 中的问题,逐个地介绍这次Sprint 的结果,和演示新功能。如果产品负责人或需求方想要改变功能:添加一个新问题到产品Backlog 中如果对功能有一个新的想法:添加一个新问题到

15、产品Backlog 中如果小组报告项目遇到阻碍现在还没能解决:把该障碍加入到障碍Backlog5.3 会议结果对这次Sprint 的结果和整个产品的开发状态的共识6、Sprint 回顾会议目标:通过总结以往的实践经验来提高团队生产力。注意:主要指导原则:不管我们现在发现了什么问题,我们必须懂得并坚信每个人通过他们当时所知的,他所拥有的技能和可得到的资源,在限定的环境下,都尽其所能做出了最好的成绩。6.1 会议准备邀请与会者: Scrum Master团队所有成员产品负责人(可选附属工具便签纸白板在白板上写上主要指导原则在白板上画上一个至少三页纸连在一起长的时间轴在白板上写上我们的成功经验是什么

16、在白板上写上有什么能够改进在白板上写上谁负责,然后分成两个区域团队和公司附属工具:6.2 会议进程介绍会议目标介绍会议主要指导原则在时间轴上,标记出Sprint 的开始和结束时间向与会者解说如何使用该便签纸进行工作派发便签,并且让每人写上他们认为这次Sprint 中最为重要的事,限时 5 分钟每个与会者轮流把他的贴纸贴到白板的时间轴上,并用两句话来解说这事有什么特别的地方分发便签纸,并让每人写上我们的成功经验是什么,限时5分钟每个与会者轮流把他的贴纸贴到白板我们的成功经验是什么的区域上,并解说。分发便签纸,并让每人写上有什么能够改进的,限时5分钟每个与会者轮流把他的贴纸贴到白板有什么能够改进的的区域上,并解说。对于挂纸板上有什么能够改进的区域中的每一项 询问团队谁去负责解决这个问题？ 把便签纸移到挂纸板中谁负责的区域中 和团队一起把这些区域按优先次序排好 给会议做个总结 每个与会者对 Sprint 回顾会议作简短的回馈 6.3 会议结果 白板上谁负责这栏对于公司内所有人是公开的 把与公司范围相关的障碍增加到障碍 Backlog 中去 把与团队范围相关的障碍增加到障碍 Backlog 中去 整理所有会议结果，邮件至团队中所有人