團(tuán)隊(duì)拓?fù)鋵W(xué)
Hi，我是阿昌，今天學(xué)習(xí)記錄的是關(guān)于團(tuán)隊(duì)拓?fù)鋵W(xué)的內(nèi)容。
看看最近這幾年來新誕生的組織結(jié)構(gòu)模型——團(tuán)隊(duì)拓?fù)鋵W(xué)（Team Topologies）。
一、團(tuán)隊(duì)拓?fù)?/h3>
盡管組件團(tuán)隊(duì)、特性團(tuán)隊(duì)和 Spotify 模型，都為團(tuán)隊(duì)的組成提供了不錯的建議，但團(tuán)隊(duì)的類型應(yīng)該是什么樣并沒有一致的標(biāo)準(zhǔn)。
如果所有團(tuán)隊(duì)都是特性團(tuán)隊(duì)，專注在某一個業(yè)務(wù)領(lǐng)域，那么業(yè)務(wù)領(lǐng)域開始變得復(fù)雜時，仍然僵化地專注于功能特性就會導(dǎo)致一些問題。
比如一個支付平臺，它除了有源源不斷的業(yè)務(wù)需求外，還有很多技術(shù)相關(guān)的事情要做，如數(shù)據(jù)的同步、分布式事務(wù)，或業(yè)務(wù)的回滾、對沖等。
假設(shè)按照系統(tǒng)的復(fù)雜度來判斷，需要三十個人來維護(hù)這個平臺，要是按照特性團(tuán)隊(duì)的思路來進(jìn)行組織，就會分為三個特性團(tuán)隊(duì)，它們做著完全類似的業(yè)務(wù)開發(fā)。對于復(fù)雜的技術(shù)問題，就可能無人問津了。
盡管有了分會和協(xié)會可以一定程度上緩解，但這種自組織社區(qū)的執(zhí)行力顯然還不夠。
這時，應(yīng)該從團(tuán)隊(duì)優(yōu)先（Team First）的角度去思考，將任務(wù)按照不同的復(fù)雜度來進(jìn)行分解，并據(jù)此來創(chuàng)建團(tuán)隊(duì)。
比如對于高復(fù)雜度的任務(wù)，應(yīng)該建立一個以解決這些問題為 KPI 的專門團(tuán)隊(duì)，只有這樣的團(tuán)隊(duì)才能真正解決這些復(fù)雜的問題。
有時候會覺得，團(tuán)隊(duì)無法滿足開發(fā)的需要，是因?yàn)槌蓡T的能力不行，因此重點(diǎn)對人進(jìn)行賦能，增加他的內(nèi)在認(rèn)知負(fù)載。但其實(shí)有可能是團(tuán)隊(duì)結(jié)構(gòu)不合理，導(dǎo)致外在認(rèn)知負(fù)載過高。
Matthew Skelton 和 Manuel Pais 提出的團(tuán)隊(duì)拓?fù)鋵W(xué)（Team Topologies），就從這一角度對團(tuán)隊(duì)的組成和溝通模式進(jìn)行了大膽的嘗試。
二、團(tuán)隊(duì)拓?fù)漕愋?/h3>
他們提出了四種團(tuán)隊(duì)拓?fù)漕愋秃腿N交互模式。
-
第一種團(tuán)隊(duì)拓?fù)漕愋褪?strong>業(yè)務(wù)流團(tuán)隊(duì)（Stream-aligned Team），這里的“流”是指與
業(yè)務(wù)、領(lǐng)域或組織能力對齊的工作流程，業(yè)務(wù)流團(tuán)隊(duì)的工作有可能是一個產(chǎn)品或服務(wù)，也可能是一組特性、一個用戶旅程或一個用戶畫像。他們有能力快速、安全、獨(dú)立地構(gòu)建和交付用戶價值，而不用將部分工作交給其他團(tuán)隊(duì)。業(yè)務(wù)流團(tuán)隊(duì)是最主要的團(tuán)隊(duì)拓?fù)漕愋?，你可以將它理解為特性團(tuán)隊(duì)，或 Spotify 中的小隊(duì)，負(fù)責(zé)核心的價值交付。其他團(tuán)隊(duì)拓?fù)漕愋投际菫榱藴p輕業(yè)務(wù)流團(tuán)隊(duì)的負(fù)擔(dān)，降低他們的認(rèn)知負(fù)載而演進(jìn)出來的。比如，一個遺留系統(tǒng)想做微服務(wù)拆分，這是一項(xiàng)高難度的架構(gòu)遷移工作。業(yè)務(wù)流團(tuán)隊(duì)的成員每天處于高強(qiáng)度的交付壓力之下，根本沒有時間去調(diào)研、探索和學(xué)習(xí)。 -
這時候就誕生了第二種團(tuán)隊(duì)拓?fù)漕愋汀?strong>賦能團(tuán)隊(duì)（Enabling Team），它由特定
技術(shù)領(lǐng)域或產(chǎn)品領(lǐng)域的專家組成。賦能團(tuán)隊(duì)里的這些專家可以開展調(diào)研，嘗試不同的方案，尋找最佳實(shí)踐。然后對業(yè)務(wù)流團(tuán)隊(duì)進(jìn)行賦能，使他們不需要太多的努力，就能具備拆分微服務(wù)的能力，大大降低了認(rèn)知負(fù)載。賦能團(tuán)隊(duì)并不會親力親為地解決具體技術(shù)問題，這些問題還是由業(yè)務(wù)流團(tuán)隊(duì)來處理。賦能團(tuán)隊(duì)主要關(guān)注的是，對組織中的所有業(yè)務(wù)流團(tuán)隊(duì)能力的提升。相比 Spotify 模型中的分會和協(xié)會等松散的技術(shù)社區(qū)，賦能團(tuán)隊(duì)的工作內(nèi)容更聚焦，可以有效地幫助業(yè)務(wù)流團(tuán)隊(duì)，解決某方面能力欠缺的問題。不知道你的項(xiàng)目中是否有這樣的模塊，它的業(yè)務(wù)邏輯十分復(fù)雜，要想熟悉和理解需要極高的認(rèn)知負(fù)載。比如視頻的編解碼、復(fù)雜的數(shù)學(xué)模型、語音識別算法等等。 -
這時通常的解決辦法是，由該
領(lǐng)域的專家組成一個固定的團(tuán)隊(duì)，來維護(hù)這個復(fù)雜的模塊。這種團(tuán)隊(duì)拓?fù)漕愋?，就叫?strong>復(fù)雜子系統(tǒng)團(tuán)隊(duì)（Complicated-Subsystem Team）。在遺留系統(tǒng)中，如果有些復(fù)雜的計(jì)算位于存儲過程，轉(zhuǎn)換成 Java 十分困難，而且效率也不一定高。這時候可以考慮把它整體隔離出去，構(gòu)建一個復(fù)雜子系統(tǒng)，再相應(yīng)去組建一個復(fù)雜子系統(tǒng)團(tuán)隊(duì)，專門來維護(hù)它。團(tuán)隊(duì)自己可以決定是保持不變，還是將存儲過程慢慢演進(jìn)成代碼。
業(yè)務(wù)流團(tuán)隊(duì)在和復(fù)雜子系統(tǒng)交互時，只需要使用復(fù)雜子系統(tǒng)團(tuán)隊(duì)提供的 API，而不用費(fèi)力地去理解這個復(fù)雜模塊，同樣可以降低認(rèn)知負(fù)載。然而有的時候，業(yè)務(wù)流團(tuán)隊(duì)不止需要訪問復(fù)雜的業(yè)務(wù)模塊，還要和一些組織內(nèi)部的基礎(chǔ)設(shè)施打交道，比如 CI/CD 服務(wù)器、各種容器和中間件等。
- 比如一個剛剛做到持續(xù)構(gòu)建的遺留系統(tǒng)，很可能持續(xù)集成服務(wù)器并不穩(wěn)定，動不動就會掛掉，但業(yè)務(wù)流團(tuán)隊(duì)沒有精力去解決這些問題。
這時候你需要的是第四種團(tuán)隊(duì)拓?fù)漕愋汀?strong>平臺團(tuán)隊(duì)（Platform Team）。它們負(fù)責(zé)解決底層問題，讓業(yè)務(wù)流團(tuán)隊(duì)可以更專注于業(yè)務(wù)開發(fā)。
可以看到，團(tuán)隊(duì)拓?fù)涞某霭l(fā)點(diǎn)是團(tuán)隊(duì)的認(rèn)知負(fù)載，它所倡導(dǎo)的團(tuán)隊(duì)結(jié)構(gòu)是認(rèn)知負(fù)載最低的。它并沒有嘗試從不同的技術(shù)層面去解決團(tuán)隊(duì)的認(rèn)知負(fù)載問題，這個角度仍然是在跨職能的業(yè)務(wù)流團(tuán)隊(duì)內(nèi)部，通過不同的技術(shù)角色來解決的。因?yàn)闃I(yè)務(wù)流團(tuán)隊(duì)的成員雖然技術(shù)棧不同，但解決的都是價值流交付的問題。
團(tuán)隊(duì)拓?fù)浣⒘艘粋€更高層次的抽象，按照技術(shù)和業(yè)務(wù)不同的復(fù)雜度，以及不同的團(tuán)隊(duì)目標(biāo)來劃分團(tuán)隊(duì)結(jié)構(gòu)。
這是一種權(quán)衡。因?yàn)閷€人來說，認(rèn)知負(fù)載最低的一定是只從事自己最擅長的工作，也就是位于技術(shù)組件團(tuán)隊(duì)或職能團(tuán)隊(duì)中。但由于一個業(yè)務(wù)總是跨技術(shù)層級的，這就增加了溝通成本，導(dǎo)致了外在認(rèn)知負(fù)載的升高；
另一方面，特性團(tuán)隊(duì)雖然能很好地解決溝通問題，但不同層級的技術(shù)問題仍然會增加他們的認(rèn)知負(fù)載，使他們無法專注在業(yè)務(wù)交付上，身心俱疲。團(tuán)隊(duì)拓?fù)湔菑倪@個角度，引入了另外三種團(tuán)隊(duì)類型，來解決特性團(tuán)隊(duì)的各種問題。
三、團(tuán)隊(duì)交互模式
這些團(tuán)隊(duì)之間是如何交互的呢？
團(tuán)隊(duì)拓?fù)鋵W(xué)中給出了三種交互模式，分別是
- 協(xié)作
- 服務(wù)
- 促進(jìn)
協(xié)作（Collaboration）是指一個團(tuán)隊(duì)與另一個團(tuán)隊(duì)緊密合作。比如前面提到的，業(yè)務(wù)流團(tuán)隊(duì)通過 API 來訪問復(fù)雜子系統(tǒng)，當(dāng)新的需求需要復(fù)雜子系統(tǒng)提供新的功能時，業(yè)務(wù)流團(tuán)隊(duì)就需要和復(fù)雜子系統(tǒng)團(tuán)隊(duì)通力合作，來完成這個需求；再比如一個用戶登錄功能，也需要業(yè)務(wù)流團(tuán)隊(duì)和平臺團(tuán)隊(duì)的協(xié)作，業(yè)務(wù)流團(tuán)隊(duì)負(fù)責(zé)開發(fā)面向用戶的界面和相應(yīng)的后臺，平臺團(tuán)隊(duì)負(fù)責(zé)開發(fā)認(rèn)證與鑒權(quán)功能，或者與其他單點(diǎn)登錄系統(tǒng)集成。協(xié)作也會增加溝通成本，但這種成本是系統(tǒng)的復(fù)雜性所導(dǎo)致的，并不是像按技術(shù)分組那樣，是人為因素導(dǎo)致的。
服務(wù)（X-as-a-Service）是指使用或提供某種服務(wù)，而盡量減少協(xié)作。比如如果復(fù)雜子系統(tǒng)已經(jīng)提供了完成需求所用的 API，業(yè)務(wù)流團(tuán)隊(duì)就無需與復(fù)雜子系統(tǒng)團(tuán)隊(duì)協(xié)作；如果平臺團(tuán)隊(duì)已經(jīng)封裝好了用戶認(rèn)證和鑒權(quán)的所有功能，業(yè)務(wù)流團(tuán)隊(duì)也只需要“拿來主義”即可。由于 API 或服務(wù)開箱即用，業(yè)務(wù)流團(tuán)隊(duì)無需關(guān)注底層的實(shí)現(xiàn)細(xì)節(jié)，就可以快速地實(shí)現(xiàn)功能。
促進(jìn)（Facilitating）是指幫助其他團(tuán)隊(duì)清除障礙。這是賦能團(tuán)隊(duì)主要的交互模式，他們對外部團(tuán)隊(duì)提供支持和賦能，來提升他們的生產(chǎn)力和效率。
四、逆康威定律
適合遺留系統(tǒng)的團(tuán)隊(duì)結(jié)構(gòu)到底是什么樣的呢？
前面提到了康威定律，即 團(tuán)隊(duì)的結(jié)構(gòu)會影響到系統(tǒng)的架構(gòu)。
假如系統(tǒng)包含四個團(tuán)隊(duì)，每個團(tuán)隊(duì)都包含前端和后端開發(fā)，而僅有一個 DBA 負(fù)責(zé)數(shù)據(jù)庫變更。那么根據(jù)康威定律，得到的軟件架構(gòu)一定是，擁有四個獨(dú)立的應(yīng)用，包含各自獨(dú)立的用戶界面和服務(wù)端，而它們共享一個單體數(shù)據(jù)庫。
如果在保持團(tuán)隊(duì)結(jié)構(gòu)不變的情況下，企圖拆分?jǐn)?shù)據(jù)庫，一定是辦不到的。即使勉強(qiáng)拆分出來，也會很快腐化。
正確的做法應(yīng)該是，順應(yīng)康威定律，為每個團(tuán)隊(duì)配備一名 DBA，然后再拆分?jǐn)?shù)據(jù)庫。
每個應(yīng)用的數(shù)據(jù)庫由單獨(dú)的 DBA 去維護(hù)，才能保證它不會腐化。這種為得到理想的架構(gòu)而改變團(tuán)隊(duì)結(jié)構(gòu)的做法，叫做逆康威定律（Inverse Conway Maneuver）。
也就是說，想得到什么樣的架構(gòu)，就先把組織結(jié)構(gòu)調(diào)整成那個樣子，以此來推動組織變革。
在遺留系統(tǒng)中，需要根據(jù)自己的目標(biāo)架構(gòu)來調(diào)整組織結(jié)構(gòu)，同時參考特性團(tuán)隊(duì)、Spotify 模型和團(tuán)隊(duì)拓?fù)洹?/p>
康威定律不但會影響到架構(gòu)形態(tài)，還會影響到架構(gòu)師的技術(shù)決策。
很多架構(gòu)師在做方案時，總是期望一步到位，這樣會給原本簡單的方案帶來很多復(fù)雜度。
更合理的方式應(yīng)該是，先用簡單的方式 run 起來，盡早上線去交付價值，等發(fā)現(xiàn)問題再去修補(bǔ)和演進(jìn)。
這樣更符合增量演進(jìn)的原則，也更容易得到一個“剛剛好的架構(gòu)”。
而“一步到位”的想法則更容易導(dǎo)致過度設(shè)計(jì)。產(chǎn)生“一步到位”這種想法的根本原因是什么？
表面上，是架構(gòu)師在做設(shè)計(jì)的時候可能不會想到那么多，只是一種先入為主或者說習(xí)慣的想法，但實(shí)際上背后可能隱藏著康威定律。
如果有一個獨(dú)立的團(tuán)隊(duì)去維護(hù)一個服務(wù)，這個團(tuán)隊(duì)能有足夠的人力、有足夠的上下文去守護(hù)這個服務(wù)的架構(gòu)，就會更傾向于構(gòu)建一個可演進(jìn)的架構(gòu)。
但如果團(tuán)隊(duì)接下來有哪些人不確定，他們有沒有能力演進(jìn)同樣不確定，那么主觀上我們就會不自覺地傾向一步到位式的設(shè)計(jì)。因?yàn)槿绻F(xiàn)在不做，以后就可能沒機(jī)會了。如果是項(xiàng)目的負(fù)責(zé)人，希望能夠主動改變團(tuán)隊(duì)的結(jié)構(gòu)，以得到理想中的架構(gòu)，并且潛移默化地改變團(tuán)隊(duì)中的各項(xiàng)技術(shù)決策。
五、總結(jié)
一種全新的團(tuán)隊(duì)結(jié)構(gòu)模型——團(tuán)隊(duì)拓?fù)鋵W(xué)。
所以在它后面加了一個“學(xué)”字，是因?yàn)樗啾忍匦詧F(tuán)隊(duì)和 Spotify 模型，更接近一門學(xué)問。
它提出的團(tuán)隊(duì)認(rèn)知負(fù)載和團(tuán)隊(duì)優(yōu)先的理念，更是超前于這個時代。
組件團(tuán)隊(duì)、特性團(tuán)隊(duì)、Spotify 模型或團(tuán)隊(duì)拓?fù)?，它們并不是相互替換的關(guān)系，而是可以按需合并和剪裁的。
它們面向的問題域不同、目標(biāo)不同、出發(fā)點(diǎn)不同，因此不存在誰比誰高明的情況。
一張表格，總結(jié)幾種講過的團(tuán)隊(duì)類型，做個參考。
應(yīng)該根據(jù)自己團(tuán)隊(duì)的實(shí)際問題，找出合適的方案。
比如可以以特性團(tuán)隊(duì)為基礎(chǔ)，并為幾個特性團(tuán)隊(duì)配備平臺團(tuán)隊(duì)和賦能團(tuán)隊(duì)，這樣的幾個團(tuán)隊(duì)組成一個部落，同時也有跨團(tuán)隊(duì)的各種技術(shù)社區(qū)。比如很多組織的開發(fā)團(tuán)隊(duì)忙于需求開發(fā)，根本沒有時間思考流程改進(jìn)。
這時候想推動類似主干開發(fā)這類實(shí)踐，是很難有進(jìn)展的，因?yàn)樗枰芏嗯涮椎幕A(chǔ)設(shè)施，開發(fā)團(tuán)隊(duì)沒有時間去做這些。
業(yè)務(wù)部門也只要看到需求上線就行，根本不關(guān)心流程改進(jìn)，畢竟開發(fā)的痛點(diǎn)跟他們沒關(guān)系。業(yè)務(wù)方總是把開發(fā)團(tuán)隊(duì)當(dāng)成工具人，而不是合作者。
現(xiàn)在很多大廠開始組建工程效能部門，負(fù)責(zé)開發(fā)工具、優(yōu)化流程、改進(jìn)基礎(chǔ)設(shè)施，一定程度上解放了開發(fā)部門。
雖然很難說這種工程效能部門是屬于賦能團(tuán)隊(duì)還是平臺團(tuán)隊(duì)，但至少都是在解決業(yè)務(wù)流團(tuán)隊(duì)平時沒時間解決的痛點(diǎn)問題，為他們服務(wù)。
這就是一種非常有價值的探索。同時要記住的是，團(tuán)隊(duì)結(jié)構(gòu)也要不斷演進(jìn)。雖然以不變應(yīng)萬變很酷，但當(dāng)“應(yīng)付”不了的時候，還是應(yīng)當(dāng)“應(yīng)變”。文章來源：http://www.zghlxwxcb.cn/news/detail-742406.html
因?yàn)闃I(yè)務(wù)在變化，架構(gòu)自然需要跟著變化以支撐業(yè)務(wù)，那么根據(jù)逆康威定律，也要調(diào)整團(tuán)隊(duì)結(jié)構(gòu)，以支撐新的架構(gòu)。文章來源地址http://www.zghlxwxcb.cn/news/detail-742406.html
到了這里，關(guān)于Day967.團(tuán)隊(duì)拓?fù)鋵W(xué) -遺留系統(tǒng)現(xiàn)代化實(shí)戰(zhàn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
