最小的“完成的定义”

Scrum中有一个“完成的定义”(Definition of Done),其实就是对于Sprint待办事项列表(Sprint Backlog)中的每一个承诺的用户故事,都要达到的质量标准。通常包括:

  • 代码签入到主线
  • 代码审查
  • 单元测试
  • 功能测试
  • 系统测试
  • 。。。

教科书上的Scrum要求,每个sprint都能上线,也就是对于每个用户故事都需要达到所有的内部质量标准(也就是完成的定义)。因为功能上下,客户才会去使用,然后就会有反馈,从而指导产品演进的下一步方向。从而实现健康的关于产品演进发展的反馈环。如果功能不能达到上线的质量要求,与客户之间的反馈环就断了。那很有可能团队制造出很多sprint的垃圾。

 

但是不是所有的团队都有足够的能力去把功能推上线。很多团队不能在sprint内做系统测试,很多由于软硬件依赖的原因甚至不能做功能测试,不能把相关功能的所有bug都解决掉。因此在上线前,需要经过很长的stabilization阶段,不能在Sprint中完成,而只能在发布前的Stabilization阶段完成的工作叫“未完成工作”(Undone Work),这其中也包括很多技术负债。“未完成工作”越多,债就越多,用来还债的stabilization阶段就越长。 而这直接后果就是拉长了客户之间的反馈环。在当前竞争激烈的市场中,这种缺陷可能是致命的。所以好的团队会花一部分精力去提高自身能力,“完成的定义”增强之后,从而减少“未完成工作”,

 

但是还有一个问题,既然“完成的定义”是不断发展、扩充的。那是否需要一个最小集合的“完成的定义”,而连这个最基本要求都没有达到的团队,连最起码的Scrum都不是呢?首先看一下Scrum,Scrum是一个基于反馈的框架,不断审视反馈中获得的数据,然后相应去调整。如果连反馈都没有的话,那就不是Scrum了。那软件开发中的反馈包括开发人员与测试人员、开发团队与产品负责人、团队与客户等等,那其中最小的反馈是什么呢?是开发人员和测试人员之间的反馈,从这个意义上说,最起码的“完成的定义”必须包括最基本的测试人员测试,哪怕是手动测试。如果连手动测试都没有的话,对团队正在做的功能来说,连最小的反馈都没有了。前一阵子网上看到一些公司的Scrum实际经验,其中很多公司提出了“具有XXXX特色的Scrum”,就是把未完成的工作放到下个Sprint去测试,对于这些团队来说,哪怕他们也有每日Scrum站会、各种各样的Scrum会议,由于连最基本的“完成的定义”都没有达到,违反了Scrum的最基本原则。

 

总结:

Scrum团队应该有一个“完成的定义”,哪怕是一个很弱的“完成的定义”,但是再弱也不能弱到连一点儿测试都没有。团队能力提高的过程就是不断强化“完成的定义”的过程。

 

Share

0 comments

请输入正确的验证码