Scrum Gathering Shanghai 2014與會分享

分享者 : David Ko

大綱• 大會簡介

• 議題分享

• 與會感想

• Q & A

Scrum Gathering

• 由非營利組織 Scrum Alliance 所發起

• 由社區主導和自負盈虧

• 以 Scrum of Scrum 方式跨地區合作

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

偉大的志工

組頭 : 李清玉

大會日程 – 工作坊

大會日程 – 6/6-6/7

經濟合理的 Scrum

• Speaker: Ken Rubin• Essential Scrum– #1 Bestselling Agile Book

in Amazon• Certified Scrum Trainer

餐廳經營模式

餐廳故事的啟示• 所多組織 Scrum 執行的不錯 , 但是並沒有反應到

商業營收上面• 因為他們– 沒有掌握 Scrum 基本原則的精髓– 也不知道如何以經濟合理的方式來運用

單只有 Scrum 不足以成功 , 經濟合理的 Scrum 才行

ScrumBut

• 我們用 Scrum, 但是 ……– 8 周一個 iteration– 沒有產品負責人– 不是每天召開每日例會– Iteration 規劃會議花了 2 天

但沒有違背 Scrum 就一定會成功嗎 ?

人們在運用 Scrum 時

常不知道為什麼要這樣做

以及何時去採用這些方法

Economics – 是產品開發共同的語言

三個障礙• 開發過程中忽視或是誤用敏捷核心原則

• 未能在價值鏈中從頭到尾運用敏捷原則

• 未能以經濟合理的方式來組織團隊

三個障礙• 開發過程中忽視或是誤用敏捷核心原則

• 未能在價值鏈中從頭到尾運用敏捷原則

• 未能以經濟合理的方式來組織團隊

何時可以改變 ?

經濟合理的變化

及時 (JIT) 的誤解

平衡前期預測與及時調整

預測 混亂

前期預測

及時調整

產品類別開發的限制方法的不確定性

識別庫存的浪費• 工廠的庫存物理上和

財務上都容易看見• 知識資產物理上和財

務上都不可見

關注接力棒而非運動員

團隊一起快速交付價值給客戶

三個障礙• 開發過程中忽視或是誤用敏捷核心原則

• 未能在價值鏈中從頭到尾運用敏捷原則

• 未能以經濟合理的方式來組織團隊

下游系統不配合

內部管理不一致• 只有開發是 agile• 其他都是事先就要提供精準的規劃

吃碗裡看碗外

Sales 無法配合

合作夥伴無法配合

三個障礙• 開發過程中忽視或是誤用敏捷核心原則

• 未能在價值鏈中從頭到尾運用敏捷原則

• 未能以經濟合理的方式來組織團隊

減少多工的現象

擁抱多技能的團隊

永續的團隊• 彼此間信任及有默契

• 比新組成的團隊更有生產力

• 因為有默契導致產出更有效率更有品質

• 在評估時有歷史資料可以參考

當人很多時 , 如何切割團隊 ?

• 依角色分割團隊 (畫面設計 , 開發 , 測試 )• 依所在位置分割團隊 (美國 , 臺北 , 日本 )• 依架構分割團隊 ( 前端 , 平台 , 資料庫 )• 依元件分割團隊• 依功能團隊

根據經濟效益展延團隊而非教條

• 老實思考何種組合會產生最大的利益 ?• 沒有單一做法可以適合所有狀況

總結• 利用被證實過的方法

來實施所有 Scrum 的practices

• 運用 Scrum 要基於敏捷核心原則 , 以及思考合理的經濟效益

必要但是還不夠

敏捷 , 請卸下你的重鎧• 騰訊外聘顧問• 卸下重鎧– 不要因為最佳實

務讓你動彈不得• 輕裝上陣

騰訊電腦管家

現狀與目標• 理想– 2 周一個 beta 版本 , 每個月發佈一個穩定版

本• 現實–各種延遲 , 2 – 3 個月沒有穩定版本可發佈

• 目標– 1 天 2 個 beta 版本 , 每個一個候選穩定版本

目前開發流程• 6 周一發

遭遇的問題• 整合很慢

• 因為 iteration 的關係 , 系統常常不穩

第一招 : 架構重整• 花 2 -3 月重新調整架構• 這段時間幾乎沒有任何發佈

改善結果• 5 周一發

第二招 交錯開發• 2.5 周一發

接下來的問題

