RSG Taipei 2023 LeSS Design Principles
•
2 likes•370 views
LeSS Design Principle RSG Taipei 2023
Recommended
More Related Content
What's hot
What's hot (20)
Similar to RSG Taipei 2023 LeSS Design Principles
Similar to RSG Taipei 2023 LeSS Design Principles (20)
More from Jen-Chieh Ko
More from Jen-Chieh Ko (20)
RSG Taipei 2023 LeSS Design Principles
- 1. 1
- 2. 我是誰? 2008 在大型組織玩敏捷 Agiletour 台北組織者 敏捷社群創始人 谷歌設計衝刺推廣者 敏捷三叔公 David Ko davidko@odd-e.com
- 3. • 願景 Ø 致力於用更好的方式做產品 Ø 也幫助客戶用更好的方式做產品 • 服務 Ø 開發與交付 Ø 諮詢與輔導 Ø 培訓與認證 3
- 4. 大家交流一下 • 你的角色: RD, QA, PM/PO, 其他 • 有用 Scrum 開發的 • 有多個團隊一起開發產品 • 有多個團隊一起用 LeSS 開發產品 4
- 5. 大規模軟體開發常見問題 • 1. 不知道對方在做什麼, 會重複開發元件 • 2. 最後整合才發現有問題 • 3. 彼此互相無法支援 • 4. 先做自己會的而不是最有價值 • 5. 團隊人數一直在增加 • 6. 小功能要做很久才出來, 因為跟很多人 有關 5
- 8. 2004 年 Nokia 想導入敏捷開發 8
- 9. 9
- 11. 一開始的挑戰 11 只有 1.5 個 coach 支援 10 個團隊 Nokia 都是多個團隊 完成產品
- 13. 師法前人經驗 (非理論) 13 回顧 Excel 1.0 的開發作法 回顧 VC++ 1.0 的開發作法 Daily Build Feature Team
- 14. Ericson – 對手的作法 XP and large distributed software projects 14 Source: Extreme programming examined: XP and large distributed software projects 避免進行太大的代碼合併
- 15. Ericson – 對手的作法 XP and large distributed software projects 15 Source: Extreme programming examined: XP and large distributed software projects 專注於客戶要的價值, 而非技術
- 19. Component Team 的缺點 • 循序開發 • 限制學習 • 不見得都 很忙 • 延遲交付 19
- 20. Feature Team 的設計思維 20 彼此協作 須了解 較多事情 成長思維
- 21. 世事總是有不完美 21 Feature Team A Feature Team B Feature Team C Component Team D Product Backlog ü 太專業 ü 很少用的 ü 沒空學 ü 太多元
- 22. 世事總是有不完美 22 Feature Team A Feature Team B Feature Team C Component Team D Product Backlog (1) 去 Feature Team A 一 起開發出來 (2) 各個 Feature Team 派人來開發 (3) 去 Feature Team C 指 導他們開發出來
- 23. 單一 PB, 單一 PO 23 Team Product Owner Scrum 時代 LeSS 時代 統一優先順序, 避免多頭馬車 Team Product Owner Team Product Owner Team Product Owner
- 24. 但是 Product Owner 不是操人 24 Team Product Owner LeSS 時代 BA 分擔 工作 決定最 後順序 直接面對客戶 學習領域知識
- 26. 處理開發相依性的起源 26 Daily Build Continuous Integration • 重心在程式碼 • 多人的開發程式碼會相互影響 • 利用 持續整合早點發現被影響
- 30. 30 迭代 1 迭代 2 故事 A (C1, C2) 故事 B (C2, C3) Team A 故事 C (C4) Team B 故事 D (C2) Team A 和 Team B 同時要討論怎麼用 C2
- 31. 31 如果團隊們 同時 專注在同一部分的代碼 團隊間 預期 會彼此干擾 但這樣的相依是好的 鼓勵不同團隊間: 擴大學習/系統思考/提早整合
- 32. 32 迭代 1 迭代 2 故事 A (C1) 故事 B (C2, C3) Team A 故事 C (C4) Team B 故事 D (C2) Team A 之後會改到 C2, 但是目前沒空和 Team B 討論 Team B 現在會改到 C2, 但是 Team A 沒空和他 們討論
- 33. 33 迭代 1 迭代 2 故事 A (C1) 故事 B (C2, C3) 故事 C (C3) 故事 D (C2) Team A Team B Team B 在忙別的, 沒空處理 Team A 對 C2 的修改 Team A 需要 Team B 調整 C2 的用法
- 34. 34 團隊們 不同時間 相依在同一部分的代碼 導致團隊會受到 不預期 的干擾 這樣的相依才是問題: 延遲整合/局部優化
- 36. 利用擴大學習來解決 36 Product Backlog 數目 團隊工作的 範圍 對團隊靈活 性的要求 團隊靈活性 的差距 團隊靈活性 團隊承受的 壓力 團隊 擴大學習 + + + + + + - - B2 團隊擴大學習 提高靈活性 B1 團隊靈活性 限制全局優化價值 https://github.com/yilv/LargeScaleProductDevelopmentOrganization/blob/master/Chapter4/WorkDesignChoices.md • 團隊相依狀況 • 不懂別人在做什麼 • 沒有相關技能 • 時程很趕 • 品質不佳 • ….
- 37. LeSS 如何處理 37 需求釐清 • 子需求領 域 • 多團隊 PBR • 撰寫不熟 的需求 迭代規劃 • 同地點的 會議 • 聯合設計 工作坊 • 漸進式領 需求 開發 • 搭擋編成 • 持續整合 • 程式碼共 有 迭代檢視 • 展示不熟 的需求 • 展示市集
- 39. 39 (1) 有關連的需求 大家一起來進行 需求梳理 (2) 每個需求團隊 都派代表參加 (3) 或是利用世界 咖啡館方式討論 https://www.infoq.com/presentations/less-workshop-backlog-refinement/
- 40. 對不熟故事撰寫驗收條件 40 用戶故事 1 (A|B|C) 用戶故事 2 (A|D|E) 用戶故事 3 (B|D|E) 用戶故事 4 (A|D|F) Team C (A|B|D) Team B (A|D|F) Team A (A|B|C)
- 41. LeSS 如何處理 41 需求釐清 • 子需求領 域 • 多團隊 PBR • 撰寫不熟 的需求 迭代規劃 • 同地點的 會議 • 聯合設計 工作坊 • 漸進式領 需求 開發 • 搭擋編成 • 持續整合 • 程式碼共 有 迭代檢視 • 展示不熟 的需求 • 展示市集
- 43. 漸進式領需求 43 用戶故事 1 (A|B|C) 用戶故事 2 (A|D|E) 黃色團隊 (A|B|C) 綠色團隊 (C|D|E) 藍色團隊 (A|B|E|F) 綠色團隊和藍色團隊 為了接用戶故事 2, 需要學習新技能
- 44. LeSS 如何處理 44 需求釐清 • 子需求領 域 • 多團隊 PBR • 撰寫不熟 的需求 迭代規劃 • 同地點的 會議 • 聯合設計 工作坊 • 漸進式領 需求 開發 • 搭擋編成 • 持續整合 • 程式碼共 有 迭代檢視 • 展示不熟 的需求 • 展示市集
- 45. 開發三板斧 45 持續整合 (每 30 分鐘要 push) 搭擋編程 程式碼共有
- 46. LeSS 如何處理 46 需求釐清 • 子需求領 域 • 多團隊 PBR • 撰寫不熟 的需求 迭代規劃 • 同地點的 會議 • 聯合設計 工作坊 • 漸進式領 需求 開發 • 搭擋編成 • 持續整合 • 程式碼共 有 迭代檢視 • 展示不熟 的需求 • 展示市集
- 47. 展示不熟的用戶故事 47 用戶故事 1 (A|B|C) 用戶故事 2 (A|D|E) 用戶故事 3 (B|D|E) 用戶故事 4 (A|D|F) Team C (A|B|D) Team B (A|D|F) Team A (A|B|C) Team A (A|B|C) Team C (A|B|D) Team B (A|D|F)
- 49. 總結 – LeSS 的設計 站在 巨人的肩膀 上 最大化 團隊之間的相依性 善用 擴大學習, 讓略懂略懂 > 0 49
- 50. 後續參考文章 50
- 51. Q & A