# 老闆，您敏捷和我們不一樣 - 大型混合敏捷團隊 (Scrum, Kanban) 的踩坑經驗 - 李名揚(Vincent)

{%hackmd @HWDC/BJOE4qInR %}

>#### 》[議程介紹](https://hwdc.ithome.com.tw/2024/session-page/3189)
>#### 》[填寫議程滿意度問卷｜回饋建言給辛苦的講者](https://forms.gle/cjRY2dMU45RiK26c9)

## 自我介紹

* ###後端工程師
* 現在的 scrum 證照包含許多 AI 的內容

## start with WHY
黃金圈法則 Simon O. Sinek => Why/How/What
- 要解決什麼問題？
- 知道導入敏捷會遇到什麼問題

## agenda
- 改變的起點-組織改組
- 一些好的改變
- scrum & Kanban 的團隊協作
- 周詳的計畫與微管理

## 失敗的敏捷實踐元素
- 高階：不懂為何導入敏捷的高層
- 中層：對敏捷精神不了解、學習歷練不足的推行者
- 基層：對產出品質沒有堅持的知識工作者 (How)
- 我們現在導敏捷，所以不用寫文件 (It is true?)
- 測試隨便做一下，這是 QA 的事情 (true?)
- 在每次開發要避免技術債，否則未來的開發速度會越來越慢

## 背景
### 改變的起點
技術單位
- Infra..
- 其他團隊
- 其他團隊

### 一些好的轉變

- office hour : CTO 親自主持
- lunch sharing: 一邊吃午餐，一邊分享
- 包括大規模的技術分享
- Agile Summit, MWC, GA 應用..等
- 交付週期的統一 milestone, sprint
- 2 週 1 sprint
- 3 sprint = 1 milestone
- 統一時程語言，讓討論時間與協作變得相對容易
- 整體技術單位的 Planning, Review
- 原本想要成為自負盈虧的單位
- 協作不會自然發生
- 同一套專案管理工具（Jira Cloud）
- 提升透明度

> 前提：原先每個團隊各有自己的週期，在協作上的合作會有所衝突

## 壞味道
### 壞味道之 1：Scrum,Kanban which one? 一刀切的劃分方式
- 計畫性工作：Scrum
- 忽略團隊特性
- 臨時性工作：Kanban
- 只有 2-3D 工時的工作，才使用這個方法
- Kanban 本身著重價值交付
- infra 維運團隊，常常會位於流程的最上游或是最下游
- 最上游：架構建立好，才可以接續開發動作
- 最下游：要上線前，開發團隊才想到要提架構方面的需求

### 壞味道 1：解決方式

==如果有機會在開發階段，也把架構性質的工作計畫進去，會是什麼狀況？==

緩衝區：工單系統（臨時性工作）

==No WIP Limit -> No Priority==

可以都要，但重點是：
1. 同時小批量
2. 順序性

### 壞味道之 2：周詳的計畫與微管理
Milestone planning『所有的』工作都要展開
- 優點：鼓勵協作與透明化
- 缺點：過早的計畫與拆分造成庫存
- 發生越近的，可以越仔細拆分 (maybe 這樣解決)

=思考：scrum guide 對於需求的說法：需求是湧現的=

### 壞味道之 2 解決方式／思考

- 微管理
- sprint goal: 一個好的通常是商業目標
- 對單獨的工作項目，討論工時的合理性？重點應該是目標是否有達成
- e.g. 獲取 100 個客戶
- Review 燃盡圖
- 過度追求：補工作，移動 ticket
- 過度追求完成工作，搞不好都是完成一些不是很重要的工作
- 重點仍在於有沒有完成商業價值

### 壞味道之 3：我們是釘子戶 - 工時 StoryPoint
- 費氏數列 VS. 工時
- 嚴格來說 story point 不是 Scrum 必要條件
- 真正要思考的是：為什麼要做估算

工時每個迭代幾乎是固定的，用工時無法體現速率的改變
估點是需要時間學習熟悉，人是有學習潛能
原文：一樣的邏輯，複雜度不同人來開發都是一樣的：junior:16, senior:2 這個 2/16 是有意義的嗎？
> 應該是指用複雜度來作為 storypoint 對不同程度的開發者才是共同的？

講員回答：是，然而這個對複雜度的定義是需要團隊有共識的。這個共識一般來說，需要花一段時間建立
以我們自己團隊的實踐經驗，兩週一次的 Sprint，也是大約實踐 4 到 6 次後，經過這些練習與熟悉，才形成了比較具體的團隊對於複雜度的共識
時間約莫是經過 2 到 3 個月，才逐步成形

## 規模化 Daily
- 顯示化流程規則
- 注重時間控制（盯著錶開始）
- 共同決定
- 迭代、不斷迭代
- 透過獎勵機制提升趣味（第一位到的夥伴有額外獎勵）

## Planning 協作討論

- 成熟度 0：沒有討論、做到某些需要配合的工作，才趕快提出協作需求（衝突上升 :up:）
- 成熟度 1 層：有先告知預計需要配合，沒有說明工作範圍（scope），與具體配合協作項目（潛在風險）
- 成熟度 2 層：有先告知預計需要配合，有說明具體配合協作項目，沒有做評估和協調時程
- 成熟度 3 層：有先告知預計需要配合、有說明體配合協作項目，有做評估和協調時程

> 看產出不看燃盡圖

講員( Vincent ) 補充：擔心我演講中的內容沒有解釋清楚，做一個簡單的小補充
並不是說完全不觀測燃盡圖，燃盡圖還是很有效的觀測數據的工具，應該有效的利用它，來找出一些趨勢和好/壞現象
只是不應該把全部的重點放在呈現完美的燃盡圖
重點是 sprint goal 是什麼 (最好是一個具體的商業目標)，看我們的目標是否有效達成
( 開發或是調整軟體功能只是達成目標的可供選擇的手法之一 )

## 公司政策和我們團隊的實踐，差異在哪裡？

| | 公司政策 | 團隊實踐 |
| -------- | -------- | -------- |
| Daily | - | 今日作戰計畫 |
| 後續效應 | - | 共同優先級與目標，團隊更聚焦 |
| Planning | 詳細的計畫與微管理，有分工卻缺少協作 | 對焦目標，處理相依性與協作，相信團隊自主管理 |
| 後續效應 | 過早的拆分造成庫存與浪費 | 自我管理能力 :up: |
| Review | 觀測燃盡圖，焦點在工時花在哪裡，重視和計畫的吻合程度 | 在意實際產出，讓夥伴主動分享 |
| 後續效應 | 在意產能（Throughput） | 注重價值（Outcome） |

## 還想繼續做哪些嘗試？

- PO 間的交流與討論
- 跨團隊障礙與紀錄排除
- 除了小團隊 retro 整體的 retro 可以再做更多