Lisa和Janet告诉你：敏捷团队的人员分布

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

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

          Janet分享了自己的故事：

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

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

         Janet举了一个例子：

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

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

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

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

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

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

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

        Lisa则分享了自己的故事：

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

       相反的，我现在的团队每三或五个程序员有两个测试人员。我们生产的基于web的财务应用有非常复杂的业务逻辑，有很高的风险，而且密集测试。测试任务通常与编码任务的时间一样多。即使是测试人员——开发人员高比例，程序员也会做一些功能测试自动化并部分承担手动测试任务。专门的测试任务，例如编写高层次的测试用例和详细描述面向客户的测试通常由测试人员完成。

       与其关注比例，团队更应该估计他们需要的测试技能并找到合适的资源。负责测试的团队可以持续地估计是否有需要的技能和数量。使用回顾总结来确定是否需要聘用更多的测试人员是一个解决方法。

       测试人员适合敏捷团队的工作需要一定的条件。我们不会过多讨论聘用什么类型的测试人员的细节，因为每个团队的需求是不同的。但是，我们相信态度是一个重要的因素。

        下面是Lisa的团队如何聘用一个新的敏捷测试人员的故事：

        我们招募另一名测试人员的第一次尝试并不是很成功。第一个工作招聘公告吸引了很多人，我们面试了三名应征者，但是没有找到合适的人选。程序员希望找到“技术人员”，但是我们也需要有同业务人员合作和帮助他们描述实例和需求的技能的人。为了吸引有正确的态度和思想的应聘者，我们努力明确工作招聘公告的内容。

       在听取Janet和敏捷测试社区的其他同事的想法和建议以后，Lisa改变了工作招聘公告，包含如下的条款：

        熟悉黑盒和GUI测试用例，设计测试减轻风险，帮助业务专家定义需求。

       熟练编写简单的SQL查询和插入/更新语句，掌握Oracle或其他关系型数据库的基础知识。

       至少使用某种脚本语言或编程语言和/或开源测试工具超过一年。

       使用基本Unix命令的能力。

       擅长与程序员和业务专家协作。

       最好有基于上下文环境的测试、探索性测试或场景测试的经验。

       融入自组织团队的能力，即与同事协调确定每天的任务，而不是等待分配的工作。
 

       Lisa表示：这些需求带来了更适合敏捷测试工作的应聘者。我通过小心的筛选，排除了有“质量警察”思想的人。追求职业发展和对敏捷开发显示出兴趣的测试人员更倾向于有正确的思想。团队需要对测试工具和自动化领域有较强能力的人，所以学习的热情是极为重要的。这种新颖的招募测试人员的方式是值得的。当时，找到好的“敏捷测试”候选者是不容易的，但是接下来进行得更顺利。我们发现把测试职位公告放到不那么明显的位置，例如Ruby的邮件列表或者本地敏捷用户组，可以帮助延伸到更广阔范围的合适的候选者。招聘敏捷测试人员教授了我许多关于敏捷测试思想。

      有良好技能的测试人员对于任何传统测试团队都是有价值的，但是因为他们对测试的态度，可能不适于敏捷团队。