Scrum实施日记 - QA很累

今天是项目的Review的日子,几个Manager和老板坐在一起,看一下项目及团队的情况。起初一切都还平常,但后来在讨论到目前项目的Process的时候,一个关于DEV和QA协作的问题被提了出来,说是在其余的Scrum Team中,大家都有一个共同的抱怨,就是QA在每个Sprint中只有最后几天很少的时间去做测试的工作,而这点时间往往是不够的,因此QA只能加班加点,所以感觉非常的累。

在讨论的过程中,有人提出了一个新的流程,就是将现在的Sprint划分为两个,一个是DEV的Sprint,另一个是QA的Sprint,QA滞后后DEV一个Sprint,这样DEV的Sprint中完成的代码就交给QA的Sprint去测试,而QA的Sprint中找到的代码缺陷,将在DEV的下一个Sprint中来修复。

关于这样的Sprint的安排,从我个人的角度上来看,是不符合Agile的基本原则的,那就是每个Sprint的产出是“Potential Shippable”的软件,是经过完整的测试验证的,这样一个Sprint才可说是“DONE”。另外这样的安排,就是很多的专家提醒要避免的一种迭代方式,就是“瀑布式的Sprint”。

另外,就这个大家都抱怨的问题本身,我觉得根本的原因并不是因为QA的工作总是要比DEV的工作开始的晚,而是因为在制定Sprint的计划时,整个团队对于团队在一个Sprint中可以完成(DONE)多少的工作还没有一个清楚的认识,有的时候这是因为团队还不清楚自己的能力,另一方面,可能是团队在计划时没有充分考虑完成一个用户故事(DONE)需要完成的所有任务。所以在作出承诺时,会过头,导致承诺了太多的故事,也许从完成代码的角度是可以的,但如果要DONE,就会有困难了。因此,解决这个问题,关键是指导团队逐步提高计划的能力,这样才能根本的解决这个问题。

另外,从DEV和QA的协同工作来看,我觉得TDD的方式能够帮助团队更好的协调开发和测试的工作,当开始一个Sprint的时候,整个团队一起设计测试用例的时候,不仅能让大家一起分担更多的测试工作,而且可以更好的理解需求,从而更好地保证开发的质量。

Scrum不是魔法,它需要时间去不断的学习和实践,有时这是一个很长的过程,有时也会很痛苦,关键是坚持,不断的“Inspect & Adapt”

posted @ 2008-10-15 23:27  Li Dingshan  阅读(...)  评论(... 编辑 收藏