最新

我当时带领着一个团队，感觉一切都很缓慢。每个人都很忙，但交付功能的速度仍然很慢。我们跟踪了团队的“速度”和“故事点”，但这些指标根本不关心业务做得有多好，也不关心开发成本，所以我意识到它们对我来说毫无用处。 我们（理论上）有一个干净的架构，但它却因为协调需求而束缚了我们。每次小的功能更改都需要跨多个团队的同步会议，而且更改通常也会波及到其他团队。我们花在沟通和架构开销上的时间，比实际的工程工作还要多。 我停止了衡量“速度”，开始衡量“结构性摩擦”。我将其定义为用于协调任务（即会议、设计、在其他模块中进行开发）的总人力工时，相对于用于高影响代码的实际工时。这个数字令人震惊。 我不得不将每个模块进行模块化，这样领域数据就不会再泄露。这至关重要，这样一来，该模块内的更改就永远不需要协调会议或在其他模块中工作。 我的团队在三个月内的产出翻了三倍。“结构性摩擦”是一个架构特性，你必须主动优化以保持其较低水平。如果你的架构迫使你进行协调（无论是在技术上、在会议上，还是两者兼而有之），那么它就是有缺陷的。消除协调的需求，你就能消除浪费。