多年来，我们注意到开发具有高性能和高效率的软件是多么困难，以及团队因素在这个等式中是多么重要。有时我们没有意识到，我们并不总是需要最好的语言、技术或任何先进或疯狂的概念来达到最佳效果。相反，我们需要的是在心中保持最佳的组织结构，以便使事情变得简单。
通过教导我们如何必须准备好为我们的团队实现最佳的中期和长期成本效益，团队拓扑结构的概念已经帮助指导我们在Pipefy目前的演变。在研究团队拓扑结构时，我们注意到了显著的相似性，同时修改了软件开发的所有基础。这让我们对这个过程的每个阶段都有了深入的了解。
我们可以观察到，团队拓扑学是一种不同的思考方式，即公司必须如何组织，因为它不是一个专门针对开发人员的方法论，而是有效地集中了广泛的技术来帮助管理人员和开发人员。通过关注所追求的现状或快速流动，这种方法旨在建立一个更好的组织架构，以便获得最高的交付质量、高性能和公司的成熟度，这对整个工作流程有利，并减轻压力和倦怠等因素。
我喜欢把 "团队拓扑 "看作不仅仅是一种敏捷方法论，因为马修斯-斯凯尔顿更进一步，巧妙地结合了许多技术和模型，专注于XP、DevOps、SRE等方面的精华，并在每个阶段提供坚实和高质量的技术内容。所有这些都可以根据我们团队的沟通结构和互动来建立一个有组织的模型。
- 组织结构图的问题
- 康威法则
- 逆向康威法则
- 团队的规模
- 认知负荷
- 基本拓扑结构
组织结构图的问题
世界上大多数公司都组织成层次结构，这些层次结构通过一个复杂、单调和线性的层次结构图来直观地表示，该层次结构图显示了团队、部门和单位。这种垂直的工作和沟通模式意味着这种控制分工可以创造一个允许大量创新的环境。同时，一切都快速交付，就像我们在工厂中的生产线一样运作。
但我们知道，如果我们在这种分层限制的模型中构建软件，我们将在贡献、沟通以及最重要的参与方面产生问题，由于来自链的两侧或顶端的沟通，肯定会产生不切实际的期望。结果，开发人员可能只想知道他们在这个分层图表中的位置，并且每天都将自己的工作流程变成瓶颈。
团队拓扑主要侧重于通过设置具有明确定义的交互模型的动态组织结构来赋予团队权力，这些模型有助于团队快速采用新条件。因此，当被视为构建块时，工程师、开发人员和 PO 一起工作，因为他们是一群在相同环境中行动的人。
康威定律
当我们想到一家公司并考虑它的成功发展时，组织以及它的团队结构、软件结构以及最重要的是它的沟通成为一个关键问题。
康威定律创建于 1969 年，让我们有机会将这些方面作为我们分析的主要焦点，后来我们发现，忽略该定律会对您的软件产生或不产生的影响产生重大影响。
康威的论文认为，当公司设计他们的系统时，他们注定要生产出他们的通信结构的副本。这可能是好是坏，因为您公司的重大沟通问题可能会影响您的产品质量。
简而言之，如果与业务团队的沟通不明确，这将导致产品成功的机会减少，与最好的技术和工程师合作也毫无用处。另一方面，如果一个组织被安排成 QA、DBA、前端、后端等功能孤岛，则不太可能生产出设计良好的端到端产品。
如果系统架构和组织架构不一致，则组织架构获胜。
反向康威定律
在 Conway 方法中，我们倾向于不可避免地将我们的组织模型复制到我们的代码中。当我们颠倒这个概念时，我们在组织中复制了我们的软件模型。换句话说，我们必须在软件准备好之前重塑团队沟通的方式。
换句话说，当我们应用逆康威定律时，我们可以设计我们的团队，使他们能够匹配软件设计的需求，因为开发人员被赋予了不同的功能。
作为一种安全措施，随着快速流动带来的变化，我们必须牢记团队的范围及其架构必须保持一致。因此，在草拟完茶的属性草案后，我们必须应用代码架构最佳实践，例如：
- 低耦合：组件不能强依赖于其他组件。
- 高凝聚力：组件必须具有明确的职责和边界，通过表明与其内部元素的强关系。
- 软件架构原则，例如 SOLID（单一职责、开放式关闭、Liskov 替换、接口隔离和依赖倒置）、KISS（保持简单、愚蠢）和 DRY（不要重复自己）
这些实践有助于优化并增强我们探索架构如何以相对较低的成本促进快速变化的方式。
团队规模
一旦我们对团队的规模有了很好的了解，我们就必须考虑到团队成员之间的关系。因为 Team Topologies 主要专注于打破任何可能的沟通障碍，所以如果出现沟通障碍，指望世界上最好的工程师是没有用的。
一个团队的极限不仅仅是一个数字。我们必须认为，一个团队必须像足球队一样培养内部信任和良好的融洽关系。邓巴的研究表明，当我们能够在一个小团队中培养信任时，就会提高生产力。当然，大型团队能够保持高度信任的情况也有例外，但这种情况很少见。如果我们像看待家人一样看待我们的团队，很自然我们不会与所有成员保持联系，而邓巴在他的研究中成功地找到了一些信任模式。
即使找到了合适的数字和合适的人，我们仍然需要改变团队的思维方式，以便让沟通顺畅，让拥有必要知识的紧凑团队受益。为此，所有成员都必须明白，他们必须将团队的需求置于个人需求之上，遵守基本的工作协议，例如映射讨论和调查，并始终关注团队的需求，无论是目标还是主动性，守时， ETC。
认知负荷
拥有足够规模的团队但承担很多责任是没有用的。因此，为了让团队保持专注并提供最佳绩效，我们必须能够衡量其认知负荷并在为时已晚之前识别瓶颈。
为了更好地理解认知负荷是什么，我们首先需要了解我们是如何学习的。我们的记忆分为工作记忆和长期记忆。一些研究，例如 John Sweller 的“认知负荷理论 (1988)”，表明我们能够在工作记忆中保留七到九个过程。由于知道一个人处理信息有这样的限制，我们必须提前计划以防止信息过载。
但到底什么是认知超载？
已使用的工作内存资源量。
无论你的团队多么诚实，认知过载是很难衡量的，对认知过载的管理不足会导致产品以及沟通质量的严重困难。
这种负荷被分为三个不同的时刻。内在的、外在的和内在的。在软件开发领域，我们可以将它们定义为。
- 内在的（Intrinsic）：做新事情的复杂性，比如当我们有一个史诗般的或非常大的任务需要完成时，需要多少认知资源来把这些信息转移到长期记忆中。
- 外来的（不相关的Irrelevant）。这种类型的负荷会造成分心，使我们的工作记忆无法正常运作，比如在嘈杂的环境中工作，缺乏开发工具，或者代码写得不好。所有这些都会阻碍学习，使我们更难获得长期记忆，因此我们应该尽可能地减少这种负荷。
- 相关（Germane、Relevant）。这是意味着更深层次处理的负荷，这被称为流动，是一个认知水平，在这个水平上我们能够处理复杂的信息，访问我们的长期记忆，并更好地与我们的推理互动。出于这个原因，这是我们必须最大化的负荷。
当负载因素在日常工作中没有得到正确解决时，我们可能会注意到团队开始失去焦点和时间，仅仅是因为过多的责任和领域。下面的图片显示，功能和任务与其他关键点竞争，这些关键点占用了我们的认知能力，而我们并不总是注意到这些。
我们需要谨慎，能够很好地管理我们的沟通和团队组织，这样才能从认知负荷理论中获益，发挥其最大潜力。为了做到这一点，我们必须管理好内在的负载，比如我们把一个史诗分成故事，然后再分成任务，从而减少不相关的负载，在一个安静的环境中工作，减少框架的数量，保持代码的健康，最后，通过在不同的环境中进行充分的重复，使我们的相关负载得到最大的利用。
基本的拓扑结构
当我们定义了一个团队的规模、领域和人员后，我们就能发现它的拓扑结构是什么。这样一来，所创建的每一个服务或应用都必须由一个具有认知能力的团队来建设和运营。这可能会引起一些疑虑，比如。我们是否有合适的团队在合适的时刻？或者，在一些看似没有主人的领域，是否缺乏能力？因此，我们必须从每个团队如何融入组织的角度来思考。为了使这个过程更简单，我们可以通过团队拓扑结构将团队的变化数量减少到四个基本团队。
- 流对齐Stream-Aligned 团队：与业务领域或组织能力紧密结合的持续工作流程是这些团队的基础。这个团队负责交付价值，必须保持其目的、目标和责任非常明确。其范围可以从简单的产品、服务或角色，到一系列的功能或用户旅程。
- 赋能团队：这是一个高性能的团队，由具有高技术水平或业务所有权的专家组成，他们为流向一致的团队的发展提供支架，因为后者将专注于高价值的交付。因为这个团队有很强的协作意识，他们能够分享知识，并提高流线型团队的自主性，而不会成为英雄。
- 复杂-子系统团队: 这个团队负责建立和维护系统中强烈依赖特定知识的部分，大多数团队成员是某一领域的专家，对执行系统模块和子模块的变化有很强的理解。
- 平台-团队：这个团队的目的是让流向一致的团队能够完全自主地完成他们的工作。这个团队提供服务，以减少认知负荷，这对于流对齐的团队建立这些服务是必要的。
持续改进
在我们的团队被定义、调整和分类之后，我们能够通过不同团队在不同时刻的交付来支持他们的快速和可持续增长。这创造了一个低耦合的环境，良好的沟通，指导我们的决策以实现 "快速流动"，并给组织一个现实的使命。
如何应用价值导向技术？ 这个问题在Pipefy这里被仔细研究，我们的组织方式是，这个问题的答案可以让简单的变化产生最大的影响。因此，我们一直在重新审视和重构我们的工作流程，应用团队拓扑结构，注重以人为本，并使用许多方法使我们的团队重组与我们的目标、客户和商业价值相一致。