观看完本文后，你将能够识别组织结构如何影响DevOps，解释康威定律，并描述DevOps团队的最佳组织形式。

让我们来看看你的组织结构是如何影响你采用DevOps的能力的。

要成为一个采用DevOps的组织，首先要做到敏捷，因为敏捷是DevOps的基本准则。

你必须问问自己：“我的组织文化是否真正接受了敏捷思维？” 要记住，敏捷团队必须规模小，这一点很重要。

如果你有大型团队，又想成功实施DevOps，就需要缩小团队规模。

敏捷团队应该专注。

你不能让团队成员同时参与多个项目，还期望所有项目都能以相同的速度推进，或者指望团队成员长时间专注于任何一个项目。

敏捷团队应该是跨职能的。

我们所说的 “开发团队” 包括所有负责产品开发的人员。

这意味着软件工程师、测试工程师、运维工程师、业务分析师，无论需要什么角色。

这些人需要在同一个团队中，而不是各自为政，通过票务系统来引起彼此的注意。

这些团队需要自我组织。

他们一次只专注于一个冲刺阶段的工作。

让我们从康威定律开始，看看组织架构为什么如此重要。

早在1968年，梅尔文·康威就指出：“任何设计系统（广义定义）的组织，其产生的设计结构都会是该组织沟通结构的复制。”

例如，如果你让四个团队构建一个编译器，你会得到一个四遍扫描的编译器。

你得到一个四遍扫描的编译器并不奇怪，因为你让四个团队来构建它。

如果你有一个用户界面团队、一个应用程序团队和一个数据库团队，你会得到一个三层架构。

你得到一个三层架构并不奇怪，因为你让三个团队来构建它。

这就是康威定律在起作用。

如果你想改变构建软件的方式，采用微服务应用架构，就需要围绕你期望构建的架构来重新组织人员。

在一个围绕技术组织的传统机构中，你可能会有一个独立的用户界面团队，负责所有用户界面相关的工作。

无论你在构建什么功能，都需要引起这个团队中某人的注意，并占用他们的时间，来为你的功能添加一个用户界面元素。

这个团队有时也被称为前端团队。

然后是应用程序团队，或后端团队，他们添加应用程序逻辑。

他们不处理前端或数据库模式之类的事情，因为有数据库管理员团队来管理这些。

除非提交工单让数据库管理员（DBA）来处理，否则没人会碰数据库。

当你这样组织时，就会得到一个三层架构。

就像我说的，你得到一个三层架构并不奇怪，因为你让三个团队来构建它。

康威定律告诉我们，一个组织产生的设计结构会反映该组织的沟通结构。

这并不奇怪。

我们得到的就是我们组织架构所造就的。

这就是为什么特别关注组织架构如此重要。

围绕业务领域来组织团队会更好。

你可能有一个账户团队，负责管理登录、注册和用户数据。

在这个跨职能团队中，他们具备用户界面、应用程序和数据库方面的技能。

然后是个性化团队。

他们使用人工智能（AI）创建个性化算法。

他们管理自己的用户界面、应用逻辑和数据库。

最后，你可能有一个仓储团队，负责构建与运输、收货和库存相关的功能。

这些是他们从头到尾管理的微服务。

仓储团队在开发功能时，不需要与其他任何团队协调。

他们不需要提交工单来引起其他团队的注意以完成自己的功能。

他们作为一个小型、专注、跨职能、自我组织的团队开展工作。

如果你不围绕业务领域组织团队，就无法充分获得DevOps带来的好处。

你要让团队与业务保持一致。

每个团队都应该有与业务领域一致的使命。

确保他们拥有所需的自主权，让他们感觉像是一个 “小型初创公司”。

他们需要自我组织、跨职能，由5 - 7名工程师组成，但最多不超过10人。

然后，你要赋予团队对其产出的端到端的责任，以此来赋能团队。

他们负责提交、构建、部署、维护和运营自己的服务。

他们掌控一切。

而且你要让他们承担通常围绕单一业务领域的长期使命。

在打造高绩效团队时，这一点的重要性再怎么强调都不为过。

如果团队人员不断变动，你就永远无法获得拥有专注于长期使命的团队所带来的好处，这种团队能够培养对工作的主人翁意识和自豪感。

在本文中，你了解到组织必须拥有小型、专注、跨职能、自我组织的团队，才能成功实施DevOps。

康威定律意味着公司的设计成果是公司沟通结构的直接反映。

成功的DevOps团队应该围绕业务领域进行组织。

每个团队都应该有与业务领域一致的使命。