沟通挑战

　　一些敏捷过程提供了便于团队交流的方法。例如，Scrum有Scrum会议，来自多个团队的代表每天交流。如果工作的测试团队或其他部门与编码团队分离，那么需要找到保持不断交流的方式。例如，如果数据库团队是完全分离的，那么需要寻找一种与数据库专家密切合作的方式来及时获得需要的信息。大公司容易存在的另一个问题是客户可能不像小公司那样容易接近。这是当你试图获取需求和实例并牡蛎在开发周期中让客户参与的巨大障碍。一个解决方案是让测试人员或分析人员及领域专家作为客户代理。交流工具也可以帮助处理这种情况。需要寻找创造性的方式来克服大公司固有的这些问题。

　　组织内的文化冲突

　　在大的软件开发公司，敏捷开发通常先在一个或几个团队中使用。如果敏捷团队需要与使用其他方式例如阶段开发的团队合作，那么会有更多的挑战。如果有些外部团队运转不良，那么情况将会更加困难。即使整个公司采用敏捷，有些团队的转变也会比其他的更成功。

　　团队可能也会收到专家团队的抵制，他们会觉得需要保护自己特定的利益。Lisa曾遇到过一个团队的成员不能从公司的配置管理团队中获取任何帮助，这是一个巨大的障碍。一些开发团队遇到的障碍是不能直接与客户团队交流。

　　如果有第三方和团队一起开发系统，彼此的文化也可能引起冲突。可能你的团队是第三方，正为客户开发软件。你需要思考如何减轻文化差异。

　　提前计划

　　如果与其他团队合作，可能需要在版本规划时或迭代开始前与他们一起协商。需要时间使自己的过程适应与其他团队的过程协同工作，他们可能需要改变自己的过程来满足你的需求。考虑安排某些资源共享，例如性能测试人员或压力测试环境，并依据其他团队的进度计划你的工作。你的利益相关者可能需要一些自己的敏捷过程无法提供的资料，例如正式的测试计划。额外的计划可以帮助你克服这些文化差异。

　　先行动后道歉

　　我们不愿意提出可能会引起麻烦的建议，但通常在大的组织中，官僚政治的节奏太慢，团队可能需要找到并执行自己的解决方案。例如，不能从配置管理团队得到协作的团队可以简单地使用他们自己内部的构建过程，并不断地改进使之整合到官方认可的过程中。

　　当没有官方途径得到你所需的东西时，想办法创新。测试人员可能以前没有直接与客户交谈过。自己尝试安排一个会议或者找到可以扮演客户代理或者中间人的人。

　　授权团队

　　在敏捷项目中，让每个开发团队感觉到有做决定的权力是很重要的。如果你是经理，并且希望敏捷团队成功，让他们自由地行动并积极地响应。为了敏捷项目的成功，公司文化必须适应这种变化。

　　建议

　　在做出任何变化之前考虑组织文化。

　　当整个组织重视质量的时候，测试人员可以容易地融入敏捷团队，但是具有“质量警察”思想的测试人员存在困难。

　　有些测试人员可能会在适应“整体团队”对质量负责的时候有困难，但是团队方式可以帮助克服文化差异。