团队拓扑

在过去的 10 年中，我曾参与过多次扩大规模的工作，因此我采用了一些原则来扩大技术和产品团队的规模。 第一个，是组织跨职能的团队。通常，要构建任何产品，您需要产品经理代表业务，产品设计师代表客户和工程师来构

让我分享一下我尝试在大中型公司中引入它的经验。有些你会看到的东西听起来很明显，但是这是我的经验，我想和你分享。这些年来我学到的第一件事是：从小处着手！ 从小事做起这是什么意思？这意味

亮点：微服务并不能确保良好的模块化：如果您使用微服务足够多，您可能会构建或借用一些不错的工具来简化服务之间的通信。但是，如果你不小心，你最终会得到一个紧密耦合的微服务式单体，每个函数都有大量的 HTTP 调用和要处理的版本控制。 在 Web 软件架

组件团队：每个团队负责一个系统组件。例如，有一个团队负责前台，一个团队负责后台，还有一个团队负责数据库。这三个团队独立运作，这经常导致团队之间的相互依赖。这些团队不是为最终用户提供价值，而是花了很多时间来讨论依赖关系和测试各组件的行为。从买方的角度来看，这些要素完全不重要。组

有人曾经告诉我，任何类型的团队或组织所经历的最艰难的转变是从大约 30 人增长到 60 人。当时，我记得我在想，“嗯，这很随意。当然，每个组织都是不同的。” 在某些方面，每个组织都是不同的。然而，我见过各种各样的团队都经历过这样的成长期，一遍又一遍地面临同样的挑战。随着每年都有大量新

成为软件架构师的典型路径始于多年来亲身参与的软件开发工作。你已经积累了广泛而深入的技术知识。在这个过程中，你已经发展了你的沟通技巧。我并不只是指状态报告。我指的是通过指导初级开发人员，向你的同行介绍你在特定工具、框架或语言方面获得的知识，以及与系统和业务分析师的互动。

让我们从基础架构即代码 (IaC) 和配置管理开始： 基础设施即代码/配置管理基础架构即代码 (IaC) 允许您自动配置云基础架构。无论是虚拟机、数据库、云网络、安全等，您都可以创建一个包含所有细节的 JS

情境-行为-影响：Situation-Behavior-Impact简称SBI，不加评判地向他人提供更清晰的反馈。 当我们对某人的行为持否定态度时，我们往往会跳出结论，并对某人的行为方式做出假设。在给那个人提供反馈时，可能很难保持客观。情景-行为-

如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读，那就是Mathew Skelton 和 Manuel Pais 的《团队拓扑》。顾名思义，主题是关于组织业务

在您的软件开发生涯中开发应用程序可能采用的众多方法之一是API-First Approach。在本文中，我们将深入探讨其核心概念并了解有关此方法的更多信息，我们还将熟悉在此方法中可能需要的一些工具。 背景从

敏捷无处不在。似乎每个人都想成为敏捷。如果你没有敏捷的团队，你就是一个恐龙。 但是，一个组织并不是简单地成为敏捷。下面是组织在成为敏捷时犯的十个错误。 10. 自上而下的敏捷实施

在我的工程生涯中，我做出了一个选择，离开了个人贡献者（IC）的轨道，转而担任技术领导职务。当时，我觉得自己已经在一些工程学科上取得了知识和技术深度，想尝试一下领导力。像很多人一样，我做出这样的选择是出于各种我认为很明显的原因：获得更多的权力、更多的声望、更多的报酬，以及在整个组织内更大的影响

随着软件开发的工作变得越来越复杂，现在可能是开发和运营专家再次分开的时候了。但这能做到不重复过去的错误吗？ 2000年代末，随着敏捷方法论和云计算的兴起，Devops也随之出现，因为软件开始侵蚀世界。Devops是 "开发 "和 "运营 "的谐音，

我们需要转向所有产品和工程团队（不仅仅是共享服务）都发布 API 的模型，这样其他团队就可以从他们正在构建的东西中受益，而无需安排会议。 随着公司规模的扩大，他们通常会放慢速度，并变得更有效率。需要更多的钱、更多的人和更多的时间来完成任何事情。协调

敏捷项目已经变成了 2 周冲刺的臃肿、懒惰的瀑布项目。瀑布式生产线方法适用于具有已知需求或制作小部件的项目。 敏捷宣言充满

关于如何更快地交付软件的讨论在我们的社区中无处不在。围绕着流程和组织结构的讨论有很多，但围绕着提高信任度作为快速流程的促成因素的讨论却不多。 今年，我有一些对话和经历，让我真正意识到信任的重要性。特别是，领导层和工作团队之间的信任关系。这是我已经观