第三招 組織架構重整

改善結果 (1)

• 單線 3 周

改善結果 (2)

• 交錯開發約 2 周

下個難題• 互相影響需要更快知道

第四招 建立配置表

改善結果• 2 天一發

第五招 自動化體系推動高速發展• 自動建構系統• 自動化測試• 自動環境部署• 一鍵發佈• 一鍵回滾• 自動監控

目前結果• 一天雙發

結論• 技術架構解構

• 組織架構解構

• 配置管理體系

• 自動化體系

百度知道研發能力三級跳揭秘• 講者 : 李忠利• 百度高級架構師• 有翻譯以下書籍– 管理 3.0– 敏捷武士 -- 看敏捷高手交

付卓越軟件– Scrum 敏捷產品管理

演化過程• 20 -> 11• 11 -> 6–研發模型

• 6 -> 3–創新方法

• 啓示錄

那時候 , 我們交付週期約 20 天• 工作方式– Waterfall–專業角色分工

• 協作模式– 沒有項目經理– PM team, Dev team, QA team 各自把工作做好

第一跳 : 從 20 天到 11 天• 時間 : 2012• 方法– Iteration–老大說時間砍一半

• 問題–依然是串行工作方式– 可是 iteration 會讓問題快速被暴露• 不同角色協作不順暢• 品質變差

第二跳 : 從 11 天到 6 天• 時間 : 2013 初• 方法– 敏捷開發方法–控制方法• 檢查需求抵達方式 (怎麼來 )• 檢查需求處理方式 (怎麼處理的 )• 改變研發交付習慣• 轉變測試職責

檢查需求抵達方式• 你很少能控制需求抵達的時間和數量• 如何應對–排入序列中– 分時段談需求– 大概的優先順序– 清晰展示帶做事項和其優先順序–需要加人嗎 ?

檢查需求處理方式• 做法– 分 sprint 來完成– 將大的 story 切成小的 story

• 可以從中找出哪些不需要做• 好處– 每個 sprint 有機會再來看要做哪些– 提升質量需求

• 低變化率• 容易理解• 去除鍍金功能

– 加速價值交付 ( 因為切小了 )

改變研發交付習慣• 開發習慣調整– By story–依優先順序– 統籌前端和 server 端–落實 done 的定義– Bug > 待做事項

• 廣泛參與需求討論和可實現性分析• 品質意識

轉變測試職責• 後保險桿 前車燈– 及時提供品質回饋–根據及時品質訊息 , 進行調整• 團隊速度• 開發品質• 工作協同

窘境• 研發模式不斷改進 , 效果良好– 從 20 天到 6 天

• 但無法解決業務問題–缺乏前期產品效果評估規劃– 無法將產品特性和業務發展聯繫起來

做正確的事情效果才會大

做正確的事情

正確地做事情

面臨新挑戰• 無線 ( 從 2012 激增 ) • 問答模式– 原先是偏知識性 (電腦 , 網路… )– 生活化的問題變多 (這附近哪裡

有吃的 )• 需要即時性回答

• 問答能力– 百度知道上面回答問題的人沒有

變多 , 但問問題的人變多– 有回答但品質不一定很好

新創意出爐 , 但挑戰比較大

如何開始

製作畫布 , 並分析風險

如何消除風險• 確保問題和解決方案相匹配–設計一系列 MVP, 對風險項進行一系列的系統

測試– 測試各項風險和方案可行性

MVP.1 – 手動測試• 120 個線上問題 , 找到 40 % 未答覆 , 手動

發到某個問答端–回答端 A, 解決率 : 50%–回答端 B, 解決率 : 55%

這事情可以搞

MVP 2. 推戶用量 = 16

效果比較理想

MVP 3. 推戶用量 = 30

效果有變好

MVP 4. 推戶用量 = 60, 策略增加地域類屬性

Lean

• 方向正確• 還需要驗證– Web app 對用戶的回答有折損嗎 ?–回答者不喜歡 web app? 還是喜歡直接回復 ?– …

繼續就各種風險進行測試

注意 : 上面我們沒有任何產品上線

但我們非常有把握這個事情可以做成

第三跳• 2 ~ 3 天

啟示錄 (1)

• 快是對價值的探求–追求的是體驗– 從商業價值的角度來看快

• 如何衡量創新產品的研發

啟示錄 (2)

• 適當的度量指標– 5/10/20 分鐘內的解決率– 下載量 / 購買率

