Define Definition of Done in SCRUM

SCRUM会有这样的情况,一个Team Member说,这个Story我完成了,然后接下来的时间是(测试)不断的发现Bug,不停的修改。PO对此进度也无法掌控。

那最终的完成是由谁来定义,如何定义?在SCRUM中似乎不大被提起。

Thanks Helen for discussion, always can learn much from you!

首先来看下一般项目中什么才算是完成,在传统项目中,客户交付就是完成,但敏捷是个迭代,每个迭代中的完成应该由谁来定,应该是PO和Stockholder,但这会产生一个问题,有些跟本次业务无关的东西会被忽略,比如技术架构,为了达到代码的易读和可扩充,实现上满足一定的模式,代码要符合规范。同时发动不会引发其它feature问题。

所以Done的定义是多方面的,一般来说User Story有以下几点:

  • 所有的用户故事都达到验收标准
  • 代码符合编码规范
  • 在实现功能之后进行完整的功能测试
  • 代码被review过
  • 新加代码要保证70%的测试覆盖率
  • 有为功能添加自动验收测试,并保证全部通过
  • 该功能所涉及的所有方面都要被集成测试覆盖并通过测试
  • 这一段是从SCRUM中的DoD定义中摘来的,可以看出,大多与自动化测试有关,可见在实施Agile中Automation的重要性。

对于Sprint来说,关注点会有所不同。

  • 所有的故事都已完成,并通过所有DoD定义
  • 代码已冻结
  • 所有的单元测试、验收测试都通过
  • 回归测试也完全通过
  • 所有的Bug都被Fix
  • 一个可以随时为Release而做的Tag(Git)/Shelveset(TFS)

所以,对一个开发人员来说,绝不仅是完成了代码上的实现,就宣称工作已完成,完整的单元测试,功能测试和回归测试之后,还要走上最后一公司,发布。这其中哪一个环节失败都是一种失败。

在实践中,特别推荐的就是验收标准,因为在讨论该标准时,会需要开发,测试,PO等多方角色参与,讨论过程中最大化的剖析功能点,更好、更全面的对产品进行定义,让测试覆盖更全的同时,开发也会更多了解需求和潜在问题,更好的把握开发进度和会遇到的难点,为接下来的开发过程节省大量沟通成本。

也就是说,在Sprint planning meeting时,Feature相关人要认真的思考,更多的提出细节,从而制定验收标准(验收标准是Feature在本Sprint中所必须实现的最小标准),最后在各方人员的共同确认下,确定Sprint/User Story的完成。

###参考:

http://alaverdyan.com/readme/2011/01/the-definition-of-done-dod/
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod
http://www.scrumalliance.org/articles/106-definition-of-done-a-reference