我们的Scrum

自春节以来组里实施Scrum，但不幸的是由于产品质量不高（bug太多），我们只采用了Scrum的一些pratice来武装我们改bug的流程。

 

我们是一周一个sprint，每周五下午plan meeting. 在这之前，Scrum master 给列出一个wish list（其实就是一个bug的列表），然后team在plan meeting上估算所需时间，最后和Scrum master确定哪些bug会被fix. 定wish list这事儿本来是Product Owner做的，但Product Owner对Scrum这东西还没兴趣，加之又忙（Owner总是很忙的），所以Master只好暂时代劳。选完bug后，team就要细化这些bug，做进一步的估算。如果team觉得改某个bug需要的时间多于8小时，那么就需要把这个bug切分（如investigation、fixing+unit testing、audit+verification），确保每个小任务所需时间小于8小时。细化结束后，每个小任务都要写在便签贴然后贴在墙上。OK，plan meeting到此结束，然后周末回家好好休息，下周回来就要将那些任务便签贴一一铲除。在铲除过程中，每天早上都有一个standup meeting, 汇报昨天的进度与困难和今天的安排。到周四中午，所有的bug都应该改完并测试过。然后team build一个包含所有改动的新版本，下午进行final testing。第二天也就是周五上午将这个版本交给Scrum master，由他来折磨这个版本，检查那些bug是否被铲除并给出新的建议。他的所有建议会被重新加进product backlog。这个折磨过程一般是一小时。然后team在开一个Retrospective meeting。这个会主要是总结大会，自我表扬哪些方面做的好需要保持，自我批评哪些方面做的不好需要改进。然后选一些做的不好的方面，制定一些相应的改进计划，下个Sprint实施改进。  这些结束之后这个sprint也就算圆满落幕了。

 

我们在修改bug时也尝试一些Scrum的建议，如所有开发人员都是cross function，代码为team共有，不存在（或者说尽量避免）某一块代码只有某一个人熟知，改bug时所有涉及到design的修改时都要与team其他成员讨论决定。

 

这个过程其实还是蛮艰难的，Scrum本质就是要暴露一些开发过程中存在的问题，而暴露问题总会或多或少的让我们不快。Ken Schwaber说Scrum有三条腿transparency, inspection and adaptation。我觉得他就是要我们不要隐藏任何问题，要经常发现问题并解决问题。只有这样团队的效率才会越来越高。

 

一个好消息，我们从下个月开始要接着开发新功能，这意味着我们可以真正的在开发中试试Scrum了。