硝烟中的 Scrum 和 XP（一）

一、怎么编写产品backlog？

从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事(story)，有时候也叫做 backlog 条目。

我们的故事包括这样一些字段:

ID———统一标识符，就是个自增长的数字而已。
Name——简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由 2 到 10 个字组成。
Importance(重要性)——产品负责人评出一个数值，指示这个故事有多重要。例如 10 或 150。分数越高越重要。
Initial estimate(初始估算)——团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点(story point)，一般大致相当于一个“理想的人天 (man-day)”。
How to demo(如何做演示)——它大略描述了这个故事应该如何在 sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到......的结果 ”。
Notes(注解)——相关信息、解释说明和对其它资料的引用等等。一般都非常简短。

ID	Name	重要性	初始估算值	如何演示	注解
1	存款	20	8	登陆，打开存款界面，存入10元；转到我的账户余额，检查到增加了10元。	目前不需要考虑加密问题。

二、怎么准备sprint计划？

在 sprint 计划会议之前，要确保产品 backlog 的井然有序。

产品backlog必须存在(你能想象到这一点么?)。
只能有一个产品backlog和一个产品负责人(对于一个产品而言)。
所有重要的backlog条目都已经根据重要性被评过分，不同的重要程度对应不同的分数。
产品负责人应当理解每个故事的含义

三、怎么制定sprint计划？

举办 Sprint 计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。

其实，Sprint 计划会议会产生一些实实在在的成果:

sprint目标。
团队成员名单(以及他们的投入程度，如果不是 100%的话)。
sprintbacklog(即sprint中包括的故事列表)。
确定好sprint演示日期。
确定好时间地点，供举行每日scrum会议

为什么产品负责人必须参加？

原因在于，每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖。范围(scope)和重要性(importance)由产品负责人设置。估算 (estimate)由团队设置。在 sprint 计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。

如果产品负责人还是坚持没时间参加怎么办?一般我会按顺序尝试下面的策略:

试着让产品负责人理解，为什么他的直接参与事关项目成败，希望他可以改变念头。
试着在团队中找到某个人，让他在会议中充当产品负责人的代表。
试着说服管理团队为我们分配新的产品负责人。
推迟 sprint 的启动日期，直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情。

为什么不能在质量上让步？

外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。

Sprint 计划会议日程

在 sprint 计划会议之前先为它初步制定一个时间表，可以减少打破时间盒的风险。

确定sprint 长度

Sprint 演示日期是 sprint 计划会议的产出物，它被确定下来以后，也就确定了 sprint 的长度。

产品负责人一般会喜欢短一点的sprint，而开发人员喜欢时间长的 sprint。所以sprint的长度是妥协后的产物。做过多次实验后，我们最终总结出了最喜欢的长度:三个星期。绝大部分团队的sprint长度都是三周。它不长不短，既让我们拥有足够的敏捷性，又让团队进入“流”的状态，同时还可以解决sprint中出现的问题。

确定sprint 目标

Sprint 目标需要回答这个根本的问题，“我们为什么要进行这个 sprint?为什么我们不直接放假算了?”要想从产品负责人的口中哄骗出 sprint 目标，你不妨一字不差的问他这个问题看看。

决定 sprint 要包含的故事

决定哪些故事需要在这个 sprint 中完成，是 sprint 计划会议的一个主要活动。更具体地说，就是哪些故事需要从产品 backlog 拷贝到 sprint backlog 中。

在 sprint 中包含多少故事由团队决定，而不是产品负责人或其他人。

产品负责人如何对 sprint 放哪些故事产生影响?

为什么产品负责人必须参加？

如果产品负责人还是坚持没时间参加怎么办?一般我会按顺序尝试下面的策略:

试着让产品负责人理解，为什么他的直接参与事关项目成败，希望他可以改变念头。
试着在团队中找到某个人，让他在会议中充当产品负责人的代表。
试着说服管理团队为我们分配新的产品负责人。
推迟 sprint 的启动日期，直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情。

为什么不能在质量上让步？

外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。

Sprint 计划会议日程

在 sprint 计划会议之前先为它初步制定一个时间表，可以减少打破时间盒的风险。

确定sprint 长度

Sprint 演示日期是 sprint 计划会议的产出物，它被确定下来以后，也就确定了 sprint 的长度。

确定sprint 目标

决定 sprint 要包含的故事

决定哪些故事需要在这个 sprint 中完成，是 sprint 计划会议的一个主要活动。更具体地说，就是哪些故事需要从产品 backlog 拷贝到 sprint backlog 中。

在 sprint 中包含多少故事由团队决定，而不是产品负责人或其他人。

产品负责人如何对 sprint 放哪些故事产生影响?

产品负责人很失望，因为故事 D 不会被放到 sprint 里面。那他在 sprint 计划会议上能做些什么?

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

其次，他可以更改范围——缩小故事 A 的范围，直到团队相信故事 D 能在这个 sprint 里完成为止。
最后，他还可以拆分故事。产品负责人判断出故事 A 中某些方面实际并不重要，所以他把 A 分成两个故事 A1 和 A2，赋给它们不同的重要级别。

