On demand（按需）

　　也被看做是“卓越中心”，这个模型的功能等价于将其外包给一个内部组织。这并不是一个过渡敏捷的模型，但是这个是大多数企业试图一开始集成其性能测试到敏捷开发周期中，因为性能测试已经是敏捷转换开始之前的“on demand”模型了。

　　对于“On demand”模型的性能测试，要和敏捷开发周期共同运作，有几处需要处理的不同于在非敏捷开发工作。尤其是：

　　定期利用“On demand”服务，不仅仅是为产品发布候选版构建。

　　性能目标、目的、宗旨或是预算必须成为每一个用户故事的标准部分。

　　开发者必须对测试单元层、组件层负责。

　　全职的团队成员必须管理性能相关工作，包括这些没有明确提到的部分。

　　“On demand”在性能非常重要的情况下可能并不充分，比如开发者没有进行性能测试并在他们的水平不断调试，或者当非全职团队成员负责协调、支撑以及管理性能相关的任务。

　　On retainer（聘用）

　　“On retainer”模型通常是企业所使用的一种“On demand”和“full immersion”之间的过渡模型。因为企业没有足够的性能测试人员、性能测试环境或者是性能测试工具来支持“full immersion”模型。

　　在这个模型中，每一个开发项目都分配给具体的性能测试人员，但是性能测试人员会被分配给两个或者更多的开发项目。尽管这个模型为每一个项目带来了更多的性能测试专业意见以及为每个性能测试人员带来了更多的项目级知识，但是性能测试人员缺乏与团队的完全整合。结果导致性能测试人员倾向于独立工作，但是提供了周期性地提供建议和指导。为了让这个模型运作并提供比“on-demand”更多的增加价值。

　　性能测试人员必须能被团队随时利用，这对于项目性能发展是十分重要的。

　　“on demand”模型的缺陷同样适用于“on retainer”模型。此外，“on retainer”模型通常要求更多的测试人员、环境和工具，但是对于“on retainer”模型大的原因在于不能提供增长的价值。

　　Full immersion（全部投入）

　　这是每一个敏捷企业项目团队的目标，至少如果性能对于产品价值或者是企业声誉来说很重要的话。在“Full immersion”模型中，全职软对成员要擅长交付和测试性能，并对整个开发周期的协调和管理性能相关活动负主要责任，甚至可能是整个产品生命周期。

　　注意我说的负主要责任，而不是负责。性能人是每一个人责任的一部分，性能专家将用其专业技能以及项目需求，主要专注于开发流程的其他方面。

　　企业实现“Full immersion”经常会受挫，因为没有足够拥有正确技能的人才，没有足够的测试环境，没有有效的工具来为每一个开发团队分配自己的资源。

　　总结

　　尽管性能测试的迭代性能使其内在的是敏捷的，但是对于将性能测试完全集成到现有敏捷团队中仍旧是个挑战。这三个性能测试模型在敏捷企业中提供了一些选择，这些企业团队中包含了性能测试资源，确保性能测试在整个开发声明周期中关注需求。