###### tags: `敏捷`
## 共筆快速入門
https://hackmd.io/s/quick-start-tw
<font color=#f00>**如果有需要貼入圖片可以直接螢幕截圖放到本共同筆記裡,如以下影片示範**</font>
[https://youtu.be/W2tIBZiTYR0]
如果換字體顏色, 把以下程式碼拷貝來改即可
* <font color=#f00>紅字</font>
* <font color=#00f>藍字</font>

* <font color=#390>綠字</font>
## 主講人簡介


# 個人簡介


# 大家都想知道

今天的主題會討論 4 個圈起來的問題。

# 什麼是 FLOW METRICS



flow metrics 不是衡量產品的價值，而是衡量團隊從產生想法到產出價值的整個過程所需要的時間


flow metrics 可以協助衡量價值產生的過程是否良好，
根據公司的型態，可採取不同的衡量因子。有 5 個主要的衡量類別
- 功能
- 缺陷
- 風險
- 依賴
- 技術債

可以衡量
- 類型 flow distrubution
- 速度 flow velocity
- 時間 flow time
- 效率 flow efficiency
- 負載 flow load (團隊同時間要負責多少工作項目)

回到 SCRUM TEAM 我們可以怎麼應用 flow metrics

# 實際案例


以 Sprint 4 為例
- 20 個 Bug Fix
- 7 個 User Story
- 4 個 Task
- 1 個 其它項目

# FLOW DISTRIBUTION
你可以給團隊什麼建議呢？

UAT 在 sprint 4 ，所以有許多 BUG 出現，需要壓低 User Story 的數量，額外來處理 BUG


從圖表，我們就可以發現許多的問題，可以加以改善。

# FLOW VELOCITY
以 FLOW VELOCITY 圖表來看，可以給團隊什麼建議呢？




# FLOW TIME
以 FLOW TIME 圖表來看，可以給團隊什麼建議呢？



由這張圖可以發現
這個團隊花了很長的時間在討論需求然後才交付開發。
所以這個團隊很可能仍然是採取 waterfall 的開發方式。

# FLWO EFFICIENCY
以 FLOW Efficiency 圖表來看，可以給團隊什麼建議呢？

Efficiency = Development Time / Done Time

以 sprint 1 為例： 50% = 5 / 10


從 spritn 1 到 sprint 6，可以發現這個開發團隊已經開始懂得如何運用敏捷來進行開發。

# FLOW LOAD
以 FLOW LOAD 圖表來看，可以給團隊什麼建議呢？



工作負載理想狀態應該是高低起伏，然後維持一個平穩的振盪狀態。
UAT 工作項目持續累積，這是一個應該要解決的問題。

# FLOW METRICS 很好用，不過…


flow metrics 很好用，但是用的不好會造成更多的問題，造成團隊的壓力。

數字高低不代表絕對的好與壞，更重要的是
- 趨勢
- 相對數值比絕對數值重要
- 數值只是參考 (ex: 團隊 A 的 velocity 是 10，團隊 B 的 velocity 是 20，不代表團隊 B 比 團隊 A 好)
- 了解和成長 (解決問題比較重要)

結論：數字不是絕對的好壞，用數字去理解發生了什麼事情更為重要