Pipefy如何使用團隊拓撲方法建設敏捷團隊？

• 組織結構圖的問題
• 康威法則
• 逆向康威法則
• 團隊的規模
• 認知負荷
• 基本拓撲結構

組織結構圖的問題
世界上大多數公司都組織成層次結構，這些層次結構通過一個複雜、單調和線性的層次結構圖來直觀地表示，該層次結構圖顯示了團隊、部門和單位。這種垂直的工作和溝通模式意味著這種控制分工可以創造一個允許大量創新的環境。同時，一切都快速交付，就像我們在工廠中的生產線一樣運作。 
但我們知道，如果我們在這種分層限制的模型中構建軟體，我們將在貢獻、溝通以及最重要的參與方面產生問題，由於來自鏈的兩側或頂端的溝通，肯定會產生不切實際的期望。結果，開發人員可能只想知道他們在這個分層圖表中的位置，並且每天都將自己的工作流程變成瓶頸。 
團隊拓撲主要側重於通過設定具有明確定義的互動模型的動態組織結構來賦予團隊權力，這些模型有助於團隊快速採用新條件。因此，當被視為構建塊時，工程師、開發人員和 PO 一起工作，因為他們是一群在相同環境中行動的人。

康威定律
當我們想到一家公司並考慮它的成功發展時，組織以及它的團隊結構、軟體結構以及最重要的是它的溝通成為一個關鍵問題。 
康威定律建立於 1969 年，讓我們有機會將這些方面作為我們分析的主要焦點，後來我們發現，忽略該定律會對您的軟體產生或不產生的影響產生重大影響。
康威的論文認為，當公司設計他們的系統時，他們註定要生產出他們的通訊結構的副本。這可能是好是壞，因為您公司的重大溝通問題可能會影響您的產品質量。
簡而言之，如果與業務團隊的溝通不明確，這將導致產品成功的機會減少，與最好的技術和工程師合作也毫無用處。另一方面，如果一個組織被安排成 QA、DBA、前端、後端等功能孤島，則不太可能生產出設計良好的端到端產品。
如果系統架構和組織架構不一致，則組織架構獲勝。

反向康威定律
在 Conway 方法中，我們傾向於不可避免地將我們的組織模型複製到我們的程式碼中。當我們顛倒這個概念時，我們在組織中複製了我們的軟體模型。換句話說，我們必須在軟體準備好之前重塑團隊溝通的方式。 
換句話說，當我們應用逆康威定律時，我們可以設計我們的團隊，使他們能夠匹配軟體設計的需求，因為開發人員被賦予了不同的功能。
作為一種安全措施，隨著快速流動帶來的變化，我們必須牢記團隊的範圍及其架構必須保持一致。因此，在草擬完茶的屬性草案後，我們必須應用程式碼架構最佳實踐，例如：

• 低耦合：元件不能強依賴於其他元件。
• 高凝聚力：元件必須具有明確的職責和邊界，通過表明與其內部元素的強關係。
• 軟體架構原則，例如 SOLID（單一職責、開放式關閉、Liskov 替換、介面隔離和依賴倒置）、KISS（保持簡單、愚蠢）和 DRY（不要重複自己）

團隊規模
一旦我們對團隊的規模有了很好的瞭解，我們就必須考慮到團隊成員之間的關係。因為 Team Topologies 主要專注於打破任何可能的溝通障礙，所以如果出現溝通障礙，指望世界上最好的工程師是沒有用的。 
一個團隊的極限不僅僅是一個數字。我們必須認為，一個團隊必須像足球隊一樣培養內部信任和良好的融洽關係。鄧巴的研究表明，當我們能夠在一個小團隊中培養信任時，就會提高生產力。當然，大型團隊能夠保持高度信任的情況也有例外，但這種情況很少見。如果我們像看待家人一樣看待我們的團隊，很自然我們不會與所有成員保持聯絡，而鄧巴在他的研究中成功地找到了一些信任模式。
即使找到了合適的數字和合適的人，我們仍然需要改變團隊的思維方式，以便讓溝通順暢，讓擁有必要知識的緊湊團隊受益。為此，所有成員都必須明白，他們必須將團隊的需求置於個人需求之上，遵守基本的工作協議，例如對映討論和調查，並始終關注團隊的需求，無論是目標還是主動性，守時， ETC。 

