scrum gathering 2014sharing v4
DESCRIPTION
TRANSCRIPT
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
XP的使用者很忙• 產生需求
• 頻繁的回饋
• 對變化的需求進行評估 , 及排優先順序
• 與關係厲害人合作
• 確保品質
• 評估中間的產出物
• 對需求蔓延的狀況負責
• 預設未來及漸進式的規劃
在 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