1.6 自主权和改进

当团队开始拥有自主权时，我一次又一次地目睹了以下情况。团队首先提出了最简单的请求—那些使流程和工作方式现代化的请求：“我们能改变发布的节奏吗？”接下来，团队开始更关心质量：“让我们把测试左移。”“让我们增加更多自动化部分。”[21]然后是改变团队构成的请求：“我们可以转型为跨职能（或全功能）团队吗？”

取舍、失败和教训总会存在，但变化是自驱的。你会发现自己开始修改并调整关注点和解决方案，因为你开始不断关注端到端视图，并且更深入地理解了它带来的好处。

所有这些变化很快都汇聚到了一处：它们揭示了架构问题。也许这些问题就存在于白板设计中。也许白板上的设计很好，但最终在生产环境中实现时就不行了。不管怎样，总有问题需要被解决，例如耦合并不像你想象的那么松，领域边界不像最初出现的那么清晰，框架会阻碍而不是帮助团队，模块和基础架构可能不像你希望的那样容易测试，微服务在真实流量下运行时可能难以被观测。这些都是作为负责任的架构师必须要处理的问题。