• 關注於探索和學習 , 而非按計劃完成• 用 MVP 檢驗假設和回答問題• 永遠不要認為你已經了解用戶 , 直到你真實驗證過

遇見閃耀的你 – 遊戲化項目團隊實踐

• 講者 : 江舒• 網龍公司• 敏捷顧問 , 催化師 ,

CSM• 福州 Tclub 沙龍創立者

策略再高明 , 員工沒有熱忱 , 一切都是空談

遊戲化 (Gamification)

• 遊戲化就是來讓大家提高參與的熱忱 , 樂於解決重要的問題 .

• 元素–遊戲設計–忠誠方案– 以及行為經濟學

資源等級點數

社交元素

代表人物任務

怎樣才好玩• 想贏

• 解難題

• 放鬆

• 合作

• 被認同

• 收集物品

• 想像力

• 角色扮演

遊戲化畫布

遊戲化畫布• 願景 : 組織和個人的共同願景• 目標 : 短期要完成的有挑戰性任務• 反饋 : 以實體或虛擬方式及時回饋• 成功 : 如何慶祝每一次目標的達成 ? 讓人

有成就感• 失敗 : 快樂的尷尬 , 互相調侃• 鏈接 : 如何鏈結加強團隊互助協同 , 戰鬥力• 驚喜 : 一不小心就收到禮物

敏捷開發中的客戶角色的演變• Speaker: Alan Atlas• Certified Scrum Coach• Certified Scrum Trainer• Amazon S3 Dev Manager• Adopt Scrum in S3 team

瀑布式開發方法• 客戶 ? 什麼是客戶 ?

XP 的 Practices

XＰ的使用者很忙• 產生需求

• 頻繁的回饋

• 對變化的需求進行評估 , 及排優先順序

• 與關係厲害人合作

• 確保品質

• 評估中間的產出物

• 對需求蔓延的狀況負責

• 預設未來及漸進式的規劃

在 XP 中客戶的角色• 我們發現客戶是一個有壓力的角色 , 導致

了有持續性的問題

• XP 客戶需要扮演多個角色 , 從 “測試驗收者” , “政治顧問” , 到”超級秘書”

在 XP 中 ,

客戶是團隊其中一個成員

Scrum 中的客戶• 產品負責人代表用戶 , 客戶的產品或系統– Roman Picher

• 沒有人可以代替實際的客戶– Chris Diggins

• Scrum review meeting 的參與者 , 通常包括產品負責人 , Scrum 團隊 , Scrum Master, 管理者 , 客戶 , 和來自其他專案的開發者– Mike Cohn

在 Scrum 中 , 客戶是會發出聲音的旁觀者

如果你不聽你的客戶 , 你就 GG 了

如果你只聽你的客戶 , 你就 GG 了

Lean Startup

驗證學習客戶開發

如果你不知道誰是客戶 , 你就不知道什麼是品質

精益創業的客戶• 不是某個人• 定義品質• 提供新方向• 沒有角色• 驅動開發

小米• “米粉” 驅動產品開發

• 公司產品經理可以花一半時間 , 泡在該公司的活躍用戶論壇

• 建議可以在下一周建構出來

雷軍定義小米的用戶• 如果一個用戶開始使用小米手機 , 他的朋友可能也願意使用

• 他們傳播這個用語

• 粉絲門付費參加小米 Mi2 北京發佈會 , 並且身穿橙色 , 來顯示他們是小米的粉絲

Crowdsourcing

• 小米使用群眾外包開發其操作系統

• 我覺得小米最重要的成功祕訣 : 是不賣產品 , 而是提供參與的機會 – 雷軍

• 攻入其鐵桿粉絲來生成的口碑營銷– 如果你發明了一種功能而我來幫你完成它 , 難

道你不會去告訴你的同學 , 同事和朋友是你做的這項功能嗎 ?

每個用戶將成為你的研發 ,

每個用戶將成為你的朋友 ,

這就是我們想做的公司

在小米中 ,

客戶是公司的一部份

持續演進

循序開發

敏捷開發

流程改善

做對的事

全面配合

流程 工具 心態 組織

不只 Scrum

Lean Startup

Kanban

Scrum

落實工程實務

敢用新思維

Impact Mapping

商業模式畫布

最小可行產品

跨區域合作

跨界學習

羨慕 , CIO 帶隊

Q & A