远程办公与集中办公之间并非简单的二分法，团队分布模式有很多种，每种模式都有不同的优缺点和适用技巧。虽然不可能得出确凿的证据，但我认为大多数团队在集中办公的情况下效率更高。但是，您可以通过使用分布式工作模式来打造更高效的团队，因为它可以让您接触到更广泛的人才库。

软件项目是资助和组织软件开发的一种流行方式。它们将工作组织成临时的、仅构建的团队，并通过商业案例中预测的特定收益获得资金。产品模式则使用持久的、构思-构建-运行的团队来处理持续的业务问题。产品模式允许团队快速调整方向，缩短端到端周期时间，并允许通过使用短周期迭代来验证实际收益，同时保持软件的架构完整性以保持其长期有效性。

在理想状态下，产品模式组织由松散耦合、自治的团队组成，这些团队对明确和未明确的用户需求做出快速响应。然而，有时会出现需要跨多个团队协调才能应对的机会。如果管理不当，结果将导致收入损失、客户不满意和团队能力浪费。我们将应对这些机会的组织举措称为项目。在本文中，我们将通过一个失败项目的例子，分享我们在产品模式组织中管理项目的经验。

平台团队特别依赖于其他团队来确保其平台的采用 - 将代码更改纳入其他团队的代码库对其成功至关重要。跨团队协作有多种模式，选择正确的模式取决于平台采用阶段以及团队和代码库接受外部影响的能力。

康威定律（由梅尔文·康威于 1968 年提出）指出，系统的设

模块化架构可以改进软件交付吗？是的！- 但有一些需要注意的地方。本文描绘了一家企业为了缓解日益增长的痛苦而着手将其架构转变为更加模块化的架构的过程。他们发现，模块化是一个多方面的解决方案，它超越了架构，扩展到业务沟通线、团队拓扑结构和有效的开发者体验。通过密切关注这些因素，该企业能够在其移动应用程序的交付性能方面取得显著提升。

任何重要的软件开发工作都需要进行几项不同的活动：分析、用户体验设计、开发、测试等。面向活动的团队围绕这些活动进行组织，因此您有专门的用户体验设计、开发、测试等团队。面向活动承诺了许多好处，但软件开发通常最好由面向结果的团队完成。

一致性地图是组织信息辐射器，有助于可视化正在进行的工作与业务成果之间的一致性。这项工作可能是常规功能添加或技术工作，例如重新架构或偿还技术债务或改进构建和部署管道。团队成员使用一致性地图来了解他们的日常工作旨在改善哪些业务成果。业务和 IT 负责人使用它们来了解正在进行的工作与他们关心的业务成果之间的关系。

软件开发中尚未解决的问题之一是确定软件的边界是什么。（浏览器是操作系统的一部分吗？）许多面向服务架构的支持者认为应用程序正在消失 - 因此未来的企业软件开发将是关于将服务组装在一起。

我认为应用程序不会消失，原因与应用程序边界如此难以划定的原因相同。本质上，应用程序是社会建构

双模 IT 是一个有缺陷的概念，认为软件系统应该分为这两个不同的类别进行管理和控制。

• 前台系统（参与系统）应针对快速功能开发进行优化。这些参与系统需要对不断变化的客户需求和商机做出快速反应。缺陷应该被容忍，因为这是快速开发周期的必要成本。
• 后台系统（记录系统）应针对可靠性进行优化。作为记录系统，重要的是不要出现损害企业的缺陷。因此，您需要放慢变更速度。

限界上下文是领域驱动设计中的一个核心模式。它是 DDD 战略设计部分的重点，该部分全部是关于处理大型模型和团队的。DDD 通过将大型模型划分为不同的限界上下文并明确它们之间的相互关系来处理它们。

以业务能力为中心的团队是指其工作长期与企业特定领域保持一致的团队。只要上述业务能力与业务相关，该团队就一直存在。这与项目团队形成对比，项目团队只持续到交付项目范围为止。

我遇到过各种各样的代码所有权方案。我将它们分为三大类

我所青睐的软件架构从业者几乎都对该领域中的任何一般性定律深表怀疑。好的软件架构是非常依赖于上下文的，它分析了在各种环境中以不同方式解决的权衡问题。但如果说他们都同意一件事，那就是康威定律的重要性和力量。它足够重要，足以影响我遇到的每一个系统，而且足够强大，以至于如果你试图与之抗衡，你注定会失败。

当有人在研究是什么造就了一流的企业软件开发人员时，谈话往往会转向对框架和语言的了解，或者可能是理解复杂算法和数据结构的能力。对我来说，程序员或开发团队最重要的特征之一就是我所说的客户亲和力。这是开发人员对软件所解决的业务问题以及生活在该业务领域的人们的兴趣和密切程度。

敏捷软件开发打破了需求分析、测试和开发之间的一些孤岛。部署、运营和维护是其他一些活动，它们与软件开发过程的其他部分也存在类似的分离。DevOps 运动旨在消除这些孤岛，并鼓励开发和运营之间的协作。

一个常见的问题是，大型项目是否可以使用敏捷技术来完成。毕竟，许多敏捷方法都是为较小的项目设计的，而它们所抵制的重量级思想在更大的项目中更需要。

我使用非专业程序员这个词来指代那些在编程时并不认为自己是程序员的人。一个整天都在处理电子表格的人就是在编程，而且通常是非常密集的编程。然而，她通常不会称自己为程序员，也不会想过花太多时间学习如何更好地编程。

