Microsoft 如何使用 DevOps 進行規劃
Microsoft 是世界上使用敏捷式方法的最大公司之一。 經過多年的經驗，Microsoft 開發了 DevOps 規劃程式，透過 Windows 等大量工作，從最小的專案相應增加。 本文說明 Microsoft 在規劃整個公司的軟體專案時所實作的許多教訓和作法。
工具變更
下列重要變更有助於讓開發和出貨週期更健康且更有效率：
- 促進文化一致性和自主性。
- 將焦點從個人變更為小組。
- 建立新的規劃和學習策略。
- 實作多組模型。
- 改善程式代碼健康情況做法。
- 促進透明度和問責。
促進文化一致性和自主性
彼得·德魯克說，“文化吃早餐的策略。自主性、掌握性和目的是人類的關鍵動機。 Microsoft 會嘗試將這些激勵因素提供給 VM、開發人員和設計工具，讓他們覺得能夠建置成功的產品。
此方法的兩個重要參與者是 一致性 和 自主性。
- 一致性來自上而下，以確保個人和團隊瞭解其職責如何與更廣泛的業務目標保持一致。
- 自主性會從下而上發生，以確保個人和團隊對日常活動和決策產生影響。
對齊和自治之間有微妙的平衡。 太多的對齊方式可以創造一種負面文化，因為人們只會在被告知時執行。 太多的自主性可能會導致結構或方向不足、決策效率不佳，以及規劃不佳。
將焦點從個人變更為小組
Microsoft 會將人員和小組組織成三個群組：PM、設計和工程。
- PM 會定義 Microsoft 建置的內容，以及原因。
- 設計負責設計 Microsoft 所建置的專案。
- 工程會建置產品，並確保其品質。
Microsoft 小組具有下列主要特性：
- 交叉紀律
- 10-12 人
- 自我管理
- 清除憲章和目標 12-18 個月
- 實體小組會議室
- 擁有的功能部署
- 生產環境中擁有的功能
爭取垂直團隊
用來水平、涵蓋所有UI、所有資料或所有API的 Microsoft小組。 現在，Microsoft 致力於 垂直團隊。 Teams 擁有產品端對端區域。 特定層級的嚴格指導方針可確保整個產品的小組之間的統一性。
下圖概念化水準和垂直小組之間的差異：
允許自我選取小組
大約每 18 個月，Microsoft 會執行一個「黃色黏性練習」，讓開發人員可以選擇他們在接下來的幾個規劃期間想要處理的產品區域。 此練習提供自主性，因為小組可以選擇要處理的內容，以及組織一致性，因為它會在小組之間促進平衡。 這項練習中約有80%的人仍然留在他們目前的團隊中，但他們感到有權力，因為他們有選擇。
建立新的規劃和學習策略
德懷特·艾森豪威爾說，“計劃毫無價值，但規劃是一切。Microsoft 規劃分成下列結構：
- 短跑 （3 周）
- 計劃 （3 個短期衝刺）
- 季節 （6 個月）
- 策略 （12 個月）
工程師和小組大多負責短期衝刺和計劃。 領導主要負責季節和策略。
下圖說明 Microsoft 規劃策略：
此規劃結構也有助於在進行規劃時最大化 學習 。 Teams 能夠取得意見反應、瞭解客戶想要的內容，以及快速且有效率地實作客戶要求。
實作多機組人員模型
先前的方法培養了 Bug 和即時網站事件的「中斷文化」。 Microsoft 小組想出了自己的方法來提供焦點並避免干擾。 小組會針對每個衝刺自行組織成兩個不同的機組人員：功能（F-crew）和客戶（C-crew）。
F-crew 負責認可的功能，而 C-crew 會處理現場問題和中斷。 小組會建立旋轉頻率，讓成員更輕鬆地規劃活動。 如需多機組人員模型的詳細資訊，請參閱 建置具生產力的客戶焦點小組。
改善程式代碼健康情況做法
切換至敏捷式方法之前，小組用來讓程式代碼 Bug 建置，直到程式代碼在開發階段結束時完成為止。 小組接著探索到錯誤，並致力於修正錯誤。 這種做法創造了一個過山車的 Bug，這影響了團隊士氣和生產力，當小組必須處理 Bug 修正，而不是實作新功能時。
Teams 現在會實 作錯誤上限，由公式 # of engineers x 5 = bug cap計算。 如果小組的 Bug 計數超過短期衝刺結束時的錯誤上限，他們必須停止處理新功能並修正 Bug，直到其上限下為止。 Teams 現在會在他們去時償還 Bug 債務。
促進透明度和問責
在每個短期衝刺結束時，每個小組都會傳送一封郵件，報告他們在先前短期衝刺中完成的工作，以及他們打算在下一個短期衝刺中執行的動作。
目標與關鍵結果（OKR）
當小組清楚瞭解組織嘗試達成的目標時，最有效。 Microsoft 透過目標和關鍵結果 （OKR） 為小組提供更清楚的瞭解。
- 目標會 定義要達成的目標。 目標是重要的、具體、行動導向的，而且理想情況下是有啟發性的意圖陳述。 目標代表大理念，而不是實際數位。
- 關鍵結果 會定義達成目標的步驟。 關鍵結果是可量化的結果，可評估進度，並針對特定時段的目標指出成功。
OKR 會反映最佳的可能結果，而不只是最可能的結果。 領導人試圖雄心勃勃，不謹慎。 推動小組追求具有挑戰性的關鍵結果，會推動加速目標，並優先處理朝著較大目標邁進的工作。
採用OKR架構可協助小組以下列原因執行得更好：
- 每個小組都 與 計劃保持一致。
- Teams 著重於 達成結果 ，而不是完成活動。
- 每個小組 都會定期負責 工作。
OKR 可能存在於產品的不同層級。 例如，可能有最上層產品OKR、元件層級OKR和小組層級OKR。 讓OKR保持一致相當容易，尤其是在目標設定由上而下時。 任何出現的衝突都是組織不對齊的寶貴早期指標。
OKR 範例
目標：拓展強大且快樂的客戶群。
關鍵結果：
- 將外部凈升階者分數從 21 提高到 35。
- 將文件滿意度從55提高到65。
- 新的管線流程的 Apdex 分數為 0.9。
- 作業的佇列時間是 5 秒或更少。
如需OKR的詳細資訊，請參閱 使用目標和關鍵結果測量業務成果。
選取正確的計量
主要結果只適用於它們所依據的計量。 Microsoft 會使用著重於變更的領先指標。 經過一段時間，這些計量會建置產品加速或減速的工作圖片。 Microsoft 通常會使用下列計量：
- 採用每月成長率的變化
- 效能變更
- 變更時間以學習
- 事件頻率變更
Teams 可避免不會累算目標價值的計量。 雖然它們可能有特定用途，但下列計量對追蹤目標進度沒有説明：
- 原始估計的正確性
- 完成時數
- 程式碼
- 小組產能
- 小組待執行工作
- 小組速度
- 錯誤 (bug) 數量
- 程式碼涵蓋範圍
在 Agile 之前和敏捷式之後
下表摘要說明 Microsoft 開發小組採用敏捷式做法時所做的變更。
| 之前 | 之後 |
|---|---|
| 4-6 個月里程碑 | 3 周短期衝刺 |
| 水平小組 | 垂直小組 |
| 個人辦公室 | 小組會議室和遠端工作 |
| 長期規劃週期 | 持續規劃和學習 |
| PM、Dev 和 Test | PM、設計和工程 |
| 每年的客戶參與度 | 持續客戶參與 |
| 功能分支 | 每個人都在主要分支中工作 |
| 20 個以上的人員團隊 | 8-12 人組 |
| 秘密藍圖 | 公開共用藍圖 |
| Bug 債務 | 零債務 |
| 100 頁規格檔 | PowerPoint 規格 |
| 私人存放庫 | 開放原始碼或 InnerSource |
| 深層組織階層 | 扁平化組織階層 |
| 安裝數位定義成功 | 用戶滿意度定義成功 |
| 功能每年出貨一次 | 功能隨附每個短期衝刺 |
重要心得
- 認真對待敏捷式科學，但不要過於規範。 敏捷式可能會變得過於嚴格。 讓敏捷思維和文化成長。
- 慶祝結果，而不是活動。 部署功能超過程式代碼行。
- 在每個衝刺中寄送，以建立節奏和節奏，並找到所有需要完成的工作。
- 建置您想要取得所要尋找之行為的文化特性。