发展不能违背康威定律

在 SpringOne 大会上，来自 Credera 的 Jason Goth、Micah Blalock 和 Patricia Anderson 介绍了他们如何使用康威定律调整一个客户的技术架构和流程，帮助他们扭转了生产率下降的趋势，提高了高质量代码的生产速度。

康威定律指出“设计系统的组织……其产生的设计等价于组织间的沟通结构。”也就是说，团队创建的东西依赖于组织内部的沟通方式。

在为他们的医疗客户创建自定义分析平台时，Credera 了解到，对于一个或两个并行的软件开发团队而言行之有效的架构和流程，在并行开发团队发展到五个时会迅速陷入僵局。Credera 的方案是，根据康威定律重新定义问题，调整技术架构和流程。最后，经过努力，Goth、Blalock 和 Anderson 扭转了生产率下降的趋势，提高了高质量代码的生产速度。在 2016 年 8 月份举行的 SpringOne 大会上，Credera 分享了他们的经验。

起初构建代码时，只有两个并行 Scrum 团队，Credera 取得了初步的成功。因而，客户给他们安排了额外的工作。新工作需要另外增加几个并行开发团队，以应对同时到来的截止期。遗憾的是，这种规模的增长让他们的工作陷入了停滞。简单的代码变更需要级联修改多个下游服务。团队之间在工作时间里召开的沟通会议呈指数增长。不同团队的工作量差别很大，有些团队的成员很早就离开了，而其他团队则工作到深夜。士气下降，截止期已过，事情悬而未决。

为了匹配自己的沟通结构，Credera 团队从技术上改进了其软件设计。为了完善划分，他们在代码上应用了开 / 闭原则。在多个团队操作类似的代码时，这可以降低成本，但会导致团队编写重复的代码。他们将这一做法称为 GARY（继续前进，重复自己）。为了解耦大部分代码，他们创建了一个水平面，以防止许多与生成的重复代码相关的缺陷使他们多次“野蛮地重构”。

Goth、Blalock 和 Anderson 进行了组织变革，停止违背康威定律。代码标准被取消，只为开发人员提供了一份可以让他们快速从一个代码集迁移到另一个代码集的准则。一名成员充当软件开发过程中所有团队的负责人，推动团队之间的沟通。另一名资深成员 Blalock 则成为“献祭的羔羊”，负责会见客户以及与遗留代码打交道。虽然并不常见，但团队成员在冲刺过程中会在团队之间流动。结果是会议频次降低。团队工作量正常化，士气上升。最后，截止期不再那么令人焦虑。

该团队是受 Fred Brook 的著作《人月神话》所启发。通过那本书，他们认识到，沟通成本加上工作划分会导致效率变化。只有当工作可以划分时，你才可能通过增加团队成员来提高效率。

该团队采用了 Spring 平台，并将微服务作为项目的一部分。他们使用 Angular 和 Java 编码。

查看英文原文：Grow with Conway’s Law, Not Against It