# 企業應用敏捷的七個模式 - 徐柏峰

> 從這開始共筆，您可以分享任何聽到、學到的事物

:::info
針對求新、求快、求變的產業，不論是開發創新產品，優化既有流程還是進行數位轉型，敏捷是眾所公認最「有道理」（making sense)的協作方法，敏捷團隊的角色、活動和產出，已經是團隊協作的最佳實務。本次講座，邀請資深企業敏捷教練，分享2009年起協助36家公司轉型敏捷的過程中，最常見的幾種敏捷模式，不論是敏捷新手還是已經有經驗的老司機，都能獲得啟發。
:::

# 敏捷宣言的背後含意

- 敏捷的由來，敏捷軟體開發宣言：
- 個人與互動重於流程與工具
- 可用的軟體重於詳盡的文件
- 與客戶合作重於合約協商
- 回應變化重於遵循計畫
- 敏捷宣言後，2001年經濟學人發表《Agile Count》以後是敏捷說了算的時代
- 再之後不同行業的人都在敏捷了

## 敏捷宣言就是**簡單的規則**

> 面對複雜又持續演變的情境，授權團隊依據「簡單的規則」自主做決定

老闆不會樣樣都懂，也沒時間事事下決定

才能增加活下去的機會

這樣比較敏捷

- 自然界的例子：幾百萬隻鳥依據簡單的規則，快速變化隊形，增加活著的機會
- 交通的例子：圓環運作規則，是複雜又會演變的系統。

-> 敏捷就是針對複雜又會演變，創造一個環境讓員工自主做決定

# Scrum 是敏捷世界的「最大公因數」

## 3個簡單規則
1. 每個迭代結束前都交出實際的成品
- 是真正可以用的東西
2. 根據成果調整後續需求，優化產品
- 終端用戶用起來如何，根據結果調整未來的需求，讓需求越來越得分
- outcome != output
3. 團隊持續探索優化合作效能的方法
- 讓團隊為自己的scrum 負責

> Scrum is like your mother-in-law; it points out all your faults.

Scrum 敏捷像是面鏡子，若兩週做不出來，可以照出應該要從何調整

Scrum 是體檢報告，讓你看出來每次要調整的項目

# 敏捷轉型是轉變體思維

不會說導入敏捷，而是轉型
1. 每個迭代結束前，都交出實際的成品
2. 根據成果調整後續需求，以優化產品
3. 團隊持續探索優化合作效能的方法
- 問團隊說：我們可以持續做什麼改善的方式

轉型非常困難，實戰要花很多年，每家公司都不一樣
- 小公司轉型是增肌：例如找full stack
- 大公司轉型是減脂：例如：減少重複的工作

# 企業應用敏捷的七個模式

## 模式零：口說敏捷
- 不調整流程只壓縮交付時程
- 每日站立會議
## 模式一：工具敏捷
- 既有的report line 沒變，只用工具來做敏捷
- 立會變成純粹報告進度
## 模式二：敏捷規劃
- 用敏捷方法定義需求，開發流程照舊
- 沒有排IT資源
## 模式三：混種開發
- 需求和驗收流程照舊，只有開發流程應用敏捷
- 只是中間壓時間，而不是每個迭代都有實際的成品
## 模式四：雙環敏捷
- 需求與開發各組敏捷團隊頻繁對焦，一起前進
- 沒有reorg，約定好需求與開發團隊每兩周見面，讓需求方陳述已經準備好的需求，測試有問題會滾到下一次迭代。每天會有兩場會議，內部一場，團隊間同步一場。
- 台灣多數金融公司開始的方式，在reorg前運作還算順利，但要注意
- 不要分你們我們，因為長久希望變成同一個team
- 小心瀑布的文化跑回來
## 模式五：敏捷工廠
- 跨部門成員短期內集中辦公，使用公司的敏捷資源
- 有經驗的人當coach，希望能擴散
- 在台灣要注意的是
- 考績沒有對標
- 不要搞 train the trainer，要的是實戰的人不是講師
## 模式六：敏捷戰情室
- 組成臨時性的跨職能部門，執行全公司最重要的敏捷案
- 加入者有戰情室光環，但事情仍是帶回原部隊做
- 打考績大小眼，無法抵抗人性
- 沒有目標淪為追業績部門
## 模式七：共同敏捷
- 跨職能團隊，每個迭代都交付實際成品
- 是跨職能團隊，真正的敏捷。
- 耗時多年，需要組織重組
- 亞洲人不習慣自主做決定的文化

從模式零到七轉型的力度越後面越強

# 敏捷轉型成功的關鍵
1. 老闆管理原則
2. 原則管理團隊
3. 團隊自主做決定

# Q&A

- 已經中了 WaterScrumFall 的招，這毒怎麼解？
- 如果公司不想改變本來的分工跟合作方法，而希望能變更快速，需要審慎思考是否可能
- 用實際的成果建立credit，讓長官看到真正的東西

- 請問沒有培訓內部種子講師，要怎麼擴散敏捷文化? 都花錢找外面顧問嗎?
- 老師七年前在國泰人壽的經驗，沒有找顧問而是帶著團隊找實際使用者，在做中實戰。
- 一開始培育六個人，要擴散時再分兩組，透過細胞分化的分法擴散

- 在迭代過程中, 假設可用成品優先於制定文件規格, 但文件規格在商業交付, 或是內部交接, 也算重要的工具或窗口'媒介, 所以想問迭代過程中該如何衡量成品與文件產出的關係? 比如是該考慮產出時間先後? 或是成品與文件品質的百分比? 或是該等迭代收斂後再收斂文件規格嗎? 謝謝
- 文件有多種 best practice
- Dodument Late：讓兩人在同一隊，甚至坐隔壁，便能很快做出實際東西。可拿真正會動的截圖結果再回頭補文件
- 倒過來做，先留填空，文件再回頭記做完的結果

- 大公司執行敏捷要減脂，但大公司的法遵、稽核流程一點都不能少，怎麼辦？
- 老師做智能理財的經驗，20~30跨部門的人聚在一起一個月，有刻意找法尊、稽核部門加入，成為隊員一起創需求。

- 請問雙環敏捷的運作方式是「每天」都有規劃和回顧的概念存在嗎？是不是developers和POs一起持續讓需求不斷前進的感覺？
- 立會：兩邊同時開會，開完後再與對方對接
- 不是每天retro，是趁立會時兩邊同步

- 要讓團隊變成一個Team，是不是一定得把PO, RD, QA Reorg為同一個整體團隊？
- 讓共事的人互打考績
- 派出的單位也要為派出的人員考績負責