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之间。

 

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

posted @ 2008-09-08 14:06 Li Dingshan 阅读(...) 评论(...) 编辑 收藏