從 Scrum 到 Kanban:

為什麼 Scrum 不適合 Lean Startup

CTO PassionBeanihower@gmail.com

2012/9/11

About me

• 張⽂文鈿 a.k.a. ihower

• http://ihower.tw

• 熱情⾖豆⾏行動樂活科技 CTO

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

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

第⼀一名竟然是 The Lean Startup ?!!

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

第⼀一名竟然是 The Lean Startup ?!!

這個作者 Eric Ries 竟然是CTO技術出⾝身!!

好吧，就來翻⼀一翻

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

Cross-functionalSolution Team

PO

Dev Dev Dev Dev Dev Dev

SM

決定做什麼 決定怎麼做

• 採⽤用 Scrum，你其實有兩個 Team，⽽而 cross-functional 和 self-organized 講的都是右邊的Team。

• 決定做什麼是 startup 最關鍵的事情，但是 Scrum 裡都交給書裡篇幅最少的PO

• Scrum 常站在⼯工程團隊的⾓角度去凸顯 Problem team 和 Solution team 之間的衝突 (例如 SM 要保護右邊 Team 的⼈人不受干擾，⽼老把⽼老闆跟PO當成敵⼈人。建議 PO 和 SM 最好不要同⼀一⼈人因為⾓角⾊色衝突)

Cross-functional?

⺫⽬目標不⼀一致也許是不同部⾨門，或是外包的情況

• Problem team: 盡量壓榨 Solution Team 做更多的事情

• Solution team: 可以如期 (Sprint) ⾼高品質的完⼯工

Startup 應該只有⼀一個 Team

Problem/Solution Team

DesignDev 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 Deploymenthttp://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