测试团队在从传统开发模式向敏捷模式转变的过程中存在各种障碍，敏捷测试专家Lisa和Janet从自身经验出发探讨了其中的原因和解决方法。

　　任何变化都面临成功路上的障碍。组织文化可能是要克服的最大障碍。组织文化一旦建立就很难改变。组织文化的形成需要时间，一旦就绪，员工会忠于该文化，这使得对改变相当的抵制。

　　丧失身份

　　由于很多原因，测试人员坚持独立的质量保证团队，但是主要原因是害怕，特别是：

　　害怕丧失质量保证人员的身份

　　害怕如果向开发经理汇报，会丧失支持，程序员会获得优先权

　　害怕缺乏在敏捷团队中工作的技能从而丢失工作

　　害怕当分散于开发团队时，得不到需要的支持

　　害怕他们和经理在新的组织中迷失

　　其他角色

　　按照我们的经验，新的团队往往缺少使项目成功的关键专家。Lisa的团队曾经遇到巨大的障碍，唯一能做的事情是停工和询问：“我们的团队缺少什么角色导致我们停止不前？我们需要什么？另外一个开发人员、另外一个测试人员，还是一个数据库设计人员？”我们知道测试是一个宽广的领域。也许需要一个对敏捷团队的测试有经验的人员，或者可能需要一个性能测试专家。需要花时间去分析产品的成功需要什么角色，是否需要从团队外引入这些角色，这很重要，一定要做。产品团队中的每一个人都需要理解他们的角色并认识到他们是新的敏捷团队的一部分，这很重要。但是这需要时间和培训。

　　缺乏培训

　　我们曾在Agile 2007大会中一次会议上询问人们在敏捷团队中有什么测试相关的问题。其中一个与会者告诉我们，他们根据敏捷资料的建议分拆了测试组织。但是，他们没有经过任何培训就把这些测试人员编入开发团队。在三个月中，所有的测试人员由于没有理解他们的新角色而离职。这类问题可以通过正确的培训和指导来避免。

　　当开始在第一个敏捷团队中工作时，没有太多的资料能够帮助我们理解敏捷测试人员应该做什么以及我们应该怎么同团队一起工作。如今，你可以找到很多能够帮助培训测试人员适应敏捷环境及帮助测试团队进行敏捷转变的先行者。本地用户组、会议、研讨会、在线介绍和邮件列表都为想学习敏捷的测试人员和经理提供了有用的资料。当你需要帮助时，不要害怕寻求帮助。出色的培训会为你的投资带来良好的回报。

　　不理解敏捷概念

　　不是所有的敏捷团队都是相同的。敏捷开发有许多不同的方式，例如极限编程、Scrum、Crystal、特征驱动开发、领域定义模型、Open UP。我们认为一些自称为“敏捷”的团队其实不是使用敏捷。许多团队只是简单采用对他们有用的实践，并不管来自于哪里还是自己的发明。这是允许的，但是如果他们不遵循任何核心敏捷价值和原则，我们会怀疑他们的敏捷身份。按月发布和丢弃文档并不等同于敏捷开发！

　　如果不同的团队成员对“敏捷” 的构成有相反的想法，例如，使用什么实践或者这些实践应该是怎么样的，那么将会有麻烦。例如，如果你是推动团队使用连续迭代的测试人员，但是程序员拒绝使用，那么你就处于麻烦的境地。如果你是不能参与一些实践的程序员，例如通过面向业务的测试来推动开发，那么，也会引起冲突。

　　团队必须就如何实现向敏捷的成功转变而达成一致意见。很多敏捷开发实践是相互协作的，因此如果单独使用这些实践，可能得不到团队希望的效果。团队也许可以同意在一定的迭代中试验某些实践并评价其效果。可以寻找外部的帮助来协助他们理解这些实践并如何将它们协作。多样化的观点对团队是有益的，但是每个人都需要朝同一个方向努力。

　　过去的经验/观点

　　很多人经历过改变，但没有延续下来。一些开发组织已经有过一连串的“方法”。他们质疑：“我们为什么还要再次做这个？”人们坚持陈旧、失败的模式。即使当他们试验新的方法时，也可能在压力下重复坏的老习惯。下面是一些例子，列举了人们由于过去的经历和对事物的误解而抵制变化：

　　测试人员坐在座位上不与程序员讨论存在的问题。抱怨程序员不能理解他想要什么。

　　测试人员无法改变看法：开发人员不知道如何写出好代码或如何测试。他完全没有谦逊的态度，作为测试人员的威信也受到质疑。