许多考虑采用敏捷的组织没有把团队迁移到开放式环境就尝试创建项目团队。敏捷价值和原则中，当团队成员可以随时接触到所有其他团队成员、易于获得所有的项目进度图表、在鼓励交流的环境中时，团队可以更好地工作。敏捷测试专家Lisa和Janet分享了敏捷测试团队的人力资源经验。

测试人员和客户与程序员坐在一起可以促进必要的交流。如果实际情况不允许重新迁移位置，那么团队可以创造性地解决这问题。

Janet分享了自己的故事：

我曾经在这样一个团队工作，空间问题使得所有团队成员不能坐在一起。程序员有一个可以使他们方便结对编程的区域，但是测试人员和客户坐在其他的区域。首先，是测试人员走到程序员坐的用户故事白板区域去参加每日站立会议，当他们有需要问程序员的问题时，也是这样。基本没有程序员走到测试人员的区域(大约50英尺的距离)。我开始准备一些招待他们的糖果，并鼓励开发人员在需要的时候拿一些。但是有一条规矩——如果他们来拿糖果，他们必须问其中一个测试人员一个问题。随着时间的过去，所有的团队成员都会相互走到另一个区域了。不是一边总走向另一边，交流也更频繁了。

团队规模给组织带来了不同类型的挑战。小团队意味着小的区域，所以通常更容易将成员的位置换到一起。大的团队可能分布在全球，这时需要虚拟交流工具。调动大团队的座位通常意味着整修目前的空间，很多组织不愿意这么做。明白你的限制，努力找到团队遇到的问题的解决方法，而不是仅仅接受现实并“保持现状”。Janet举了一个例子：

我工作过的一个团队一开始在楼层的一角，但是通过三年的扩张，逐渐的占据了楼层的75%。墙被拆掉了，去掉了办公室，创建了大的开放区域。团队在这种开放区域工作地很出色，但是所有的开放空间意味着墙没有了。窗子变成用户故事板和白板，白板按顺序卷起以便团队需要时使用。

坐在一起的团队并不总是存在于完美世界中，分布式团队有另外的一些挑战。分布式团队需要帮助团队交流和合作的技术。电话会议、视频会议、网络摄像机和即时消息是一些可以促进在不同位置的团队实时协作的工具。不管团队是在一个位置的还是分布式的，通常存在的一个同样的问题是，敏捷团队需要什么资源，如何获取它们。

新的敏捷团队成员和他们的经理对于团队的组成有很多疑问。可以使用在传统项目中同样的测试人员吗，或者是否需要聘用那个不同类型的测试人员？需要多少测试人员？是否需要具有其他专业技能的人？

关于测试人员和开发人员的“正确”比例的问题已经有很多讨论。组织使用这个比例来确定项目需要的测试人员的数量，可以根据这个数量来聘用测试人员。在传统项目中，没有“正确的”比例，每个项目需要自己估计。需要的测试人员的数量是不同的，依赖于应用的复杂性、测试人员的技能和使用的工具。

Lisa和Janet曾经工作在不同的测试人员——开发人员比例的团队，从1：20到1：1都有。以Janet来说：

我曾从事一个开发消息处理系统的项目，他们的比例是1：10。GUI很少，我手动测试应用的这一部分，查看可用性和是否符合客户的期望。程序员做所有的自动化回归测试，我同他们一起验证编写的测试用例的有效性。我把测试的用户故事，包括某些用户故事的负载测试，分配到开发人员。

我从来没觉得没有足够的时间做需要的测试，因为开发人员相信质量是整个团队的责任。

Lisa则分享了自己的故事：

我曾经是一个有20名程序员的团队的唯一一名专业测试人员，该团队开发在线商店网站的内容管理系统。当程序员负责手动测试和测试自动化时，团队才真正有工作效率。一个或两个程序员在每个迭代的中扮演测试人员，在编码前编写面向客户的测试并执行手动测试。其他的程序员在迭代中承担起测试自动化的任务。

21/212>