認知負荷
擁有足夠規模的團隊但承擔很多責任是沒有用的。因此，為了讓團隊保持專注並提供最佳績效，我們必須能夠衡量其認知負荷並在為時已晚之前識別瓶頸。
為了更好地理解認知負荷是什麼，我們首先需要了解我們是如何學習的。我們的記憶分為工作記憶和長期記憶。一些研究，例如 John Sweller 的“認知負荷理論 (1988)”，表明我們能夠在工作記憶中保留七到九個過程。由於知道一個人處理資訊有這樣的限制，我們必須提前計劃以防止資訊過載。 
但到底什麼是認知超載？

已使用的工作記憶體資源量。

無論你的團隊多麼誠實，認知過載是很難衡量的，對認知過載的管理不足會導致產品以及溝通質量的嚴重困難。

這種負荷被分為三個不同的時刻。內在的、外在的和內在的。在軟體開發領域，我們可以將它們定義為。

• 內在的（Intrinsic）：做新事情的複雜性，比如當我們有一個史詩般的或非常大的任務需要完成時，需要多少認知資源來把這些資訊轉移到長期記憶中。
  
• 外來的（不相關的Irrelevant）。這種型別的負荷會造成分心，使我們的工作記憶無法正常運作，比如在嘈雜的環境中工作，缺乏開發工具，或者程式碼寫得不好。所有這些都會阻礙學習，使我們更難獲得長期記憶，因此我們應該儘可能地減少這種負荷。
  
• 相關（Germane、Relevant）。這是意味著更深層次處理的負荷，這被稱為流動，是一個認知水平，在這個水平上我們能夠處理複雜的資訊，訪問我們的長期記憶，並更好地與我們的推理互動。出於這個原因，這是我們必須最大化的負荷。

基本的拓撲結構
當我們定義了一個團隊的規模、領域和人員後，我們就能發現它的拓撲結構是什麼。這樣一來，所建立的每一個服務或應用都必須由一個具有認知能力的團隊來建設和運營。這可能會引起一些疑慮，比如。我們是否有合適的團隊在合適的時刻？或者，在一些看似沒有主人的領域，是否缺乏能力？因此，我們必須從每個團隊如何融入組織的角度來思考。為了使這個過程更簡單，我們可以通過團隊拓撲結構將團隊的變化數量減少到四個基本團隊。

1. 流對齊Stream-Aligned 團隊：與業務領域或組織能力緊密結合的持續工作流程是這些團隊的基礎。這個團隊負責交付價值，必須保持其目的、目標和責任非常明確。其範圍可以從簡單的產品、服務或角色，到一系列的功能或使用者旅程。
2. 賦能團隊：這是一個高效能的團隊，由具有高技術水平或業務所有權的專家組成，他們為流向一致的團隊的發展提供支架，因為後者將專注於高價值的交付。因為這個團隊有很強的協作意識，他們能夠分享知識，並提高流線型團隊的自主性，而不會成為英雄。
3. 複雜-子系統團隊: 這個團隊負責建立和維護系統中強烈依賴特定知識的部分，大多數團隊成員是某一領域的專家，對執行系統模組和子模組的變化有很強的理解。
4. 平臺-團隊：這個團隊的目的是讓流向一致的團隊能夠完全自主地完成他們的工作。這個團隊提供服務，以減少認知負荷，這對於流對齊的團隊建立這些服務是必要的。

持續改進
在我們的團隊被定義、調整和分類之後，我們能夠通過不同團隊在不同時刻的交付來支援他們的快速和可持續增長。這創造了一個低耦合的環境，良好的溝通，指導我們的決策以實現 "快速流動"，並給組織一個現實的使命。

如何應用價值導向技術？ 這個問題在Pipefy這裡被仔細研究，我們的組織方式是，這個問題的答案可以讓簡單的變化產生最大的影響。因此，我們一直在重新審視和重構我們的工作流程，應用團隊拓撲結構，注重以人為本，並使用許多方法使我們的團隊重組與我們的目標、客戶和商業價值相一致。