Recommended
More Related Content
What's hot
What's hot (20)
Similar to 以 PM 角度來看轉型 Agile 的歷程，與那些踩過的坑
Similar to 以 PM 角度來看轉型 Agile 的歷程，與那些踩過的坑 (20)
以 PM 角度來看轉型 Agile 的歷程，與那些踩過的坑
- 1. 以 PM 角度來看轉型 Agile 的歷程，與那些踩過的坑 CJ @ ProductTank#10
- 3. 從 PM 的視角，分享改善開發流程的過程中... ● 我們每階段嘗試的做法 ● 採用敏捷開發，PM 你該注意的事
- 4. A Squad B Squad D Squad C Squad PO / PM Designer Developer QA ● 從 Startup，逐漸轉型中小型公司 ● Squad 制度，跨功能小隊 ● 共同目標，各自行動 x1 x1.5 x3 x1
- 6. ● 契機：不滿現狀 ○ 需求不定時提出 ○ 時程常常延誤 ● 凝聚共識，是推動流程改善的第一步 ○ 透過 Brainstorming，彙整團隊意見與問題 ○ 大家一起來，增加參與感（發洩意見） ● 不要一開始就導入新流程
- 8. ● 先採用看板 ○ 容易採用 ○ 作業情形一目瞭然 ○ 針對大家提出的問題，觀察原因何在 ● 看板幫助你看到瓶頸 ○ 有人吃太多 Task，負荷不了？ ○ 工作是否停留過久，都卡在哪？
- 9. ● 看板讓我們知道： ○ 頻繁的插單跟額外的 Task，讓發版時間不穩定 ○ 規格要幫助使用者解決什麼問題，大家並沒有共識 ● 看板也讓我們感覺到： ○ 板子沒有時間感，會沒有完成目標的感覺，團隊無法專注
- 10. 階段二 階段三 歷程 階段一 階段四 • 開發流程不順，與團隊共同找出問題 • 導入看板，先讓工作透明 • 轉型 Scrum，聚焦目標
- 11. ● 採用 Scrum ○ 固定開發週期，為每個 Sprint 設定要達成的目標 Sprint = 2 週 ● Sprint Planning 會議 ○ 設定目標 ○ 選擇要做的 Story ● Sprint Review 會議 ● Retrospective 會議
- 12. ● 採用 Scrum ○ Task → User Story ○ 重點：溝通使用者價 值 / 商業價值，以及驗收標準 身為一個 “特定角色”，我希望/想要 “特定功能”，讓我能/幫助我 “得到某種價值“
- 13. ● 討論跟選擇 Story 時： ○ 著重使用者的問題解決，而非技術 細節或功能 ○ 多問 “使用者的目的是什麼？他 要解的問題是什麼？ ”
- 14. ● 拆解跟執行 Story 時： ○ 根據 Story 目的，討論有效率的做法 ○ 多問 “如果這張 Story 的目的是 XX，我 們需要做 Task2 嗎？” Task1 Task2 Task3 Task4 Task5
- 15. ● 不要隨便亂寫 User Story ○ 增加無所謂的工作，不針對目的做事會讓 產出沒有效率 ○ 不知道完成的標準與品質 ○ 交付價值不明確
- 16. 跑一陣子 Scrum 後，我們又發現： ● 見樹不見林，無止境的 Sprint？ ○ 沒有產品策略，亂塞下個 Sprint 的 Story ○ 大家總是會問：之後會不會改？設計會變動嗎？ ● PM 只要寫寫 User Story 就好了？ ○ 當有一堆 Story 時，哪個要先做，效益比較大？
- 17. 階段二 階段三 歷程 階段一 階段四 • 開發流程不順，與團隊共同找出問題 • 導入看板，先讓工作透明 • 轉型 Scrum，聚焦目標 • 採用 Impact Mapping 工具，作為每個 Sprint 的進攻策略
- 20. Source: 2012, Gojko Adzic, “Impact Mapping”
- 21. ● 以終為始，展開 Impact Map ○ 每個 Sprint 都是透過 Impact Map 驅動 ○ 每季開始前： ■ 與利害關係人溝通目標 Goal Revenue 1.2M
- 22. ● 以終為始，展開 Impact Map ○ 每個 Sprint 都是透過 Impact Map 驅動 ○ 每季開始前： ■ 與利害關係人溝通目標 ■ 跟團隊一起打造 Impact Map
- 23. ● 以終為始，展開 Impact Map ○ 每個 Sprint 都是透過 Impact Map 驅動 ○ 每季開始前： ■ 與利害關係人溝通目標 ■ 跟團隊一起打造 Impact Mapping ■ 排序路徑優先順序 1. 找出對目標效益（影響）大， 成本小 2. 哪些角色能幫助 / 阻撓你？
- 24. ● 好處 ○ 團隊清楚了解產品脈絡 ○ 開發：提早知道哪些機制要先研究或準備 ○ 設計：可以事先了解的設計如何連貫 ○ 老闆：知道你的進攻策略
- 26. Source: 2012, Gojko Adzic, “Impact Mapping”
- 27. 定期了解成效，再思考如何調整 Impact Map ● 對目標有效益，思考是否做深或延伸 Story？ ● 對目標沒效益，快點換另一條路徑？ 驗證 假設
- 28. 這段歷程，我們花了近兩年，並且持續調整 • 開發流程不順，與團隊共同找出問題 • 導入看板，先讓工作透明 • 轉型 Scrum，聚焦目標 • 採用 Impact Mapping 工具，作為每個 Sprint 的進攻策略 2016 / 10 2017 / 03 2016 / 07 2018 / 1
- 30. 對 PM 的要求 敏捷流程是一面照妖鏡，也照的 PM 不要不要的
- 31. Scrum 不是只有每個 Sprint 塞 Story 進去
- 33. ● 思考全局的產品路線圖 ○ 戰略層，專注結果如何進攻 ○ 目標如何制定？ ○ 有哪些進攻策略與路徑？ ○ 哪一條最有可能成功？ 你需要的能力 Source: https://www.impactmapping.org/drawing.html
- 34. ● 妥善安排你的 Release Plan ○ 戰術層，專注如何有效 產出 ○ 如何決定下一個 Sprint 的內容？ ○ 哪些 Story 要先做？ 你需要的能力
- 35. Sprint1 - [Develop] Story 1 - [Study] Story 2 - [Infra] Story 3 ... Sprint2 - Release Story 1 Sprint3 - Release Story 2 Sprint4 - Release Story 3 Sprint5 - Release Story 4 Sprint6 - Release Story 5 一季中，有六次發布 ● 妥善安排你的 Release Plan ○ 根據 Imapct Map 路徑的優先順序，往回逆推： ■ 先考量最有效益的 Story ■ 排序發布時間點 ■ 再思考 ● 是否需要基礎設施 ● 是否需要研究 / 實驗 你需要的能力
- 36. 小技巧：定義不同類型的 Story ● Product：規格明確，直接 impact 結果，直接做。 ○ 身為一個 “特定角色”，我希望/想要 “特定功能”，讓我能/幫助我 “得到某種價值“ ● Infra：產品基礎設施，是一種未來的投資。 ○ 身為一個 “特定角色”，我希望/想要 “特定功能”，讓產品 “得到某種價值/改善“ ● Bug：明顯錯誤，需要修復。 ● Study：價值有，但還不明確的，用有效的方法驗證 ○ A/B Testing ○ User Research / Interview / Kano ○ POC (Proof of Concept)，技術可行性驗證
- 37. Sprint1 - [Develop] Story 1 - [Study] Story 2 - [Infra] Story 3 ... Sprint2 - Release Story 1 Sprint3 - Release Story 2 Sprint4 - Release Story 3 Sprint5 - Release Story 4 Sprint6 - Release Story 5 一季中，有六次發布 ● 為什麼要這樣做？ ○ 你不可能有時間完成所有策略 ○ 沒辦法每個 Story 都去做研究 / 測試 ○ 考量你的資源，評估你的目標是否合理，達成機 會多高 你需要的能力
- 38. 軟技能，不能少 ● 向上管理 ○ 主動溝通目標與產品路線圖，而非上對下接單 ○ 主動溝通下一個 Sprint 的優先順序，而非討論何時做完 ○ 要插單，先來比較價 值有多少
- 39. 軟技能，不能少 ● 跟團隊，有效率的溝通是你必備技能 ○ 有效率的開會 ■ 掌握時間，設計流程，事先準備 ○ 文件也是溝通的一種 ■ 清楚的 SPEC，不管在哪種流程都是必備 ○ 解決方案的討論 ■ 先溝通結果 > 現況是什麼 > 有哪些做法 > 選哪個，叫誰做，何時做
- 41. 身兼 Product Owner 跟 Scrum Master 好嗎？ ● Scrum 的詮釋權 ○ 小心利害關係，最好讓專業的來 ○ 引導的功夫要先有，否則事倍功半 ● 你有更重要的事情要專注 ○ 顧好你的產品策略
- 42. 多費心在自省會議（Retrospective） ● 流程不會馬上變順，一開始都會有陣痛期 ○ 心態：多一點耐心，讓子彈飛一會兒 ○ 多多觀察一開始不順利的現象，通常都是最明顯的問題 ○ 流程不用一次到位，視情況調整 ● 進步，來自於紮實的 Retrospective 與改善執行 ○ PM 被打臉沒關係，這是信任的展現 ○ 對事不對人，別害怕衝突。專心在問題解決上 ○ Retrospective 是需要練習的，Retro 你的 Retro
- 43. 最後
- 44. ● 採用敏捷前，先問：你要解決什麼問題？ ○ 從瓶頸先下手，找出問題 ○ 任何方法都只是工具，別把手段當目的 ○ 沒有什麼流程改革是馬上見效的，多關注團隊的回饋，進行調整 ○ 多思考公司戰略與目標，再搭配適合的流程
- 45. 推薦書單
- 46. Impact Mapping 的介紹，教你如何使用以及告訴你如 何執行 Impact Mapping 的會議技術 詳細介紹看板的用法。是一本實用的工具書，可以 很快上手
- 48. Thank You