敏捷团队
考虑到敏捷团队的组织结构，让我们以笔者亲身经历的项目为例来说明。笔者曾共事的整支产品开发团队被划分成 4 个相对独立的敏捷开发队伍，而每支队伍拥有相同配置的 7 名成员，他们分别具有不同的职能属性。如图 1 所示，每支敏捷队伍组成成员角色包括 1 名 UCD（User Centered Designer），主要负责产品的主要设计，其工作主要包括界面设计、用户的用例设计等等； 1 名 Visual Designer，主要负责产品界面的色彩搭配、控件的外观设计和 UCD 界面设计方案的初步实现和美化；1 名 Information Developer，主要负责产品中信息的编辑和重要文档的撰写工作； 3 名开发人员，主要负责产品的实现。和 1 名 QA，主要负责产品质量的保障。（更多的我们将 QA 定义为具有相比于测试人员拥有更多责任的一个职能，在本文中，为了简便起见，我们仍称之测试人员）。4 支敏捷的队伍拥有相同的 SCRUM MASTER STAKEHOLDER。通常会在同一时间进入一个迭代周期，制定各自的敏捷计划，并在同一时间退出，发布各自功能实现。而 4 支队伍的劳动果实被集成到一起就形成了可发布的产品了。
因为敏捷团队中只有 1 名测试人员，因此需要一臂承担测试策略的制定，测试计划，测试脚本，测试用例设计以及测试的执行，帮助团队发现潜在问题，并协助解决问题的工作。敏捷团队的敏捷原则也是测试人员敏捷活动的规范，测试也需要拥有和团队的良好沟通，高度迭代的活动和不断的获得 STAKEHOLDER 的反馈。那团队的结构与敏捷本身有什么直接关系呢？与敏捷测试又有多少关联呢？
谈到这里，想起曾经有朋友向我咨询有关敏捷团队的某些职能的人力配备的问题。其实，笔者也无意论证 7 个人为什么是最佳组合，为什么不是 17 个，20 个人的组合。但是，敏捷原则告诉我们敏捷团队是高度协同、民主和平等的团队，为了让团队中每个人充分高效的工作。相同职能下的组员至多不好超过 3 名，最佳配置也是不同职能下配置 1 个人头。因此、在这样一个小型、平行的组织结构里，沟通更加易于建立，沟通复杂度也相对较低，相比 17、20 人的团队组织，沟通的代价也小很多。相反，很难想象在一个敏捷团队中会拥有诸多不同风格的执行者，决策者将是个怎样的混乱情况。
此外，经历过敏捷测试的体验，我们发现一个单一的敏捷团队最好保持较小的“尺寸”。这是因为拥有很多测试人员的敏捷团队通常不但需要更大的实际工作量来匹配庞大的机体而导致团队任务量更巨大，更复杂，失去自我管理的信心，而每个测试人员也将要花费大量精力和时间投入到内部沟通，和可能因为内部缺乏一致而导致的更加频繁的反复沟通中。
每名敏捷的测试人员需要和其他敏捷团队成员保持频繁而必要的沟通以保证对目标，需求、设计的充分正确的理解，对需求变化能够迅速的做出反应。另外，还需要与职能队伍中的其他测试成员保持一致性。如此一来，沟通代价激增了，它将占到测试人员的工作中的较大比例。而这种内部沟通、协调，却不能定义为敏捷的 Backlog 项目来计入团队整体的工作输出。因此，整体的测试效率并不一定随着人力资源的投入而递增。非但没有实现敏捷原则，而恐怕因为团队的组织结构变得更加庞杂。所谓的“自我管理、自我发展”的团队只能因而依靠传统的管理和规划了。笔者认为，除了因为特殊阶段，特殊时期，敏捷团队需要“聚合”更多资源来一并解决存在的高优先级的体力型问题外，敏捷的团队应该尽量保持着较小的“尺寸”。
果真项目投入了很多的人力资源，无论设计还是实现、测试团队拥有较大的人数，那么我们应该考虑将这样的团队可以分得更小些，工作量也相应分得更精细些，直至接近我们建议的最佳组合。至少我们认为要做好敏捷测试，就要确保敏捷团队中的每一个职能拥有足够清晰的职责范围和一定程度下自由空间和在这个空间内的充分授权。因此，但从人数和职能构成上，敏捷团队的构成一定是不可忽略的重点。
正像我们前面提到的，确认软件开发过程的正确性也尤为重要，因此作为敏捷的测试人员，更要了解敏捷的过程，比如说，测试人员需要帮助 UCD 和开发人员确定需求的可行性，测试人员要督促开发人员及时发布 build，以保障迭代结果最终能够在通过足够的测试后成功发布等。在 build 发布后，测试人员要首先验证当前迭代的任务是否已经完成，其次才是验证产品功能的正确性。也为了能够在日后重复性和体力型劳动中解放出宝贵的时间去覆盖测试更加紧要的内容，如可用性，全球化等，测试人员需要自动化一部分测试，创新的、灵活的工作。
敏捷团队是自我管理的团队，高度协作的团队，质量目标即是测试团队也是整个开发团队追求的目标，因此开发团队应将做好单元测试，设计团队将帮助测试团队设计好测试用例作为计划内的一项工作。这里我们推广、建议开发人员采用、普及测试驱动开发模式。
