迭代计划会(Sprint Planning Meeting)
1、迭代计划会在每个迭代的第一天召开,目的是选择和估算本次迭代的工作项。
2、产品负责人逐条讲解最重要的产品功能。
3、开发团队共同估算故事所需的工作量,知道本迭代工作量达到饱和。
4、产品负责人参与讨论并回答与需求相关的问题,但不干扰估算结果。
迭代计划会I(产品Backlog)
会议准备:
1、邀请与会者(产品负责人、ScrumMaster、团队所有成员)
2、已按优先级排列产品Backlog中的各项问题
3、已评估产品Backlog中的各项问题
4、把产品Backlog公开给会议中的每个人,保证其可被获取
5、每个人都可以获取上次Sprint评审会议和Sprint回顾会议的结果
6、Sprint时间表已经安排:
a. Sprint计划会议1的时间安排
b. Sprint计划会议2的时间安排
c. Sprint的第一天已经确定
d. Sprint的最后一天已经确定
e. Sprint每日例会的时间安排
f. Sprint评审会议的时间安排
g. Sprint回顾会议的时间安排
会议进程:
1、把Sprint时间表公开给所有人
2、把Sprint评审会议的结果公开给所有人
3、把Sprint回顾会议的结果公开给所有人
4、产品负责人向团队成员阐述产品远景
5、产品负责人和团队一起确定Sprint目标
6、如果Backlog里有问题遗漏:产品负责人有权往Backlog里添加问题
会议结果:
为Sprint计划会议II的进行准备好既定产品Backlog
迭代计划会II(SprintBacklog)
会议准备:
1、邀请与会者(产品负责人、ScrumMaster、团队所有成员)
2、既定产品Backlog
3、记录任务时需要的卡片或贴纸
会议进程:
1、团队成员从Backlog的各项问题中分出相应的任务。
2、确保考虑到工作中的所有细节
a. 编码
b. 测试
c. 代码评审
d. 会议
e. 学习新技术
f. 编写文档
3、如果任务需时超过一天:尝试把该任务分割成几个小任务。
4、如果团队认为SprintBacklog中项过多:和产品负责人一起删减Backlog中的问题。
5、如果团队认为SprintBacklog中项过少:和产品负责人一起从产品Backlog中选出最重要问题,加入SprintBacklog中。
6、团队确认Sprint目标。
会议结果:
1、Sprint目标和SprintBacklog对于公司内的所有人都是公开的
2、所有团队成员都可以获取SprintBacklog中的任务
产品负责人准备什么?讲解什么?
1、会前准备:条目化的需求(用户故事),优先级排序,最近1-2个迭代最希望看到的功能。
2、会上讲解:较难以文字表述的内容。讲解过程中团队可以随时发问,产品负责人要予以解答。若产品负责人感觉答案没有想清楚,可以推迟故事的开发,或将故事分解为“已想清楚的”和“未想清楚的”,后者推迟到下一个迭代或更晚。
3、两者的关系:准备活动类似于电影剧本编写,它导致了这是不是一个好故事的基本问题;会上讲解类似于导演说戏,它导致了这个故事我们能不能演好的问题。
4、一般一个团队只有70%的工作可以进行正式工作,因此每个月安排15人天左右即为饱和,新团队则可能低至10人天。
团队怎样估算?
1、共同估算:在估算前不应该指定谁将开发这个故事,而是以接收故事的小组为单位集体估算,每个人提出自己的看法,大家综合。这样才能以集体智慧完成任务。
2、在估算过程,产品负责人不能离开,因为很多估算差异问题来自于“做什么,做到什么地步”,产品负责人需要予以解答,而不是让团队按自己的理解去做。
3、共同估算的目的不是一个数字上的统一,而是用集体智慧和知识对“做什么,怎么做”达成共识。
4、共同估算是共同跟进的基础,若不能共同估算,则后面的“每日站会”几乎不可能正常进行,因为大家只关心自己曾经一起分析,思考,提问,设计乃至于争论过的任务进展的怎样了,是不是和自己想象的一样。
5、共同估算的最佳方法是“扑克牌估算”。估算扑克是几个潜在的任务承担者(如某个功能小组)共同估算的方法,他们一起听产品负责人讲解,一起估算,以达到利用集体智慧解决问题的目的。
a. 每人各自估算后独立出暗牌,听口令一起开牌。
b. 数值最大者与最小者PK,其他人旁听也可参与。
c. 讨论结束后重新出牌与开牌。
d. 重复上述过程,知道结果比较接近。
其它会议:
在Sprint开始前,需确定各常规Scrum会议中的时间安排。
一般两周的Sprint,建议其常规的Scrum会议时间安排如下:
来源:https://www.cnblogs.com/raol/archive/2013/05/15/3080960.html