Scrum实战一:Sprint Planning Meeting

  今天终于正式的开第一个Sprint的Planning Meeting了,可是谁也没料到,PO今天突然有另外的事情,没办法到场。但我们这个计划又不便修改了,就只有我暂时代一下PO的角色来开Sprint Meeting1了。

    上午给大家时间,再看看原始的需求,我也再计划一下此次会议,中午1点我们正式开始Planning Meeting。
    首先给大家简单介绍了我们走Scrum的背景,以及Scrum流程,进行了一次Scrum的扫盲。同时介绍了本次Sprint的计划,起始日期,Review meeting,retrospective meeting的日期,Daily standup meeting的安排。一开始就发现问题,PO提供的需求,User Story太大了,没进行拆分,我们必须把他们再次细分,才好继续下去。同时我们发现JIRA Agile里,只要把Story 移到已经开始的Sprint里,就没办法移出了,真是郁闷,并且一旦移动到里面了,就没办法修改Story Point (这也许是要求我们必须在Product backlog里就必需把Point定好)。我给大家介绍了一下每个Story的需求,但是有些细节我没法解答,只好下周PO来给我们再解答一下。大家理解需求理解的差不多后,
我们就开始扑克牌估算,我们首先找了一个比较简单的story 作为参考,把它的复杂度定为3,然后再去估算其他Story,这样下来,我们经过多次出牌,总共估算了5个Story,总共有27个point,最终我们决定选择其中的4个story作为本次sprint的目标。Meeting1到此结束,休息片刻后,我们继续Meeting2。
    Meeting2我们主要做任务的拆分,基本上把每个Story 分为Coding,Test Case,Testing,然后分别进行扑克牌估算,在估算的时候有有人提议用小时,但我觉得用天更好,因为既然是一个任务,我认为至少得要1/2天,需要把差距拉出来,不然1小时和2小时差别太小了,看不出差距。最后我们估算的时候,也发现有如果是1/2的倍数,可能大了一点或者小了一点,我们在微调,比如大家一致认为比1/2大,比1小,那我们就估算出来6小时。最后我们把任务估算了,最后还加了一个CodeReview的Tast和Release的Task,并且也估算了工时。

    这样来来回回的折腾了,差不多花了3.5小时,才Meeting算是完了,看着这么Task,大家都还比较有成就感。

   总的来说,第一次会议我们依葫芦画瓢,算是走了下来,第一次能做成这样,感觉还是不错的。但发现有以下问题,有的在Sprint中就可以运用,有的在下次Sprint Planning Meeting中改进。

  • Story不够标准,并且在Sprint开始之前,不要把Story提前放到Sprint里,这里应该在Meeting1的时候来决定。
  • 估算式还是比较顺利,只是觉得花的时间稍长,以后可以更快,大家估算工时候还是稍显悲观,还不知道总工时太离谱了不?
  • 整体下来,大家对需求的细节理解还是不够,在开Sprint Planning Meeting1的时候,大家应该带着些问题来;并且在Meeting1和Meeting2之间,需要一段时间消化需求,并且考虑如何拆分Task。
  • 考虑在开发Coding和测试写Case之前,先碰头再明确一下需求,这样比较保险一点。
  • Coding与Case进行交叉Review。
  • 漏掉了一个Test case review的Task,和Bug fix的Task。

展开阅读全文

没有更多推荐了,返回首页