测试团队成功适应敏捷的障碍

原文:

http://www.wumii.com/topbar/Dt9jlJoG

 

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

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

丧失身份

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

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

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

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

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

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

其他角色

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

缺乏培训

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

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

不理解敏捷概念

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

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

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

过去的经验/观点

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

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

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

客户发现程序员做了其不喜欢的事情时提出抗议，因为程序员总是为所欲为。

当面临到敏捷开发的转变时，这样的人经常迅速离开，不给新的过程机会。敏捷开发不适合所有人，但是培训和实验的时间可以帮助改变这个态度。让每个人成为解 决方案的一部分，协同工作来发现对其特定情况最适用的过程和实践。自组织的团队是一个可以用来保证开发团队所有成员掌握他们自己的命运的强大工具。

角色间的文化差异

每个敏捷团队的新成员都在从不同的角度转变。程序员经常习惯于编写产品代码并使其尽可能快地发布。系统管理员和数据库专家可能习惯于在他们自己的领域工 作， 根据自己的进度执行需求。客户可能从来不与开发团队成员直接谈话。测试人员可能习惯于在项目的末期参与而且不与程序员有太多的交互。

毫无疑问，到敏捷的转变可能引起惊慌。团队可以通过规则和方针帮助他们交流和顺利地协同工作。例如，Lisa曾经加入一个新的敏捷团队，团队有一条规则是，如果有人要求和你结对，你必须同意。你可能一开始无法适应，一旦融入进来，你就需要帮助团队伙伴。

识别不同角色的人的需求，并想办法来提供帮助。客户需要途径来获得开发进度和了解他们的条件是否会被满足。开发人员需要知道业务优先级和需求。测试人员需 要途径来获取实例和将其转变为测试。所有的团队成员希望感觉到他们是有价值的，是优秀的团队成员。每一个团队成员也需要安全感和可以自由地提出问题，以及 尝试新观点。了解每个角色的观点可以帮助团队完成转变。

对于以上问题，测试团队应该如何面对呢?Lisa和Janet提供了以下建议：

讨论恐惧

当开始迭代开发时，使用回顾总结来提供讨论恐惧和获得反馈的机会。让人们知道感觉到恐惧是正常的。保持开放态度，告诉大家感到恐惧和不适应是可以接受的。 讨论每个恐惧的根源，从讨论中学习，作出决定并继续前进。恐惧是对变化的正常反应。强迫人们做他们不想做的事情必定会反对变化。