阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿，两个小时左右的完善和回顾（我曾在一个地方有四个小时的完善），那简直就是把一天的冲刺时间浪费在了会议上。如果团队中.

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

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

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

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

 连续架构六大原则 连续架构不是一种架构方法。这真的是一种心态，几乎是一种工作方式，一种思维方式。第一个是你应该架构你的产品。很多人会考虑我需要实施的项目，但您应该考虑我正在实施的软件产品是什么，以及.

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

本文《Agile as Trauma》指出敏捷的本质是反动的（reactionary：保守、落后、反动）。敏捷就像任何概念一样，必须适应和学习，将产品管理和领域驱动设计的方法与敏捷相结合是我们今天所处.

改善交付时间应该是每个组织的目标。阻碍交付流程加速的一个主要减速器是组织中的不同团队传统上一直在孤岛中工作。为了解决这个问题，在大多数情况下会出现一个简单的解决方案：增加不同团队之间的沟通。但是，这个.

我知道微服务的话题已经被反复讨论过，我只是想根据我在这种设计 Web 应用程序的方法方面的经验，将我的经验加进去： 很多人认为微服务架构解决了具有扩展性和性能性质的软件问题。但他们解决的最重要的问题是.

美国组织理论家罗素·阿科夫 (Russell Ackoff) 说：“一个系统不仅仅是其各部分的总和；它是一个不可分割的整体。当它被分解时，它就会失去其本质属性。”在进行API设计时，我们*喜欢*还原论.

Nick Horney 是《VUCA Masters》的作者和 Agility Consulting 的创始人。在这一集中，Nick 分享了他在领导敏捷性方面的创新，包括 AGILE Model 和.

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

需要其他团队合作是很自然的。等待他们或依赖他们为您提供一些东西可能很诱人，发生这种情况是因为他们拥有您需要工作的区域。例如，您可能需要一个团队将一个字段添加到他们的 API 中。或者您可能需要它们为您.

本文列举了一些可以应用于软件开发的最流行的规则和原则。对于每条定律，我们将快速讨论其主要命题，然后探讨如何将其应用于软件开发。 帕累托原则（80/20 规则）帕累托原则指出，通常80% 的结果来自 2.

2010 年代是软件工程史上的一个转折点。在本世纪初，Eric Ries 通过The Lean Startup(精益创新)颠覆了构建数字产品的传统方法。在这十年末，Matthew Skelton 和 .

新型产品技术团队模型简述： 没有孤岛，团队专注于了解客户的问题和市场挑战（环境），并由此发现和塑造他们应该如何构建和发展他们的产品（技术系统）。（他们显然在业务/公司使命和目标之间取得了平衡）。 这并.

是业务决定技术？还是技术决定业务？是人决定IT，还是IT决定人？这是康威定律与敏捷的区别：一位叫Melvin Conway学者进行了社会学观察：组织中IT 解决方案的结构遵循组织结构。弗雷德里克·布鲁.

随着时间的推移，不同的人以各种不同的方式阐明了康威定律。这是我最近在阅读康威定律文献时发现的变化的概述。Melvin Conway对康威定律的原始定义：设计系统的组织被限制生产设计，这些设计是这些组织.

假设有一个农业机械零件的批发商。他们建立了一个 B2B 网上商店，供经销商和机器维修公司订购。在他们无处不在的统一语言与术语中，订单代表了这个自动化流程：它使客户能够挑选产品，应用正确的折扣，并将其推.

领域驱动设计的主流思想是关于实体、值对象、聚合、存储库、服务、工厂……各种技术模式。因此，大多数人认为他们不需要领域驱动设计，因为这对他们的领域来说很复杂。为什么你需要所有这些“东西”？好吧，也许你不.

当前人们对大脑自身的认识深入促进人工智能和认知科学等方面发展，仿真人类的大脑思考模型称为启发很多创新方法研究的源泉，例如人其实是神经元交互聚合的产物，人类群体是否可视为神经元集合的延伸？如何借鉴神经元.

当您公司的整体Web应用变得太大而脆弱时，部署变得缓慢而令人恐惧。因此，作为一家软件公司，您已决定遵循许多其他公司所采用的方法——将这个整体/单体架构拆分为微服务架构。这个迁移旅程可能漫长而艰难，潜伏.

很多团队没有专职的架构师，但是实际上有一些角色参与了架构决策，根据康威定理，组织架构决定了技术架构，如果管理者确定了系统的体系结构，那么他们实际上就是其架构师。如果程序员确定了体系结构决策，则实际上是.

Uber核心平台技术最初押宝Thrift和Mesos，这种两种技术后来分别被gRPC和Kubernetes主流技术替代。当初您做出技术路线决策的上下文已经时非今日可比，问题：技术决策的上下文半衰期是多.

1.康威定律也称为：“您将承载组织结构。 ”“任何设计系统的组织都将产生其结构是组织通信结构副本的设计。”您可能认为可以通过跨职能的站立会议、利益相关者更新和决策矩阵来避免这种情况，但是最终且不可避免.