软件开发的赞助者通常对开发指标（如速度或生产部署频率）不太感兴趣。他们更关心软件将带来的业务收益，例如减少人工、提高销售转化率、提高客户满意度，即业务成果。以结果为导向的团队是指被授权和配备了实现业务成果的团队，这些团队的人员有能力开展所有必要的活动来实现成果。相比之下，以活动为导向的团队既没有能力也没有被授权这样做。他们只能执行实现成果所需的几项活动中的一项。

关于结对编程的一些常见误解。

通信技术的进步导致越来越多的团队以远程优先的方式工作，这一趋势在新冠疫情的强制隔离下得到了加强。但是，远程工作的团队仍然可以从面对面聚会中受益，并且应该每隔几个月进行一次。

想象一下招聘场景。有两个候选人，都有几年的经验。在蓝色角落，我们有一位在您喜欢的设计风格方面拥有良好广泛设计技能的人（对我来说，这将是 DRY、明智地使用模式、TDD、沟通代码等，但实际列表并不重要 - 重要的是这是您喜欢的）。然而，她对您正在使用的特定平台技术一无所知。在红色角落，我们有一位对这些问题知之甚少（或不感兴趣）的人，但他非常了解您的平台 - 语言中的边缘情况、可用的库、手指在工具上自然移动。假设他们其他方面都相同（除了像这样的思想实验之外，这永远不会发生），并且您的团队没有任何需要这位候选人填补的空白。您会更喜欢哪一个？

软件的好处之一是人们似乎想要它，并且想要得很快。组织要求团队加快软件生产速度是很常见的，而且组织不时地会寻求以真正体现其承诺的方式提供帮助 - 通过花钱为团队增加更多人手。

对信息丰富的程序进行模块化的最常见方法之一是将其分为三大层：表示层（UI）、域逻辑层（又称业务逻辑层）和数据访问层。因此，您经常会看到 Web 应用程序分为了解如何处理 HTTP 请求和渲染 HTML 的 Web 层、包含验证和计算的业务逻辑层，以及整理如何管理数据库或远程服务中的持久数据的数据库访问层。

去年我花了很多时间在 Thoughtworks 四处走动，与许多项目上的许多人交谈。我深刻认识到轮岗的价值。

上周，我很高兴在佛罗里达州与 Dan Sandlin 和 David LeBlanc 一起参加了一系列微软架构委员会会议。对于那些不了解 David LeBlanc 的人来说，他与 Michael Howard 合著了非常受欢迎的书籍《编写安全代码》（Writing Secure Code）。在每次会议上，我都会做一个关于P of EAA的演讲/问答（本周获得了 JavaWorld 的奖项），David 会接着讲安全。

让我们想象一个美好的 SOA 快乐世界，在这个世界里，企业的计算需求被分解成许多小型应用程序，这些应用程序相互提供服务，以实现有效的协作。一个美好的早晨，一个消费者服务需要来自供应商服务的一些信息。问题是，尽管供应商服务拥有获取此信息的必要数据和处理逻辑，但它还没有通过服务接口公开该信息。供应商有一个潜在的服务，但它实际上还没有。

在我最近的代码所有权帖子中，我描述了我对代码所有权问题的看法。我的许多软件开发朋友都是极限编程的拥护者，并且倾向于集体代码所有权。然而，这类实践并不是绝对的，应该始终根据当地情况进行调整。我的一位同事给我发了一封邮件，其中讲述了以下故事，我认为这是一个很好的例子，说明了什么时候必须改变你的实践，即使你是 XP 的忠实粉丝。（当他谈论他的团队时，他更愿意保持匿名。）

自从我进入我们这个行业以来，将软件开发从费力地编写代码转变为通过简单地组装组件来构建强大的系统的想法一直是一个目标。这是一个有时可以看到但从未真正实现的目标 - 尽管许多技术都悬挂着工业复用的诱人前景。

任何大型软件工作，例如大型公司的软件资产，都需要很多人 - 每当你有很多人时，你都必须弄清楚如何将他们分成有效的团队。组建以业务能力为中心的团队有助于软件工作快速响应客户的需求，但所需技能的范围往往会让这些团队不堪重负。团队拓扑是由 Matthew Skelton 和 Manuel Pais 开发的一种用于描述软件开发团队组织的模型。它定义了四种形式的团队和三种团队交互模式。该模型鼓励健康的互动，使以业务能力为中心的团队能够在其提供稳定价值流的任务中蓬勃发展。

在过去几年中，移动应用程序一直是软件开发领域的热门话题。像许多软件交付公司一样，Thoughtworks 收到许多客户的请求，要求我们为他们构建移动应用程序。然而，大多数情况下，当一家公司要求我们（或任何人）构建移动应用程序时，他们一开始就错了。我认为，在大多数情况下，即使您希望用户与移动设备进行交互，您也永远不应该考虑构建移动应用程序。相反，您需要考虑构建一个可以在多种设备上呈现的单一应用程序：移动设备、台式机、平板电脑 - 或者您的用户可能使用的任何设备。

两个披萨团队是一个小型团队，完全支持特定业务能力的软件。这个词之所以流行起来，是因为它曾经被用来描述亚马逊如何组织他们的软件人员。

在我的职业生涯中，我一直看到的一个主题是软件开发的性质和重要性。几年前，一位潜在客户告诉我们的一位销售人员，“软件就像污水管道，我希望它能可靠地工作，我不想知道细节”。这就是尼古拉斯·卡尔在《IT 不重要》中谈到的那种方法。相比之下，我们为许多企业做过工作，在这些企业中，IT 显然是其业务的战略推动力，使它们能够进入新市场或显著提高市场份额。那么，IT 到底是像污水管道一样的公用事业，还是一项战略资产？