团队怎样决定把哪些故事放到 sprint 里面?

我们在这里使用两个技术:1. 本能反应2. 生产率计算

用生产率计算来估算这项技术包括两步:1. 得出估算生产率2. 计算在不超出估算生产率的情况下可以加入多少故事。生产率是“已完成工作总量”的一个衡量方式，其中每一个条目都是用它的原始估算进行衡量的。

有一个很简单的办法:看看团队的历史。看看他们在过去几个 sprint 里面的生产率是多少，然后假定在下一个 sprint 里面生产率差不多不变。

这项技术也被叫做“昨日天气(yesterday’s weather)”。要想使用该技术，必须满足两个条件:团队已经完成了几个 sprint(这样就可以得到统计数据)，会以几乎完全相同的方式(团队长度不变，工作状态等条件不变)来进行下一个 sprint。当然也不是绝对如此。

只要条件允许，你就应该看看从前的 sprints，计算出平均数，这样可以得到更合理的估算。

如果这是个全新的团队，没有任何数据怎么办?你可以参考一下在类似条件下工作的团队，他们的投入程度数值是多少。

为何使用索引卡

要想收到好的效果，不妨创建一些索引卡，把它们放到墙上(或一张大桌子上)。这种用户体验比计算机和投影仪好得多。原因是:

大家站起来四处走动=> 他们可以更长时间地保持清醒，并留心会议进展。
他们有更多的个人参与感(而不是只有那个拿着键盘的家伙才有)。
多个故事可以同时编辑。
重新划分优先级变得易如反掌——挪动索引卡就行。
会议结束后，索引卡可以拿出会议室，贴在墙上的任务板上。

定义“完成”

有一点很重要:产品负责人和团队需要对“完成”有一致的定义。

我们尽可能使用这样的定义:“随时可以上线”，不过有时候我们也这样说:“已经部署到测试服务器上，准备进行验收测试”。

使用计划纸牌做时间估算

估算是一项团队活动——通常每个成员都会参与所有故事的估算。为啥要每个人都参加?

在计划的时候，我们一般都还不知道到底谁会来实现哪个故事的哪个部分。
每个故事一般有好几个人参与，也包括不同类型的专长(用户界面设计、编程、测试、等等)。
团队成员必须要对故事内容有一定的理解才能进行估算。要求每个人都做估算，我们就可以确保他们都理解了每个条目的内容。这样就为大家在 sprint 中相互帮助夯实了基础，也有助于故事中的重要问题被尽早发现。

如果要求每个人都对故事做估算，我们就会常常发现两个人对同一个故事的估算结果差异很大。我们应该尽早发现这种问题并就此进行讨论。有一项很优秀的技术可以避免这一点——它的名字是计划纸牌。

明确故事内容

是确保每个故事的所有字段都被填满(更精确地说，这里提到的是具有高优先级，应该在这个 sprint 里面完成的故事)。

把故事拆分成任务

故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。

注意——我们在实践 TDD(测试驱动开发)，所以几乎每个故事的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”(提高代码的可读性，消除重复)。

定下每日例会的时间地点

Sprint 计划会议有一个产物常常被人们忽略:“确定的时间和地点，以供举办每日例会”。

最后界限在哪里

如果时间不够的话，那么我们该把哪些本该做的事情砍掉呢?

优先级 1:sprint 目标和演示日期。

优先级 2:经过团队认可、要添加到这个 sprint 中的故事列表。

优先级 3:Sprint 中每个故事的估算值。

优先级 4:Sprint 中每个故事的“如何演示”。

优先级 5:生产率和资源计算，用作 sprint 计划的现实核查。包括团队成员的名单及每个人的承诺(不然就没法计算生产率)。

优先级 6:明确每日例会固定举行的时间地点。这只需要花几分钟，但如果时间不够用，Scrum master 可以在会后直接定下来，邮件通知所有人。

优先级 7:把故事拆分成任务。这个拆分也可以在每日例会上做，不过这会稍稍打乱 sprint 的流程。

技术故事

指的是需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值。

比如安装持续构建服务器、重构 DAO 层、升级 Jira (bug 跟踪工具)

我们得出的结论是，产品负责人往往不能对此做出正确的权衡。所以我们采取了下面这些做法:

1) 试着避免技术故事。努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡。

2) 如果无法把技术故事转变成普通故事，那就看看这项工作能不能当作另一个故事中的某个任务。例如，“重构 DAO 层”可以作为“编辑用户”中的一个任务，因为这个故事会涉及到 DAO 层。

3) 如果以上二者都不管用，那就把它定义为一个技术故事，用另外一个单独的列表来存放。产品负责人能看到它，但是不能编辑它。用“投入程度”和“预估生产率”这两个参数来跟产品负责人协商，从 sprint 里拨出一些时间来完成这些技术故事。

Bug 跟踪系统 vs. 产品 backlog

Jira