建置生產力小組

工程師在能夠專注並 進入該區域的環境中茁壯成長。 團隊通常會面臨分心和競爭優先順序，迫使工程師轉移內容並分散注意力。 他們很難平衡 低 頭與 抬頭 時間。 新增功能需要小組成員向下和專注。 回應客戶問題並解決即時網站問題，需要小組主管並了解發生了什麼事。

為了減輕干擾，小組可以將自己分成兩 個船員：一個用於功能，一個用於實時網站健康。

雙船員方法可產生更高的生產力和可預測性。 成功的實作依賴下列重要元素：

• 明確定義的船員角色
• 定義完善的船員輪替程式
• 經常調整船員大小

功能人員

功能組或 F-crew 著重於 未來。 他們作為一個具有明確使命和目標的有效單位：建置和運送高品質的功能。

F-crew 受到日常即時服務混亂的防護，以確保他們有時間設計、建置和測試他們的工作。 他們可以依賴最少的分心和自由，而不需要修正隨機發生的問題。 他們被鼓勵很少檢查他們的電子郵件，並避免被提取到其他問題，除非他們很重要。

當 F-crew 成員加入交談或偶爾被吸進電子郵件線程時，其他小組成員應該叫他們： “你在 F-crew 上，你在做什麼？ 如果 F-crew 成員需要解決重大問題，建議他們將其委派給客戶人員，並返回功能工作。

F-crew 是一個緊密編織的團隊，在一小組功能上蜂擁而至。 良好的工作進展（WIP）限制是飛行中的兩個功能，4-6人。 藉由密切合作，他們會建置深入的共享內容，並找出數據指標程式代碼檢閱遺漏的重要 Bug 或設計問題。 專用的機組人員允許更可預測的輸送量速率和前置時間。 小組成員經常將 F-crew 稱為平靜和專注。 他們發現，它和平和復興，深入關注一個特徵，並充分關注它。 人員 離開他們的時間在F船員感覺重新整理和完成。

客戶小組

客戶小組或 C-crew 著重於現在，並提供客戶和即時網站問題、Bug、遙測和監視的前線支援。 C 組通常會擠在計算機周圍，對重大即時網站問題進行偵錯。 其頭號優先順序是即時網站健康情況。 以鐳射為主的環境，他們建立了專家偵錯和分析技能。 客戶小組通常稱為 盾牌 小組，因為它會保護小組的其餘人員不受干擾。 C-crew 不是處理即將推出的功能，而是客戶與目前產品之間的橋樑。 船員在電子郵件、Twitter 和其他意見反應頻道上都處於作用中狀態。 客戶想知道他們被聽到，而 C 組的工作是聽到他們。 C-crew 會立即對客戶回報的問題進行分級，並快速參與並協助封鎖客戶。

隨著即將來臨的任務的暴漲，有時，在快速節奏的 C 組工作可以令人振奮。 在忙碌的一周內，他們會處理多個電子郵件、即時網站調查和 Bug。 當作業安靜下來時，他們會努力改善遙測和報告，並投入時間讓服務維護變得更容易。

C-crews 可讓小組解決問題，而不需要將小組成員從其他優先順序提取，並確保聽到客戶和合作夥伴。 對問題和問題的回應，成為 C-crews 的驕傲點。 然而，這種速度可能會耗盡，需要船員之間頻繁輪換。

船員輪替

定義完善的輪替程式可讓兩組人員系統運作。 您可以簡單地交換船員（F-crew 變成 C-crew，反之亦然），但這限制了船員之間的知識共用。 相反地，選擇每周輪替。

在每周結束時，進行簡短 的交換會， 小組決定誰在船員之間交換。 您可以使用白板圖表來追蹤目前在每個機組人員上的人員，以及交換人員時。 每個機組人員最長的任期人員通常應該彼此交換。 不過，在任何給定的一周內，有人可能會想要繼續在即時網站調查或功能上完成工作。 雖然有彈性，但某人在船員上的時間越長，他們就越有可能交換。

每周輪換有助於防止小組中知識的尋址接收器，並確保船員之間不斷流動的信息和觀點。 工程師的頻繁移動會建立小組工作的共用知識，這有助於 C-crew 在沒有其他人協助的情況下解決問題。 通常，新的 F-crew 成員很快就會發現先前忽略的設計或程式代碼缺陷。

船員大小

船員大小會有所不同，以維持團隊的健康情況。 如果團隊的即時網站問題率很高，或有大量的技術債務，C 組就會變得更大，反之亦然。 每周調整大小會增加小組交付專案和相依性的可預測性。 在幾周內，小組可能會將每個人移至 C-crew，以解決大版的意見反應。

此策略可簡化與管理的通訊。 如果沒有雙機組人員系統，工程師通常會同時處理多個工作。 當一周發生數次分心時，進行中的功能通常會延遲。 因此，小組可能無法自信地為未來的功能工作提供時程表。

專用的 F-crew 會導致可預測的輸送量和前置時間。 在團隊之間分割資源會增加小組內的責任，以及管理小組每周和每個短期衝刺所能完成的工作。

下一步

兩組人員系統可協助小組瞭解工程師應該花在何處，並在許多競爭優先順序上取得進展。

除了提高生產力和可預測性之外，兩組人員系統還可以提高團隊士氣。 每個小組的工程師清楚地瞭解其角色和責任，並更獨立地運作，並承擔更大的責任。 此方法適用於DevOps小組，負責開發和作業的人員。 不過，此方法幾乎可以套用至任何處理競爭優先順序的敏捷式小組。

Microsoft 是世界上最大的敏捷式公司之一。 瞭解 Microsoft 如何在 DevOps 規劃中組織小組。