美文网首页
谈谈我们的Scrum

谈谈我们的Scrum

作者: 贱小得 | 来源:发表于2016-09-19 15:04 被阅读0次

转自Baiyan Huang同学, 感觉对初学者还是很有帮助的。

为什么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(Product Owner)回去整理,细化每个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(Scrum Master)的好帮手。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. 充分的交流,利于及时发现问题,利于得出最佳的方案

相关文章

  • 谈谈我们的Scrum

    转自Baiyan Huang同学, 感觉对初学者还是很有帮助的。 为什么Scrum 对于我们team来讲,这其实是...

  • 我理解的敏捷开发实践

    流行的敏捷开发方法有SCRUM与XP,下面我谈谈对其中一些实践的个人理解。 1)scrum团队。scrum团队分为...

  • You are not your job

    受到光磊的系列文章——《Scrum:死马?》的启发,我也来谈谈Scrum中的元素之一——站会。 还记得经典Scru...

  • 敏捷漫画#54-Scrum指南

    Scrum指南(The Scrum Guide) 作者评论: 周三,最新版Scrum指南发布了。这是我们对它的致敬...

  • 丰盛日记20180409

    今天的丰盛日记,今天王琳提到了敏捷scrum的四会,这提示我了,我也是个敏捷教练呢,那让我们今天就来谈谈吧。 敏捷...

  • 敏捷其实很简单(3)--敏捷方法之scrum

    通过上图我们可以看到Scrum作为各种敏捷实践方法中最为常用的一种,今天我们也来聊一聊Scrum。 Scrum的历...

  • 敏捷漫画#63-我们需要的Scrum Master

    我们需要的Scrum Master(The Scrum Master We Need) 作者评论: 为什么许多公司...

  • 关于Daily Scrum的一切遐想

    Definition of Daily Scrum Daily Scrum是什么?某君也没有开过。 我们都开过例会...

  • 知行团队敏捷开发之每日站立会

    我们团队使用Scrum敏捷开发已有一年多的时间,日复一日的站立会从未间断过,今天我来谈谈对站立会的理解和认识。 站...

  • Scrum 3355

    Scrum的起源 接触过敏捷的我们,一定对Scrum都不陌生,Scrum是众多轻量级敏捷框架中应用最广泛的一种。 ...

网友评论

      本文标题:谈谈我们的Scrum

      本文链接:https://www.haomeiwen.com/subject/yohnettx.html