建置生產力小組

工程師在可以專注于 並進入該區域的環境中成長。 小組通常會面臨干擾和競爭優先順序,以強制工程師轉移內容並劃分其注意力。 他們難以平衡 頭部向下 時間與 向上 時間。 新增功能需要小組成員往下和專注。 回應客戶問題並解決即時網站問題,需要小組一起瞭解情況。

為了減輕干擾,小組可以將自己分成兩個 小組:一個用於功能,另一個用於即時網站健康情況。

功能小組和客戶小組合作的圖例。

雙小組方法會產生更高的生產力和可預測性。 成功的實作依賴下列重要元素:

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

功能小組

功能小組或 F-crew著重于 未來。 他們會以清楚的任務和目標作為有效單位:建置和交付高品質的功能。

F 小組受防護,不受即時服務的日常混亂所防護,以確保他們有時間設計、建置及測試其工作。 他們可以依賴最少的干擾,並自由地解決隨機發生的問題。 除非重要,否則鼓勵他們不常檢查其電子郵件,並避免被提取到其他問題。

當 F 小組成員加入交談或偶爾被擷取到電子郵件對話中時,其他小組成員應該叫用他們:「 您正在 F-team,您要做什麼?」 如果 F 小組成員需要解決重大問題,建議他們將其委派給客戶小組,並返回功能工作。

F 小組會以緊密的小組身分運作,在一小組功能上群集。 良好的工作進行中 (WIP) 限制是 4-6 人正式發行前小眾測試版的兩項功能。 藉由密切合作,他們會建置深入的共用內容,並找出資料指標程式碼檢閱會遺漏的重要錯誤或設計問題。 專用的小組允許更可預測的輸送量速率和前置時間。 小組成員通常會將 F 小組稱為無所不及專注。 他們發現它很輕鬆且專注在功能上,以充分注意功能。 人員讓 F 小組的時間保持重新整理並完成。

客戶小組

客戶小組或 C 小組目前著重于 並提供客戶和即時網站問題、Bug、遙測和監視的前線支援。 C 小組通常會圍繞電腦,對重大即時網站問題進行偵錯。 其第一個優先順序是即時網站健康情況。 以雷射為主的這個環境,他們會建置專家偵錯和分析技能。 客戶小組通常稱為 防護 小組,因為它可防護小組的其餘人員不受干擾。 C 小組不是處理即將推出的功能,而是客戶與目前產品之間的橋樑。 小組成員在電子郵件、Twitter 和其他意見反應頻道上處於作用中狀態。 客戶想要知道他們收到意見,而 C 小組的工作就是聆聽他們。 C 小組會立即分類客戶回報的問題,並快速參與並協助封鎖的客戶。

透過連入的工作,有時可以快速處理快速的 C 小組工作, 很令人滿意。 在忙碌的一周中,他們會處理多個電子郵件、即時網站調查和 Bug。 當作業無訊息時,他們會努力改善遙測和報告,並投入時間讓服務維護更容易。

C 小組可讓小組解決問題,而不需要將小組成員提取到其他優先順序,並確保聽到客戶和合作夥伴。 對於問題和問題的回應能力,會成為 C 小組的一點。 不過,此步調可能會耗盡,需要小組之間頻繁輪替。

小組輪替

定義完善的輪替程式可讓雙小組系統運作。 您可以直接交換 (F 小組的小組變成 C 小組,反之亦然) ,但這會限制小組之間和內部的知識共用。 請改為選擇每週輪替。

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

每週輪替有助於防止小組中知識的定址接收器,並確保小組之間持續流動的資訊和觀點。 工程師經常移動會建立小組工作的共用知識,這可協助 C-team 解決問題,而不需要其他人的協助。 新的 F 小組成員通常會快速發現先前忽略的設計或程式碼瑕疵。

小組大小

小組大小會因維護小組的健康情況而有所不同。 如果小組有高即時網站問題的傳入率,或有許多技術債務,C 小組就會變大,反之亦然。 每週調整大小會增加小組交付專案和相依性的可預測性。 在幾周內,小組可能會將每個人移至 C 小組,以解決來自大發行的意見反應。

此策略可簡化與管理的通訊。 如果沒有雙小組系統,工程師通常會同時處理多個專案。 當單一周發生數個干擾時,進行中的功能通常會延遲。 因此,小組可能無法放心地提供未來功能工作的時程表。

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

後續步驟

這兩個小組系統可協助小組瞭解工程師應該在何處花費時間,並在許多競爭優先順序上進行進度。

除了改善生產力和可預測性之外,雙小組系統還可以提高小組的心力。 每個小組的工程師清楚瞭解其角色和責任,並更獨立且更有責任。 這種方法很適合 DevOps 小組,這些小組負責開發和作業。 不過,此方法幾乎可以套用至任何處理競爭優先順序的敏捷式小組。

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