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

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

　　角色间的文化差异

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

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

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

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

　　讨论恐惧

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

　　赋予团队权力

　　一个关键的成功因素是团队是否有权决定自己的方式。如果得到正确的帮助，人们将会改变他们的观点和感觉。Lisa曾经观察Mike Cohn在团队中作为教练的情况。作为一个自组织的团队，团队需要确定并解决他们自己的问题。Mike确保他们有时间和资源来实验和改进。他确保业务人员理解质量比数量和速度更重要。每个团队，即使是自组织的团队都需要一个可以有效的与组织的管理层沟通的领导。

　　庆祝成功

　　变化需要时间并且会遇到挫折，所以，一定要庆祝你的团队获得的所有成功。当达到在迭代的第四天为所有用户故事写出高层次的测试用例这个目标时，你应该庆幸。 当成功完成一个迭代，让团队一起做小游戏或者吃午饭。认可成果对于变化的巩固很重要。

　　在让测试人员继续向质量保证经理汇报的同时，融入开发团队是帮助转变到敏捷开发的好办法。测试人员可以发现从对程序员的敌对关系转变到协作关系的方式。可以展示他们如何帮助团队理解客户需求并交付满意的业 务价值。可以举办令人愉快的活动来建立良好的团队交互。给团队成员准备饼干和巧克力是让他们走近你的一种好的方式。耐心和幽默是巨大的优势。

　　但是，Lisa和Janet也提醒测试团队——改变并不容易。