转载

【好书连载】请别小看组织的力量——你真的会搭建团队吗？

在这篇文章中，我们将探讨采用云原生应用程序架构时在组织团队方面所必要做出的改变。根据著名的Conway’s Law（康威定律），好的解决方案，其核心思想是创建团队，并使员工与产品相关的长期准则相结合，而不是将每个团队（比如：测试团队）中拥有单一准则的员工隔离开来。

—Melvyn Conway

”

业务能力团队

任何组织在搭建系统时都将产生自己的设计，该设计的结构是组织沟通结构的副本。 ——梅尔文•康威

我们在前面的连载中已探讨了将IT转移到特定silo的操作方法，很自然，当我们创建了这些silo之后，我们自然就将个体放入了与这些silo相对应的团队。当我们需要开发一个新软件时应该怎么做呢？

一个非常普遍的做法是创建项目团队，首先，为该项目团队指派一名项目经理，然后项目经理会与各种silo进行协作，为配备项目成员所需的每个特性获取“资源”。从康威定律中我们得知：这些团队将很自然地在其系统设计内生成自身的silo，由此，我们最终得到的将是silo架构，该架构包含已与silo本身对齐的模块。

● 数据访问层

● 服务层

● Web MVC层

● 消息传递层

上述每一层都跨越了多个可识别的业务能力，使得创新和独立部署单个业务相关的功能变得异常困难。

寻求向云原生架构（如：被业务功能隔离的微服务）转变的公司一般都采用Thoughtworks公司所称的 Inverse Conway Maneuver（反向康威操纵） 办法，它们先决定想要的架构，并重组组织以符合该架构，而不是把建立与其组织机构图相符的架构放在第一步。如果你这么做了，你想要的架构迟早会浮现。

因此，作为向DevOps文化转移的一部分，组织开发产品而非项目的跨功能业务团队十分重要。产品是长期的努力，它将一直持续，直至不再为业务提供价值为止。（当你的代码不再用于生产时，你的任务即告结束）建立、测试、交付和运营等能够传递业务能力的角色都在团队中，团队不会将代码交予组织的其它部分。

剩下的问题是，决定创建怎样的团队。若按照反向康威操纵理论，我们将从组织的领域模型开始，寻求可封装到局域的业务能力。一旦辨别出这些能力，我们将创建业务能力团队，使其在这些能力的生命周期内拥有这些能力。

平台运营团队

业务能力团队需要依赖于上篇文章说到的“自服务敏捷架构”。实际上，我们可以将一种新的特殊的业务能力定义为“开发、部署和运营业务能力的能力”，此业务能力 由平台运营团队所拥有。

平台运营团队使用自服务敏捷架构平台，团队里一般包括传统系统、网络和存储管理的角色。如果公司在经营场所操作云平台，则平台运营团队还将拥有数据中心本身的管理团队，或与这些团队密切协作的渠道，同时，他们需要理解提供基础设施平台所需要的硬件能力。

IT运营一般通过各种基于工单的系统与用户进行互动。由于平台运营团队运营的是自助服务平台，因此跟与用户间的交互有所不同。业务能力团队围绕定义好的API契约相互协作，平台运营团队则为平台提供API契约，这样，业务能力团队便可以采取更精简的方法建立自动化发布流程，以便按需地提供环境和服务，而不是列队请求提供应用程序环境和数据服务。

【好书连载】请别小看组织的力量——你真的会搭建团队吗？