More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Scrum gathering 2014sharing v4
Similar to Scrum gathering 2014sharing v4 (20)
More from Jen-Chieh Ko
More from Jen-Chieh Ko (20)
Scrum gathering 2014sharing v4
- 1. Scrum Gathering Shanghai 2014 與會分享 分享者: David Ko
- 2. 大綱 • 大會簡介 • 議題分享 • 與會感想 • Q & A
- 3. Scrum Gathering • 由非營利組織 Scrum Alliance 所發起 • 由社區主導和自負盈虧 • 以 Scrum of Scrum 方式跨地區合作
- 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. 偉大的志工
- 6. 組頭: 李清玉
- 7. 大會日程 – 工作坊
- 9. 經濟合理的 Scrum • Speaker: Ken Rubin • Essential Scrum – #1 Bestselling Agile Book in Amazon • Certified Scrum Trainer
- 10. 餐廳經營模式
- 11. 餐廳故事的啟示 • 所多組織 Scrum 執行的不錯, 但是並沒有反應到商 業營收上面 • 因為他們 – 沒有掌握 Scrum 基本原則的精髓 – 也不知道如何以經濟合理的方式來運用 單只有 Scrum 不足以成功, 經濟合理的 Scrum 才行
- 12. ScrumBut • 我們用 Scrum, 但是 …… – 8 周一個 iteration – 沒有產品負責人 – 不是每天召開每日例會 – Iteration 規劃會議花了 2 天 但沒有違背 Scrum 就一定會成功嗎?
- 15. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
- 16. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
- 17. 何時可以改變?
- 18. 經濟合理的變化
- 19. 及時 (JIT) 的誤解
- 22. 關注接力棒而非運動員
- 23. 團隊一起快速交付價值給客戶
- 24. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
- 25. 下游系統不配合
- 26. 內部管理不一致 • 只有開發是 agile • 其他都是事先就要提供精準的規劃 吃碗裡看碗外
- 27. Sales 無法配合
- 28. 合作夥伴無法配合
- 29. 三個障礙 • 開發過程中忽視或是誤用敏捷核心原則 • 未能在價值鏈中從頭到尾運用敏捷原則 • 未能以經濟合理的方式來組織團隊
- 30. 減少多工的現象
- 31. 擁抱多技能的團隊
- 32. 永續的團隊 • 彼此間信任及有默契 • 比新組成的團隊更有生產力 • 因為有默契導致產出更有效率更有品質 • 在評估時有歷史資料可以參考
- 33. 當人很多時, 如何切割團隊? • 依角色分割團隊 (畫面設計, 開發, 測試) • 依所在位置分割團隊 (美國, 臺北, 日本) • 依架構分割團隊 (前端, 平台, 資料庫) • 依元件分割團隊 • 依功能團隊
- 35. 總結 • 利用被證實過的方法 來實施所有 Scrum 的 practices • 運用 Scrum 要基於敏 捷核心原則, 以及思考 合理的經濟效益 必要但是還不夠
- 36. 敏捷, 請卸下你的重鎧 • 騰訊外聘顧問 • 卸下重鎧 – 不要因為最佳實 務讓你動彈不得 • 輕裝上陣
- 37. 騰訊電腦管家
- 38. 現狀與目標 • 理想 – 2 周一個 beta 版本, 每個月發佈一個穩定版本 • 現實 – 各種延遲, 2 – 3 個月沒有穩定版本可發佈 • 目標 – 1 天 2 個 beta 版本, 每個一個候選穩定版本
- 39. 目前開發流程 • 6 周一發
- 40. 遭遇的問題 • 整合很慢 • 因為 iteration 的關係, 系統常常不穩
- 41. 第一招: 架構重整 • 花 2 -3 月重新調整架構 • 這段時間幾乎沒有任何發佈
- 42. 改善結果 • 5 周一發
- 43. 第二招 交錯開發 • 2.5 周一發
- 44. 接下來的問題
- 45. 第三招 組織架構重整
- 46. 改善結果 (1) • 單線 3 周
- 47. 改善結果 (2) • 交錯開發約 2 周
- 49. 第四招 建立配置表
- 50. 改善結果 • 2 天一發
- 51. 第五招 自動化體系推動高速發展 • 自動建構系統 • 自動化測試 • 自動環境部署 • 一鍵發佈 • 一鍵回滾 • 自動監控
- 52. 目前結果 • 一天雙發
- 53. 結論 • 技術架構解構 • 組織架構解構 • 配置管理體系 • 自動化體系
- 54. 百度知道研發能力三級跳揭秘 • 講者: 李忠利 • 百度高級架構師 • 有翻譯以下書籍 – 管理3.0 – 敏捷武士--看敏捷高手交付 卓越軟件 – Scrum敏捷產品管理
- 55. 演化過程 • 20 -> 11 • 11 -> 6 – 研發模型 • 6 -> 3 – 創新方法 • 啓示錄
- 56. 那時候, 我們交付週期約 20 天 • 工作方式 – Waterfall – 專業角色分工 • 協作模式 – 沒有項目經理 – PM team, Dev team, QA team 各自把工作做好
- 57. 第一跳: 從 20 天到 11 天 • 時間: 2012 • 方法 – Iteration – 老大說時間砍一半 • 問題 – 依然是串行工作方式 – 可是 iteration 會讓問題快速被暴露 • 不同角色協作不順暢 • 品質變差
- 58. 第二跳: 從 11 天到 6 天 • 時間: 2013 初 • 方法 – 敏捷開發方法 – 控制方法 • 檢查需求抵達方式 (怎麼來) • 檢查需求處理方式 (怎麼處理的) • 改變研發交付習慣 • 轉變測試職責
- 60. 檢查需求抵達方式 • 你很少能控制需求抵達的時間和數量 • 如何應對 – 排入序列中 – 分時段談需求 – 大概的優先順序 – 清晰展示帶做事項和其優先順序 – 需要加人嗎?
- 61. 檢查需求處理方式 • 做法 – 分 sprint 來完成 – 將大的 story 切成小的 story • 可以從中找出哪些不需要做 • 好處 – 每個 sprint 有機會再來看要做哪些 – 提升質量需求 • 低變化率 • 容易理解 • 去除鍍金功能 – 加速價值交付 (因為切小了)
- 62. 改變研發交付習慣 • 開發習慣調整 – By story – 依優先順序 – 統籌前端和 server 端 – 落實 done 的定義 – Bug > 待做事項 • 廣泛參與需求討論和可實現性分析 • 品質意識
- 63. 轉變測試職責 • 後保險桿 前車燈 – 及時提供品質回饋 – 根據及時品質訊息, 進行調整 • 團隊速度 • 開發品質 • 工作協同
- 64. 窘境 • 研發模式不斷改進, 效果良好 – 從 20 天到 6 天 • 但無法解決業務問題 – 缺乏前期產品效果評估規劃 – 無法將產品特性和業務發展聯繫起來
- 66. 面臨新挑戰 • 無線 (從 2012 激增) • 問答模式 – 原先是偏知識性 (電腦, 網路…) – 生活化的問題變多 (這附近哪裡 有吃的) • 需要即時性回答 • 問答能力 – 百度知道上面回答問題的人沒 有變多, 但問問題的人變多 – 有回答但品質不一定很好
- 67. 新創意出爐, 但挑戰比較大
- 69. 如何開始
- 70. 製作畫布, 並分析風險
- 71. 如何消除風險 • 確保問題和解決方案相匹配 – 設計一系列 MVP, 對風險項進行一系列的系統測 試 – 測試各項風險和方案可行性
- 72. MVP.1 – 手動測試 • 120 個線上問題, 找到 40 % 未答覆, 手動發 到某個問答端 – 回答端A, 解決率: 50% – 回答端B, 解決率: 55% 這事情可以搞
- 73. MVP 2. 推戶用量 = 16 效果比較理想
- 74. MVP 3. 推戶用量 = 30 效果有變好
- 75. MVP 4. 推戶用量 = 60, 策略增加地域類屬性
- 76. Lean • 方向正確 • 還需要驗證 – Web app 對用戶的回答有折損嗎? – 回答者不喜歡 web app? 還是喜歡直接回復? – … 繼續就各種風險進行測試
- 78. 第三跳 • 2 ~ 3 天
- 79. 啟示錄 (1) • 快是對價值的探求 – 追求的是體驗 – 從商業價值的角度來看快 • 如何衡量創新產品的研發
- 80. 啟示錄(2) • 適當的度量指標 – 5/10/20 分鐘內的解決率 – 下載量/ 購買率 • 關注於探索和學習, 而非按計劃完成 • 用 MVP 檢驗假設和回答問題 • 永遠不要認為你已經了解用戶, 直到你真實 驗證過
- 81. 遇見閃耀的你 – 遊戲化項目團隊實踐 • 講者: 江舒 • 網龍公司 • 敏捷顧問, 催化師, CSM • 福州 Tclub 沙龍創立者
- 83. 遊戲化 (Gamification) • 遊戲化就是來讓大家提高參與的熱忱, 樂於 解決重要的問題. • 元素 – 遊戲設計 – 忠誠方案 – 以及行為經濟學
- 85. 怎樣才好玩 • 想贏 • 解難題 • 放鬆 • 合作 • 被認同 • 收集物品 • 想像力 • 角色扮演
- 86. 遊戲化畫布
- 87. 遊戲化畫布 • 願景: 組織和個人的共同願景 • 目標: 短期要完成的有挑戰性任務 • 反饋: 以實體或虛擬方式及時回饋 • 成功: 如何慶祝每一次目標的達成? 讓人有 成就感 • 失敗: 快樂的尷尬, 互相調侃 • 鏈接: 如何鏈結加強團隊互助協同, 戰鬥力 • 驚喜: 一不小心就收到禮物
- 98. 敏捷開發中的客戶角色的演變 • Speaker: Alan Atlas • Certified Scrum Coach • Certified Scrum Trainer • Amazon S3 Dev Manager • Adopt Scrum in S3 team
- 100. XP 的 Practices
- 101. XＰ的使用者很忙 • 產生需求 • 頻繁的回饋 • 對變化的需求進行評 估, 及排優先順序 • 與關係厲害人合作 • 確保品質 • 評估中間的產出物 • 對需求蔓延的狀況負 責 • 預設未來及漸進式的 規劃
- 102. 在 XP 中客戶的角色 • 我們發現客戶是一個有壓力的角色, 導致了 有持續性的問題 • XP 客戶需要扮演多個角色, 從 “測試驗收者”, “政治顧問”, 到”超級秘書”
- 103. 在 XP 中, 客戶是團隊其中一個成員
- 104. Scrum 中的客戶 • 產品負責人代表用戶, 客戶的產品或系統 – Roman Picher • 沒有人可以代替實際的客戶 – Chris Diggins • Scrum review meeting 的參與者, 通常包括產 品負責人, Scrum 團隊, Scrum Master, 管理者, 客戶, 和來自其他專案的開發者 – Mike Cohn
- 105. 在 Scrum 中, 客戶是 會發出聲音的旁觀者
- 106. 如果你不聽你的客戶, 你就 GG 了 如果你只聽你的客戶, 你就 GG 了
- 108. 精益創業的客戶 • 不是某個人 • 定義品質 • 提供新方向 • 沒有角色 • 驅動開發
- 109. 小米 • “米粉” 驅動產品開發 • 公司產品經理可以花一半時間, 泡在該公司 的活躍用戶論壇 • 建議可以在下一周建構出來
- 110. 雷軍定義小米的用戶 • 如果一個用戶開始使用小米手機, 他的朋友 可能也願意使用 • 他們傳播這個用語 • 粉絲門付費參加小米 Mi2 北京發佈會, 並且 身穿橙色, 來顯示他們是小米的粉絲
- 111. Crowdsourcing • 小米使用群眾外包開發其操作系統 • 我覺得小米最重要的成功祕訣: 是不賣產品, 而是提供參與的機會 – 雷軍 • 攻入其鐵桿粉絲來生成的口碑營銷 – 如果你發明了一種功能而我來幫你完成它, 難道 你不會去告訴你的同學, 同事和朋友是你做的這 項功能嗎?
- 113. 在小米中, 客戶是公司的一部份
- 116. 全面配合 流程 工具 心態 組織
- 118. 落實工程實務
- 120. 跨區域合作
- 121. 跨界學習
- 122. 羨慕, CIO 帶隊
- 123. Q & A
Editor's Notes
- 越多人進來就越成功嗎? 是不是完全照做就是對的
- 6-? 3 研發手法到極限了, 要有些創新方法
- Queue: 讓人家知道你真的很多東西在處理 分時段: 指定某個時間才能提, 避免隨時被抓去談需求 大概的
- 1.願景:欣賞式探詢：把正面結果放到最大 (Appreciative inquiry) 「如果我們要帶著過去的一部分走向未來，那就應該帶著最好的那一部份。」 2. 目標: 一開始要很容易達成, 才能給玩家正向回饋, 之後才逐漸變難 知道狀態, where we are, 進度
- 这个团队基本是白手起家，由于业务需要赶鸭子上架，对其专业所要求的专业技能严重缺乏。 且这个团伙里只有一个是全职，其他都是只有部分工作时间来做这件事情。知识沉淀、人员培养，团队情绪都有不小问题。 于是我们是试图用游戏化的方式，让这样一个重负且挫折和混沌感频频的工作好玩起来。
- 我们用欣赏式探寻的方式尝试调动大家对未来的希望，以及对自身成长的激情。
- 然后让每位朋友创建了一个内心的英雄图，定制了一些自己英雄特殊的属性，悲情故事等等等。 我们将英雄图做成了每个人的卡片徽章，发到每位朋友手上。让梦想具象化。
- 收集各种信息，来形成各种反馈，目的帮助大家了解自己在团队中的位置，看见各自的贡献度，以及其他一些数据等等，以产生一种持续的成长和学习的团队氛围。
- 大家组成了两个门派，有时我们会对这些数据来一次结算，类似于
- 獎勵的手氣
- 事件卡牌如下： 1、祈祷，抽卡人向游戏中的其他人发出请求，使他帮忙/代替其达成任务，事成之后，两人均获得一张卡牌。 2、度假，抽卡人一日不做任务，纯放松。 3、宽恕，豁免卡。 4、心愿，心想事成卡，可任意选择一张你喜欢的事件卡。 5、迷迭香，每位游戏同伴都找一种自己喜欢的香花香草赠与抽卡人。 6、馋嘴猫，每位游戏同伴都找一种带有自己儿时记忆的食物赠与抽卡人。 7、Augst Rush音乐会, 全员DJ,各贡献一首自己热爱的歌曲，Timebox:<=30mins。