敏捷服務管理的相關指引
- DevOps
- ITIL
- SRE
- 精實(Lean)
- Scrum
DevOps
根據維基百科的定義,DevOps是:一種文化和專業化運動,強調軟體開發人員和 IT 維運專業人員之間的溝通、協作和整合,同時實現軟體交付和基礎設施變更流程的自動化。
DevOps不是甚麼:
- 框架、標準或方法
- 記錄在出版品中
- 分離的團隊
DevOps是:
- 一套指導原則與一套價值
- 不斷成長的集體知識體系
- 將系統系性思考應用於整個價值流
DevOps的價值
最重要的是,DevOps 是一種基於人與技術互動的文化運動,旨在改善”關係和結果”。
C.A.L.M.S 對於 DevOps 實行至關重要且非常核心。
- 文化(Culture)是指對當今定義組織和 IT 的價值觀、信念和心態需要轉變以支持 DevOps 舉措的理解。
- 自動化(Automation)相信幾乎任何事情都可以自動化,手動可重複流程應盡可能自動化。
- 精實(Lean)強調精實價值體系和方法論中的原則,以降低流程複雜性、消除浪費並簡化工作流程。
- 測量(Measurement)重點在於測量一切和建立可見且透明的流程的重要性。
- 共享(Sharing)包含了開發和維運之間協作和溝通的主要概念,使他們能夠有效地整合他們的作業努力以實現共同的目標。
DevOps原則-三步工作法
可參考"DevOps的基礎知識-Part 2"一文。
ITIL
ITIL 提供了一個最佳實踐框架,組織可以採用該框架來交付和維護 IT 服務,從而為包括客戶在內的所有利害關係人提供最佳價值。
- ITIL 是企業最廣泛接受的 ITS方法
- ITIL 為變更賦能、服務配置、部署、發布、事故和問題管理等實踐提供指導和結構
- 流程能支援實踐
ITIL的指導原則
- 關注價值
- 從你所在的地方開始
- 透過反饋進而迭代推進
- 協作並提高可見度
- 全面性的思考與工作
- 保持簡單實用
- 最佳化和自動化
指導原則是可以在所有情況下指導組織的建議。
SRE
參閱SRE — 原則與實踐一文
Lean(精實)
精實是一種生產理念,專注於減少浪費和改善流程,以提高整體客戶價值。
精實原則:
- 定義價值 — 從顧客的角度決定價值
- 對映價值流 — 對映價值流中創造價值的步驟,消除任何沒有價值的不必要步驟
- 創造流程(Create Flow)-讓步驟流暢地創造價值
- 建立拉力(Pull) — 在可以連續流動的步驟之間引入拉力
- 追求完美-努力讓事情每天變得更好一點
價值流程圖
價值流程圖直觀地描述了從初始請求到為客戶創造價值的端到端活動流程。
- 價值流程圖描繪了跨職能群組的資訊、材料和作業的高階流程,包括為客戶提供價值的時間和品質
- 價值流程圖的目的是改善流程並消除或減少價值流中的“浪費”
- 浪費是指任何不會為流程、產品或服務增加價值的活動
看板(Kanban)
看板是一種工作方法,它以可管理的速度推動(pull)整個作業的工作流程。
- 視覺化和管理工作流程
- 當團隊準備好時為他們拉動(pull)作業
- 使人們能夠協同工作以改善流程
- 減少流程中的閒置時間和浪費
- 讓作業是可見的
- 將在製品 (WIP-Work in progress) 限制為一種作業量能
為什麼 WIP 太多不好?
主要有以下幾個原因:
- 減少專注力和效率:當團隊同時處理過多的任務時,注意力被分散,導致每個任務的處理速度下降。同時多個任務處理會讓團隊成員頻繁在任務之間切換,造成背景脈絡切換成本的增加,效率降低。
- 延長交付時間:當WIP過多時,單個任務從開始到完成的時間(週期時間)會變長。因為資源被分散到多個任務上,每個任務的完成時間都被拖延。
- 增加錯誤和重工率:過多的WIP會讓團隊難以保持高品質的工作,容易導致錯誤的產生。更多的任務意味著更高的複雜性,增加了出錯和需要重工的機會。
- 降低可視化和控制能力:看板方法強調工作流程的可視化,以便團隊能夠清晰地看到任務的狀態和進展。WIP過多會使看板上的任務數量過多,難以一目了然地理解和控制工作流程,失去了看板的透明度和管理效能。
- 資源分配不均:當WIP過多時,資源可能被分散到優先等級不高的任務上,重要任務得不到充分的資源和關注,影響整體工作的優先等級和戰略目標的達成。
- 團隊士氣和壓力:過多的WIP會導致團隊成員感到壓力和負擔,影響士氣和工作滿意度。長期在高壓下工作,可能導致團隊成員的倦怠感,影響工作質量和效率。
為了有效管理WIP,看板方法通常會設置WIP限制(WIP Limit),即在工作流程的每個階段中,限制同時進行的任務數量。這有助於團隊保持專注、提高效率、保證工作品質,並及時交付任務。通過控制WIP數量,團隊能夠更好地管理工作負載,優化工作流程,實現更高效的工作模式。
Scrum
Scrum 是一個輕量級框架,可協助人員、團隊和組織透過針對複雜問題的自適應(adaptive)解決方案創造價值。Scrum 是:
- 最常用的敏捷軟體開發實踐
- 看似簡單卻很難掌握
- Scrum 提高了更頻繁發布的能力
三種角色、五種事件、三種工件
角色:
- Product Owner
- Scrum Master
- Developers
五種事件:
- The Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
三種工件(Artifacts)
- Product Backlog
- Sprint Backlog
- Increment
支柱與價值
· 透明度(Transparency) — 讓觀察者對所看到的內容有共同的理解
· 檢查(Inspection) — Scrum 工件和實現 Sprint 目標的進度,以偵測不必要的差異
· 適應(Adaption) — 當任何方面偏離可接受的限度時,必須盡快進行調整,以盡量減少進一步的偏差
詳細解釋可以參閱此篇文章。而Scrum可以總結成下圖:
Scrum是把事情完成
這是持續不斷的增量進度並提供回饋以調整下一個 Sprint。在 Sprint planning期間定義了 3 個關鍵項目:
- Sprint Goal— 為什麼這個 Sprint 有價值?
- Sprint Backlog — 這個 Sprint 可以做什麼?
- 計劃滿足完成的定義(Definition of Done) — 工作將如何完成?
完成的定義是對增量(Increment)或backlog item必須達成的預期的共同認知。