我: Tech Leader
团队:团队成员分布在两个城市,我所在的城市包括我有4个成员,另外一个城市包括SM有7个成员。另外由于我们的BA离职了,我暂代IT 的PO 职位.PM和我在一个城市,但他不参于敏捷的运作里面.
迭代: 双周
主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting.
现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3开始,外部教练基本上没有看我们的状况,由我指导着团队和远程的SM进行敏捷活动。
-------------------------以上是基本背景----------------------------------------------------
不好意思,昨天晚上哄小朋友睡觉时,自己也睡着了,忘记上来写blog了。
Sprint Planning 是Sprint里很重要的一个会议,这个会议开得好坏,对整个Sprint的交付有很大的影响,开得好,团队可能会如期交付,开得不好,不但会影响团队的交付,而且还会对整个团队的气氛,士气有着消极的影响。
首先让我们一起来看看开计划会议的几个要素:
1. 计划会怎么开?计划会实际包括两部分,一部分是PO讲解需求(Grooming),另一部分是团队估算并和SM排计划。
2. 什么时候开计划会议?上一个Sprint的结束或者Sprint的开始阶段。
3. 计划会的目的是什么?计划,定义Sprint目标和交流需求。
4. 开多久? 在一个双周的Sprint里面,我们的建议是2-4小时 (包括Grooming).
让我们来看一看如果计划会开得不好,会发生什么样的情况:
1. 估算不准, 会影响团队的交付承诺。
2. 对需求理解得不一致,会导致交付物不是PO想要的。
3. 需求不清晰,会导致开会时间都用在讨论需求了,开会时间会过长。
4. 团队承诺太少,影响产品的交付物或市场效应,一般很少发生这种情……
5. 团队承诺太多,导致团队交付不了,或者质量差,或者导致团队加班严重。
所以计划会的质量有时决定了Sprint的交付。
昨天星期二,根据团队的意愿,我们开计划会议,时间:下午四点到五点半,历时一个半小时。
输入:product backlog, 优先级
输出:sprint backlog, 估算
估算方法:以Sprint1的某一个2个点的story做为基准,
notes: 估算时将开发所需天数和复杂度一起考虑,留意,我们没有以开发的天数作为一个点数,而是以时间加复杂度的方式让团队一起分析并估算。
因为前一天开了grooming,所以在开会前我只是过了一遍backlog,好让大家有一个印象,然后我们再把原来定的基准Story拿出来,给大家回顾一下,就开始估算了。团队一起会将开发时间和点数联系起来,这个时候,SM就要强调我们的点数可能不精确,只是做为一个参照物和基准进行比较;并且要团队一起估算,我们就是让大家一起出手来投票点数,当某一两个同事的点数和大多数人不一致时,不一定是少数服从多数,而是让团队去发言,为什么要估这个点数,在这个讨价还价的过程当中,就会讨论需求,激发大家的思考和对需求的理解,这个时候呢,PO就最好是可以随时联系的,好让PO澄清需求,和回答和需求相关的问题。开始的几个story可能会花费时间长一点,因为团队还没开始进入状态,后来的估算进展还是比较顺利,大家估的点数都大体上一致。
估算完后,就是认领story了,我和SM坚持让团队自己认领story,一个人只可以领一个story,轮完一轮后再重新轮过,直到认领完为止,除各别的story要某个人才能做的需要指定,认领完后,基本就结束了。
总结:
1. 大家对需求的理解比以前加深了, 不像以前, 团队的个人基本只关注自己的任务,很少去关注其它人的任务。
2. 经过前两个sprint后,大家估算越来越准了,而且速度也快了。
3. 不足的地方是没有定sprint目标,这两天叫我们的SM定一下。
4. 由于上一个sprint还有些没完成,就没有在计划上定完成时间,完成时间我是今天才让大家更新上去的。
5. 明知有一些story是完不成的,该不该把它排进这个sprint了呢?教练曾经说过,就算完不成,也要排,否则在开早会的时候跟踪不了这个story的进度,因为早会我们是对着每一张story的卡片去过状态的。
6. 尽量完成这个sprint的所有story,不让它们遗留到下一个sprint去.
暂时写到这里吧,又两点钟了,睡觉去了,明天继续。