• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

Mike的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。会议结束,非常感谢大家”

关于作者

李丁山(Mike Li)
CSM,CSP
1998 ~ 2004 上海宝信软件 项目经理
2005 ~ 2007 Infosys中国 高级项目经理
2008 ~ 至今 Autodesk中国 项目经理

从事项目管理的相关工作近10年,期间积累比较丰富的项目管理和团队建设的经验。从2008年开始接触敏捷开发,从此成为敏捷的积极推介者。对敏捷的核心价值有较深刻的理解,同时对国内软件企业的问题有比较深刻的认识,对于敏捷的实施,注重循序渐进,与实际情况相结合,强调价值的实现而不过于拘泥于具体的方式方法。

Mike的博客:http://www.cnblogs.com/RelaxTintin/

Search
最新敏捷认证课 ~ 火热报名中
3月2-3日
Scrum.org专业Scrum Master (PSM I) 认证课
丁志润 Derek Ding 授课
3月9-10日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
3月23-24日
高级Scrum Master (A-CSM) 认证课
Ethan Huang 授课
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280