開發人員體驗
「協助開發人員實現更多的最佳方式不是期待更多，而是改進其體驗。」
–Nicole Forsgren，Microsoft 的 DORA 計量建立者和合作夥伴研究經理
開發人員體驗 (DevEx) 是什麽？
賦予開發人員能力
這些年，組織均將焦點放在提高開發人員生產力以加速業務。不過，只專注於開發人員生產力可能會產生負面影響，例如倦怠、錯誤和減少保留。
模式已經轉變。關於開發人員生產力或開發人員速度等結果已不再是熱門的話題，現在討論的是如何使用開發人員經驗 (DevEx) 以永續的方式達成這些結果。
DevEx 不僅協助開發人員撰寫程式碼，還可在為撰寫程式碼最佳化的環境中撰寫程式碼。
Microsoft 合作夥伴研究經理 Nicole Forsgren
為什麼 DEVEX 很重要？
最佳化 DevEx 可改善商務成果
正在測量 DevEx
SPACE 架構簡介
SPACE 架構為了解和評定開發人員體驗提供了新的整體方法。「生產力不僅僅是個人或工程系統；它不能僅透過單一計量或活動資料來測量...SPACE 架構的開發旨在擷取生產力和開發人員體驗等複雜概念的不同維度。」
–Nicole Forsgren，Microsoft 的 DORA 計量建立者和合作夥伴研究經理
-
滿意度：開發人員對於工作、團隊、工具或文化的滿意度如何？
身心健康: 開發人員有多健康和快樂?
範例計量• 開發人員滿意度
• 開發人員保留
• 參與
• 倦怠
-
評估系統或流程的結果。因為變數太多，所以效能難以量化。
範例計量程式碼品質：
• 可靠性
• 沒有錯誤
• 進行中的服務健康情況程式碼的影響：
• 客戶滿意度
• 客戶採用和保留
• 功能使用方式
• 降低成本
-
了解在執行工作過程中完成的動作或輸出的數量。
範例計量
• 已完成的程式碼檢閱數目
• 編碼時間
• 認可數
• 程式碼行
• 故事點數已完成
• 部署頻率
-
擷取人員與團隊的溝通與合作方式。
範例計量• 程式碼檢閱分數 (品質或周全程度)
• 提取要求合併次數
• 會議品質
• 文件和專長的可探索性
-
衡量開發人員和團隊的工作進展，或在不中斷或延遲的情況下完成工作。
範例計量• 開發人員感知到的保持流程和完成工作的能力
• 檢閱時機
• 流程中人員/團隊之間的交班次數
• 中斷數
最新 DevEx 研究
了解如何協助開發人員茁壯成長
DevEx 演進
• 2024 年 5 月
播客: 使用 SPACE 架構測量 DevEx
最新消息
DevEx 影響
• 2024 年 1 月
DevEx 的實際應用：其實際影響研究
混合式開發人員
• 2023 年 5 月
兩全其美: 釋放軟體工程師混合式工作的潜力
DevEx 與 AI
• 2023 年 2 月
AI 對開發者生產力的影響：來自 GitHub Copilot 的證據
探索開發人員經驗實驗室 (DXL) 這個 Microsoft 與 GitHub 研究開發人員工作與福祉的地方。
DevEx 工具
將 DevEx 最佳化的新式開發人員工具
使用現成可用的協同工作工具簡化開發。
DevEx 快速檢查
DevEx 成熟度快速檢查
使用此測驗判斷您組織的 DevEx 成熟度，並獲得如何改進的指導。
-
若為是:
移至 02。若為否:
了解開發人員的痛點是改善 DevEx 的第一步。建議的後續步驟：
對您的開發人員執行問卷，並向其詢問以下問題：
- 您的工作最難的部分爲何，爲什麽？
- 在思考您的開發工具和流程時，您的生產力最大障礙是什麼?
- 如果您能變更我們團隊建置軟體的方式，您會變更什麼?
-
若為是:
移至 03。若為否:
DevEx 是多面向的，所以需要多面向架構才能了解它，這就是我們發明 SPACE 架構的原因。它會考慮 DevEx 的五個維度: S 滿意度與福祉、P 效能、A 活動、C 溝通與共同作業，以及 E 效率與流程。為了評定您的 DevEx，我們建議在 SPACE 的至少三個維度上追蹤計量/KPI。
如要深入了解 SPACE 架構，以及參閱各維度的計量範例，請參閱研究報告。
建議的後續步驟：- 深入了解 SPACE 架構。
- 選取 SPACE 的三個維度以在貴組織中設定優先順序 (應與開發人員的痛點一致)。
- 為那三個維度中的每一個選取或建立計量。
- 實作隨時間追蹤那些計量的方法 (例如，DevEx 儀表板)，並使用它們來評定 DevEx 投入的影響。相應地調整您的方法。
-
若為是:
移至 04。若為否:
務必為每個計量定義清楚、真實的目標。此外，這些目標亦務必與您的開發人員痛點一致。設定目標可能很困難。部分選擇參考來自其他高效能團隊或公司的計量，部分參考產業基準。另請注意，您的目標可能會隨著時間變更，以反映持續的改善。
如要深入了解如何量化 DevEx 和可能的 ROI，請參閱我們的部落格和研究報告。
建議的後續步驟：- 為每個 DevEx 計量設定明確、現實的目標。
- 召開季度會議，檢查這些計量並檢閲您的 DevEx 進度。
- 根據您所看到的影響來調整您的 DevEx 投入和投資。
-
若為是:
移至 05。若為否:
改善 DevEx 的唯一方法是改善開發人員的工作方式。通常，這代表投資一些能讓他們生活更輕鬆的工具，或簡化重要流程。為了提升效率，建議您使用您所識別的計量，專注並追蹤您的 DevEx 改進工作。以下是一些指導您 DevEx 投資的秘訣：- 免去工作流程中的辛勞。將「工作流程效率低下」列為首要工作挑戰的開發人員，表示工作效率感覺低落的機率為 2 倍，且尋找其他工作的機率也高出 67%。簡化計劃和工作管理流程，改進合規性工作流程，是减少開發人員辛勞的有效方法。
- 取得新式開發工具。這樣做也可以減少工作。GitHub Copilot 等新式工具可協助開發人員加快完成工作的速度，最高可提升 55%，且可縮短記錄等例行工作所需的時間。
- 提早測試安全性。透過在軟體開發生命週期較早設定安全性的優先順序，組織可以在問題進入生產之前解决問題，從而降低成本並節省開發人員的時間。新式開發人員工具可以透過在程式碼建立期間掃描弱點來協助此問題。
建議的後續步驟：- 透過投資新工具或簡化流程來改進開發人員的工作方式，以符合其痛點和 DevEx 計量。
-
若為是:
請移至 [繼續您的旅程]。若為否:
有時候，組織會錯誤地讓其開發人員對其 DevEx 負責，但這是不公平的，因為開發人員不設計公司的工具鏈或流程，而是領導團隊設計的。DevEx 專案應由領導團隊領導，具有改進開發人員體驗的明確目標，且領導團隊應對這些專案的成功負責。
這並不是說開發人員不應該參與 DevEx 專案。這些專案設計旨在解决開發人員的痛點，因此當然應該在整個流程中諮詢開發人員並讓他們參與其中，但歸根結底，領導團隊應該負責改進其組織中的 DevEx。
建議的後續步驟：- 在領導團隊中建立 DevEx 擁護者，以領導 DevEx 投入。
- 進行季度檢閲，檢查您的 DevEx 計量並評定您的進度。
- 包含 DevEx 旅程中所有階段的開發人員，其輸入很寶貴。
開始使用
立刻開始您的 DevEx 旅程
透過為開發人員提供注入 AI 力量的新式工具，增強您的商務並協助其茁壯成長。
在 DevEx 實驗室深入了解
探索 Microsoft 和 GitHub 共同研究實驗室的最新 DevEx 出版物。
取得專家協助
如果您想了解 Microsoft 關於最佳化 DevEx 的指導，請連絡我們的銷售團隊，他們將為您提供適當的資源。
探索 SPACE 架構
若要深入了解 DevEx 的測量，請閱讀完整 SPACE 架構研究論文。