今天是项目的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”