团队拓扑

将 DevOps 运动中的团队拓扑与领域驱动设计社区的上下文映射相结合，可以深入了解软件工程团队之间的潜在摩擦接触点。

我知道微服务的话题已经被反复讨论过，我只是想根据我在这种设计 Web 应用程序的方法方面的经验，将我的经验加进去： 很多人认为微服务架构解决了具有扩展性和性能性质的软件问题。但他们解决的最重要的问题是组织问题。 康威定律一直在起作用。当您考虑构建的软件应该是什么样子时

我想写下为什么从一个全新的项目开始使用微服务通常是一个坏主意。时机已到，这正是我将在本文中讨论的内容。微服务变得越来越自然，我们几乎感觉自己一直生活在微服务的世界里。最近，当我与其他开发人员交谈并询问他们将如何启动绿地项目时，几乎可以肯定，答案是，嗯，一个微服务用于此，另一个

由 Matthew Skelton 和 Manuel Pais撰写的《团队拓扑——组织业务和技术团队以实现快速流动》一书将帮助您设计团队组织结构，从而帮助您变得更加敏捷。这本书分为三个部分： 第一部分侧重于作为交付手段的团队。 第二部分解释了适用于流程的团队拓

自然界是由复杂的系统组成的，对于任何人群来说，最好的策略都是考虑到复杂性的策略。这是分层组织模型的局限性。正如1997 年关于复杂性概况的论文

本文《Agile as Trauma》指出敏捷的本质是反动的（reactionary：保守、落后、反动）。敏捷就像任何概念一样，必须适应和学习，将产品管理和领域驱动设计的方法与敏捷相结合是我们今天所处的位置，但这种组合还没有被命名。原文点击标题：

AdHoc需要在快速发展的工程团队中推出新的领导层，需要重新构想如何沟通，以及信息将如何在这个新的领导层中流动。 松耦合和高对齐成长中的公司通常只是在高级领导下划分子组的层次结构，这会导致多个不同的组织孤岛，负担过重的高级领导者试图协

美国组织理论家罗素·阿科夫 (Russell Ackoff) 说：“一个系统不仅仅是其各部分的总和；它是一个不可分割的整体。当它被分解时，它就会失去其本质属性。”在进行API设计时，我们*喜欢*还原论作为处理复杂性的一种方式：例如《Web API 设计原则：通过 API 和微服务交付

Eric Evans在 2000 年代初撰写领域驱动

向技术领导地位的转变是一个巨大的挑战。技术领导是不同的。领导技术团队不仅需要管理技能，还需要技术实力和驾驭科技世界的能力。在数字产品上工作，您需要了解如何领导您的技术团队，为用户提供高价值，同时保持敏捷并准备好改变方向。我们收集了一些最好的技术领导力书籍，因此您可以深入了解成功的最佳

Matthew Skelton与 Manuel Pais 合著了《团队拓扑：组织业务和技术团队以实现快速流程》一书，这是一篇开创性的文本，讲述了如何围绕软件对您的特定组织的角色构建最佳团队结构。Matthew 在 2018 年、2019 年和 2020 年被 TechBeacon 评

大多数工程组织都专注于交付项目。他们应该专注于里程碑。管理项目很困难。公司会为了做好这件事而扭曲自己。与其下棋，不如改用跳棋。里程碑是一个更简单的游戏，你会得到更好的结果。在这篇文章中，我描述了：我建议您采用一种特殊的里程碑。为什么人类很讨厌

根据宾厄姆顿大学管理学院的研究，既值得信赖又能干的人最受追捧。根据纽约州立大学宾厄姆顿大学的一项新研究，友好和值得信赖的人比那些仅以技能能力和个人声誉着称的人更有可能被选入团队。虽然在团队组建方面，既可靠又能干的人最受追捧，但友善和守信往往比能力更重要。Maupin

改善交付时间应该是每个组织的目标。阻碍交付流程加速的一个主要减速器是组织中的不同团队传统上一直在孤岛中工作。为了解决这个问题，在大多数情况下会出现一个简单的解决方案：增加不同团队之间的沟通。但是，这个解决方案就足够了吗？当公司成长时，“增量沟通解决方案”如何扩展？我们将在本文中解释其

Amplitude 的核心是为跨职能的产品团队（以及影响产品体验的增长和营销团队）而设计。我们将我们的产品视为加速学习、透明度、结果、一致性和自主性的良性循环。成为“真正的产品团队”（

需要其他团队合作是很自然的。等待他们或依赖他们为您提供一些东西可能很诱人，发生这种情况是因为他们拥有您需要工作的区域。例如，您可能需要一个团队将一个字段添加到他们的 API 中。或者您可能需要它们为您构建新的 API。有时，如果没有这些更改，您就无法交付所需的内容。这是一个组织陷阱。