SCRUM节外生枝（五）

 

上接：SCRUM节外生枝（四）

 

5.       Bug！Bug！Bug！

 

理想中的SCRUM世界，不需要验收测试阶段，因为每个Sprint结束，都会交付一个可发布的版本。但是，现实中每个Sprint结束后都会不断涌现新的Bug。所以《硝烟中的Scrum和XP》说：“你大概没法取消验收测试阶段”。但正是这Sprints之外的验收测试阶段，把我们拖入了万劫不复的境地。产品原本计划1年Release，但1年半时我们仍在修复不断涌现的Bug。我们的目标是修复所有Priority 0和1的Bug，并使Bug修复率达到至少80%，才能宣布到达Beta 这个Milestone。但每轮Full Test发现的Bug总是与修复的Bug不相上下，Bug数始终没有呈现收敛的迹象。最终VP Engineering辞职，大家对于这种状态也是非常沮丧。

 

到了这种程度，再想回到一个良性循环的状态，谈和容易。这个教训告诉我们，如果验收测试无法避免，我们也要努力使其缩到最短。而要实现这一点，一要保证在每个Sprint中开发人员交付的代码质量，二要提高每个Sprint中测试工作的效率。只有这样，在每个Sprint结束后，Bug才会尽可能的少。

 

按照以前的做法，其实每个Sprint是个微观的顺序开发过程，开发人员先写代码，完成功能，快到Sprint的结束的时候，测试人员才开始测试，必然地，发现的Bug没时间修复。不是影响下一个Sprint，就是累积到最后的验收测试阶段。后来，我们把开发人员和测试人员按Backlog分组，每个Sprint，从第一天起，开发人员和测试人员都开始忙碌的工作，开发人员只要有新代码提交，测试人员就立即测试，有Bug马上反馈；没有新代码提交，测试人员也会准备测试环境、编写测试用例等。另外，增加单元测试覆盖率、建立自动化测试团队以开发自动化测试框架、增加Exhaust Test等手段从另一个方面提高代码质量。而且，将发布新版本的周期从一年左右，减为半年左右，每个版本增加较少的功能，但使交付更频繁。这样的变化，使情况有了较大改观。

 

所以要尽可能地让Bug消灭在每个Sprint中，不要等到最后验收测试阶段，那时Bug们会形成合力，你只有招架之功，无还手之力了。

 

结束语

 

本文只记述了几个我们在实践SCRUM中遇到的问题，像这样的问题还有很多，有些得以解决，有些则还没有。但是无论怎样，SCRUM所描绘的完美世界有着巨大的吸引力，激励着越来越多的实践者不断前行。