從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup

從 Scrum 到 Kanban:為什麼 Scrum 不適合 Lean Startup CTO PassionBean ihower@gmail.com 2012/9/11

About me• 張⽂文鈿 a.k.a. ihower• http://ihower.tw• 熱情⾖豆⾏行動樂活科技 CTO

本來我也是不屑 Lean Startup 的，我⼜又不是創業家...

本來我也是不屑 Lean Startup 的，我⼜又不是創業家... 第⼀一名竟然是 The Lean Startup ?!!

本來我也是不屑 Lean Startup 的，我⼜又不是創業家... 這個作者 Eric Ries 竟然是CTO技術出⾝身!! 第⼀一名竟然是 The Lean Startup ?!!

好吧，就來翻⼀一翻

so... 到底什麼是 “Lean” Startup?

Lean Startup• ⼀一套管理創業過程的⽅方法• 透過 Build -> Measure -> Learn 的循環過程，快速、低成本的科學實驗⽅方法，不斷調整來驗證產品跟市場的契合度• 開發任何功能前，都必須先有假設，然後當做實驗來驗證學習。任何和學習無關的功能開發都是浪費。• 直到找出 Business Model 營利模式，才開始進⾏行規模擴張。

⼀一開始⺫⽬目標客⼾戶跟產品特性都是不確定的• Scrum/XP 等敏捷⽅方法論 • Problem 已知 (PO和Client會告訴你要建造什麼) • Solution 未知 (透過Iteration開發)• Lean Startup • Problem 未知 (透過BML循環逼近) • Solution 未知 (透過continuous deployment開發)

抱歉，我只有五分鐘，詳情建議⼤大家回去買書來看...

對我最⼤大的啟發• 敏捷和精實開發強調開發有效率、不浪費• 但是最⼤大的浪費是做出沒⼈人⽤用的東⻄西• Lean Startup != 創業才能⽤用，只要開發新產品，就值得⼀一看• 我開始跨界了

Scrum 跟 Lean Startup 不速配嗎?

我覺得有疑慮的幾點• 不夠均衡的⾓角⾊色定義• ⾃自找⿇麻煩的固定開發週期• 只強調⼯工程品質• 不必要的估算• 無法照顧全局的流程

1. Scrum 不均衡的⾓角⾊色定義決定做什麼決定怎麼做Problem Team PO SM Cross-functional Solution Team Dev Dev Dev Dev Dev Dev

Cross-functional?• 採⽤用 Scrum，你其實有兩個 Team，⽽而 cross- functional 和 self-organized 講的都是右邊的Team。• 決定做什麼是 startup 最關鍵的事情，但是 Scrum 裡都交給書裡篇幅最少的PO• Scrum 常站在⼯工程團隊的⾓角度去凸顯 Problem team 和 Solution team 之間的衝突 (例如 SM 要保護右邊 Team 的⼈人不受干擾，⽼老把⽼老闆跟PO當成敵⼈人。建議 PO 和 SM 最好不要同⼀一⼈人因為⾓角⾊色衝突)

⺫⽬目標不⼀一致也許是不同部⾨門，或是外包的情況• Problem team: 盡量壓榨 Solution Team 做更多的事情• Solution team: 可以如期 (Sprint) ⾼高品質的完⼯工

Startup 應該只有⼀一個 Team Problem/Solution Team Dev Design Marketing

Startup Team ⼤大家⺫⽬目標⼀一致:產品有⼈人⽤用

⼈人⼈人都要參與產品規劃• 在 startup 裡，PO也不知道做什麼才是對• 在 startup 裡，要做什麼，scope 有多⼤大，⾮非常彈性可以商量，可以也應該要納⼊入⼯工程端的想法• 因此，參與新產品開發，不要把⼯工程師只當做⼯工⼈人，⽽而是⼀一起積極參與產品規劃。• ⼤大家都透過 Lean Startup 的 BML 循環來學習驗證

