谈谈我们的Scrum

为什么Scrum

对于我们team来讲,这其实是个被动的过程。

我们部门之前在一些team实行过Scrum,可能是感觉效果还不错,而且觉得原来的瀑布模型太过古老和死板,于是决定今年年初开始全面实施Scrum。

由于大家都是新手,公司采用了两个方法: 

  1. 一是超密集的培训。请专门机构来培训;请US的同事来培训;请实施过Scrum的同事来培训...
  2. 二是实战演练。组成几个临时的team,用两个礼拜的时间跑一个sprint,使大家对Scrum的理解从理论拓展到实际...,同时也有利于培养出第一批的Scrum Master...

当然,自我学习也是一个很重要的过程,在那段时间,也参阅了不少这个领域的好书:Scrum书籍豆列

 

我们是怎么做的 

配合Scrum的流程,我们使用了Wiki和Jira来管理项目。

Jira主要是管理整个项目的User Story和Task,以及相关的一些材料,讨论等。Wiki则用来管理整个项目的安排和每个Sprint的状况。

大概列一下我们跑的流程:

  1. 在项目初始阶段,先整个team在一起头脑风暴,想出所有可能的story,由于问题的不确定性,可能需要几个session。
  2. PO回去整理,细化每个story,并做好rank。
  3. Team做完所有story的point估算。 (为了获得team对story point,对velocity的感觉,最好先跑一、两个sprint。不然可以先估计,然后逐步调整)
  4. 根据team的velocity和总的story point,做出release plan。并设定出一些主要的milestone(一般三个sprint一个milestone),release plan需要随着product backlog的不断更新而更新。
  5. 我们的sprint长度是两周。感觉刚好,因为一周的话,减去所有会议时间,剩下的时间就不多了;三周以上的话感觉对整个sprint的掌控度不够,而且不易应对impediments。
  6. Plan meeting的agenda一般为:设定sprint的goal;计算team的availability;估算上个sprint中新创建的story的point;选择这个sprint的要做的story;Task breakdown & assignment。
  7. Review和Retrospective meeting一般放在一起,agenda为:对过去一个sprint的总体回顾,如planning时commit的story,遇到的impediments等;轮流demo自己所做的task;确定story的状态:complete,split或者defer;restrospective。
  8. Daily meeting中大家轮流讲一下自己的状态,人少的话还可以讨论一些具体的问题。
  9. Wiki中包含的信息:项目概况;team组成;项目文档;release planning;team calendar;product backlog;其中每个sprint会有一个页面:sprint goal与commit的point;该sprint的team availability;会议时间与地点;上个sprint的retrospective的结果;本sprint的notes;本sprint的impediments记录等等。
  10. Jira是PO的好朋友,是SM的好帮手。Jira用来管理所有的story与task,以及关于story与task的文档与讨论。具体的,我们可以用Epic来表示一些项目的大方向并链接相关story;用其他类型的item(如improvement)表示分隔栏,用来分隔must have,nice to have等,并且可以使用label来标记相关story。
  11. 对于不是很明确的story,一般分成两步走:一个investigation的story,一个实际工作的story。这样化整为零就能比较好的解决其估算问题了。虽然对于第一个investigation的story也不是很清晰,但根据经验,还是可以给一个比较靠谱的估计。
  12. 很多bug很难根据描述判断其effort,所以我们一般有个惯例,就是一个bug默认给3个小时,如果经过3个小时的研究后发现问题比较大,可以另外拎出来放到下个sprint去完成。
  13. 为了便于更好的估算,一般需要积累一些不同size的story作为baseline。
  14. story point不能太大,不然失去其准确性就没有什么意义了,如20,40等,一般情况下,8以上的story是不应该出现的sprint中的。
  15. 用excel表统计team availability,根据availability以及历史数据算出可commit的story point数。利用excel的计算功能可以自动化整个的计算过程。

哪里需要改进

  1. 每个story的COS(Criteria Of Satisfaction)需要明确定义,也就是需要有完整的acceptance test。
  2. Scrum是个比较流程性的东西,尤其是会议,所以在开会的时候,一定要注重实效,不要为了流程而流程从而浪费了无数时间。

我对Scrum的感受 

  1. Daily meeting有两个很重要的作用:一个是表面上的,让大家了解team的状态;另一个是潜在的,催促大家努力工作以便在这个会议中能讲点什么~~~ 话说回来,虽然有效,我对每天早上要开会还是蛮反感的~~~
  2. 依赖于product backlog与team velocity的数据支持,使得team对自己能做什么比较清晰,加强了项目的可控性。
  3. 充分的交流,利于及时发现问题,利于得出最佳的方案


(持续更新中) 

posted @ 2010-11-29 20:59  lzprgmr  阅读(7276)  评论(5编辑  收藏  举报

黄将军