敏捷开发团队管理系列：程序与测试团队
这是敏捷开发团队管理系列的第二篇。（之一，之二）
整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。
所以，下面多说一点各自的坏处。
独立的测试团队
这个是的与程序团队打架的测试团队。
好处
独立团队，还是能保证一定的“公正性”的，比如在测试的终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。
坏处
当测试团队完全独立于开发团队的时候，常常有几个误区。
1、程序团队是用来开发功能的，测试团队是用来查找缺陷的
有了这个认识，要让两者打架不难了。
2、更多的测试人员=更高的质量
很多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平（50：80），但是质量……一般缺陷率都能达到航天飞机的一万倍左右。
1和2是互相促进的，一旦拥有了1的认识，程序团队对质量不太在乎了，因为后面有人负责擦屁股，并为擦不干屁股而承担责任，所以自己只管按自己的兴趣编写代码是了；而留下的缺陷越来越多，自然需要更多的测试人员来解决。
分散的测试团队
好处
每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候启动测试活动；由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。
坏处
常常有这样几个误区。
1、人员不能共享，测试人员不足
基本出发点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的擦屁股者。
由于只能调用自己的测试人员，当然逐渐地几个人不够用了，也需要更多的测试人员。
2、缺少总体质量的把关者
由于所有测试人员都被当作小组的负责质量的人，产品终所有模块集成在一起的时候，质量由谁负责，成了个问题；集成后如何验证整体业务（而非技术），也是个问题。
F型测试团队
这是本人“次喜欢”的一种模型。
如果历史问题已经形成，或者说不可能拆分掉专业测试团队，可以考虑这个形状。
F的两个横线，代表分散的测试团队，是整体上测试团队的人员在项目成立时，分别被指派到程序团队中，协助在早期提升质量。
而竖线，则表明他们定期向测试经理报告各小组的的进展，分散到各小组的几个测试人员之间也可以频繁通气，以便做好集成准备；并在几个小组都完成了内部的工作时，很方便地接管集成和整体测试工作。
好处
是当团队使用敏捷开发的迭代交付的时候，这几个测试人员还是可以进行很好的持续支持的，比如完成一个版本，测试一个版本。
由于他们长期在项目组内工作，而且定期通气，所以接管系统测试会变得非常顺畅。
坏处
这个模型有些矩阵式的团队的确在用，不过需要很好的管理，确切说是文化，才能做好。
个人感觉在操作这种团队的时候，整个大项目的经理（同时管理开发和测试的），必须要有很强的管理能力，并随时防止程序团队和测试团队分化。
实际上在很多时候，领导的作用都不再是管事，而是管人，是如何管理好多个团队之间的关系。
小型测试团队
个人感觉容易驾驭的团队。
比如有20个人，4～5个程序团队外加1个测试团队。
每个程序团队都各自负责自己的质量（不派驻测试人员），而那个测试团队则只负责业务层面的测试或称为验证，不负责质量。
好处
这种团队基本上是前面那个案例1（参考I和II）中的团队模型，由于当年的团队非常成功，所以非常推荐。
这种团队的集成活动是由开发团队和测试团队一起完成的，两者都为此负有责任；但完成集成后，由测试团队自己做系统级的业务测试。
整体上，是一种很“无我”的敏捷团队。
坏处
这种团队只在上面提到的那个公司见过一次，之后的团队似乎都没有采取这个形式的，表明这种形式不容易自然形成。
不过，鉴于当年的效果如此之好，本人一定会在自己未来的团队中采用这个模型。
而实际上每个公司，与其在那些很容易组建但同时很难做好的团队模型中挣扎，不如去尝试一下真正效果好的团队模型。
很多人都很希望找到一种很容易做到，效果又好的模型（以及任何其他东西）。如果这种模型存在，人民都别炒房了，都来开软件公司吧。
