这是敏捷开发团队管理系列的第二篇。（之一，之二）

　　整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。

　　所以，下面多说一点各自的坏处。

　　独立的测试团队

　　这个是的与程序团队打架的测试团队。

　　好处

　　独立团队，还是能保证一定的“公正性”的，比如在测试的终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。

　　坏处

　　当测试团队完全独立于开发团队的时候，常常有几个误区。

　　1、程序团队是用来开发功能的，测试团队是用来查找缺陷的

　　有了这个认识，要让两者打架不难了。

　　2、更多的测试人员=更高的质量

　　很多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平（50：80），但是质量……一般缺陷率都能达到航天飞机的一万倍左右。

　　1和2是互相促进的，一旦拥有了1的认识，程序团队对质量不太在乎了，因为后面有人负责擦屁股，并为擦不干屁股而承担责任，所以自己只管按自己的兴趣编写代码是了；而留下的缺陷越来越多，自然需要更多的测试人员来解决。

　　分散的测试团队

　　好处

　　每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候启动测试活动；由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。

　　坏处

　　常常有这样几个误区。

　　1、人员不能共享，测试人员不足

　　基本出发点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的擦屁股者。

　　由于只能调用自己的测试人员，当然逐渐地几个人不够用了，也需要更多的测试人员。

　　2、缺少总体质量的把关者

　　由于所有测试人员都被当作小组的负责质量的人，产品终所有模块集成在一起的时候，质量由谁负责，成了个问题；集成后如何验证整体业务（而非技术），也是个问题。

　　F型测试团队

　　这是本人“次喜欢”的一种模型。

　　如果历史问题已经形成，或者说不可能拆分掉专业测试团队，可以考虑这个形状。

　　F的两个横线，代表分散的测试团队，是整体上测试团队的人员在项目成立时，分别被指派到程序团队中，协助在早期提升质量。

　　而竖线，则表明他们定期向测试经理报告各小组的的进展，分散到各小组的几个测试人员之间也可以频繁通气，以便做好集成准备；并在几个小组都完成了内部的工作时，很方便地接管集成和整体测试工作。

　　好处

　　是当团队使用敏捷开发的迭代交付的时候，这几个测试人员还是可以进行很好的持续支持的，比如完成一个版本，测试一个版本。

　　由于他们长期在项目组内工作，而且定期通气，所以接管系统测试会变得非常顺畅。

　　坏处

　　这个模型有些矩阵式的团队的确在用，不过需要很好的管理，确切说是文化，才能做好。

　　个人感觉在操作这种团队的时候，整个大项目的经理（同时管理开发和测试的），必须要有很强的管理能力，并随时防止程序团队和测试团队分化。

　　实际上在很多时候，领导的作用都不再是管事，而是管人，是如何管理好多个团队之间的关系。

　　小型测试团队

　　个人感觉容易驾驭的团队。

　　比如有20个人，4～5个程序团队外加1个测试团队。

　　每个程序团队都各自负责自己的质量（不派驻测试人员），而那个测试团队则只负责业务层面的测试或称为验证，不负责质量。

　　好处

　　这种团队基本上是前面那个案例1（参考I和II）中的团队模型，由于当年的团队非常成功，所以非常推荐。

　　这种团队的集成活动是由开发团队和测试团队一起完成的，两者都为此负有责任；但完成集成后，由测试团队自己做系统级的业务测试。

　　整体上，是一种很“无我”的敏捷团队。

　　坏处

　　这种团队只在上面提到的那个公司见过一次，之后的团队似乎都没有采取这个形式的，表明这种形式不容易自然形成。

　　不过，鉴于当年的效果如此之好，本人一定会在自己未来的团队中采用这个模型。

　　而实际上每个公司，与其在那些很容易组建但同时很难做好的团队模型中挣扎，不如去尝试一下真正效果好的团队模型。

　　很多人都很希望找到一种很容易做到，效果又好的模型（以及任何其他东西）。如果这种模型存在，人民都别炒房了，都来开软件公司吧。