管理活动指南Sprint计划会

Scrum管理活动指南-Sprint计划会文档编号：YY/PF/AGUI/06/G02文档信息：组织级过程文件文档名称：Scrum开发活动指南-Sprint计划会文档类别：过程改进类密级：内部版本信息：1.0建立日期：2015/12/30创建人：张颖审核者：罗涛批准人：谢志华批准日期：2016/01/01文档修订记录版本编号或者更改记录编号*变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人V0.5A新建2015/12/30张颖*变化状态：A——增加，M——修改，D——删除文档评审记录序号评审人角色评审日期签字备注1罗涛开发管理部经理2016/0123文档审批信息序号审批人角色审批日期签字备注目录1.简介 41.1目的 41.2适用范围 41.3术语与缩略语 41.4参考资料 42.指南概述 43.实施步骤指导 54.常见问题： 6

1.简介1.1目的Sprint计划会是敏捷流程scrum方法中的一条关键实践，Sprint计划会议的目的就是要为这个Sprint的工作做计划。这份计划是由整个Scrum团队共同协作完成的，共同选择和理解在即将到来的Sprint中要完成的工作。本指南主要指导敏捷教练或者敏捷开发团队如何开好计划会，发挥计划会的真正作用。1.2适用范围 本过程适用于：机构：适用于集团内各产品研发，运维运营组织业务：全生命周期研发及运维运营产品类型：全部产品类型1.3术语与缩略语团队生产率：一轮迭代完成的故事点就是团队生产率。项目做计划时，可以参考之前迭代的生产率。因此生产率是一个有用的管理工具，在每轮迭代结束和迭代中监控团队的生产率是很重要的。1.4参考资料集团敏《集团敏捷研发管理体系V2.0》《硝烟中的Scrum和XP》《Scrum-Guide-CN》Scrum中文网2.指南概述敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础。这是一个固定时长的会议，推荐时长Sprint中的每周对应两小时或者更少(例如，一个Sprint包含2个周，则Sprint计划会议时长应为4个小时或者更少)。Sprint计划会议的成功十分依赖于产品Backlog的质量，一个井然有序的产品backlog是Sprint计划会成功的基础。Sprint计划会议有两部分:1、决定在Sprint中需要完成哪些工作2、决定这些工作如何完成3.实施步骤指导会议准备邀请与会者：产品负责人、ScrumMaster、团队所有成员在sprint计划会议之前，要确保产品backlog的井然有序（已按优先级排列的产品Backlog）把产品Backlog公开给会议中的每个人，保证其可被获取保证房间环境适合小组讨论，一个比较安静的会议室，有投影仪每个人都可以获取上次Sprint评审会议和Sprint回顾会议的结果用作计划纸牌的卡片一个任务看板会议进程（2周的sprint，一般4个小时）第一部分：产品负责人和团队一起，在产品backlog基础上，定出Sprint目标和SprintBacklog，决定在Sprint中需要完成哪些工作。SM把Sprint完成周期公开给所有人。SM把上一次Sprint评审会议的结果公开给所有人。SM把上一次Sprint回顾会议的结果公开给所有人。PO向团队产品阐述产品远景，以及达成该远景所需要完成的产品Backlog，让团队成员了解客户的需求。整个Scrum团队为了更好地了解Sprint的工作进行讨论。PO和团队一起确认sprint目标。估算本迭代团队生产率。团队确认要放入sprint中的Backlog。产品负责人在必要时修改重要性评分，理清每个条目的含义。产品负责人和团队需要对“完成”有一致的定义。确定评审会日期。确定回顾会日期。确定每日站会时间和地点。第二部分：决定这些工作如何完成，并评估相应的完成时间。团队从最重要的故事开始逐一讨论每个故事，SM带团队拆分工作任务，将sprint中的Backlog转换成可工作的产品增量所需要的工作，建议每个工作任务最好不要超过一天。Scrum团队对Sprint需要完成工作的复杂度进行工作量估算，并达成共识。通常使用计划纸牌做工作量估算，估算需要考虑到工作中所有的细节:编码、测试、代码评审、会议、学习新技术、编写文档。当任务确定后，团队成员可以自愿承担任务，也可以由SM分配任务。Sprint计划会议结束时，开发团队解释他们将如何以自组织团队的形式完成Sprint目标。绘制任务看板和燃尽图。会议输出Sprint目标和SprintBacklog任务看板（含燃尽图）确定好sprint演示日期确定好sprint回顾日期确定好时间地点，供举行每日站会4.常见问题参会人员哪些是必须的？PO是必须的，产品需求，客户价值就靠他了；SM必须的，他要保证流程，整个环节里面，他是最了解流程的，会议需要他把握节奏，风险等；团队成员更是必须的。三种角色缺一不可。sprint应该多长才好？经验证明一般2-4周比较合适，可以拥有足够的敏捷性，又让团队进入“流”的状态，团队刚开始要确定sprint的长度，不要浪费太多时间做分析，选一个可以接受的长度先开始再说，等做完一两个sprint再进行调整。不过，团队确定了最合适长度之后，就要在长时间内坚持住。因为接下来的迭代过程有的时候会稍稍感觉有点长，有的时候感觉有点短。但保持住这个长度以后，它似乎变成了大家共同的心跳节奏，每个人都感觉很舒服。接下来无须讨论发布日期之类的事情，因为大家都知道：每过三周都会有一个发布。如何计算团队生产率？团队生成率是团队在迭代中完成的故事点，计算团队生成率是用迭代开始前分配的故事点数。一旦迭代完成，就不要改变迭代中团队获得的任何故事点数。举个例子来说，假如一个故事估算是4个故事点，但其实更大。后来团队发现他们应该估7个故事点。在计算团队生产率时，这个故事应该算4个点，而不是7个点。通常情况下，应鼓励团队在为下轮迭代生产率时，不要超过上轮迭代的生产率。然而，如果团队确实认为有个故事被严重低估，在下轮迭代中他们能做更多，就应该让他们计划一个稍微高一些的生产率。通常最初的生产率往往不准确，而且生产率在初期的迭代中也很不稳定。可能需要两三个迭代之后，才能获得一个长期的，比较稳定的生产率。Sprint过程中，Sprintbacklog是否可以随意添加？由SM进行风险把控，确保整个Sprint不被影响。需要判断添加的backlog优先级，是否紧急，sprint剩余工作量等进行综合考虑。在sprint计划会议之前，要确保产品backlog的井然有序，是什么意思？井然有序表示的意思是：所有重要的backlog条目都已经根据重要性被评过分，不同的重要程度对应不同的分数。无论任何故事，如果产品负责人认为它会在下一个sprint实现，那它就应该被划分到一个特有的重要性层次。分数只是用来根据重要性对backlog条目排序。假如A的分数是20，而B的分数是100，那仅仅是说明B比A重要而已，绝不意味着B比A重要五倍。如果B的分数是21而不是100，含义也是一样的。最好在分数之间留出适当间隔，以防后面出现一个C，比A重要而不如B重要。当然我们也可以给C打一个20.5分，但这样看上去就很难看了，所以我们还是留出间隔来。是否可以把一个产品backlog当做一个Sprintbacklog？看情况而定，如果产品backlog就是一个比较小的特性来说，是可以的，如果产品backlog确实很大，那么作为Sprintbacklog来说，就不太合适了。如何使用计划纸牌做时间估算?每个人都会得到一些纸牌，在估算故事的时候，每个人都选出一张纸牌来表示他的时间估算（例如以故事点或人天的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。重要的是，团队成员需要清楚，他们要对这个故事中所包含的全部工作进行估算。而不是“他们自己负责”的部分工作。估算需要考虑到工作中所有的细节:编码、测试、代码评审、会议、学习新技术、编写文档。如何决定sprint要包含的故事？决定哪些故事需要在这个sprint中完成，是sprint计划会议的一个主要活动。更具体地说，就是哪些故事需要从产品backlog拷贝到sprintbacklog中。每个矩形都表示一个故事，按重要性排序。最重要的故事在列表顶部。矩形尺寸表示故事大小（也就是以故事点估算的时间长短）。蓝括号的高度表示团队的估算生产率，也即团队认为他们在下一个sprint中所能完成的故事点数。右侧的sprintbacklog是产品backlog中的一个故事快照。它表示团队在这个sprint中承诺要完成的故事。如果故事D不会被放到sprint里面，但是产品经理又认为故事D很重要，那团