微服務架構或單體式架構?先從團隊認知負擔談起

Team Topologies: Organizing Business and Technology Teams for Fast Flow

自從鳳凰計畫以後都一直有訂itrevolution.com 在 SoundCloud 上的頻道



今天一早推送的新書試聽 Team Topologies 的新書，一聽驚為天人，感覺正在回答我最近面對與思考的問題，有興趣的可以聽這個演講。

所有組織都是從一個team 開始，而一個 team 合理的上限大概5 ~8 個人(鄧巴係數是五人)
因為 Team 的重點是 Trust & communication ，任何工作都是 Assign 給 team ，再由 team 內自己決定，所以 Scrum 的設計都是有依據，之後組織再依據鄧巴係數一層一層長上去。

Team first architecture

Team 的架構也會影響到軟體架構，所以最好的設計就是依照組織設計系統架構(交互影響)

Team 最好是一個 long live team , Team should stable and static

對這幾張投影片特別有感覺：


關於軟體開發上，主要會有三種面向的腦力負擔或稱認知負荷，我們應該盡量極大化讓工程師的腦力可以專注在 Domain 方面也就是 Germane Cognitive load。

到底一個 Team 必須要知道多少東西，必須要承載多少工作量。 一個軟體大小(複雜度)取決於腦袋的大小。

有趣的解讀與設計，事實上很多公司就這樣用

Stream aligned team

就是 DevOps end to end Scrum team

Platform team

類似 SRE (如負責維運 k8s)

Complicated subsystem team

有的公司叫做 Core team
有的叫做 Research team
有的叫做 Data Scientist team
主要由 PHD 組成負責複雜的演算法和核心技術

Enabling team

非常微妙的存在，有點像 Taskfore 用來幫助各 team 之間的協作與融合，比如說我們現在要轉型，要導入Agile or DevOps 這個 Team 就像先行團對來幫助各團隊導入。


而隨著專案/產品 的進行，有些 team 會一直存在，有些可能是臨時組成，我覺得這比 LeSS or SAfe 多了更多細膩的解釋，應該是可以搭配服用~


又要剁手買書了...:P