梅尔·康威（MelConway）提出了著名的康威定律：“任何组织在设计系统时，其设计的系统架构是该组织沟通结构的写照。简单来说，产品必然是其组织沟通结构的缩影。”

你想要什么样的系统，就应该搭建什么样的团队。如果你的团队分成前端团队、DBA团队、中间件团队这种筒仓式的职能部门，将会产生筒仓式的软件架构（如图6-2所示）。

图6-2康威定律

这时候，组织若要交付一个潜在的可交付产品增量（PotentialShippableIncrement），就需要跨越DBA团队、中间件团队、UI团队。团队与团队之间的交接和等待，就像一场接力赛，这样的速度无法满足互联网时代激烈的竞争要求。

此外，当组织要改变一个产品特性的时候，可能会牵动每个层次的整体架构的变动。

诺基亚手机在实施敏捷转型之初，其终端功能机的研发部门的组织架构保留了原有的组件式团队。对于手机里的相机功能，需要有相机UI、相机Middleware、相机驱动程序三个Scrum团队来完成。每个Scrum团队貌似都做得很好，每个Sprint中自己开发的部分也都能顺利完成，但总是出现UI在等中间件、中间件在等驱动程序的情况。每个团队在Sprint结束时完不成的产品特性都需要对外依赖，而对外依赖的部分不受自己控制和影响，所以每个团队都把能搞定的先搞定，搞不定的都只能等着。结果，每个Sprint都有完不成的产品特性。实际上，整个相机研发过程中的每个Sprint都没有一个完整的可交付的产品增量。

此外，被依赖的组件即使交付给需要的团队，也经常发生不可用的情况。比如，中间件团队足足等待驱动团队两个Sprint的时间交付了一个组件，可是当中间件团队拿来与自己的组件联调后，发现很多不适配的问题，不得不打回驱动团队修改；而驱动团队有自己的优先级和Sprint计划，只能把修改任务排在后面。于是，中间件团队不得已又等了一个Sprint才拿到修改后的组件。每一次返工都将彼此的等待时间扩大了一倍。中间件团队拿到修改好的组件后，又花了一个Sprint的时间进行联调、发布。这样，为交付一个产品特性，经过几个团队之间的辗转反复，至少需要四个Sprint的时间。如果有的特性需要贯穿UI、中间件、底层驱动三个团队协同交付，所需的周期更长，返工更多。

在这样的按职能分工的组织里工作，每个团队只能把自己的那部分工作做到最好，控制不了的只能搁置一旁。而那些被搁置的工作，却是能够连接、集成整个系统的关键部分，从而造成整个产品交付效率低下。因此，组织必须基于产品特性组建跨领域团队才能实现高效交付。

梅尔·康威（MelConway）提出了著名的康威定律：“任何组织在设计系统时，其设计的系统架构是该组织沟通结构的写照。简单来说，产品必然是其组织沟通结构的缩影。”

你想要什么样的系统，就应该搭建什么样的团队。如果你的团队分成前端团队、DBA团队、中间件团队这种筒仓式的职能部门，将会产生筒仓式的软件架构（如图6-2所示）。

图6-2康威定律

这时候，组织若要交付一个潜在的可交付产品增量（PotentialShippableIncrement），就需要跨越DBA团队、中间件团队、UI团队。团队与团队之间的交接和等待，就像一场接力赛，这样的速度无法满足互联网时代激烈的竞争要求。

此外，当组织要改变一个产品特性的时候，可能会牵动每个层次的整体架构的变动。

诺基亚手机在实施敏捷转型之初，其终端功能机的研发部门的组织架构保留了原有的组件式团队。对于手机里的相机功能，需要有相机UI、相机Middleware、相机驱动程序三个Scrum团队来完成。每个Scrum团队貌似都做得很好，每个Sprint中自己开发的部分也都能顺利完成，但总是出现UI在等中间件、中间件在等驱动程序的情况。每个团队在Sprint结束时完不成的产品特性都需要对外依赖，而对外依赖的部分不受自己控制和影响，所以每个团队都把能搞定的先搞定，搞不定的都只能等着。结果，每个Sprint都有完不成的产品特性。实际上，整个相机研发过程中的每个Sprint都没有一个完整的可交付的产品增量。

此外，被依赖的组件即使交付给需要的团队，也经常发生不可用的情况。比如，中间件团队足足等待驱动团队两个Sprint的时间交付了一个组件，可是当中间件团队拿来与自己的组件联调后，发现很多不适配的问题，不得不打回驱动团队修改；而驱动团队有自己的优先级和Sprint计划，只能把修改任务排在后面。于是，中间件团队不得已又等了一个Sprint才拿到修改后的组件。每一次返工都将彼此的等待时间扩大了一倍。中间件团队拿到修改好的组件后，又花了一个Sprint的时间进行联调、发布。这样，为交付一个产品特性，经过几个团队之间的辗转反复，至少需要四个Sprint的时间。如果有的特性需要贯穿UI、中间件、底层驱动三个团队协同交付，所需的周期更长，返工更多。

在这样的按职能分工的组织里工作，每个团队只能把自己的那部分工作做到最好，控制不了的只能搁置一旁。而那些被搁置的工作，却是能够连接、集成整个系统的关键部分，从而造成整个产品交付效率低下。因此，组织必须基于产品特性组建跨领域团队才能实现高效交付。