# 從 VSM 到 DevOps 指標了解交付能力 - 楊琬晴 (Rose Yang)

{%hackmd @DevOpsDay/BJXaW1_k6 %}

講者：Rose Yang
官網：https://cpht.pro

## 提升交付能力？
> 做到下列想法，能夠提升交付能力？
- 增加自動化比例
- 點滿工程師技能樹
- 加入好的工具（人）

### 一個軟體服務的誕生
軟體服務的**價值流**
- 從商業夠想到向客戶交付價值，所經歷的一系列流程活動

### 陷入盲點
- 專注在價值流中的局部環節（局部優化）
- 改善不一定解決貧頸點
- 缺乏共同的目標、多頭馬車（每個部門、人員的目標項目不一致）
- Burnout

### 理解了流向，下一步是？
引用 Peter Drucker:
> If you can't measure it,
> You can't improve it.

### 價值流程圖(Value Stream Mapping, VSM)

VSM是從製造業過來的
- 設計與分析
- 開發
- 程式碼整合
- 開發節奏落差
- 經驗、任務顆粒度
- 高耦合
- 大批量合併
- 程式碼衝突、審核等待
- 單元測試
- 部署到預備環境
- 端到端測試
- 需求落差
- 資源（人）等待
- 部署到正式環境
- 流程等待
- 資源（人、運算資源）等待
- 部署相依性

**從關鍵指標，識別整體流程的瓶頸與浪費**
**評估關鍵指標**
1. 前置時間（Lead Time）
2. 處理時間（Process Time）
3. 完成率與準確率（%C/A）

### DORA - 軟體交付與維運績效指標
- 開發
- 提交程式碼（前置時間開始計算）
- 整合
- 建置
- 測試
- 部署
- 部署頻率
- 維護
- 變更失敗率
- 可靠性

### Devops績效：
> 來自 Google dora 2022 年度報告
- 部署頻率
- 前置時間
- 平均復原時間
- 變更失敗率

### 希望要有更好的績效
**把指標當成目標時，會失去指標的意義。**
- 失衡的指標
- 虛榮的數字（工程數據）
- 缺乏理解設立指標的用意
- 缺乏識別團隊、服務等特性
- 不願調整指標
- 變相鼓勵團隊間競爭 > 團隊內改善
- 與商業目標脫鉤

指標，是用於讓團隊改善的方向

### 以業務價值為目標
> OKR
- O 目標：改善延遲交付，提升客戶信賴度
- KR 關鍵成果
- 優化前置時間
- 減少批量大小
- 建立採取行動
- 需求
- 小粒度的需求（垂直切割）
- 需求不應該大到三、四個月才能完成
- 開發
- 小步迭代（短週期分支）
- 低耦合架構
- 交付
- 保持可發佈狀態
- 部署與維運
- 可靠性
- 有意義且可採取行動的監控機制
`可以不要把什麼都往slack送了嗎`
- 觀察哪些工程指標
- 需求
- 總產出量
- Story point
- 燃盡圖
- 開發
-

## DORA 三個面向的平衡
- 產出量
- 穩定性
- 可靠性

### 影響交付與維運績效的面相
- 流程（協定）
- 情境：跨團隊的交接與等待
- 前置時間
- 部署頻率
- 技術（手段）
==技術很酷想要導入->團隊可以支撐這個技術嗎==
- 情境：拼裝了一條可用但只有少數才懂的工具鏈
- 監控（指引）
- 情境：Info, Warning, Critical 無差別攻擊的資訊
- 文化（支持）
- 情境：對「人」不對事
- 可以多了解 威康定律

**DEVOPS為什麼會失敗->文化問題**

書籍：devops handbook

==平衡取決於context==

==指標要回歸業務目標==

----