2. ⾃自找⿇麻煩的固定開發週期• 已知：營運 Operation team 不適⽤用 • Op team 是 Event-driven，每天都有問題需要優先處理 • 無法事先計畫⼀一週不被打擾的 Sprint • ⼀一天的 Sprint 也不⾏行，有的任務會超過⼀一天

Startup 就只有⼀一個 Team 同時負責開發和營運啊!• Scrum 似乎假設了你會有分開的 Development Team 和 Ops Team• 只有⼀一個 Team，Developer 就是 DevOps• Product is Living，⽽而採⽤用 Sprint 的平均反應時間會是週期的⼀一半，太慢了。

UI 設計要在 Sprint 裡嗎? • 設計算是 Problem team 需求範圍還是 Solution team 範圍? • 如果放 Solution 範圍，在 Sprint 內完成的話 • planning meeting 時可能會發⽣生⼯工程師會無法估計⼯工時的情況 (UI 複雜度可能會影響施⼯工難度) • Sprint 裡容易發⽣生 Developer 在空等設計的情況 • 好吧，那把設計提前⼀一個 Sprint?

你需要 Code Freeze 的驗收測試階段嗎?• 完美的 Scrum 世界，每個 sprint 結束就是可以發佈的狀態，所以不需要• 實際上，Sprint 1 之後你會得到有 bug 的 1.0.0 版本• 所以 Sprint 2 會被 bug 回報插⼊入... • Scrum ⼤大師會跟你說那你 Sprint 要提⾼高品質啊...• 在 Scrum and XP from the Trenches ch.14 ⼀一書也提到，作者也沒辦法做到...• 實務上，他不建議有專⾨門的 release 階段，⽽而是塞到 Sprint 2 作為⾼高優先權....

錯置的 Deadline ⺫⽬目標• 容易發⽣生為了開發⽽而開發的情況，為了塞滿這兩週開發週期的能量，不讓⼯工程師閒著，⽽而找事情給⼯工程師做。• 設定 sprint 也會偏向讓⼤大家計較完成的 deadline，⽽而不是產品真正的⺫⽬目標。

Apple Store 審核時間不固定• 審核時間從幾天到兩週不固定• ⼀一個版本上架後，希望⾺馬上送審下⼀一個版本

Iteration 裡不能變更規格• 本意很好，但這是從 Problem team 和 Solution team 拆開的情況下，⽤用⼯工程師的⾓角度來看... PO 好邪惡，要改規格....• 對 startup 來說，⼤大家的⺫⽬目標⼀一致，需要變更就變更啊...• 不是每個⼈人都介意修改

同⼀一個開發週期嗎?• 我的產品有 iOS, Android, Web 三個版本• Scrum ⼤大師說，要 cross-functional，每個⼈人都要會 coding iOS, Android, Web 才是同⼀一個 Team...

Continuous Deployment http://radar.oreilly.com/2009/03/continuous- deployment-5-eas.html• Lean Startup 提倡的作法• fail often fail early 才是最有效率降低發佈⾵風險的辦法• 持續性的發佈產品，從每個 sprint 發佈⼀一次，縮短到每天，甚⾄至是每個 commit 就可以發佈。• 要怎麼跟固定週期的 Sprint 搭配呢?

到底哪些東⻄西要放 Sprint 前或後，要下⼀一個 Sprint 還是這⼀一個 Sprint?我們是來解決問題的，不是製造問題!!

3.只強調⼯工程品質• Lean Startup 講的低品質，跟 Scrum 講的⾼高品質，講的是兩回事• 前者主要講功能完善和作法• 後者主要講⼯工程品質，會定義於 Done 的條件• Lean Startup ⼀一樣不認同產品缺陷 Defect，產品發佈後才修正，的確是⼀一種浪費

