Scrum实施日记 - 这个故事太大了

今天是第一个Sprint计划日,早上10点,所有的人都准时来到了会议室。

“好了,大家都知道今天我们要干什么。” 我开始了会议,“请每个人拿一副估算扑克。”
每个人都从我手里拿了一幅扑克,开始在手里把玩,一个个好像都是Show Hand高手。

“请Product Owner先把她希望在这次Sprint中开发的用户故事说明一下。” 我按照会议的流程开始了第一项内容。

Product Owner接上投影仪,打开Excel,列出了按照重要程度排好序的用户故事,将每个故事需要开发的内容大致介绍了一下。其间不停的有人提出一些疑问,请Product Owner解答。经过大约45分钟的讨论,大家对这些用户故事已经比较清楚了。

“现在我们开始进行估算,就像我们评估发布计划时做的一样,从第一个故事开始,每个人根据自己的估计,给出点数,但直到我允许,才翻出来给大家看。” 我开始进入第二个阶段,估算用户故事的点数以便确定Sprint Backlog。

由于是第一个Sprint,大家对于每个Sprint可以完成多少点的故事没有任何概念,所以我们决定每次估算完一个故事后,大家就开始进行任务分解,并对每个任务需要的工作时间进行估计,累计所有任务的工作时间,看看是否达到了所有团队成员在这个Sprint中可以投入的工作时间总和。也就是说,如果一个用户故事的任务分解后,总共需要50个小时,而一个5人的开发团队在两周(10天)的Sprint中总共的可用工作时间是5×10×6=300小时,(注意,这里每天的工作时间是按照6个小时计算的,而不是8个小时,这样是考虑到每天8小时的工作时间,总是有些时间需要用来参加一些与项目无关的活动,比如会议,回邮件,培训,休息等等),那么团队就可以决定这个故事可以在这个Sprint中完成,然后进行第二个故事的故事分解,看看剩下的时间是否足够可以完成第二个故事,这样反复进行,知道团队觉得已经不能承诺更多的故事为止,这时候就可以得到这个Sprint中,团队可以承诺的故事集合,也就是Sprint Backlog。

按照这个方法,我首先请大家把在这个Sprint中各自可以投入的时间汇总一下(这个团队为了确保计划会议和Demo会议的时间能够比较固定,决定总是在周一开始计划会议,而在第二周的周五进行Demo,这样实际上只有8天的工作时间)。一个开发人员说他只能有50%的时间放在这个项目上,而其他的人可以100%投入,由于总共只有3个人会参与到开发中,所以总共的时间是2.5×8×6=120小时。

有了这个时间后,我们正式开始估算,大家首先给出了第一个故事的点数,5点,然后我让团队一起立刻开始对第一个故事进行任务的分解,这个过程中,DEV和QA是各自完成任务分解,然后再汇总,得出总的需要时间,其间,QA和DEV会互相交流,以便确保对用户故事的理解是一样的,特别是QA,对于如何进行测试提出了很多的问题,这帮助大家对这个用户故事有了进一步的理解。

就在大家进行任务分解的时候,突然DEV有人叫了出来:“这个用户故事好像太大了,一个Sprint根本不可能完成。”

我看了看大家,似乎团队都有同感,于是我问他:“你能不能具体解释一下?”

“这个故事要求可以对系统的信息进行维护,可是这个涉及到增加几张数据表保存系统的信息,同时还要实现好几个API和一些UI,对信息进行增删改查的操作,同时还要对错误的操作进行处理,这太多了,无法在两周内完成。”

我转头问Product Owner:“你的意见呢?”

“嗯,如果这太复杂了,那么我可以第一步只希望有一个地方看到所有系统的信息,以方便系统管理员查看系统的状态。错误的处理可以暂时不考虑。” Product Owner说。

“那么关于其它的维护操作,你会用新的用户故事来描述,就是说,你会根据操作,进一步分割这个用户故事,是吗?” 我问到。

“是的。”

“那我们可不可以先把这个用户故事描述的再清楚一些,说明只需要查看系统的信息?”

“当然可以,我现在就改掉它。”

然后我问团队:“你们现在还觉得这个故事是5点吗?” 大家点点头,都表示同意。

团队开始继续分解任务,经过大约1个多小时的时间,他们给出了答案,第一个故事大约5点,总共需要差不多114个小时,基本上已经占满了这个Sprint的所有工作时间。考虑到第一个Sprint中,还需要一些时间来建立代码的分支版本,还有测试环境等,所以团队决定第一个Sprint只承诺一个故事。我看看Product Owner,她看上去有些失望,于是我问她:“你同意大家的决定吗?”

她犹豫了一下,然后说:“我觉得如果按照这样的进度的话,我们不可能在计划的时间内完成这个项目的。”

我对她说:“这只是刚刚开始,大家需要一些时间来熟悉这个项目,一般来说,他们的速度会随着项目的进行而提高。所以现在还不是下结论的时候。另外,之前的计划只是一个非常粗略的估计,并没有这个开发团队任何实际的数据的支持,非常有可能原来的计划并不正确。重要的是,我们现在就意识到原来的计划可能需要调整,这样我们可以有足够的时间去处理这些变化,是吗?”

“嗯,我想这一点确实是非常重要的一点,我想我们可以先这样开始,看情况再定。” Product Owner说道。

“OK,” 我对所有参加会议的人宣布说:“这个Sprint我们将实现第一个用户故事,5点,下周五Demo。会议结束,非常感谢大家”

posted @ 2008-09-10 23:12 Li Dingshan 阅读(...) 评论(...) 编辑 收藏