Scrum实施日记 - 发布计划评估，万事开头难

今天是计划中对发布计划进行团队评估的日子。考虑到这是一个才刚刚开始的Scrum团队，在安排会议的时候，我定了4个小时，以便大家有比较充分的时间进行讨论和评估。

会议开始，Product Owner将第一次发布所需要的用户故事用Excel列了出来，一共分为两个阶段，大约10个用户故事，Product Owner希望能够在两个半月完成这些内容，按照两周一个Sprint的计划，大约是5个Sprint。这时候团队请Product Owner对每个故事做一个比较详细的解释，并且在有疑问的时候，就随时提出，请Product Owner解答一下。这个过程还是比较顺利的。然后，我拿出了估算扑克，给团队的每个人发了一套。

 

“这就是培训的时候，我给大家说的估算扑克。” 我说，”我们将要对整个发布计划中的每个用户故事进行估算，方法是从第一个故事开始，我会要求你们根据自己的理解，给出自己对这个故事点数估计，并将对应点数的扑克取出扣在桌上，直到我让你们亮出来，才翻开，明白吗？这样是为了避免你的点数的判断会影响其他人的估算。”。

 

看起来对于这一点，大家没有什么疑问。所以，我接着说：“在我们开始估算之前，我想问一下，在列出的所有故事中，有没有哪个故事，你们非常清楚要做什么，而且比较简单，可以被定为2点？”。这时候，大家看上去有些疑惑了，一个人问道：“请问2点的意思是什么？”。我回答说：“它并没有具体的意义，如果你们记得，在培训的时候我说过，故事点的估算是一个相对精确的估算，就是说，如果一个故事的点数是2点，另一个是5点，那就是说5点的故事的规模大概是2点故事的2倍多。我们希望找出一个2点的故事，就是为了能够找到你们这个项目的一个估算的基准，有了这个基准的2点的故事后，其它故事的点数估算，是通过和这个基准的故事比较来做出的。”

 

“那就是说，如果我们找一个故事是20点，以此为基准，也是可以的，是吗？” 一个人举手问我。

怎么回答这个问题呢？我心里犯了点嘀咕。“嗯。。。，理论上说，你是对的，但从实践的角度上，不推荐这样的做法。我们希望用户故事足够小，以便能够在1个Sprint内完成。另外，太大的故事之间进行比较，误差也会比较大。比如说，让你比较两个山头的大小，和让你比较两堆沙子的大小，哪个误差会更小呢？”

 

“那我们具体该如何确定一个2点的故事？我还是觉得挺抽象的。” 另一个人还是觉得不知如何下手。

“OK，其实并没有一个特别标准的做法，每个团队都可能不同，即使针对同一个项目，也可能有不同的选择。既然我们刚开始，也许可以借鉴一下别人的做法，我知道有的团队会定义一个2点故事，大概就是一个可以在2~3个工作日内可以完成的故事，你们觉得这样可以吗？” 

“好吧，这样好像比较清楚了，让我们看看这些故事吧。” 大家终于觉得可以进行估算了，我也暗自舒了一口气:)

 

“我觉得这些故事没有一个可以是2点的，因为没有哪个可以在2～3天内完成。” 一个资深的开发人员提出了疑问。

我看了看Product Owner，他解释说，因为这是一个发布计划，按照之前和我商量的，开始的时候，可以不需要制定太细的用户故事，可以给出一些Epic（史诗，就是比较大的故事），所以很有可能目前这些故事还需要进一步的细分。

我点点头，“没错，今天这个会议是对整个发布计划的内容做一个整体的评估，让所有人了解一下整个项目的范围和规模，给出一个粗略的估算。以后在做具体的Sprint的计划的时候，需要再进一步的切分它们，直到足够小。所以，如果现在没有一个故事符合2点的定义，那么请问你们觉得现在给出的所有故事中，最小的一个大概是多少点？”

“第三个吧，我觉的大概5点左右。” 一个人说。我看了看其他人，好像没什么意见。

“那么，这个故事将被定义为5点，你们同意吗？” 我问所有的人。

“应该可以” 大家都表示赞成。

“好，那我们就以它做为基准，对其它的故事进行估算。” （终于可以开始估算了。。。）

 

2分钟后

看到每个人都抽出了一张牌后，我说：“请大家把牌亮开，给出第一个故事的点数。”

基本上大家给出的都是13个点，只有一个QA给出了20点。

“你为什么给出20个点？” 我问。

“因为我觉得这个故事需要改变系统已有的代码，这样就意味着我得把从前的功能都要重新测试一遍，还是挺花时间的。” 

“其实不需要的，” 另一个开发人员说：“这个需求只是增加一个新的功能，对以前的代码没什么改变。”

“可是它要求能够查看系统已有的所有对象的属性，这个不需要改代码吗？” QA提出了疑问。

这时候，Product Owner站了出来，“这个需求只是希望能够把新的属性查看功能增加到现有系统中，对于已有对象的属性查看的要求，是第8个故事才要求的。”

“OK，我了解了，那么能不能请你更改一下这个故事的说明，因为现在的描述没有说清楚你的要求。” QA对Product Owner说。

“OK，我现在立刻就改了它。”

我看似乎大家都达成了一致了，于是问：“那么现在大家对这个故事还有什么疑问么？” 大家都摇了摇头。“OK，那我们是需要重新评估一下，还是你们已经有了统一个意见？”

“我们还是觉得13点比较合适。” 大多数人还是维持原来的估算。

“你同意13个点的估算吗？” 我问那个QA。

“按照现在这样的要求，我同意。”

“好，那么第一个故事就是13个点。” 我宣布说。

 

接着，大家用同样的方法对其它的故事进行的估算，整个估算的过程大约用了2个小时，最终，对每个故事都给出了估算的点数，总共是350个点。根据不确定的原则（参见Mike Cohn的书《Agile Planning & Estimating》），我们给出了第一个发布计划的需求规模大概是350/1.6 ~ 350 / 0.6，大约是220 ～ 580之间。

 

会议结束后，大家都有点累了，所谓万事开头难，希望这个对发布计划的评估会议，能够帮助所有的人对项目有一个初步的但是完整的了解，这样，对于以后的开发，都会有很大的帮助。