一款优秀的软件可以让交付更流畅

TL;DR:当一个组织的不同部分需要协调时，帮助他们顺利和频繁地协调似乎是一个好主意。不要。帮助他们减少协调–更明确，更少的次数。

软件系统变得很大，它们有很多部分，而这些部分需要相互交流。也许我们正在建立一个新的客户门户，而新的网络服务需要与现有的客户关系管理（CRM）、退货的仓库系统以及发票进行对话。该软件跨越了组织的边界。

如果软件要相互交谈，团队就需要相互交谈。新的服务需要改变来自仓库和开票的新API。也许在CRM中也有一些定制化的工作。所有这些都需要协调。

我们怎样才能使这种协调更容易呢？(这似乎是要问的问题。)

我知道，让我们把所有的部门都转移到同一个跟踪工具上吧!每个人都将使用JIRA。这样，我们就可以把所有的变化卷到一个地方，仓储、开票和新的客户门户团队都可以看到彼此的状态。

这种可见性使我们能够更深入地进行耦合。现在，我们在完全不同的部门的个别任务之间存在着依赖关系。现在每个人都需要跟上每个人的步伐。这么多的项目经理都忙着跟踪所有的事情!每个任务都会影响到整个公司的人。

在部门内部，各个团队在他们编写的软件系统之间有基本的耦合。启用任务级别的协调会在团队内的单个工作项目上产生耦合。这么多的协调!那么多的交接!

通过使协调变得更容易，我们就能实现更多的协调。这导致了一些优化，比如：如果我们等到服务完成后再写对仓库的调用，那么门户团队可以少做一些编码。然后，CRM的变化可以等待我们的变化，而我们的变化又在等待其他东西–协调工作就会膨胀。

但协调不是我们想做的工作！我们想建立软件。我们想做的是构建软件。

试试这个：与其让协调变得更容易，不如想象它真的很贵。我们将如何做得更少？

为了最大限度地减少协调，要建立边界和跨越边界的少数接口。在这些接口上仔细工作：彻底记录它们，并在两边进行测试。尽量少改，努力改：版本化，向后兼容，逐步淘汰。

不要问边界的另一边什么时候准备好，而要假设我们不知道。编写合同测试、翻译层和自定义假的测试。

把另一个部门当成另一个公司，就像软件即服务，我们不能控制他们的时间表。在那里我们不能访问他们的跟踪工具。

围绕界面的内容进行大量的沟通。而没有其他地方。这让各部门单独工作。

一个强大的边界就像一个额外的组件。它需要更多的工作，但这些工作停留在部门内部，而不是跨越。没有任务层面的纠缠。每个团队都按照自己的节奏进行工作。

虽然一些生产版本可能会等待所有组件的交付，但没有一个组件的开发是相互等待的。这使得这比高度协调的、紧密耦合的发布_要快_ 。当难度随着规模的增加而增加时（比如在软件系统中），几个小的系统可以比一个大的系统更有效地工作。

这种解耦需要在软件上做更多的工作。

它更快，但它更便宜吗？这需要更多的工作：编写测试和假象，架构端口和适配器，当我们对接口的第一次猜测是错误的时候改变这些适配器。这需要更多的构建软件。

这不是我们想做的工作!我们想构建软件–哦，等等。

明确边界的额外工作使软件更好。

协调的额外工作只会让它花费更多的时间。

当我们以后改变系统时，强大的边界使这些改变更快。深度协调使这些变化变得更难：紧密的耦合仍然存在，但军队已经继续前进，那些英勇地把最初的发布放在一起的项目经理的军队。

这种协调也是非常昂贵的。更多的经理。另外，软件开发人员坐在协调电话上，努力测试，并等待依赖性，是很昂贵的（而且不快乐）。

让协调更顺畅会增加耦合度，需要更多的协调。另一个选择是把开发工作花在健康的边界上。你可以为更好的协调，或者更好的软件付费。

不要统一跟踪工具。不要让协调更顺畅。让交付更顺畅！通过加强边界。