实际上，在敏捷宣言中，自组织是一个关键性原则——最好的架构、需求和设计来自自组织团队。

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

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

团队达到自组织的路径是不一样的，这有两个关键指标：

1. 不是每个团队都会选择同样的方式管理自己。
2. 比起仅仅依靠某个经理的决策，利用团队的集体智慧通常会更容易找到适合团队的工作方式。

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

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

对自组织团队的一个常见批评是：

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

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

对自组织团队的精妙控制

在最初描述Scrum的文章中，Takeuchi和Nonaka将“精妙控制”作为六项原则之一，他们将人员配置列为关键的管理职责。为项目团队选择合适的人员，监控团队动态变化，在必要的时候增减人数（这是关键的管理职责）。

本田的一位高管表示：

“如果团队倾向激进，我们就会增加一名更加年长、保守的成员。项目成员都是经过深思熟虑的，我们会分析不同人的性格，看是否能相处融洽。”

二、找到适合敏捷团队的人

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

敏捷团队需要规则

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

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

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

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

平衡敏捷团队的知识领域

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

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

探索敏捷团队的多样性

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

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

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

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

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

专制的人会做所有的决定

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

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

他的工作不应该只是做出正确的决定，还要帮助团队成员成长，使得他们能在下一个他可能不再的项目上做出正确决策。

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

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

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

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

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

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

<The end>

Mike Cohn博客：《Self-Organizing Teams Are Not Put Together Randomly》

原文地址：https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly

本文由 @敏捷行动派 翻译发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议