有⼀一些品質，其實是可以商量的，在 Lean Startup 如果和學習驗證無關，就是浪費。• 例如： • 跨瀏覽器 • 效能更快 • ⼿手機和Web是否需要資料同步 • 節省空間 • 有多 Scale • 其他⼀一些使⽤用者不容易察覺，但是⼯工程上可以偷⼯工減料的⽅方法

4.不必要的估算• 估算在 Problem team 和 Solution team 的情境下很重要...• 但是其實只有在 delay 的成本超過估算的成本時，才需要做估算• 簡單的估計可以幫助團隊凝聚共識，但多了就浪費時間了

5.無法照顧全局的流程• Scrum 只照顧了 “開發 Solution” 的流程，局部最佳化了⼯工程⾯面。• 施⼯工前的要做什麼，施⼯工後的營運，著墨甚少。• 以為導⼊入 Scrum 可以得到產品開發的流程，是錯誤的幻想。導⼊入 Lean Startup 還⽐比較有⽤用... (⾮非戰之罪，本來就不是 Scrum 的⽤用途⿇麻)

雖然有這些疑慮，但我還是相信 Scrum。直到我念了Kanban...

Kanban 解放了我被⽅方法論禁錮的⼼心

最輕量的流程管理⽅方法• Kanban 抓住最重要的流程關鍵原則 • 局部最佳化的總和效益不等於整體最佳化效益，系統的產出應等於系統中最弱⼀一環的產出：系統之最⼤大有效產出決定於瓶頸資源或產能受限資源。• Kanban 的作法很簡單 • 視覺化看板 + 限制 WIP + 關注平均完成時間• Kanban 可以讓你包含整個全局流程

Kanban 適應性強! 正是變化最⼤大的 Startup 時期所需。適規應範性性較較強強

跟 Scrum 的相同點• 都是經驗主義(Empirical)： Inspection 和 Adaptation，團隊不斷⾃自我調整找出最適合的作法• 都是 Lean 和 Agile

相異點• Kanban ⽤用每個流程狀態定 WIP 上限， Scrum ⽤用 Sprint 定 WIP• 沒有定義好的 Roles，每個⼈人沒有⼀一定要 cross-functional• 沒有⼀一定要”固定週期不能改變”的 iteration • 開發週期、發佈週期、retrospective 週期都可以依照需求設定• 沒有⼀一定要做估算

抱歉，時間不夠，建議⼤大家可以回去看這本書...

結論: 勿以器馭⼼心• Agile 不⼀一定就是要⽤用 Timeboxed Iteration• 先從 Kanban 出發，再從 Scrum 和 XP 中依現實需求來組合使⽤用• 別讓框架框住你了「勿以器馭⼼心」是宮本武藏的名⾔言，出⾃自簡體版的 Kanban and Scrum 翻譯

推薦資料• The Lean Startup• Kanban and Scrum - making the most of both, InfoQ

http://ihower.tw	6161
http://syshen.cc	568
https://www.facebook.com	245
http://www.facebook.com	152
http://feeds.feedburner.com	117
http://www.plurk.com	104
http://tweetedtimes.com	31
https://twitter.com	15
https://t.co	13
http://t.co	9
https://si0.twimg.com	7
http://xianguo.com	7
http://webcache.googleusercontent.com	5
http://www.hksilicon.com	4
https://mail.google.com	4
http://m.facebook.com	4
https://plus.google.com	4
https://twimg0-a.akamaihd.net	2
http://www.intersquash.com	2
http://touch.facebook.com	2
https://m.facebook.com&_=1358348754403 HTTP	1
http://www.linkedin.com	1
http://dev.hksilicon.com	1
http://getpocket.com	1
https://m.facebook.com&_=1358350949966 HTTP	1
http://www.newsblur.com	1
http://friendfeed.com	1
https://www.evernote.com	1
https://www.google.com.tw	1
https://imo.im	1
http://newsblur.com	1

從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup

by Wen-Tien Chang on Sep 12, 2012

Accessibility

Upload Details

Usage Rights

31 Embeds 7,467

Statistics