# 【DevOps入門班】超越直覺：產品交付階段的數據驅動科學 - Juggernaut (RSG Taipei 2021 總召)
{%hackmd @DevOpsDay/B1cnefOI0 %}

#### 》[議程介紹](https://devopsdays.tw/2024/speaker-page/247)
#### 》[填寫議程滿意度問卷｜回饋建言給辛苦的講者](https://forms.gle/oosrKbEM4NwPwhVn7)

> 共筆從這開始

- slido
- https://app.sli.do/event/enmLmpSxmZBKCzHwf1sSFo/live/questions?clusterId=eu1

## 什麼是「產品科學」？

運動科學已經很流行了，尤其在美國提升運動員表現，例如 NBA、MLB，以及在美式足球比賽裡，運動員會在嘴裡放感測器，在根據過往記錄去測量當下這個隊員可受撞擊的程度。

#### 還有什麼ＸＸ科學的例子？

ex: 西方醫學 vs 整骨，傳統師傅 vs 科技抓漏...

那產品開發呢？還在依賴直覺嘛，還是可以透過科技的方法來決策。

## 我的敏捷覺醒之路

- 「守」
- 2013 便利貼
- 2017 開始帶團隊
- 「破」
- 2019 引導/工作坊，多團隊經歷
- 2021 遠端/混合 線上工具
- 「離」
- 2023 科學化 data-driven

## 產品交付三階段

今天 focus 在「產品交付」階段

## 產品科學的願景與價值

願景：基於科學的原理和方法，協助人們在產品開發上輕鬆做出更好的決策。

價值：
data driven over output driven
data-driven over gut feeling
having insights over owning data

資料是為了協助我們產生 insight，而不是最終結果

## 產品科學的原則

- 有條理地探索
- 理性的規劃
- 務實的交付
- 科學的驗證

> 問：你們的 Scrum/Kanban/DevOps跑得如何？(Slido 答：40 % 普普通通)
> 

> 怎麼定義「好」？

## 敏捷的迷思

實施敏捷就代表不規劃嗎？

## 如何預測
- 團隊 capacity
- 跨團隊相依性
- 投資組合（portfolio)
- 細節模糊 * 在這個階段肯定是模糊的，會慢慢釐清
- 緊急狀況

### 團隊的 Capacity 如何？
- 項目數量
- 計算最簡單
- 但你的 1 不等於我的 1（每個項目的難度等級不一樣）

- 相對程度（Story point/Size) * 比較推薦用這個
- 也算簡單
- 透過相對比較
- 考慮複雜度
- 1 點 ＝ 幾天？
- 工時
- 最難預估（只要搬出實際的時間，大部分都會估比較大的 buffer）
- 最難預估
- 相對精準
- 要花太多時間去估算
- 沒有成長性（相對Story point來說）

### 投資組合

切換成各種維度來檢視季規劃的組合

> 迷思？這不就是瀑布嗎？

- plans are nothing, planning is everything.
- 我們依據的是 capacity 不是甘特圖

## 一個 sprint 能做多少事情
- definition of 'done'
- 零碎的事情要記嗎。
- 避免日復一日，sprint 復 sprint
- 團隊要穩定
- 100% 完成率是好事嗎？（感覺是好事，但其實不是，代表我們估的太簡單了，團隊還有突破的可能性）

## sprint 期間，可以檢視什麼?

- burndwon chart
- sprint 完成率
- 打擾數量
- 項目做多久了
- PR Slots
- 狀態比例

> burndown charts - 還在追求完美的斜率嗎？但每個團隊的狀況都不太一樣

> 每個 sprint 的完成率都好棒，但...客戶還不能使用

### Story Point 會通貨膨脹，但 Cycle time 不會

### 追求速度，但忽略了品質

### 所有 bug 都要解嗎？

解了多少 p1 bugs, p2 bugs
還沒解的成為隱憂
一但數量一多，就覺得有些怪怪的

## 團隊的工程能力如何？

DORA Metrics - 兼顧速度跟品質
* Deployment Frequency
* Lead Time for Changes
* Change Failure Rate
* Time to Restore Service

> 部署好之後，怎麼知道沒有問題

SRE Golden Signals
* Traffic
* Errors
* Latency
* Saturation

retrospective meeting 時用證據來說話
* 雖然市面上已經有五花八門的各式引導手法
* 印象派還是數據派？

### 敏捷方法與數據驅動的項目管理
#### 多維度檢視項目
使用不同的維度來檢視和規劃項目，例如主題、團隊、類型等。
#### 理性規劃
在規劃項目時，考慮平衡和比例，並使用圖解來檢視規劃是否達成目標。
#### 敏捷方法
強調計劃的重要性，但也要靈活應對變化，並根據容量而非時程來安排項目。
#### Spring規劃
使用Jira來規劃和追蹤Spring的進度，並確保每個項目的完成定義清晰。
#### 避免Spring for Spring
避免將未完成的項目無限期地推到下一個Spring，應重新調整和思考每個Spring的目標。
#### 完成率與估算
完成率過高可能表示估算過於保守，應該挑戰團隊的極限，通常抓80%的完成率。

# 最後想說的話
> 科學就是假設, 實驗, 收集數據, 分析, 再繼續調整
> 別人已經在上太空，我們不要再殺豬公

###### tags: `DevOpsDays Taipei 2024`