达到整体团队敏捷方法很难。这里讲述了一个教练如何采取不同寻常的方法来使她的团队成员相关讨论、寻求帮助，以及把所有问题看作是团队级别问题来处理。

整体团队敏捷并不是一夜之间就形成的。你可以选择出6或8个软件专业人士，把他们聚集到一个房间，把他们称之为一个团队。但却要付出很多努力，也会出现很多错误，这之后才能掌握整体团队敏捷方法。当团队达到这一目标时，它就可以作为一个独立的功能单元；团队成员共同致力于，或负责交付高质量的软件。出现任何问题，以及形成任何解决方案都归属于团队，并不是个人。

我最近刚刚回忆起掌握整体团队敏捷方法是多么不容易。通过网络我联系到一个前同事，联系了一个敏捷教练，她在现在工作的大型企业中领导了一个新组建的团队。现在，以六个月为一个标志，她的团队开始步入正轨。我问她，他们是如何做到的；她分享了一些我从未听过的想法。“我们集体摘蓝莓、做果沙，烤燕麦棒和做瑜伽，所有都是集体行为”，这个敏捷教练如此说。但这些都只是关于食物和锻炼的。

最大的分歧：编码人员还是测试人员？

首先，让我提供一些这一新的团队成立的背景。为了近一步投入到敏捷中，该软件开发组织重组成三个敏捷团队，每一个包含6或7个成员，有开发人员，也有测试人员。作为一个团队的教练，我的联系人理解面前的挑战：她是如何让7个软件专业人员适应在整体团队中分别作为单独的单元进行工作的？她是怎么让他们承担的那些并不在他们专业技能范围内的任务？

最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员，测试人员被期望能编写一点代码，同时开发人员可以做一些测试。各自的强项还是很重要：新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试，开发人员大都编写代码，但所有人都分享他们的工作，而且有能力承担他们面前的任务。

发现中立点

这个教练希望她的团队可以共同了解对方的优点和缺点，这样他们就可以做为一个整体来保证工作流程和职能。她很清楚，这并不会发生。几个月后，团队形成了，她发现有四个待办事项，而不是一个。显然，团队根本就没有做为一个团队在运行，只是作为团队中的个人在独立完成任务清单。

是时候要点击一下重置按钮，让团队决定作为一个团队需要做什么，如何最好地分配工作。第一步是让团队成员说说他们自己的技能集、优点和缺点。但却不希望他们根据以前角色（如，软件测试员或开发员）来定义自己。所以找到一个中立点，她列出了小型离线会议，和每周工作之外的小时集体活动所需的事项。这样，该团队去当地的农场采摘蓝莓。他们一起上瑜珈课。他们集体在厨房里烤燕麦棒，做果沙。

尽管团队成员共同致力于健康的饮食和锻炼，活动不仅仅限于敏捷教练告诉我的。“他们找到了共同点，发现彼此的优势和差异，做为中立点，”她说。回到办公室，办公室以外的活动使他们更轻松地谈他们的技能和专业领域；并且，在他们的感到舒适的范围内找到他们寻求帮助，当有任务时。

正确执行应用程序

团队找到了让自此感到舒服的新水平。整个项目的工作流程顺利进行，他们只做一个待办的事情，而不是四个。现在，他们已经做好准备迎接团队面临的大问题：在开发流程时期识别出有意义的应用执行需求。