1.6 自主權和改進

當團隊開始擁有自主權時，我一次又一次地目睹了以下情況。團隊首先提出了最簡單的請求—那些使流程和工作方式現代化的請求：“我們能改變發布的節奏嗎？”接下來，團隊開始更關心質量：“讓我們把測試左移。”“讓我們增加更多自動化部分。”[21]然后是改變團隊構成的請求：“我們可以轉型為跨職能（或全功能）團隊嗎？”

取舍、失敗和教訓總會存在，但變化是自驅的。你會發現自己開始修改并調整關注點和解決方案，因為你開始不斷關注端到端視圖，并且更深入地理解了它帶來的好處。

所有這些變化很快都匯聚到了一處：它們揭示了架構問題。也許這些問題就存在于白板設計中。也許白板上的設計很好，但最終在生產環境中實現時就不行了。不管怎樣，總有問題需要被解決，例如耦合并不像你想象的那么松，領域邊界不像最初出現的那么清晰，框架會阻礙而不是幫助團隊，模塊和基礎架構可能不像你希望的那樣容易測試，微服務在真實流量下運行時可能難以被觀測。這些都是作為負責任的架構師必須要處理的問題。