作者介紹
常紅平，IT職場老兵，在做過除用戶體驗設計師外的所有軟件研發團隊中的角色後，於10年前開始專注於管理。愛技術、愛敏捷、愛讀書、愛分享。現在IBM CIO中國實驗室作爲IBM全球軟件和雲服務銷售系統負責人，領導IBM年交易量數百億美金的核心繫統的研發和運維工作。近年來，他還帶領跨國團隊成功實施了一系列敏捷轉型、技術革新、和組織文化轉型。
隨着數字化時代全面到來，組織的敏捷轉型已經成爲必然。
2017年中國開發者調查報告顯示，在彼時已有45.6%的開發者聲稱採用了敏捷開發模式。但如果詳細瞭解這些開發團隊，事實上很多還是在用新瓶裝舊酒，甚至只是把原有的流程換個新名詞而已。
時至今日，國內除一些互聯網大廠和頂尖外企能夠做到極致的敏捷外，大量的傳統研發組織還處在敏捷轉型的進程中，而小型初創公司也仍需要將原來粗放的研發管理轉向精細化、規模化。
比如最近好幾個業界同行在諮詢我敏捷轉型應該怎麼組建團隊：
- 我團隊的項目需求特別動態，人又分佈在不同部門。可不可以每當有項目來的時候我跨部門抓合適的人組成臨時項目組？
- 我們公司有一些老舊系統，還有一些創新項目。我應該把新老項目的人都放在一個團隊，還是分開？
- 我們公司跟國外團隊一起做項目。我們共享一套代碼庫，經常一有衝突就要跟老外開會熬半宿或者等一天，怎麼破？
僅關於敏捷組織架構的問題就包羅萬象，所以我想還是有必要把這個話題詳細聊聊。畢竟一個合適的敏捷組織架構是組織敏捷轉型成功的最基本條件之一。
會者不難，在一個高效敏捷組織中司空見慣的事情，放到非敏捷組織中會被認爲不可思議。今天就先聊聊一個極致的敏捷組織或者敏捷轉型成功後一個組織大概會長成什麼樣子。
當然敏捷的組織架構只是敏捷實施成功的因素之一。但因篇幅有限，本文暫不涉及敏捷流程、實踐、文化等部分。
簡單起見，我們從小往大講。假設你現在加入了一家初創公司，全權負責公司的IT部分。你擁有了一個響亮的頭銜叫做研發總監，但手下其實也就有十來個人，你要怎麼組建團隊呢？
一、初創研發團隊
你最先想到的一定是全功能，也就是團隊中要具備各種必需的角色：業務分析、開發、測試、運維，等等。無論大小，一個非全功能團隊基本無法做到端到端的從需求分析到系統上線到運維的工作。
再有就是角色之間要比例協調。全棧工程師當然好，但是在你的小初創公司裏養不起樣樣精通的牛人，全棧只是因爲缺錢不得已而爲之的選擇。那隻好讓大家儘量一專多能，每個人有專長，必要時能互相幫個忙。
此時你還沒有必要拆分團隊。團隊從上到下、從業務到技術都是你一把抓。你只好工作996，還勉強能應付。
二、小型研發團隊
公司業務發展還不錯，你的團隊要擴張了。這對你來說是個happy problem，你一個人肯定管不過來了，必須要有人幫你。於是你把一個你一手培養起來的得力干將提拔起來做一線經理。但因爲研發團隊就你們兩個經理，於是你倆決定各分管一攤兒，但你總體負責就好。
既然是各分管一攤兒，兩個部門最好都能獨立運行，之間的交互除了必須的系統集成等必要的溝通外，互相依賴越少越好。所以你們決定在每個部門都複製全功能團隊的做法。
但怎麼把原來一個大團隊拆成兩個小部門呢？你倆決定還是按功能模塊拆。這樣兩個部門之間的耦合最小。什麼？一個部門開發，一個部門測試？馬上2020年了，難道你們還在用瀑布式開發嗎？對不起，如果是的話，這個故事我根本編不下去了，你的小公司根本活不到A輪好嗎？
部門拆分造成了一段時間的混亂。職責不清、互相指責、踢皮球的事時有發生。原來的單體軟件架構之前本來運行得好好的，因爲模塊間的嚴重依賴關係更加劇了職責劃分的難度。幾次嚴重的發佈失敗和系統宕機後，你倆一邊改進軟件架構，一邊梳理研發流程，終於在部門職責劃分上達成下面幾個共識：
1、面向資產：資產可以是模塊、應用程序、服務、平臺等等。每個部門所負責的資產範圍都要清晰，避免扯皮。如果不面向資產而是面向跨資產的業務功能、特殊技能等等劃分團隊，會造成大量跨部門的溝通。比如當兩個部門在基於同一個模塊開發時，會有大量代碼耦合甚至衝突的問題。這時必須要在技術層面進行模塊拆分和解耦。而當一個部門基於多個資產開發時，因爲要學的東西太多，新人很難培養起來，所以當出現問題或者研發進度受阻時，團隊成員之間無法互相支持。
2、端到端負責：首先是需求分析、開發、測試、部署的端到端，自己部門的事情自己從頭到尾負責，儘量不求助於其他部門。其次是開發和維護的端到端。誰開發的功能，誰就應該維護。誰出的bug誰負責。這樣保證各部門內溝通更加內聚，也跟其他部門降低耦合。
3、穩定的：各部門成員應該是相對穩定的，不經常被調動，以保證團隊不總是跟新成員磨合。部門中每增加或減少一個人，團隊都要經歷一整輪的組建期、激盪期、規範期、和執行期（Forming, storming, norming and performing），這對團隊的發佈速率是有很大負面影響的。當然出於團隊成員職業發展的需要，應該給團隊成員定期輪崗的機會。但這種輪崗不應過於頻繁。
4、專注的：各個部門應該有清晰的工作範圍，並專注在這個範圍內工作，而不是總要求去做很多團隊職責範圍之外的“雜事“，即使它很重要很緊急。這樣既能保證團隊的工作效率，又能培養團隊在某項或某類任務上的專長。你們捋了一下團隊經常抱怨的“雜事”後，發現其實很多事情在更高層面看也很重要，所以你們決定把這些事情劃分到相關部門的正式工作範圍內，並儘量在項目計劃階段考慮進去。
這樣的共識達成之後，部門間合作順暢了不少。
但隨着公司的發展，每個部門的人也越來越多，你又覺得有些管不過來了。有了上次拆分的成功經驗，你們決定嘗試把這個做法也應用到部門內部——把部門內成員再劃分成幾個小團隊。畢竟長期996之後你身體也開始有些吃不消，你希望團隊有些事自己能自組織地做起來，而不是都依靠經理。
經過一番調整嘗試，你梳理了部門內各個小團隊的文化和規模，最後又得出幾個關於小團隊的最佳實踐：
1、小的：你發現5到9個人的小團隊規模是比較合適的，因爲小團隊成員之間的溝通基本靠喊。雖然面對面溝通效率很高，但因爲這是所有人對所有人的廣播式、全渠道溝通，當團隊變大時，溝通成本會呈指數級提高，造成效率急劇降低。而當團隊太小時，保證全功能又比較困難。當然在某些特殊情況下，把團隊控制在5-9個人可能有實際困難，但是4-12人是底線了，再多再少都不好了。
2、每個隊員爲整體團隊負責：這個團隊文化你在團隊擴張之前就一直在強調了。大家都是兄弟，出了事自然應該一起扛。但是在團隊擴張之後不知爲何這個文化就慢慢沒有了，是因爲新人太多衝淡了原來的文化？後來你才知道並不是。你悟出了組織架構是組織文化的基礎。擴張每個團隊那麼大，職責不清楚，即使大家想爲整體團隊負責，也有心無力。當團隊變小、份內的職責變清晰後，大家才更容易做所謂份外的事情，整體團隊才更容易實現。
這樣在部門內拆分出小團隊後，即便每個小團隊都不再設小隊長的職務，但因爲他們可以相當程度的自組織，你們兩個部門經理一人帶2-3個小團隊感覺輕鬆了許多。既然日常研發管理方面壓力小多了，你倆也可以專注在部門發展，人才培養、目標管理、客戶關係等更重要的事情上了。
好了，現在你的小型團隊終於可以比較高效的運轉了。你突然發現你的每個小團隊自然演進的結果居然和業界著名敏捷公司Spotify組織架構中的小分隊（Squad）模式很像：
圖片中部分內容源於spotify.com
研發效率上去了，公司業務再次爆發式增長，你倆的happy problem又來了，團隊規模要再擴張一倍。怎麼辦呢？
三、中型研發團隊
你倆決定複製之前成功經驗。部門既然可以一生二，就可以二生四，將來四生八，實現傳說中的指數級增長。
但是好像事情並沒那麼簡單。現在是4個研發經理了，團隊也快漲到100號人了。每個經理的日程表都被排得滿滿的。原來兩個經理有事情商量插空就可以做，但現在必須提前好久約大家時間開會。整個團隊項目計劃時就更痛苦了。即使各個部門間耦合度已經很低了，但完全沒有是不可能的。既然有耦合依賴關係就需要協調工作，但有那麼多團隊要協調起來導致會議又多又長、還低效。研發人員寫代碼的時間被嚴重擠佔了。
於是在又一次長達數個小時的管理層會議後，你們總算想到了一個解決方案。能不能在小團隊層面做一些聚合，或者在整個研發組織層面做更高層次的拆分呢？
說幹就幹。你們把現有的小分隊都拿出來重新分了幾個大組，每個大組都像小分隊一樣遵從高內聚、低耦合、全功能的原則來劃分。每個大組負責一個大的或者一組緊密相關的資產，並且能獨立完成所負責的資產的端到端的研發工作。每個大組之間的耦合儘量小，所有事務都儘量在大組之內完成，儘量避免跨大組的溝通。
每個大組內的幾位一線經理中會選出一個總負責人，作爲各大組間的溝通接口和大組內事務的總協調員，由大組內最資深的經理來兼任，你自己作爲資深經理之一也開始兼任大組負責人。
上面的組織變革自然又少不了一番軟件架構上的調整，系統拆分、解耦、等等。畢竟技術債是要及時還的，留多了到必須連本帶利還的時候恐怕就想還也還不起了。
好了，改造完之後，現在整個研發組織的溝通被拆分成了大組之間的溝通。成本一下子就降下來了。原來隨時可以開的管理層碰頭會終於在大組內又想開就能開了。團隊的各種溝通協調在大組內也容易做得多。大家終於又可以把時間用在愉快地擼代碼上，而不是冗長的會議上了。
各個大組都是以各個大業務模塊劃分的，所以根據各模塊所需要的人數不同，各大組的人數也不盡相同。這沒關係。但你觀察發現，一般一個大組最好控制在50人以內，或者是包含2-5個小分隊。當人數超過這個之後，大組內小分隊間的溝通成本會急劇升高。
大組內個小分隊間的溝通還是挺多的，畢竟他們所負責的資產都緊密相關。這樣協調工作是少不了的。原來這都是部門經理一把抓，但是組織大了，系統複雜了之後經理就必須放權讓員工負責了。託從大公司高薪挖來的HR小姐姐的福，公司的管理和技術崗位的雙線職業發展路線也弄清晰了，是時候在組織內培養一些專職技術人才了。
本來各個部門甚至小團隊都有架構師、業務分析師等，現在基於大組內各小分隊間協調工作的需要，你開始設立總架構師、總業務分析師等等。他們的職責範圍在大組內不但是跨小分隊的，也是跨部門的。當然你還有一些角色像用戶體驗設計師、系統管理員等等，他們也是在大組內被小分隊共享的。
中型團隊的組織架構終於組建差不多了。你突然想起應該參考下Spotify的組織架構圖，你驚喜地發現你們所構建的大組很像Spotify中的部落（Tribe）。你自己所兼職扮演的角色叫做部落帶頭人。
圖片中部分內容源於spotify.com
但部落帶頭人是個兼職角色，你除了要把自己的各個小分隊帶好外，部落內事務要協調，部落外溝通也要做。你發現自己連996都快搞不定了，簡直在向007發展。
你又發現部落內的關鍵角色，像總架構師，總業務分析師等等也跟你一樣忙得焦頭爛額。更可怕的是，除了他們，其他人好像並沒有那麼忙。
在公司強制規定的996的上班時間裏，很多人工作根本不飽滿，你甚至發現有員工在邊工作邊摸魚了！與其這樣，大家都提高工作效率把工作時間改成正常965不好嗎？
你知道這些問題不解決，別提公司進一步發展壯大、上市、出海，就連生存都有危險了。
到底根源在哪裏，怎麼邁過這個坎呢？再大型的組織怎麼搞，傳統組織怎麼辦？
四、突破瓶頸
到底問題在哪裏呢？自己漏掉了什麼重要的細節嗎？你回過頭重新查看Spotify的組織架構圖，赫然發現自己確實漏掉了一個細節—部落帶頭人應該是輪值的。
圖片中部分內容源於spotify.com
之前怎麼沒想到呢？輪值最不濟可以讓自己隔段時間休息下啊。你有點兒不懷好意地笑了。當然你猜輪值的主要目的是分享轉播知識和技能，培養後備人才。那除了部落帶頭人，是不是其他關鍵角色也應該輪值呢？試試就知道。
於是你力排衆議開始執行輪值制度——所有部落內關鍵角色必須定期輪值，保證任何關鍵角色必須有備份。關鍵角色既包括幾位部落帶頭人（包括你本人），也包括部落中的關鍵共享角色。輪換週期爲半年到一年不等。
輪值的事剛開始做起來時困難重重，但你知道暫時的困難是爲了整個組的健康發展。HR小姐姐得知你的決定，也跑來給你點贊，說輪值制度是培養人才的重要實踐之一，她主動提出要向全公司推廣。
通過定期輪值制度，經過一段時間的陣痛後，組織內的瓶頸和單點故障終於慢慢消除了。原來分散在各個關鍵人物頭腦中的知識被強制地文檔化和分享。通過輪值，你發現其實組織中還有很多有能力的人才，只不過在沒有輪值之前他們根本沒有機會表現出來。
後來你才知道，這些有能力的人才裏有人曾經因爲遇到職業天花板悄悄地計劃過離職，但是因爲輪值制度讓他們看到了希望，學到了新東西，他們最終選擇留了下來。
那些原本是瓶頸和潛在單點故障員工，並沒有因爲自己變得不那麼重要了而沮喪。相反他們非常高興。他們的工作生活變得平衡了，而且仍然有機會展現自己的能力。當他們有機會向上發展時，他們的經理不會因爲團隊對他們的過分依賴而不敢放手，反而會幫他們贏得機會，哪怕是部門之外的。這不是傳說中的服務型領導嗎？
通過輪值，組織中變得人才濟濟。你發現那些關鍵總控角色慢慢變得不再需要了。於是無論是總架構師還是總業務分析師，你開始嘗試讓他們迴歸到小分隊，這樣其實連輪值都不需要了。大家在需要討論跨小分隊架構或業務需求時聚到一起共同決定下就好。
有意思的是，你發現雖然輪崗後關鍵人才迴歸了到了基層小分隊，但真正的人才其實有沒有那個頭銜都會發光的。老外管這個叫Leadership without position power。大家雖然都是平級，但是真正的人才不需要級別比別人高就能展現影響力，大家也很願意聽他/她的意見。這樣的人才走到哪裏都是Thought Leader——思想領袖。你也發現自己主導了這麼多改進後，雖然仍然是一線經理中的一員，你也變成了一線經理中的Thought Leader。你知道你離晉升應該不遠了，如果公司能繼續發展，你自然就是那下一個被任命的人。
五、大型研發團隊
機會總是會留給有準備的人。而且對於有準備的人，機會永遠不缺。現在它就來了。因爲研發團隊支持業務快速發展，公司業務蒸蒸日上，現在研發團隊規模再次擴張，真的實現了指數級增長。
你名片上“研發總監”的頭銜雖然沒有變，但是你已經從一線經理晉升爲二線，開始管理多個部門了。
你發現團隊越大，團隊間自組織溝通就變得更重要。但是這次你學聰明瞭，與其每次都自己摸索踩坑，不如先看看業界最佳實踐是什麼。翻開Spotify的組織架構圖，你發現裏面果然有這樣的正式虛擬組織。它叫做行會（Chapter）。
你看到行會一般是一個部落內部相同角色組成的虛擬組織。它的組成可以是爲了項目需要，也可以是爲了職業發展或興趣。你立刻想到各個小分隊中的架構師經常聚在一起討論整個部落級別的架構；各個小分隊中的業務分析員也經常聚在一起討論跨小分隊的需求。這不就是事實上的架構師行會和業務分析師行會嘛？！
於是你鼓勵小分隊中的所有角色都建立自己的行會。開發人員組成了開發者行會，測試人員組成了測試者行會。這些行會都自己行動起來，制定代碼規範、測試覆蓋率提升計劃、學習新語言、新技術等等，搞得熱火朝天。
行會是部落內部的，跨部落的虛擬組織也有，在Spotify裏叫公會（Guild）。公會比行會更加鬆散，多是一些興趣小組，當然必要時也可以是臨時的項目委員會。畢竟跨部落的耦合度再低也是有的。
圖片中部分內容源於spotify.com
一開始時的行會和公會還是你要求員工組建的，後來大家氣氛活躍起來了，就開始自己組織行會和公會了。大部分行會或公會自己都運行得很好，但也有少數不好的就逐漸自生自滅了。
你觀察發現，那些運行不好的行會和公會大部分都沒有很清晰的目標。於是你要求無論是你親自任命的還是員工自行組建的行會和公會，都必須要有明確的使命和目標，並且這些目標要和整個組織的目標保持一致。你會對重點的行會和公會保持關注，並在必要時提供指導和幫助。但你不會干涉行會和公會的自組織運行，包括行會和公會負責人的任命和輪換，你知道你要做好的是服務型領導。
你開始悟出作爲管理者其實只要幫團隊搭建一個良好的環境和平臺，爲他們指明方向，然後在必要的時候助推一下，團隊可以自組織運行得很好。
Spotify的組織架構中還要求，一線經理應該是行會的帶頭人而不是小分隊帶頭人擔任。但這對團隊的自組織能力的要求極高。這要求每個小分隊都能完全自組織地端到端地完成從需求分析到發佈的工作，而不需要小分隊有個帶頭人協調解決問題。你認真地評估了下自己團隊的自組織成熟度，離完全自組織還有一段距離。所以你決定暫時還是讓一線經理端到端地負責各個小分隊。但你知道培養團隊自組織的道路還是要持續走下去。
六、跨國研發團隊
公司終於在納斯達克上市，業務成功出海，要在國外也建立研發團隊以支持當地業務了。
於是你的團隊中開始有外國團隊了。你知道你應該遵循的團隊組隊原則仍然是高內聚、低耦合、全功能。因爲時差的原因，跨國團隊合作溝通自然沒有本地團隊順暢，所以你儘量讓每個部落都各自集中在一地。如果實在因爲特殊原因不能在一地，至少是應該在一個時區、或者使用同一種語言。
有一個特例是支持型的團隊，比如客戶支持、平臺運維支持等。因爲要提供跨時區7乘24小時的服務，他們就必須要零散地分佈在不同的時區。這樣的成員至少應該和部落中某個小分隊在一起，以便很容易地在部落間共享知識。
你在公司挑選的重點國家都建立了研發中心。你自己也從二線研發總監晉升到管理多個研發總監的全球研發副總裁。你努力保證組織的扁平性，每個研發總監大概有10個左右的一線經理向他們彙報，你自己有10個左右的研發總監向你彙報。你知道扁平的組織架構是服務型領導的組織架構基礎。當某個一線或二線經理所管理的人數太多或太少時，你就把他們進行拆分或合併，保證他們所負責的業務量和團隊規模是類似的。
你把高內聚、低耦合、全功能的組隊原則活學活用後，驚奇地發現你的研發組織架構居然和幾何學中的分形暗暗相合。
把你的組織放大分成數個部分後，每一部分都（至少近似地）是整體組織縮小後的形狀。就像一顆大樹拆分成枝杈，再拆分成樹葉、再拆分成葉子上的脈絡，每次拆分後的形狀都和整個大樹的形狀相似。你的每個研發總監的組織架構和你的大組織架構也是類似的。你知道你即使以後做到高級執行副總裁去管理整個跨國公司的研發組織，它的架構也應該大致長成這個樣子。
七、傳統組織怎麼辦？
故事講完了。故事中的主人公雖然是虛構的，但他/她所構建的組織架構在現實中確是真實存在且高效運轉的。如果你所在的公司恰好正經歷故事中從小到大的擴張，也許你可以借鑑一下其中的團隊組建方法。
但是，現實中的大多數問題其實來自於已有的傳統研發組織的轉型過程。
傳統研發組織的轉型是個更大的話題。傳統組織因爲歷史原因欠債太多——組織債、文化債、技術債等等，轉型的難度遠比初創公司在發展過程中遇到的大得多。這些歷史欠債還會糾結在一起互爲因果，在轉型過程中單純地去還其中任何一個債都無法讓轉型成功。這需要組織變革者像抽絲剝繭一樣地一層層地改造。這個話題我們放到後面有機會講。今天只聊純組織劃分過程中的原則。
上面故事中的團隊是一個逐漸生長壯大的過程。但不要誤認爲組織架構設計是自底向上搭積木的過程。正相反，即使在組織成長期，組織架構的搭建也是自頂向下不斷拆分和解耦的過程。這與敏捷流程和實踐的改進和創新不同，它們應該是自底向上不斷演進的。作爲組織領導者，在組織架構設計時，應該先根據自身業務特點劃分出業務領域、業務子領域、然後是部落和部落中的小分隊。
但問題是從哪裏入手做拆分和解耦。在一個傳統組織架構中，各個系統和團隊間可能都是緊密耦合的。系統間的邊界很難被識別。
這時候該用到康威定律了。根據康威定律，設計系統的架構受制於產生這些設計的組織的溝通結構。說人話就是你想要什麼樣的系統，就建什麼樣的團隊。就是說組織設計者可以按照期望的系統架構先搭建組織。在新組織架構運行一段時間後，系統會自然會像組織相同的結構演進，從而促進組織間的解耦。
你想要什麼樣的系統我不知道，但一個好的系統大概率應該是可以按業務功能端到端發佈的。從業務需求上看，各業務領域的變更頻率通常是差別很大的。這就要求各業務領域之間能保持低耦合並且可以獨立發佈。這也是拆分和解耦的目的。通過拆分，減小批量大小；通過解構，減少領域之間依賴，從而達到加快價值交付的目的。所以我們在識別部落時應儘量以業務領域劃分，而不是技術、職能等。
例如，在傳統的單體企業應用架構中可能有展現層，中間件層，和基礎架構層。如果團隊按照這三層劃分，很有可能的結果是所有業務模塊在各層都高度耦合，而任何業務領域或業務模塊的需求都不能被獨立發佈。
現代的微服務架構則是以業務爲邊界的，且每個微服務都是端到端發佈的。團隊如果按照業務領域劃分，實際上會幫助跨領域的服務間保持鬆耦合。
隨着中臺技術的興起，系統架構會分爲前臺，中臺，基礎平臺等等。中臺又可以分爲技術中臺，業務中臺，數據中臺等等。不同於傳統單體架構的中間件層，中臺本身也是具備業務能力的資產，應該被單獨測試，單獨上線。而因爲前、中、後臺的上線頻率相差甚遠，所以按平臺來劃分團隊是合適的。
八、結束語
總結一下，本文講述了組建敏捷研發組織架構的一些原則和在Spotify框架內的一些實踐。無論是小型團隊還是大規模敏捷，組隊的核心原則都是高內聚、低耦合、全功能。
組隊的方法是將整個組織按業務領域或平臺自頂向下不斷拆分，直到拆成一個個小分隊爲止。理想情況下每個負責發佈功能的小分隊都能獨立完成從需求分析到發佈的端到端的工作。跨小分隊和部落的必要溝通通過行會和公會來自組織地進行。
無論是小分隊還是部落，作爲一個團隊，它的組織架構是骨肉，但團隊整體負責，榮辱與共的文化和實踐纔是靈魂。它讓團隊能夠整體優化，而不是局部優化。如做不到這一點，這個團隊只能被稱之爲一羣人而已，而不能被稱之爲敏捷團隊。如何在能力建設、敏捷實踐和激勵機制的保障下真正做到團隊的整體負責，榮辱與共，我們有時間單獨聊。
作爲組織管理者，構建一個好的組織架構和組織文化也只是讓組織高效運轉的最基礎的條件。在此之上還要爲組織創建健康的環境、進行有效的目標管理、績效管理、和人才培養等工作。團隊管理本質上是讓團隊成員協同工作達到效率最大化。而團隊中絕大多數的協同問題都不是成員的態度問題，而是上述各種管理沒做到位，或團隊生產關係沒有設計到位。
看到這裏，我相信上文開頭提到的幾個問題大家心中都已經有答案了。掌握團隊組建原則之後要有能力活學活用。這裏再給大家留個問題思考下——DevOps團隊應該如何構建呢？是每個DevOps工程師都分散到各個小分隊裏，還是作爲部落的共享角色，亦或是所有DevOps工程師單獨組隊？
順便澄清一下，狹義上DevOps和平臺運維的工作是不同的。DevOps關注的是如何保障各發布團隊能快速頻繁地交付穩定的軟件，包括應用集成、部署、監控等工作。
而平臺運維負責的是共享基礎設施本身的管理，如系統級安全監控、容量管理、服務治理等，與軟件功能發佈無關。所以平臺團隊一般會單獨組隊。當然也有以谷歌爲代表的很多公司，將狹義的DevOps和平臺運維的工作合併後且賦予更多的管理職責，組成了網站可靠性工程師（Site Reliability Engineering）團隊。
假設是純DevOps呢？歡迎大家留言討論。提示一下，答案不是唯一或放之四海而皆準的，它與整體組織的DevOps成熟度以及在當前成熟度下DevOps的工作重心相關。適合的纔是最好的。
參考資料
《Spotify: A Scrum@Scale Case Study》
https://www.scrumatscale.com/project/spotify-a-scrumscale-case-study/
作者丨常紅平
來源丨CIO Talk（ID：CIO_China_Lab）