如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读，那就是Mathew Skelton 和 Manuel Pais 的《团队拓扑》。顾名思义，主题是关于组织业务和技术团队以实现快速流动。我想说这本书更多的是关于组织心理学而不是技术，所以我可以很容易地将它推荐给所有人，也可以推荐给与 IT 相关的企业，即使你的工作与技术没有直接关系。无论如何，现在大多数业务专家都掌握了一些 IT 知识，因此内容可能对您的工作有用。
这本书讨论了许多有趣的话题，包括以下
- 您的组织和沟通结构如何决定您的系统设计。例如康威定律。
- 团队至上的思维
- 四种基本的团队结构，以实现快速流动
- 团队互动与协作
康威定律
梅尔文康威是一位计算机科学家，他发现组织设计的系统描述了他们的沟通结构：
几年前，当我偶然发现这个并大声笑时，我正在使用管道！这很有趣，因为它是真实的。
告诉我你的开发和运维团队是如何一起工作的，我会告诉你你的CI/CD 管道是什么样的。
那是因为 CI/CD 是康威定律最纯粹的表达。您的 CI/CD 管道将以与您的工程组织被破坏和混乱的方式完全相同的方式被破坏和混乱。
团队至上的思维
在团队优先的思维中，团队拥有并为他们创造的价值负责。团队被认为是组织中的最小单位，而不是个人责任。团队不应该太大以保持沟通的有效性，但也不应该太小以避免过多的责任堆积在单个开发人员身上。应该优化团队以掌握处理职责所需的所有必要技能，同时保持工作负载管理的有效性和较小的认知负载。以两个披萨团队规模规则为例。
太多不同类型的代码库和不同的技术解决方案会产生太多的认知负担。在设计系统和设置代码库时，应考虑到代码库对于合理规模的团队保持可维护性。微服务被认为是团队优先的友好方法。
团队凝聚力和沟通非常重要，长期团队应该比短期团队更受欢迎。
我认为不幸的是，许多组织都忽略了团队组成。有人认为你可以把开发人员堆起来，他们一起处理解决方案。我的经验是，十人以上的团队工作效果不佳。由个人成员组成的子团队最终形成，认知负荷和技术债务累积。
基本的团队拓扑结构
跨功能的产品团队和自主权一直是敏捷中的一个重要事项。外部的依赖性是一直想要最小化甚至消除的东西。但产品开发并不总是那么简单，在某些情况下，我们的业务问题和系统太大、太复杂，单一的跨职能部门无法处理。有太多不同类型的代码库、技术、复杂的系统和共同的责任，给单个团队带来了很多负担。在许多团队之间分享责任有很多困难，在小范围内可以工作，但在大范围内变得困难，一些团队或个人可能会把虚拟团队的责任作为一种负担。
团队拓扑结构提出了四种基本类型的团队。
- 价值流对齐型团队，这基本上是跨职能的团队，在许多情况下提供客户价值，最好是快速。
- 扶持型团队--提供一些必要的支持性功能的团队，如法律、合规、设计或云治理。
- 复杂的子系统团队--这可能是你复杂的遗留系统团队、数据团队或任何其他你需要非常具体技术专长的团队
- 平台团队--无论你的云端或内部平台是什么样子的--你通常需要一个围绕你使用的任何平台的适当团队
所有的团队都应该是一致的，应该明白他们有什么目的。不是每个团队都能直接开发面向客户的价值。即使我们使用产品化的云环境来运行我们的应用程序，我们仍然需要共同的规则和云使用治理。在一个受监管的行业中，许多支持性的功能是必要的，我们在构建监管技术时，要对合规和法律进行转述。
所有的团队都应该有所有权和责任，而不仅仅是价值流对齐的团队。我怎么强调都不为过的是，好的平台团队是流媒体团队成功的必要条件。平台团队不应该被忽视，所有团队中的有意义的组成与价值流对齐的团队同样重要。