鐵人賽倒數兩天，就不繼續介紹付費功能了，我們來看看 GitLab 的 Quality Department 吧！

在 Day 25 ~ 28 我介紹了幾個 GitLab 原廠提供的工具，其實這些工具都是出自 GitLab 的 Quality Department。我相信那幾個工具應該有讓大家眼睛一亮，所以今天我們就來認識開發出這些工具的 GitLab Quality Department！

如果想要認識 GitLab 的 Quality Department，我們當然要從 The GitLab Handbook 開始，在 Engineering 的章節之下，即有說明 GitLab Quality Department 的頁面。

首先是 Quality Department 的 Mission

GitLab’s Quality is everyone’s responsibility. The Quality Department ensures that everyone is aware of what the Quality of the product is, empirically. In addition, we empower our teams to ship world class enterprise software at scale with quality & velocity.

我覺得它寫得很好，裡面有點出幾個重點

• 品質是每一個人的責任
• 每一個人都要了解什麼是產品品質
• 要賦能「團隊」，讓團隊可以迅速的交付高品質的產品

這整段 Mission 聽起來超 DevOps 的！一個理想中的產品團隊，不就該是如此嗎？

Principles 繼續延續 Mission 而展開，描述 Quality Department 是產品團隊的好夥伴，幫助產品團隊在產品開發的過程中能夠自然而然的關注產品品質。

• 營造一個「品質人人有責」的環境
  • 幫助產品團隊，在產品開發的初期階段就關注「品質」
  • 倡議與擁護良好的軟體設計、測試實務及 Bugs 的預防策略
• 提升測試覆蓋率，與妥善的測試分級
  • 讓合適的測試在合適的地方進行測試
  • 幫助產品團隊能夠意識與了解到他們的測試覆蓋率
  • 持續提升測試效率、穩定度，重構免去重複的覆蓋率
• 提升工程團隊的生產力、效率
  • 運用自動化來提昇工作流程中的效率與生產力
  • 確保工具與測試的可靠性
  • 確保 CI Pipeline 高效、可靠並具備合適的覆蓋率
• 數據驅動（Metrics driven）
  • 前述提到改善生產力、效率、測試、可靠性，都會是 Data driven，來自 Data 中的洞見，不是空穴來風。透過 Data 來持續改善。

這整段 Principles 的內容也同樣超 DevOps 的！這其實是「真・DevOps Team」吧？

接著是該部門的 Direction，內容較多，就只記錄我看到的幾個重點。

• 以客戶為中心的品質。（所以不是工程師自己做爽的品質，是要讓客戶有感的品質）
• 重視貢獻者（Contributors）。（讓貢獻者願意留下來繼續貢獻）
• 與 Marketing 團隊協作。（再一次，不只是工程師自己做爽的）
• 提升生產力、減少故障與浪費，包含減輕 on-call 負擔、減少 Pipeline 故障與執行時間。
• 再說一次數據驅動（Analytics Driven）。（讓工程團隊能正確理解 Mertics 的意義）
• 關注員工、貢獻者與團隊的成長。

接著談到了人員配置的比例。

• Software Engineer in Test（SET）
  • 主要比例：每一個 Product Group 會有一位 SET
  • 次要比例：SET 與 Development Department Engineer 的比例為 1:8
• Engineering Productivity Engineer
  • 主要比例：每一個 Product Stage 會有一位 Engineering Productivity Engineer
  • 次要比例：Engineering Productivity Engineer 與 Development Department Engineer 的比例為 1:40
• Quality Engineering Manager
  • 主要比例：每一個 Product Section 會有一位 Quality Engineering Manager。
  • 次要比例：Quality Engineering Manager 與 Development Department Director 的比例為 1:1

從上面的資料來看，其實人員比例並不算高。倒是出現了一個有趣的職稱「Engineering Productivity Engineer」，令人想更多了解這角色都在做些什麼事情。如果上 Indeed 去搜尋，可以發現國外已經開始有企業在徵求「Developer Productivity」有關的角色。

接下來的內容大多都是關於 Quality Department 是怎麼工作與協作，包含如何溝通、分配與管理工作任務、on-call⋯⋯，我同樣就只節錄一些我個人看上的重點。

• GitLab 有訂定團隊需遵守的 Communication guidelines 與 Engineering Culture。
• Quality Department 會進行 Week-in-review 與 Engineering-wide retrospective。
• 針對不同的議題，會在不同的 slack channel 溝通。
• 任何議題都要回報為 Issue，呈現在 Issue Board 上，並且要標注合適的 Label。
• 資訊的回報都有著各自需要遵守的格式，確保必要的「資訊內容」都有被傳遞清楚。
• 會定期溝通工作任務的優先順序與重新排序。
• 定期檢視、分類、整理 Borad，並且會指派 Owner。
• 明定團隊成員需要關注哪些 Board。
• 明定會在哪些場景與其他部門協作。
• 明定與其他部門協作時，透過哪些管道溝通，以及傳遞資訊時要包含哪些內容，例如要加上什麼 Label。
• 明定團隊會有哪些固定重複的 Events，發生的頻率、原因、目的、要達成的目標。
• 注重與所有利益關係人的溝通。
• 有一份完整的 GitLab Release Docs，說明 Release Process。
• 列舉團隊的成果，讓其他部門知道自己團隊做了哪些貢獻。

從這些內容可以看見，GitLab 作為全 Remote 的公司，在如何讓團隊能夠有效率的工作、溝通與協作下了很多功夫。事實上除了 Quality Department，如果你閱讀 The GitLab Handbook 上其他部門的頁面，也都能看到類似的內容。

好了，看完 Quality Department 的頁面，可以知道他們在 GitLab 公司及 GitLab 的產品開發中是十分重要的輔助角色。

雖然之前就說過了，但每次看完 The GitLab Handbook 的任何一個頁面，我都會再次覺得能將企業、組織、部門、團隊的相關內容，特別是團隊內部怎麼工作、如何協作溝通、他人該怎麼跟自己團隊協作溝通，全都落成文字說明清楚，是一件很厲害的事情，也是一件很值得做的事情。這就像是一份團隊的「使用說明書」，對內對外都能帶來益處，GitLab 公司透過 The GitLab Handbook 為我們做了一個很厲害的示範；也許我們都該嘗試學習 GitLab 為自己的部門與團隊撰寫類似的文件。

今天的內容就到這裡，明天就是鐵人賽最後一天啦！明天見～

圖片來源 - 吉卜力工作室 https://www.ghibli.jp/works/tanuki/#&gid=1&pid=31

參考資料

• https://handbook.gitlab.com/handbook/engineering/quality/
• https://gitlab.com/gitlab-org/quality