Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scrum gathering 2014sharing v4

774 views

Published on

  • Be the first to comment

Scrum gathering 2014sharing v4

  1. 1. Scrum Gathering Shanghai 2014 與會分享 分享者: David Ko
  2. 2. 大綱 • 大會簡介 • 議題分享 • 與會感想 • Q & A
  3. 3. Scrum Gathering • 由非營利組織 Scrum Alliance 所發起 • 由社區主導和自負盈虧 • 以 Scrum of Scrum 方式跨地區合作
  4. 4. Scrum Gathering China 歷史 • 2008 上海/杭州/成都: (9/20): 50 人 • 2009 上海 (12/12): 100 人 • 2010 上海 (4/19-20): 200 人 • 2011 上海 (6/24-25): 400 人 • 2012 上海 (6/7-9) • 2013 北京(6/29-30), 上海(7/3-5), 蘇州 (7/6) • 2014 上海 (6/5-7): 300+人 http://www.slideshare.net/shiningxyy/story-of-scrum-gathering-in-china
  5. 5. 偉大的志工
  6. 6. 組頭: 李清玉
  7. 7. 大會日程 – 工作坊
  8. 8. 大會日程 – 6/6-6/7
  9. 9. 經濟合理的 Scrum • Speaker: Ken Rubin • Essential Scrum – #1 Bestselling Agile Book in Amazon • Certified Scrum Trainer
  10. 10. 餐廳經營模式
  11. 11. 餐廳故事的啟示 • 所多組織 Scrum 執行的不錯, 但是並沒有反應到商 業營收上面 • 因為他們 – 沒有掌握 Scrum 基本原則的精髓 – 也不知道如何以經濟合理的方式來運用 單只有 Scrum 不足以成功, 經濟合理的 Scrum 才行
  12. 12. ScrumBut • 我們用 Scrum, 但是 …… – 8 周一個 iteration – 沒有產品負責人 – 不是每天召開每日例會 – Iteration 規劃會議花了 2 天 但沒有違背 Scrum 就一定會成功嗎?
  13. 13. 人們在運用 Scrum 時 常不知道為什麼要這樣做 以及何時去採用這些方法
  14. 14. Economics – 是產品開發共同的語言
  15. 15. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
  16. 16. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
  17. 17. 何時可以改變?
  18. 18. 經濟合理的變化
  19. 19. 及時 (JIT) 的誤解
  20. 20. 平衡前期預測與及時調整 預測 混亂 產品類別 開發的限制 方法的不確定性
  21. 21. 識別庫存的浪費 • 工廠的庫存物理上和 財務上都容易看見 • 知識資產物理上和財 務上都不可見
  22. 22. 關注接力棒而非運動員
  23. 23. 團隊一起快速交付價值給客戶
  24. 24. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
  25. 25. 下游系統不配合
  26. 26. 內部管理不一致 • 只有開發是 agile • 其他都是事先就要提供精準的規劃 吃碗裡看碗外
  27. 27. Sales 無法配合
  28. 28. 合作夥伴無法配合
  29. 29. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
  30. 30. 減少多工的現象
  31. 31. 擁抱多技能的團隊
  32. 32. 永續的團隊 • 彼此間信任及有默契 • 比新組成的團隊更有生產力 • 因為有默契導致產出更有效率更有品質 • 在評估時有歷史資料可以參考
  33. 33. 當人很多時, 如何切割團隊? • 依角色分割團隊 (畫面設計, 開發, 測試) • 依所在位置分割團隊 (美國, 臺北, 日本) • 依架構分割團隊 (前端, 平台, 資料庫) • 依元件分割團隊 • 依功能團隊
  34. 34. 根據經濟效益展延團隊 而非教條 • 老實思考何種組合會產生最大的利益? • 沒有單一做法可以適合所有狀況
  35. 35. 總結 • 利用被證實過的方法 來實施所有 Scrum 的 practices • 運用 Scrum 要基於敏 捷核心原則, 以及思考 合理的經濟效益 必要但是還不夠
  36. 36. 敏捷, 請卸下你的重鎧 • 騰訊外聘顧問 • 卸下重鎧 – 不要因為最佳實 務讓你動彈不得 • 輕裝上陣
  37. 37. 騰訊電腦管家
  38. 38. 現狀與目標 • 理想 – 2 周一個 beta 版本, 每個月發佈一個穩定版本 • 現實 – 各種延遲, 2 – 3 個月沒有穩定版本可發佈 • 目標 – 1 天 2 個 beta 版本, 每個一個候選穩定版本
  39. 39. 目前開發流程 • 6 周一發
  40. 40. 遭遇的問題 • 整合很慢 • 因為 iteration 的關係, 系統常常不穩
  41. 41. 第一招: 架構重整 • 花 2 -3 月重新調整架構 • 這段時間幾乎沒有任何發佈
  42. 42. 改善結果 • 5 周一發
  43. 43. 第二招 交錯開發 • 2.5 周一發
  44. 44. 接下來的問題
  45. 45. 第三招 組織架構重整
  46. 46. 改善結果 (1) • 單線 3 周
  47. 47. 改善結果 (2) • 交錯開發約 2 周
  48. 48. 下個難題 • 互相影響需要更快知道
  49. 49. 第四招 建立配置表
  50. 50. 改善結果 • 2 天一發
  51. 51. 第五招 自動化體系推動高速發展 • 自動建構系統 • 自動化測試 • 自動環境部署 • 一鍵發佈 • 一鍵回滾 • 自動監控
  52. 52. 目前結果 • 一天雙發
  53. 53. 結論 • 技術架構解構 • 組織架構解構 • 配置管理體系 • 自動化體系
  54. 54. 百度知道研發能力三級跳揭秘 • 講者: 李忠利 • 百度高級架構師 • 有翻譯以下書籍 – 管理3.0 – 敏捷武士--看敏捷高手交付 卓越軟件 – Scrum敏捷產品管理
  55. 55. 演化過程 • 20 -> 11 • 11 -> 6 – 研發模型 • 6 -> 3 – 創新方法 • 啓示錄
  56. 56. 那時候, 我們交付週期約 20 天 • 工作方式 – Waterfall – 專業角色分工 • 協作模式 – 沒有項目經理 – PM team, Dev team, QA team 各自把工作做好
  57. 57. 第一跳: 從 20 天到 11 天 • 時間: 2012 • 方法 – Iteration – 老大說時間砍一半 • 問題 – 依然是串行工作方式 – 可是 iteration 會讓問題快速被暴露 • 不同角色協作不順暢 • 品質變差
  58. 58. 第二跳: 從 11 天到 6 天 • 時間: 2013 初 • 方法 – 敏捷開發方法 – 控制方法 • 檢查需求抵達方式 (怎麼來) • 檢查需求處理方式 (怎麼處理的) • 改變研發交付習慣 • 轉變測試職責
  59. 59. 檢查需求抵達方式 • 你很少能控制需求抵達的時間和數量 • 如何應對 – 排入序列中 – 分時段談需求 – 大概的優先順序 – 清晰展示帶做事項和其優先順序 – 需要加人嗎?
  60. 60. 檢查需求處理方式 • 做法 – 分 sprint 來完成 – 將大的 story 切成小的 story • 可以從中找出哪些不需要做 • 好處 – 每個 sprint 有機會再來看要做哪些 – 提升質量需求 • 低變化率 • 容易理解 • 去除鍍金功能 – 加速價值交付 (因為切小了)
  61. 61. 改變研發交付習慣 • 開發習慣調整 – By story – 依優先順序 – 統籌前端和 server 端 – 落實 done 的定義 – Bug > 待做事項 • 廣泛參與需求討論和可實現性分析 • 品質意識
  62. 62. 轉變測試職責 • 後保險桿  前車燈 – 及時提供品質回饋 – 根據及時品質訊息, 進行調整 • 團隊速度 • 開發品質 • 工作協同
  63. 63. 窘境 • 研發模式不斷改進, 效果良好 – 從 20 天到 6 天 • 但無法解決業務問題 – 缺乏前期產品效果評估規劃 – 無法將產品特性和業務發展聯繫起來
  64. 64. 做正確的事情效果才會大 做正確的事情 正確地做事情
  65. 65. 面臨新挑戰 • 無線 (從 2012 激增) • 問答模式 – 原先是偏知識性 (電腦, 網路…) – 生活化的問題變多 (這附近哪裡 有吃的) • 需要即時性回答 • 問答能力 – 百度知道上面回答問題的人沒 有變多, 但問問題的人變多 – 有回答但品質不一定很好
  66. 66. 新創意出爐, 但挑戰比較大
  67. 67. 如何開始
  68. 68. 製作畫布, 並分析風險
  69. 69. 如何消除風險 • 確保問題和解決方案相匹配 – 設計一系列 MVP, 對風險項進行一系列的系統測 試 – 測試各項風險和方案可行性
  70. 70. MVP.1 – 手動測試 • 120 個線上問題, 找到 40 % 未答覆, 手動發 到某個問答端 – 回答端A, 解決率: 50% – 回答端B, 解決率: 55%  這事情可以搞
  71. 71. MVP 2. 推戶用量 = 16 效果比較理想
  72. 72. MVP 3. 推戶用量 = 30 效果有變好
  73. 73. MVP 4. 推戶用量 = 60, 策略增加地域類屬性
  74. 74. Lean • 方向正確 • 還需要驗證 – Web app 對用戶的回答有折損嗎? – 回答者不喜歡 web app? 還是喜歡直接回復? – …  繼續就各種風險進行測試
  75. 75. 注意: 上面我們沒有任何產品上線 但我們非常有把握這個事情可以做成
  76. 76. 第三跳 • 2 ~ 3 天
  77. 77. 啟示錄 (1) • 快是對價值的探求 – 追求的是體驗 – 從商業價值的角度來看快 • 如何衡量創新產品的研發
  78. 78. 啟示錄(2) • 適當的度量指標 – 5/10/20 分鐘內的解決率 – 下載量/ 購買率 • 關注於探索和學習, 而非按計劃完成 • 用 MVP 檢驗假設和回答問題 • 永遠不要認為你已經了解用戶, 直到你真實 驗證過
  79. 79. 遇見閃耀的你 – 遊戲化項目團隊實踐 • 講者: 江舒 • 網龍公司 • 敏捷顧問, 催化師, CSM • 福州 Tclub 沙龍創立者
  80. 80. 策略再高明, 員工沒有熱忱, 一切都是空談
  81. 81. 遊戲化 (Gamification) • 遊戲化就是來讓大家提高參與的熱忱, 樂於 解決重要的問題. • 元素 – 遊戲設計 – 忠誠方案 – 以及行為經濟學
  82. 82. 資源等級點數 社交元素 代表人物任 務
  83. 83. 怎樣才好玩 • 想贏 • 解難題 • 放鬆 • 合作 • 被認同 • 收集物品 • 想像力 • 角色扮演
  84. 84. 遊戲化畫布
  85. 85. 遊戲化畫布 • 願景: 組織和個人的共同願景 • 目標: 短期要完成的有挑戰性任務 • 反饋: 以實體或虛擬方式及時回饋 • 成功: 如何慶祝每一次目標的達成? 讓人有 成就感 • 失敗: 快樂的尷尬, 互相調侃 • 鏈接: 如何鏈結加強團隊互助協同, 戰鬥力 • 驚喜: 一不小心就收到禮物
  86. 86. 敏捷開發中的客戶角色的演變 • Speaker: Alan Atlas • Certified Scrum Coach • Certified Scrum Trainer • Amazon S3 Dev Manager • Adopt Scrum in S3 team
  87. 87. 瀑布式開發方法 • 客戶? 什麼是客戶?
  88. 88. XP 的 Practices
  89. 89. XP的使用者很忙 • 產生需求 • 頻繁的回饋 • 對變化的需求進行評 估, 及排優先順序 • 與關係厲害人合作 • 確保品質 • 評估中間的產出物 • 對需求蔓延的狀況負 責 • 預設未來及漸進式的 規劃
  90. 90. 在 XP 中客戶的角色 • 我們發現客戶是一個有壓力的角色, 導致了 有持續性的問題 • XP 客戶需要扮演多個角色, 從 “測試驗收者”, “政治顧問”, 到”超級秘書”
  91. 91. 在 XP 中, 客戶是團隊其中一個成員
  92. 92. Scrum 中的客戶 • 產品負責人代表用戶, 客戶的產品或系統 – Roman Picher • 沒有人可以代替實際的客戶 – Chris Diggins • Scrum review meeting 的參與者, 通常包括產 品負責人, Scrum 團隊, Scrum Master, 管理者, 客戶, 和來自其他專案的開發者 – Mike Cohn
  93. 93. 在 Scrum 中, 客戶是 會發出聲音的旁觀者
  94. 94. 如果你不聽你的客戶, 你就 GG 了 如果你只聽你的客戶, 你就 GG 了
  95. 95. Lean Startup 驗證學習客戶開發 如果你不知道誰是客戶, 你就不知道什麼是品質
  96. 96. 精益創業的客戶 • 不是某個人 • 定義品質 • 提供新方向 • 沒有角色 • 驅動開發
  97. 97. 小米 • “米粉” 驅動產品開發 • 公司產品經理可以花一半時間, 泡在該公司 的活躍用戶論壇 • 建議可以在下一周建構出來
  98. 98. 雷軍定義小米的用戶 • 如果一個用戶開始使用小米手機, 他的朋友 可能也願意使用 • 他們傳播這個用語 • 粉絲門付費參加小米 Mi2 北京發佈會, 並且 身穿橙色, 來顯示他們是小米的粉絲
  99. 99. Crowdsourcing • 小米使用群眾外包開發其操作系統 • 我覺得小米最重要的成功祕訣: 是不賣產品, 而是提供參與的機會 – 雷軍 • 攻入其鐵桿粉絲來生成的口碑營銷 – 如果你發明了一種功能而我來幫你完成它, 難道 你不會去告訴你的同學, 同事和朋友是你做的這 項功能嗎?
  100. 100. 每個用戶將成為你的研發, 每個用戶將成為你的朋友, 這就是我們想做的公司
  101. 101. 在小米中, 客戶是公司的一部份
  102. 102. 持續演進 循序開發 敏捷開發 流程改善 做對的事
  103. 103. 全面配合 流程 工具 心態 組織
  104. 104. 不只 Scrum Lean Startup Kanban Scrum
  105. 105. 落實工程實務
  106. 106. 敢用新思維 Impact Mapping 商業模式 畫布 最小可行 產品
  107. 107. 跨區域合作
  108. 108. 跨界學習
  109. 109. 羨慕, CIO 帶隊
  110. 110. Q & A

×