摘要： 本文將會討論如何協調公司內各個工程師團隊之間的合作，從而高效地保持系統的彈性和靈活性，以滿足敏捷開發的需求。本文選自《node.js微服務》。
如果乙個公司採用微服務來構建軟體系統，那麼每個干係人都需要參與決策。
微服務是一次重大的正規化轉換。通常，大型組織傾向於使用相當傳統的方式來構建軟體系統。每個重大發布需要經歷數月的研發週期，之後需要乙個完備的質量保證階段以及數小時的部署階段。
當乙個公司選擇使用面向微服務的架構時，方**就會發生完全的改變：每個小團隊負責各自的小功能點，包括它們的構建、測試和部署。每個團隊各司其職，並且能夠處理好各自負責的單一事項（乙個微服務，或更確切地說是數個微服務），每個團隊成員將熟練掌握構建軟體系統的相關技術與領域知識。
這通常被稱為跨職能團隊。這是乙個由少數人組成的工作單元，他們都具備了構建高質量軟體元件的能力。
有一點值得注意的是，團隊成員應當掌握必要的領域知識來理解業務需求。
在我的職業生涯中，大多數導致公司失敗的主要問題不外乎以下這點（就我個人觀點而言）。首先，有一種觀點認為開發者是「堆磚器」，即可以在沒有提前溝通的情況下卻依然能神奇地理解業務流。而且，還有觀點認為，如果乙個開發者一周可以完成x 量級的工作，那麼10 個開發者一周就可以交付10x 量級的產量。這些觀點都是錯誤的。
為了保持高效以及考慮到康威定律在改變業務流程方面對系統的影響，構建微服務的跨職能團隊中的成員必須熟練掌握（不僅僅是了解）相關領域知識。
每當談及微服務的組織架構適配時，自治才是關鍵因素。為了保證構建微服務的敏捷性，每個團隊都必須保持自治，這也意味著要確保技術的自主選擇權，如下所示：
這是非常重要的部分，因為這是我們需要定義公司如何構建軟體，並且可能會引入工程問題的部分。
舉個例子，我們來看看**規範問題，如下所示：
一般來說，我偏好於「80%準則」：80%的完美度已經足以涵蓋100%的使用場景。這意味著放寬**規範（也適用於其他領域），以及允許一定程度的不完美或者個性化，都有助於減少團隊間的摩擦，也能讓工程師能夠盡快關注到那些極少數的重要準則，比如日誌策略以及異常處理。
如果你的**規範過於複雜，那麼在某個團隊想要向其他團隊的微服務提交**時就會遇到很多阻力（切記，乙個團隊擁有自己的服務，但是其他團隊的成員也可以對這個服務做出貢獻）。
本文選自《node.js微服務》，點此鏈結可在博文視點官網檢視此書。
多團隊敏捷開發的組織架構和協作模式（續）
在部落格 中，我介紹了在實踐中多團隊敏捷開發的組織架構和協作模式。這裡在補充介紹一下 技術專家 團隊的一些特別做法。這裡的技術專家團隊可以由內部工程師組成，但一些場合也可以考量外部的技術資源。我們在實踐中有這樣的場景 系統處在試執行中，效能的問題比較突出，但客戶使用後的新需求不斷提出，所有人的精力都...
敏捷開發每日一貼 自組織敏捷團隊的特點
自組織敏捷團隊的特點 敏捷常提到自組織團隊，通俗的講它是乙個由外部建立，然後給與授權，自行決定行動綱領的乙個團隊。這個團隊接受外部給與的任務和約束條件，自行決定如何完成任務。在這個團隊中，團隊成員自己決定做什麼，以及如何做，是 民主 還是 集權 團隊說了算。橄欖球 籃球 足球等體育團隊，就是非 敏捷...
金融組織敏捷的邏輯
2017年8月，首次觸及金融行業轉型。憑藉十年的敏捷經歷以及多年來在大型組織領導敏捷轉型的經驗，三個月內達成 金融業轉型一直以來是乙個難點，大量複雜的業務 老舊的核心系統，還有科技時代最僵化的組織管理模式。這些都讓敏捷的步伐難以邁出。而我們是如何突破種種侷限，上演出一場 速度與激情 如何洞察業務價值...