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。