团队拓扑

敏捷是一种自下而上的运动，而如今，当在大型组织中实施敏捷时，往往是以从上而下的推动方式而不是拉动方式来实现的。 自下而上是让人们自愿参与变革，而不是自上而下的领导者选择。如果人们对他们施加敏捷推力，这会产生不利影响。当人们参与并想要做出贡献时，他们

我真的希望我们可以作为一个团队做更多的工程，创建、设计、研究和构建出色的软件。但相反，任何在2-4 天内无法完成的事情都会被取消优先级并放入积压工作中。其他讨厌点：会议超负荷。我觉得我是产品团队的仆人。作为一名工程师，我无法进行创新。

多年来，我们注意到开发具有高性能和高效率的软件是多么困难，以及团队因素在这个等式中是多么重要。有时我们没有意识到，我们并不总是需要最好的语言、技术或任何先进或疯狂的概念来达到最佳效果。相反，我们需要的是在心中保持最佳的组织结构，以便使事情变得简单。

软件设计与康威定理是两种不同的东西，软件设计是针对软件的，康威定律认为团队组织管理方式决定了软件的设计，因为这两者本身就属于一个大系统。但是虽然你的团队划分按照康威定律，最终软件设计还是不行，原因是康威定律并不适用于刚性的硬设计，

开发者体验(Developer EXperience，简称DX)是关于创造一个环境，让开发者可以做他们最好的工作。DX是一个可以释放开发人员生产力的环境，在这个环境中，个人需求与工程团队的需求可以成功地平衡。

Jessica Tai 是 Airbnb 的一名工程经理，负责平台基础设施方面的工作。她在 QCon上就 Airbnb 的架构以及这些年来它是如何转变的做了一场精彩的演讲。

在软件工程方面，我们的愿景是让 BBC 以其工程和内容而闻名。为此，我们必须进一步发展 BBC 作为产品和技术公司的理念。我们的资产中有数百个微服务，所以我们有跨学科团队负责每一个。我们尽最大努力在赋予每个团队权力和确保我们全面进行高度协作之间取得平衡。我们希望 BBC 以其

在这篇博客文章中详细了解团队拓扑的工作原理、好处是什么以及如何利用该方法。 由Matthew Skelton和Manuel Pais设计的 "团队拓扑 "方法，专门解决了许多组织苦苦挣扎的挑战：没有足够快和好地将软件送到客户手中。软件团队往往面临着创造价值的巨大压力。然而，除

本文是下篇，上篇见这里。耦合只是结构化设计运动所定义的两个最具突破性的概念之一。另一个可能更重要：它是关于内聚力（凝聚）的概念"。

我主要是一个传统的程序员，但当我做DevOps来支持我的应用程序时，我必须打开我大脑的另一面；我以前也是一个系统管理员，所以我不得不做这三个角色： DevOps工程师为基于基础设施的活动编写更多的声明性代码。程序员写的更多的是用于应用程序的命令式代码。 DevOps工

2021年初，在Snapcommerce，我们有25名工程师在班组工作。每个小组都有一个工程经理（EM）作为所有项目的负责人和技术负责人（TL），一个产品经理（PM），一个设计师，一个QA团队成员，以及最多七个个人贡献者（IC）工程师。对于工程师来说，从一个IC成长为TL可能是一条具有挑战性

在你的组织或公司中创造多种文化，例如先驱者、定居者和城市规划者就是具有不同的文化的人群： 先驱者是杰出的人他们能够探索以前从未发现的概念，未知的土地。他们向你展示奇迹，但他们经常失败。大概有

首先什么是敏捷？它来自哪里？ 我第一次遇到敏捷是在图书馆的工作中。我被雇来帮助一个新的数字学术中心落地，有时与图书馆的软件开发团队合作，建立工具来支持我们的项目。这个团队大约有六名成员，我马上注意到他们做事的方式与非技术人员不同。在会议上，他们不谈

Bedrock平台使Slack的开发人员能够构建他们的代码，将其打包到Docker容器中，并分配计算资源来运行它，所有这些都通过bedrock.yaml文件进行配置。Bedrock利用精心挑选的Kubernetes功能，以及旨在使启动生产级服务更简单、更愉快、更有成效的护栏和自动化。

Shubhro Saha 是 Facebook 的工程经理。他写了一篇很棒的博客文章，介绍了如何更好地估计一个项目需要多长时间才能完成。一个很好的提示是始终清楚地将估计与目标与计划分开。目标可能是最乐观的，而计划是最悲观的（它解释了可能遇到的任何问题）。

我曾在航空航天、电信、电子商务和SaaS领域的大中小型公司工作。作为一名工程师，一名经理，现在是一家小公司的C级。 几乎每一个我工作过的地方都至少提到过，而且很多人都尝试过实施某种OKR或其他正式的绩效评估过程，但都没有成功。成功是指实施，