谈谈我们的Scrum
为什么Scrum
对于我们team来讲，这其实是个被动的过程。
我们部门之前在一些team实行过Scrum，可能是感觉效果还不错，而且觉得原来的瀑布模型太过古老和死板，于是决定今年年初开始全面实施Scrum。
由于大家都是新手，公司采用了两个方法：
- 一是超密集的培训。请专门机构来培训；请US的同事来培训；请实施过Scrum的同事来培训...
- 二是实战演练。组成几个临时的team，用两个礼拜的时间跑一个sprint，使大家对Scrum的理解从理论拓展到实际...，同时也有利于培养出第一批的Scrum Master...
当然，自我学习也是一个很重要的过程，在那段时间，也参阅了不少这个领域的好书：Scrum书籍豆列。
我们是怎么做的
配合Scrum的流程，我们使用了Wiki和Jira来管理项目。
Jira主要是管理整个项目的User Story和Task，以及相关的一些材料，讨论等。Wiki则用来管理整个项目的安排和每个Sprint的状况。
大概列一下我们跑的流程：
- 在项目初始阶段，先整个team在一起头脑风暴，想出所有可能的story，由于问题的不确定性，可能需要几个session。
- PO回去整理，细化每个story，并做好rank。
- Team做完所有story的point估算。 （为了获得team对story point，对velocity的感觉，最好先跑一、两个sprint。不然可以先估计，然后逐步调整）
- 根据team的velocity和总的story point，做出release plan。并设定出一些主要的milestone（一般三个sprint一个milestone），release plan需要随着product backlog的不断更新而更新。
- 我们的sprint长度是两周。感觉刚好，因为一周的话，减去所有会议时间，剩下的时间就不多了；三周以上的话感觉对整个sprint的掌控度不够，而且不易应对impediments。
- Plan meeting的agenda一般为：设定sprint的goal；计算team的availability；估算上个sprint中新创建的story的point；选择这个sprint的要做的story；Task breakdown & assignment。
- Review和Retrospective meeting一般放在一起，agenda为：对过去一个sprint的总体回顾，如planning时commit的story，遇到的impediments等；轮流demo自己所做的task；确定story的状态：complete，split或者defer；restrospective。
- Daily meeting中大家轮流讲一下自己的状态，人少的话还可以讨论一些具体的问题。
- Wiki中包含的信息：项目概况；team组成；项目文档；release planning；team calendar；product backlog；其中每个sprint会有一个页面：sprint goal与commit的point；该sprint的team availability；会议时间与地点；上个sprint的retrospective的结果；本sprint的notes；本sprint的impediments记录等等。
- Jira是PO的好朋友，是SM的好帮手。Jira用来管理所有的story与task，以及关于story与task的文档与讨论。具体的，我们可以用Epic来表示一些项目的大方向并链接相关story；用其他类型的item（如improvement）表示分隔栏，用来分隔must have，nice to have等，并且可以使用label来标记相关story。
- 对于不是很明确的story，一般分成两步走：一个investigation的story，一个实际工作的story。这样化整为零就能比较好的解决其估算问题了。虽然对于第一个investigation的story也不是很清晰，但根据经验，还是可以给一个比较靠谱的估计。
- 很多bug很难根据描述判断其effort，所以我们一般有个惯例，就是一个bug默认给3个小时，如果经过3个小时的研究后发现问题比较大，可以另外拎出来放到下个sprint去完成。
- 为了便于更好的估算，一般需要积累一些不同size的story作为baseline。
- story point不能太大，不然失去其准确性就没有什么意义了，如20,40等，一般情况下，8以上的story是不应该出现的sprint中的。
- 用excel表统计team availability，根据availability以及历史数据算出可commit的story point数。利用excel的计算功能可以自动化整个的计算过程。
哪里需要改进
- 每个story的COS(Criteria Of Satisfaction)需要明确定义，也就是需要有完整的acceptance test。
- Scrum是个比较流程性的东西，尤其是会议，所以在开会的时候，一定要注重实效，不要为了流程而流程从而浪费了无数时间。
我对Scrum的感受
- Daily meeting有两个很重要的作用：一个是表面上的，让大家了解team的状态；另一个是潜在的，催促大家努力工作以便在这个会议中能讲点什么~~~ 话说回来，虽然有效，我对每天早上要开会还是蛮反感的~~~
- 依赖于product backlog与team velocity的数据支持，使得team对自己能做什么比较清晰，加强了项目的可控性。
- 充分的交流，利于及时发现问题，利于得出最佳的方案
（持续更新中）
