我们耳闻目睹过很多自诩为全功能团队的存在，但并不会相信他们的真实性。全功能团队，像是敏捷中一个最大的谎言。
以及并不会有那么多人介意，这里的全功能，其实并不是指角色的种类要在团队中达到完备，而是指技能集的齐整。在这种齐整的状态下，团队面临的棘手问题，无论是人员临时缺失，还是突然降临的技术屏障，因为彼此技能的覆盖和支持，团队在某种程度上，仍然能保持优雅的运行，而不会惊慌失措。
所以不难想象，在这样的全功能团队配置中，如果你看到一位资深开发者同样拥有用户视角的测试思维并能落到实处，另一位拥有客户视角的测试人员也可以随时无缝跨入业务需求分析的领域，就不足为奇了。他们的默契组合，往往是团队无往不利的法宝。
如此说来，再看看我们自己的团队，那些自诩戴上了全功能帽子的人，以及司空见惯的能力欠缺，全功能团队自然就变成不可即的企望了。但它不是永远不可达成的状态，只是需要团队的每个人付出更多的努力。
我想聊聊别的。
对于全功能团队的理解，我们也许可以走得更远一些。它应该也能够为我们展开一幅更完整而又令人遐想的图景。
齐整的技能和经验组合，彼此互相支持，及时补足。这在多数团队启动时是不现实的，正如塔克曼模型的组成阶段所描绘的那样。但一些纪律和实践方式，可以促使团队往正确的方向前进：信息共享透明化，代码共有，全员对质量负责，并持续展开学习的活动。这里区别于以往个别角色专职负责，而由全部人员对团队的整体表现共同担责。另外，以具体的证据赞美到个人身上，但因为个人的疏忽遭受的惩罚则由团队来承受。
这些显性的活动和方式，却会给团队成员带来巨大的心理暗示。他们会更容易处于一种安定的情绪中：可靠的团队，以及我需要更加努力，让团队因我而更好。这会让团队里的每一个人在面临刁钻的问题，都充满信心和对团队的信任感，并时刻迎接团队可能面临的总是于动态变化的业务、需求、人员和技术变迁，并对团队集体智慧的攻无不克充满油然而生的期待。
ThoughtWorks敏捷开发实践方面特别注意不会聚焦到个体，比如我们说到的Story估点和Velocity统计都是团队为单位，不会指定或统计到个人。
这是一个很容易被忽视的启示。
长此以往，团队体现出自治或者自组织的特质。在不脱离管理者在方向上的指导下，对于如何行动有充分的积极性和自主权，风险和责任共担。这样对于团队的创新能力又会是显著的释放。
