比較示例
特性團(tuán)隊(duì)是長(zhǎng)期存在的柄沮，跨功能的审孽，跨組件的團(tuán)隊(duì)午阵，該團(tuán)隊(duì)可以一個(gè)接一個(gè)的完成許多端到端的客戶特性躺孝。
（該定義和圖片來(lái)自LeSS官網(wǎng)）
而組件團(tuán)隊(duì)則不同于特性團(tuán)隊(duì)，是一個(gè)聚焦于一個(gè)產(chǎn)品的特定組件或者領(lǐng)域的團(tuán)隊(duì)底桂，組件團(tuán)隊(duì)是分工協(xié)作的產(chǎn)物植袍。比如前端團(tuán)隊(duì)、后端團(tuán)隊(duì)籽懦；比如開(kāi)發(fā)團(tuán)隊(duì)于个、測(cè)試團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)等類似的劃分暮顺。如泰勒的科學(xué)管理中指出：“管理要解決的就是厅篓，如何在有限的時(shí)間里獲取最大程度的產(chǎn)出，也就是如何使勞動(dòng)生產(chǎn)率最大化的問(wèn)題捶码∮鸬”泰勒給出的其中一個(gè)方法就是勞動(dòng)分工，所以這里的勞動(dòng)生產(chǎn)率最大化本質(zhì)上是指的資源利用率最大化惫恼，組件團(tuán)隊(duì)就可以實(shí)現(xiàn)這種資源利用率的最大化乏苦。后來(lái)特性團(tuán)隊(duì)的出現(xiàn)則是精益敏捷所追求的價(jià)值流動(dòng)最大化而言的，兩者追求的目的并不矛盾尤筐，但是重點(diǎn)不同汇荐。
下圖是一個(gè)典型的特性團(tuán)隊(duì)和組件團(tuán)隊(duì)的對(duì)比示例：
特性團(tuán)隊(duì)：聚焦于端到端交付，按照一個(gè)個(gè)的功能來(lái)實(shí)現(xiàn)客戶價(jià)值盆繁，Scrum team就是一個(gè)典型的特性團(tuán)隊(duì)掀淘，team從product backlog中承諾需求，將其實(shí)現(xiàn)為可工作的軟件油昂，也就是價(jià)值增量革娄。對(duì)于特性團(tuán)隊(duì)來(lái)說(shuō)倾贰，組與組直接是松耦合的，如果在大規(guī)模的系統(tǒng)開(kāi)發(fā)中做不到團(tuán)隊(duì)間完全解耦合拦惋，那么使用類似Scrum over Scrums或者LeSS這樣的模式來(lái)擴(kuò)展匆浙，宗旨是盡量減少團(tuán)隊(duì)之間的依賴，減少團(tuán)隊(duì)間工作的切換厕妖，比如從一個(gè)團(tuán)隊(duì)到另外一個(gè)團(tuán)隊(duì)的任務(wù)移交首尼，否則會(huì)增加溝通的成本，增加信息的流失言秸。減少重復(fù)的交流软能，比如使用Scrum里不同形式的會(huì)議，如每日站會(huì)举畸、計(jì)劃會(huì)等做充分的及時(shí)的溝通查排。按照特性團(tuán)隊(duì)來(lái)劃分組織的目的在于更早的交付，更早的獲得反饋抄沮，更快的適應(yīng)跋核。但其依然有自己的缺點(diǎn)：比如技術(shù)上重復(fù)造輪子，代碼重復(fù)叛买，架構(gòu)容易不一致了罪。
組件團(tuán)隊(duì)：聚焦組件的實(shí)施，無(wú)法直接交付功能聪全，團(tuán)隊(duì)之間有比較強(qiáng)的依賴。依賴的增加則需要集成工作辅辩，集成帶來(lái)的風(fēng)險(xiǎn)減少了可預(yù)測(cè)性难礼。從問(wèn)題域（需求）到實(shí)現(xiàn)域（任務(wù)）的分解，特性團(tuán)隊(duì)可以直接映射過(guò)來(lái)玫锋，但是組件團(tuán)隊(duì)還需要多一層架構(gòu)上的分解蛾茉，也就是從需求先到組件才能再到任務(wù)，團(tuán)隊(duì)成員很容易缺失業(yè)務(wù)視野撩鹿，只是完成任務(wù)谦炬。對(duì)于業(yè)務(wù)的不聚焦，可能會(huì)導(dǎo)致開(kāi)發(fā)了業(yè)務(wù)不需要的功能出來(lái)节沦，而這是最大的浪費(fèi)键思。當(dāng)然也有其優(yōu)勢(shì)，就是增強(qiáng)了架構(gòu)設(shè)計(jì)和代碼的一致性甫贯。
規(guī)暮鹆郏化下兩個(gè)團(tuán)隊(duì)的比較和示例
這里的規(guī)模化并不是僅僅指的團(tuán)隊(duì)的數(shù)量很多叫搁，而是互相依賴的團(tuán)隊(duì)數(shù)量很多赔桌，也就是一起工作在一個(gè)產(chǎn)品上的團(tuán)隊(duì)是規(guī)墓┭祝化的情況。在這種規(guī)募驳常化的時(shí)候如何考慮特性團(tuán)隊(duì)和組件團(tuán)隊(duì)呢音诫？在規(guī)模化的情況下雪位，如果都是特性團(tuán)隊(duì)竭钝，可能存在的一種情況就是一個(gè)單一特性需要跨的組件太多了，該怎么處理茧泪？LeSS中對(duì)此有所說(shuō)明蜓氨。一個(gè)選擇是團(tuán)隊(duì)是一個(gè)整體，但并不是每個(gè)人都要熟知整個(gè)系統(tǒng)队伟，團(tuán)隊(duì)里面的人依然有所分工和聚焦穴吹；二是feature也不會(huì)隨機(jī)分給隨便一個(gè)團(tuán)隊(duì)，而是考慮團(tuán)隊(duì)所擁有的知識(shí)和能力來(lái)分feature嗜侮。這兩個(gè)方法可以部分緩解這個(gè)問(wèn)題港令。如果還是會(huì)出現(xiàn)瓶頸，那么就去學(xué)習(xí)锈颗。LeSS這個(gè)思想的出發(fā)點(diǎn)就是特性團(tuán)隊(duì)可以平衡專業(yè)性和靈活性顷霹，并促進(jìn)學(xué)習(xí)型組織的進(jìn)化。
SAFe里認(rèn)可組件團(tuán)隊(duì)也是敏捷團(tuán)隊(duì)的一種击吱，在這種組織劃分方式下淋淀，對(duì)于組件內(nèi)容的修改主要是來(lái)自于組件團(tuán)隊(duì)，集體代碼所有制在該團(tuán)隊(duì)中實(shí)施覆醇，其他團(tuán)隊(duì)如果需要修改該組件朵纷，則需要提前跟owner溝通。當(dāng)然SAFe并不否認(rèn)feature team永脓，而是feature team和component team的混合袍辞，并且是傾向于feature team的。
一個(gè)具體實(shí)踐的例子：諾基亞的移動(dòng)網(wǎng)絡(luò)事業(yè)部中的探索常摧。因?yàn)槭请娦偶?jí)產(chǎn)品搅吁，一個(gè)特性往往會(huì)跨的組件比較多，所以諾基亞內(nèi)部落午，有一個(gè)domain owner的概念谎懦，每個(gè)domain可以理解為一個(gè)組件，給這個(gè)組件會(huì)制定一個(gè)domain owner溃斋，雖然owner的帽子會(huì)放到一個(gè)人頭上党瓮，但是本質(zhì)上意味著這個(gè)domain的owner是這個(gè)人所在的scrum team（或者多個(gè)team），這個(gè)domain的架構(gòu)設(shè)計(jì)來(lái)自于這個(gè)owner team盐类，其他團(tuán)隊(duì)的改動(dòng)一開(kāi)始不被允許寞奸，需要提交給這個(gè)團(tuán)隊(duì)呛谜；后來(lái)因?yàn)樾屎懿睿疫@跟敏捷的原則也不一致枪萄，遭到比較強(qiáng)的反對(duì)隐岛，改成其他團(tuán)隊(duì)的改動(dòng)可以由自己來(lái)做，但是必須要經(jīng)過(guò)owner team的review瓷翻，只有得到owner的approve聚凹，代碼才可以提交；組件的一致性齐帚、責(zé)任感和質(zhì)量都相對(duì)有比較好的保證妒牙，但是效率有所犧牲。需要指出的是這些在諾基亞的實(shí)踐都是在LeSS框架下進(jìn)行的对妄，但是跟SAFe下的描述很相似湘今。也有過(guò)不需要owner approve就可以提交代碼的時(shí)候，但是domain owner的概念一直都在剪菱，這是一個(gè)通過(guò)回顧不停探索找到適合組織的模式的過(guò)程摩瞎，跟框架無(wú)關(guān)，好用就行孝常。
混合模式
混合模式：某些產(chǎn)品中或者組織里旗们，有的情況下需要專門的團(tuán)隊(duì)負(fù)責(zé)搭建基礎(chǔ)設(shè)施，LeSS里的說(shuō)法是沒(méi)有這樣的必要构灸，可以把傳統(tǒng)組件團(tuán)隊(duì)需要完成的任務(wù)放到backlog里上渴，然后feature team領(lǐng)走完成即可。但這個(gè)就跟企業(yè)是不是需要IT部門的討論一樣喜颁。自己的觀點(diǎn)是沒(méi)必要這么絕對(duì)稠氮，要看組織和系統(tǒng)的情況。在國(guó)家的十四五規(guī)劃里面洛巢，對(duì)于國(guó)企央企提出了更高的數(shù)字化要求，在這樣的企業(yè)中次兆，最起碼目前看到是對(duì)于基礎(chǔ)設(shè)施的建設(shè)稿茉，專門的組件團(tuán)隊(duì)感覺(jué)還是效率更高一些，比如基礎(chǔ)平臺(tái)建設(shè)芥炭，統(tǒng)一工具建設(shè)漓库，統(tǒng)一運(yùn)維，主數(shù)據(jù)建設(shè)园蝠。隨著基礎(chǔ)設(shè)施的成熟渺蒿，或許可以走到更多特性團(tuán)隊(duì)的情況”胙Γ康威定律告訴我們茂装，產(chǎn)品（技術(shù)架構(gòu)）是組織結(jié)構(gòu)的縮影怠蹂，在傳統(tǒng)企業(yè)里面，組織的劃分和層級(jí)制相對(duì)固定少态，改變組織結(jié)構(gòu)的難度可能相對(duì)比較大城侧，相應(yīng)的，組件團(tuán)隊(duì)就成了不得不的選擇（可能沒(méi)那么好）彼妻。
上圖是Spotify中的一個(gè)組織結(jié)構(gòu)圖嫌佑，Squad是一個(gè)feature team，而chapter就是一個(gè)組件team侨歉。這是一個(gè)虛實(shí)結(jié)合屋摇，組件和特性團(tuán)隊(duì)混合使用的比較好的一個(gè)例子。
（圖來(lái)自“Adapt框架如何解決金融組織研發(fā)交付七大痛點(diǎn)”）
Adapt 的核心之一是虛擬部落制幽邓，其脫胎于 Spotify 的部落制炮温。虛擬部落化組織打造對(duì)齊業(yè)務(wù)領(lǐng)域的縱向交付單元，打破原有部門墻的鴻溝颊艳，同時(shí)保留了專業(yè)職能的橫向?qū)嶓w線茅特，側(cè)重提升組織人才專業(yè)化能力。從上圖可以看出來(lái)跟Spotify類似棋枕，Adapt也保留了特性和組件混合的使用白修。
最后：如何選擇團(tuán)隊(duì)類型
上圖是SAFe中的一個(gè)圖，說(shuō)明在越多團(tuán)隊(duì)公用重斑，技術(shù)的專業(yè)性越強(qiáng)的場(chǎng)景下兵睛，或許越應(yīng)該選擇組件團(tuán)隊(duì)，反之則應(yīng)該選擇特性團(tuán)隊(duì)窥浪。比如涉及到通用的算法或者其他非常深的理論基礎(chǔ)的組件祖很，選擇特性團(tuán)隊(duì)未必不是一個(gè)好的決定。spotify里有個(gè)專門的運(yùn)維團(tuán)隊(duì)也有像這樣的組件團(tuán)隊(duì)漾脂，這個(gè)運(yùn)維團(tuán)隊(duì)并不是負(fù)責(zé)具體哪個(gè)團(tuán)的運(yùn)維工作假颇，而是負(fù)責(zé)各個(gè)團(tuán)隊(duì)運(yùn)維工作的賦能。
在開(kāi)發(fā)新的產(chǎn)品骨稿、業(yè)務(wù)迅速增長(zhǎng)笨鸡，進(jìn)入新的市場(chǎng)、用戶數(shù)快速增長(zhǎng)坦冠、創(chuàng)業(yè)（包括內(nèi)部創(chuàng)業(yè)）這些場(chǎng)景之下形耗，更適合特性團(tuán)隊(duì)，因?yàn)槟芨玫膽?yīng)對(duì)不確定性辙浑。
但是在產(chǎn)品穩(wěn)定激涤、進(jìn)入成熟期的時(shí)候或許組件團(tuán)隊(duì)是一個(gè)好的選擇。因?yàn)榭梢詼p少成本判呕，比如維護(hù)團(tuán)隊(duì)倦踢。
同時(shí)Feature team也有一定的門檻或者說(shuō)是要求送滞，比如集體代碼所有制，因?yàn)椴煌膱F(tuán)隊(duì)都會(huì)修改同一個(gè)組件的任意代碼硼一。對(duì)于成員的開(kāi)放性累澡、學(xué)習(xí)能力和意愿、代碼質(zhì)量般贼、重構(gòu)技能等都有所要求愧哟。
所以，是feature team還是component team哼蛆，安于當(dāng)下還是著眼未來(lái)蕊梧，豐儉由人吧，不過(guò)我選feature team腮介！
參考文件：
https://www.scaledagileframework.com/features-and-components/
