距離上一次聽到作者的演講，並且寫了一篇：微服務架構或單體式架構?先從團隊認知負擔談起，也經過了一年多了，一直都沒時間靜下心來好好讀這本書。
直到最近漸漸開始感受到切身之痛，是時候該好好把這本書讀完（臨時抱佛腳的概念），隨著組織業務增長，團隊也越長越大，團隊之間需要更有效的橫向溝通與協做模式，此外組織為了要在業界佔有一席之地，也必須不斷的加強 domain knowledge 與技術深度，團隊成員都有種要爆的感覺，但是卻又無法具體的描述具體原因出在哪裡？因為人力資源不夠？這是每間公司都會遇到的問題阿，有哪間公司會說自己人太充足的？是因為團隊成員能力不足？其實團隊成員的能力也都是一時之選，那究竟問題出在哪裡呢？很有可能就是在於組織架構和協做溝通的方法。
Conway's law 橫跨本書的康威定律
首先先從康威定律開始講起，所謂的康威定律就是：
組織內團隊組成的架構，就會直接影響你的軟體系統架構會長成什麼樣子。因為團隊架構決定溝通模式，溝通模式就會影響軟體系統架構。如果要讓團隊進入高效的 fast delivery flow ，首先就是要規範（限制）團隊的溝通模式，這讓我想到網路上流行的這張圖，這也很可能反映了這間公司的軟體系統架構。
除了康威定律，本書的另一個重點就是鄧巴係數....
Dunbar 鄧巴係數
根據社會學家 Dunbar
的研究，團體中可以深入互相信任且 share working memory 得人數基本上大概是 5 個人左右，極限就是是 15
人，而能互相信任的上限大概就是 50 個人，當超過 150 人時就已經高過了社交認知的上限，就連要記住對方的名字都很難。
所以根據 Google 內部長時間的研究，各個 Team 之間得 dynamic （動態互動）對於產出的影響，遠遠大於有某個大大在某個團隊裡面。而會影響團隊動態互動的因素有哪些呢？
- Team Size 團隊大小
- Team Lifespan 團隊能固定在一起工作的時間
- Team Relationship 團隊成員之間的關係
- Team Cognition 團隊的認知
所以本書的第一個前提就是，好的團隊基礎就是『小巧精幹且長存的團隊』
這邊小的定義就是 5~9 人，固定的團隊成員一起為了一個目標工作得時間至少一年以上。
為什麼這邊提到至少要一年以上呢？因為根據 Tuckman's stages of group development 提到一個團隊到組成到真的可以產出績效，至少都會經歷以下四個階段：
- Forming 組成階段：英雄來自四面八方，人員陸續補充進來，很少一步到位
- Storming 磨合風暴階段：八國聯軍要怎麼變成利益共同體，需要花時間習慣彼此
- Norming 形成團隊階段：團隊逐漸演化出標準的流程方法與默契
- Performing 績效產出
但要知道的是，從 2 ~ 3 其實是會一直持續發生的，因為每次有人離去和新人加入，團隊成員的家庭和生理狀況變化，以及隨著團隊成熟度與業務量的變化，都會產生新的化學變化，這也是團隊的績效產出為什麼會一直變化。不是可以簡單用缺人加人就可以解決的問題。
Team Fist Mindset 團隊優先思考模式
所以什麼是團隊優先思考模式？
- 團隊對某個軟體（系統）負責，並且持續的關注與改善
- Daily 要承諾參與並且不要遲到
- 團隊對於內部事務要持續討論
- 專注在 Team Goal
- 幫助他人移除 blocking thing
- Mentor 新人，互相幫助成長
- 避免爭輸贏的爭論，要能包容探索各種可能性的言論
此外如果要讓團隊能以高效的模式運作，首先要以小巧精幹的長存團隊為單位，並且限制與減少不必要的溝通，這邊所謂限制不是說讓團隊互相 silo 老死不相往來，而是並不是所有的交流的都是好的和必要的，其實就跟系統開發一樣，一開始也許大家都可以互相 call 來 call 去，但是隨著系統變大邏輯變複雜，團隊與團隊之間要建立溝通的規範與 API Interface 就跟軟體一樣。
為什麼會要定 API Interface 這引出下一個話題：Cognitive Load（認知負擔）
Minimal Cognitive Load （最小化的認知負擔）
話說我們每個人的 working memory 其實是很有限的，所以要慎選佔用我們記憶體的事物，而書中提到 Cognitive Load （認知負擔）其實還可以分成三個種類：
- Intrinsic Cognitive Load （內在認知負擔）：比如說瞭解 Code 怎麼寫
- Extraneous Cognitive Load（外在認知負擔）：比如說要怎麼 deploy
- Germane Cognitive Load（有意義的認知負擔）：比如說 Service 之間怎麼溝通
根據我的理解，舉幾個軟體工程師的認知負擔例子（但不同角色例子可能就剛好相反）：
Intrinsic Cognitive Load （內在認知負擔）
比如說瞭解 Code 怎麼寫，Go 的語法 ，該用哪些 Design Pattern，如何透過 TDD refactor ，比較像工程師的本質學能。
Extraneous Cognitive Load（外在認知負擔）
比如說要怎麼 deploy，deploy 的流程是什麼，要去哪裡下載 Code？ CI / CD 的流程該怎麼設定？k8s 的環境設定要怎麼設？要去哪裡看 debug log ? 某個系統 reboot 致百病的 workaround 方法？
Germane Cognitive Load（有意義的認知負擔）
Service 要怎麼切分？ DDD 怎麼幫助設計？ 開發系統的 Domain knowledge....
那該如何最小化認知負擔呢？就是把稀缺的腦力放在有價值的地方，我們可以透過使用好的 IDE 和 tool 或是教育訓練 / Pair programming 來有效降低 Intrinsic Cognitive Load。
透過 SOP 或是專屬的 Infra Team / DevOps Team 來幫助建置優化開發部署流程，消滅工程師的 Extraneous Cognitive Load（外在認知負擔）
讓工程師更專注在於產生價值的 Germane Cognitive Load（有意義的認知負擔），設計更好的系統來解決客戶的問題帶來價值。
所以當隨著業務量變大以及團隊成長，但是團隊的績效和產出卻開始下滑，並且同仁們開始怨聲載道時，這時候可能不能簡單的認為，應該是人力資源不足加人就好，而是應該是要先從團隊的認知負擔開始檢討。是不是單一團隊承載太多認知負擔了？
切分團隊
這不就像是 Monolithic application 切分成 micro service 的過程一樣嗎？所以這就回扣到康威定律，團隊的切分與組織的溝通模式會決定你的系統架構。
團隊間的 API
當團隊切分完了就好了嗎？當然不是，如果沒處理好溝通模式，可能反而會造成穀倉效應。那團隊之前的 API 究竟是什麼呢？包含以下產出物：
- Service 間實體的 API 文件
- Document （wiki）
- 好的 User experience （讓別的團隊好懂好用）
- Versioning （版本規劃與向下相容）
- Best Practice & Principle （如何使用與規範）
- Communication method （透過什麼管道溝通？開票？開會？）
- Work info （ feature roadmap 與 bug fix time ）
此外最重要的就是把其他團隊當成顧客！要不斷的教育客戶，選傳自己的服務，測試和演化服務。
這邊提到 AWS 更極端的例子，每個 Team 的 Service 之間都還會設定 DoS rule 包含（SLA / Quota / API Call Throttling ）
更多內容讓我們繼續看下去....
有興趣的也可以先下載這本 mini-book 來看
沒有留言 :
張貼留言