团队实现自组织的能力，是实施包括Scrum在内的所有敏捷流程的基础。实际上，在敏捷宣言中，自组织是一个关键性原则：“最好的架构、需求和设计来自自组织团队”。

作为决定如何更好的实现目标的一部分，一些团队会把所有关键的技术决策交给了一个人。其他团队则会按照技术类别来分配由谁来对技术决策负责：数据库专家负责数据库决策，最有经验的Python程序员负责Python有关的决策。还有些团队是不管谁做决定，所有决策结果都是整个团队来承担。

团队达到自组织的路径是不一样的

这有两个关键指标：

1、 不是每个团队都会选择同样的方式管理自己。

2、 比起仅仅依靠某个经理的决策，利用团队的集体智慧通常会更容易找到适合团队的工作方式。

允许团队自组织的好处不是说团队能找到可能会被经理遗漏的最佳组织方式，而是通过允许团队自组织，从而鼓励团队自己承担工作。

真的可以期待团队实现自组织吗？

对自组织团队的一个常见批评是：“我们并不能把随机把8个人放在一起，告诉他们要自组织，然后期待任何好的结果。”

我不知道我们是否可以把8个人随机地放在一起并期待某些事情。但是敏捷团队不应该是一群人的随机集合。事实上，公司里负责引入Scrum项目的那些人，组建团队的时候在人员选择方面应该是花了相当大的精力的。

对自组织团队的精妙控制

在最初描述Scrum的文章中，Takeuchi和Nonaka将“精妙控制”作为六项原则之一。他们将人员配置列为关键的管理职责。

“

为项目团队选择合适的人员，监控团队动态变化，在必要的时候增减人数（这是关键的管理职责）。本田的一位高管表示：“如果团队倾向激进，我们就会增加一名更加年长、保守的成员。项目成员都是经过深思熟虑的，我们会分析不同人的性格，看是否能相处融洽。”

找到适合敏捷团队的人

如果你是一名人事主管，或者是能对团队成员构成产生影响的，还有一些因素需要考虑。

敏捷团队需要规则

作为一个跨职能团队，重要的是，从想法到实现功能需要的所有技能都能在团队中得到体现这可能意味着在最开始的时候团队规模比预期的要大。

但是，随着时间的推移，Scrum团队中的成员每个人都会学到其他同事所具备的一些技能。这在Scrum团队中各自然而然的结果。当一些人开发出更广泛的技能时，另外一些人就可以转移到其他团队去了。

敏捷团队的混合技术能力水平

根据团队的规模，应该努力平衡团队中的技能水平。如果一个团队有3个高级程序员而没有经验较少的，那么这些高级程序员就需要编写一些低临界点特性，他们可能会觉得无聊。一个初级程序员不仅可以发现这样的功能令人愉快, 也将通过与资深程序员的交流而获益。

平衡敏捷团队的知识领域

我们应该在那些对我们所工作的领域或我们试图解决的问题有深入了解的人之间寻求平衡。

这并不是说有机会组建一个全领域专家组成的团队而不去做，更多是我们应该考虑我们的组织的长期目标。其中一个目标可能是在整个组织中建立领域知识。 如果将所有领域专家放在一个团队中，您将很难实现这一点。

探索敏捷团队的多样性

多样性意味着很多不同的东西——性别、种族和文化等。同样重要的是个人如何思考问题，如何做决定，做决定之前需要多少信息等等。

研究表明，同质团队比其他多样性团队能更快地达成一致，但这是因为他们没能考虑所有选选择。

组建敏捷团队的时候要考虑持久性

团队成员学习如何更好地一起工作是要花时间的。因此，努力让过去能一起合作的成员继续在一起。在组建新的团队分配任务时，要考虑到他们能在一起工作多久。

对自组织团队常见的反对意见

专制的人会做所有的决定

一个常见反对意见是：喜欢支配的人，比如一个技术主管，会认为自组织就意味着由他/她来做所有决定。或者在团队讨论问题前就将自己的意志强加给团队。

如果你注意到开始发生这样的事情，就要找他沟通，让他了解：即使他可能知道“正确”的情况，也应该在别人有机会发表自看法前克制自己发表意见。并问他，如果将自己的想法当做一个观点而不是无可辩驳的决定，团队还能否做出正确的决定。他的工作不应该只是做出正确的决定，还要帮助团队成员成长，使得他们能在下一个他可能不再的项目上做出正确决策。

我的团队希望Scrum master能发挥领导作用

第二个常见的反对意见是团队太过被动，无法进行自组织，并且希望Scrum master或者教练来领导他们并为他们做一些重要的决定。

如果发生这样的情况，要确保团队成员知道Scrum master的职责是支持，而不是帮他们做决定。如果你既是Scrum master又是团队成员，你不需要压抑自己的意见，也不必一直保持沉默。你应该想办法让其他人参与进来而不是做决定。例如，在说出意见前，先试着问问其他人问题。

团队太初级，无法进行自组织

我从来没遇到过太初级而不能自组织等团队。如果团队成员有足够的经验构建一个软件产品，他们就可能有足够的经验来弄清楚如何管理自己。如果没有，那就为他们提供培训指导。

通常，这个反对意见是为了掩盖“我不相信团队能按照我的想法进行自组织”这样的想法。正确的做法应该是巧妙的控制组建的团队成员和既定目标，而不是控制他们如何组织日常工作。

本文翻译转载自Mike Cohn博客《Self-Organizing Teams Are Not Put Together Randomly》，原文地址https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly