《硝烟中的Scrum和XP》读书笔记之一

引言：SCRUM不是方法学，它是一个框架。

（一）SCRUM流程：
1.产品BACKLOG：
2.SPRINT计划
3.SPRINT BACKLOG（每日SCRUM例会、更新任务墙和燃尽图）
4.SPRINT演示会议
5.SPRINT回顾会议
6.SPRINT休整时刻

 

（二）SCRUM实施及注意事项
1.产品BACKLOG：
1）产品backlog是scrum的核心，也是一切的起源；
2）产品backlog列表，一般包括的字段：id、故事描述、重要性、初始估算、如何做演示（本质就是一个简单的测试规范。如：“先这样做，然后那样做，就应该得到……的结果”）、备注。额外的故事字段（如：需求提出者、相关bug的id等）
3）让产品backlog停留在业务层上。（面对技术的故事，可以问产品负责人“但是为什么呢”的问题）

2.SPRINT计划
1）前置条件：已有产品backlog列表，且只有一个产品backlog一个产品经理。
2）产品负责人应当理解每个故事的含义。
3）判定故事的重要性，是产品经理独有的权利；判定估算时间，是团队独有的权利。
4）sprint计划会议的产出：sprint目标、团队成员名单、sprint backlog、确定演示日期、确定好每日scrum会议的时间地点。
5）每个故事有三个变量：其中范围和重要性是由产品经理决定的，估算是由团队决定的。
6）绝不能在质量上让步，质量包括外部质量和内部质量，其中内部质量指用户看不到的要素，它们对系统的可维护性有深远影响。
7）scrum中的一切事情都有时间盒。
8）sprint计划会议日程：图：p15

9）试下回答“我们为什么要进行这个sprint？为什么我们不直接放假算了？”以找出sprint目标。
10）产品经理可通过以下方式影响sprint放哪些故事：a.重新设置优先级；b.调整故事范围；c.拆分故事。
11）团队通过如下两个技术决定sprint放哪些故事：a.本能反应；b.生产率计算（昨日天气、投入程度）。
12）在墙上使用索引卡进行故事排序。图：29

13）定义“完成”：一般指：随时可以上线。
14）使用“计划纸牌”做时间估算---通常团队每个成员都要参与所有故事的估算。
15）明确故事内容。（方法：描述如何手工执行最典型的测试场景。）
16）技术故事：指需完成但不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值。
注意：
1）刚开始要试验sprint的长度。不要浪费太多时间进行分析。选一个可以接受的长度先开始再说，等做完一两个sprint再进行调整。
2）确定了自己最合适的长度后，就要在长时间内坚持住，这样慢慢地就变成了大家共同的心跳节奏。
3）scrum的要求：要把事情完全做完，达到可交付的状态，事情只做了一半，它的价值就是0（也许还会是负数）。
4）作者经验值：新团队使用的默认投入程序通常是70%。
5）不要让任务拆分出现在产品backlog。
6）估算时应对该故事的全部工作时间进行估算。
7）故事是可以交付的东西；任务是不可交付的东西。
8）sprint计划的优先级：
a.优先级1：sprint目标和演示日期。
b.优先级2：sprint中的故事列表。
c.优先级3：sprint中每个故事的估算值。
d.优先级4：srpint中每个故事“如何演示”。
e.优先级5：生产率和资源的计算。
f.优先级6：明确每日例会固定举行的时间地点。
g.优先级7：把故事拆分成任务。
9）当sprint backlog含有技术故事时，应采取如下做法：
a.试着避免技术故事。努力把技术故事变成可衡量业务价值的普通故事。
b.如果无法把技术故事变为普通故事，那就看看这项工作能不能当作另一个故事中的任务。
c.如果以上二者都不管用，那就把它定义为一个技术故事，用另外一个单独的列表来存放。产品经理负责人能看到它，但不能编辑它。

 

3.SPRINT BACKLOG
1）使用“sprint信息页”，让整个公司了解我们在做什么。图：42

2）sprint计划会议一结束，scrum master创建sprint信息页，并给整个公司群发sprint启动的邮件。
3）发布管理sprint backlog最有效的形式---挂在墙上的任务板。（包括内容：计划做的；正在做的；已完成；非计划内的故事；下一个sprint故事；燃尽图）图：46

4）用人/天作为时间估算的基础（也称为故事点），它的最小值为0.5。
5）每日SCRUM例会、更新任务墙和燃尽图
6）“让团队坐在一起”的含义：互相听到、互相看到、隔离（即，如果你们整个团队突然站起来激烈的讨论，团队外的任何人都不会被打扰到。反之亦然。）
7）如何更新任务板：一般我们都是在每日例会的时候更新任务板。
a.每个人都会一边描述昨天已经做的事情和今天要做的事情，一边移动任务板上对应的即时贴。
b.如果他讲的是一个未经计划的条目，那他就新写一张即时贴，贴到板上。
c.如果他更新了时间估算，那就在即时贴上写上新的时间并把旧的划掉。
8）每日例会一结束，就要有人算出剩余时间估算之和，更新燃尽图。

注意：
1）产品经理应离团队很近，但他不应跟团队坐在一起。
2）Scrum教练，应该尽可能贴近团队，但不久以后，就离开他们，让他们凝聚在一起，自我管理。然后每隔一段时间（不能太频繁），就去参加一次他们的sprint演示，看看任务板，听听晨会。
3）每日例会，防止持续时间超过15分钟。
4）尽量让整个团队参与到保持sprint backlog及时更新工作中来。