软件测试团队成功适应敏捷的障碍(2)

　　赋予团队权力

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

　　庆祝成功

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

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

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

　　敏捷开发可能更快速，但是变化可以是缓慢的。采用敏捷的新团队将会较慢地掌握承诺使用的一些实践。我们曾遇到很多沮丧的测试人员，他们的“敏捷”开发周期实际上是小型瀑布周期。这些测试人员仍然在受压榨，只是频率更多。迭代在用户故事可以被测试前结束。 程序员拒绝或者不能适应关键实践，例如测试驱动开发或者结对。团队把质量的责任交给了测试人员，但是测试人员没有权力改变过程。

　　没有魔法使你的团队做出有益的变化，但是我们为想让团队以有益的方式改变的测试人员提供了一些技巧。

　　耐心

　　新的技术，如测试驱动开发是很难的。找到让你的团队有时间去掌握他们的方法。在你等待的时候找到可以独立做出的改变。例如，当程序员学习编写单元测试时，以最小的帮助实现一个你可以使用的GUI测试工具。帮助团队成长。记住，当人们恐慌时，他们会变回旧的习惯，即使这些习惯没有作用。关注微小的有益增长。

　　让他们感觉到痛苦

　　有时不得不看到火车失事。如果改进的建议被回绝了，团队失败了，再次提出你的建议并请团队考虑试用几个迭代。人们最希望在他们感觉到最痛苦的领域改变。

　　建立你的诚信

　　你可能现在同以前没有与测试人员亲密工作的程序员一起工作。向他们展示你如何帮助团队。告诉他们你发现的问题而不是开出缺陷报告。请他们在提交代码前和你一起检查代码。当他们意识到你提供了真正的价值，他们将会更听从你的想法。

　　从事你自己专长的开发

　　阅读书籍和文章，参加用户组会议和讨论，学习新的工具和脚本语言。开始学习你的应用编码使用的语言，如果可以同程序员结对或者他们会辅导你，那么就请教他们。同事会注意到你渴望增长自己的技能。如果本地用户组希望听你对于敏捷测试的演讲，或者软件通讯发表了你的自动化文章，团队伙伴可能会注意到你有很多值得考虑的想法。

　　警惕质量警察思想

　　做一个合作者，而不是强制实施者。如果程序员不遵循编码标准可能会影响你，但是确保他们遵循编码标准不是你的工作。向团队提出你的问题并请求他们的帮助。如果他们忽略了一个至关重要的确实会伤害团队的问题，可能需要请求你的教练或经理的帮助。但是用“请帮我找个解决方案”的语气，而不是“让这些人这么做”的语气。如果你发现一个问题，其他人很可能也发现了。

　　用离开表示拒绝

　　你已经耐心了。你已经尝试了能想到的所有方法，但是管理层不理解敏捷开发。程序员已经导致很多缺陷和不可以测试的代码，并且代码被发布了，尽管你已经尽最大努力了，包括每天工作14个小时。没有人关心质量，感觉到努力被忽略。这可能是时候寻找一个更好的团队了。一些团队满足他们的方式，并不感觉到足够需要改变的痛苦。Lisa曾在一个越来越混乱的团队中工作，因为有很多机会来解决为什么服务器会宕机并成为英雄。尽管采用了敏捷实践而且项目成功了，但是他们又回到了旧习惯，Lisa最终放弃改变他们。

原文转自：http://www.ltesting.net