管理活动指南Sprint计划会.docx

Scrum管理活动指南-Sprint计划会
文档编号：YY/PF/AGUI/06/G02
文档信息：组织级过程文件
文档名称：Scrum开发活动指南-Sprint 计划会
文档类别：过程改进类
密级：内部
版本信息：1.0
建立日期：2015/12/30

创建人：张颖
审核者：罗涛
批准人：谢志华
批准日期：2016/01/01

文档修订记录
版本编号或者更改记录编号
*变化
状态
简要说明
（变更内容和变更范围）
日期
变更人
批准日期
批准人
V0.5
A
新建
2015/12/30
张颖

*变化状态：A——增加，M——修改，D——删除

文档评审记录
序号
评审人
角色
评审日期
签字
备注
1
罗涛
开发管理部经理
2016/01

2

3

文档审批信息
序号
审批人
角色
审批日期
签字
备注

目录
1.简介 4
1.1目的 4
1.2适用范围 4
1.3术语与缩略语 4
1.4参考资料 4
2.指南概述 4
3.实施步骤指导 5
4.常见问题： 6

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

每个矩形都表示一个故事，按重要性排序。最重要的故事在列表顶部。矩形尺寸表示故事大小（也就是以故事点估算的时间长短）。蓝括号的高度表示团队的估算生产率，也即团队认为他们在下一个sprint中所能完成的故事点数。
右侧的sprint backlog是产品 backlog中的一个故事快照。它表示团队在这个sprint中承诺要完成的故事。
如果故事D不会被放到sprint里面，但是产品经理又认为故事D很重要，那团队在sprint 计划会议上怎么做呢？

首先，PO可以重新设置优先级。如果他给故事D赋予最高的重要级别，团队就不得不把它先放到sprint里面来，同时需要把重要级别低的C置换出去。

其次，PO可以更改范围——缩小故事A的范围，直到团队认为故事D能在这个sprint里完成为止。

最后，他还可以拆分故事。产品负责人判断出故事A中某些方面实际并不重要，所以他把A分成两个故事A1和A2，赋给它们不同的重要级别。