敏捷开发团队管理系列之四:程序与测试团队III

这是敏捷开发团队管理系列的第四篇。(之一之二之三之四

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

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

独立的测试团队

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

好处

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

坏处

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

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

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

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

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

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

分散的测试团队

好处

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

坏处

常常有这样几个误区。

1. 人员不能共享,测试人员不足

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

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

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

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

F型测试团队

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

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

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

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

好处

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

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

坏处

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

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

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

小型测试团队

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

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

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

好处

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

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

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

坏处

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

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

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

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

posted @ 2011-12-29 23:15  Java EE  阅读(142)  评论(0编辑  收藏  举报