SlideShare uma empresa Scribd logo
1 de 42
Baixar para ler offline
從 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

Mais conteúdo relacionado

Mais procurados

敏捷軟體開發方法與 Scrum 簡介
敏捷軟體開發方法與 Scrum 簡介敏捷軟體開發方法與 Scrum 簡介
敏捷軟體開發方法與 Scrum 簡介曦 徐
 
如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致Jen-Chieh Ko
 
「システムメタファ」再考 公開用
「システムメタファ」再考 公開用「システムメタファ」再考 公開用
「システムメタファ」再考 公開用ESM SEC
 
使用者故事對照 User Story Mapping
使用者故事對照 User Story Mapping使用者故事對照 User Story Mapping
使用者故事對照 User Story Mapping柏鈞 邱
 
シン モブ・プログラミング 第三形態
シン モブ・プログラミング 第三形態シン モブ・プログラミング 第三形態
シン モブ・プログラミング 第三形態atsushi nagata
 
不確実性に対応する開発手法 - スクラムの基礎
不確実性に対応する開発手法 - スクラムの基礎不確実性に対応する開発手法 - スクラムの基礎
不確実性に対応する開発手法 - スクラムの基礎西岡 賢一郎
 
敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊William Yeh
 
そのコマは回り続けるかそれとも倒れるか
そのコマは回り続けるかそれとも倒れるかそのコマは回り続けるかそれとも倒れるか
そのコマは回り続けるかそれとも倒れるかtoshihiro ichitani
 
從乙方PM的角度看敏捷
從乙方PM的角度看敏捷從乙方PM的角度看敏捷
從乙方PM的角度看敏捷KC Liu
 
微服務架構 導入經驗分享 吳剛志 - Community Open Camp
微服務架構 導入經驗分享 吳剛志 - Community Open Camp微服務架構 導入經驗分享 吳剛志 - Community Open Camp
微服務架構 導入經驗分享 吳剛志 - Community Open CampAndrew Wu
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?Yoshitaka Kawashima
 
我的 DevOps 故事
我的 DevOps 故事我的 DevOps 故事
我的 DevOps 故事Poy Chang
 
Stop Retrospective, Start Continuous Improving
Stop Retrospective, Start Continuous ImprovingStop Retrospective, Start Continuous Improving
Stop Retrospective, Start Continuous ImprovingJen-Chieh Ko
 
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会Arata Fujimura
 
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキTakao Oyobe
 
Scrum深入淺出
Scrum深入淺出Scrum深入淺出
Scrum深入淺出Taien Wang
 
PayPayのスピード×ビジネス×デザイン
PayPayのスピード×ビジネス×デザインPayPayのスピード×ビジネス×デザイン
PayPayのスピード×ビジネス×デザインEri Fujiki
 
もし新人のインフラエンジニアがKPTで振り返りをしたら
もし新人のインフラエンジニアがKPTで振り返りをしたらもし新人のインフラエンジニアがKPTで振り返りをしたら
もし新人のインフラエンジニアがKPTで振り返りをしたらYukitaka Ohmura
 
はじめての自己組織化
はじめての自己組織化はじめての自己組織化
はじめての自己組織化Yoshinori Ueda
 
敏捷領導力 Agile leadership
敏捷領導力 Agile leadership敏捷領導力 Agile leadership
敏捷領導力 Agile leadershipYves Lin
 

Mais procurados (20)

敏捷軟體開發方法與 Scrum 簡介
敏捷軟體開發方法與 Scrum 簡介敏捷軟體開發方法與 Scrum 簡介
敏捷軟體開發方法與 Scrum 簡介
 
如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致
 
「システムメタファ」再考 公開用
「システムメタファ」再考 公開用「システムメタファ」再考 公開用
「システムメタファ」再考 公開用
 
使用者故事對照 User Story Mapping
使用者故事對照 User Story Mapping使用者故事對照 User Story Mapping
使用者故事對照 User Story Mapping
 
シン モブ・プログラミング 第三形態
シン モブ・プログラミング 第三形態シン モブ・プログラミング 第三形態
シン モブ・プログラミング 第三形態
 
不確実性に対応する開発手法 - スクラムの基礎
不確実性に対応する開発手法 - スクラムの基礎不確実性に対応する開発手法 - スクラムの基礎
不確実性に対応する開発手法 - スクラムの基礎
 
敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊
 
そのコマは回り続けるかそれとも倒れるか
そのコマは回り続けるかそれとも倒れるかそのコマは回り続けるかそれとも倒れるか
そのコマは回り続けるかそれとも倒れるか
 
從乙方PM的角度看敏捷
從乙方PM的角度看敏捷從乙方PM的角度看敏捷
從乙方PM的角度看敏捷
 
微服務架構 導入經驗分享 吳剛志 - Community Open Camp
微服務架構 導入經驗分享 吳剛志 - Community Open Camp微服務架構 導入經驗分享 吳剛志 - Community Open Camp
微服務架構 導入經驗分享 吳剛志 - Community Open Camp
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
我的 DevOps 故事
我的 DevOps 故事我的 DevOps 故事
我的 DevOps 故事
 
Stop Retrospective, Start Continuous Improving
Stop Retrospective, Start Continuous ImprovingStop Retrospective, Start Continuous Improving
Stop Retrospective, Start Continuous Improving
 
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
 
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
 
Scrum深入淺出
Scrum深入淺出Scrum深入淺出
Scrum深入淺出
 
PayPayのスピード×ビジネス×デザイン
PayPayのスピード×ビジネス×デザインPayPayのスピード×ビジネス×デザイン
PayPayのスピード×ビジネス×デザイン
 
もし新人のインフラエンジニアがKPTで振り返りをしたら
もし新人のインフラエンジニアがKPTで振り返りをしたらもし新人のインフラエンジニアがKPTで振り返りをしたら
もし新人のインフラエンジニアがKPTで振り返りをしたら
 
はじめての自己組織化
はじめての自己組織化はじめての自己組織化
はじめての自己組織化
 
敏捷領導力 Agile leadership
敏捷領導力 Agile leadership敏捷領導力 Agile leadership
敏捷領導力 Agile leadership
 

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

Agile scrum in startup
Agile scrum in startup  Agile scrum in startup
Agile scrum in startup Len Chang
 
Scrum essential
Scrum essentialScrum essential
Scrum essential國昭 張
 
银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011Yi Xu
 
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdfIvan Chiou
 
现代化敏捷测试工作者
现代化敏捷测试工作者现代化敏捷测试工作者
现代化敏捷测试工作者Yi Xu
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comdrewz lin
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comdrewz lin
 
需求怎麼估 20150424新竹scrum社群分享
需求怎麼估 20150424新竹scrum社群分享需求怎麼估 20150424新竹scrum社群分享
需求怎麼估 20150424新竹scrum社群分享Juggernaut Liu
 
Agile introduction
Agile introductionAgile introduction
Agile introductionJen-Chieh Ko
 
Scrum Agile Development
Scrum Agile DevelopmentScrum Agile Development
Scrum Agile DevelopmentSchubert Zhang
 
Getting Real
Getting RealGetting Real
Getting Realrogerwang
 
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑Chang Shih-Chieh
 
關於產品經理的角色與職責
關於產品經理的角色與職責關於產品經理的角色與職責
關於產品經理的角色與職責Cloud Chen
 
Agile taichung 50個人跑scrum
Agile taichung 50個人跑scrumAgile taichung 50個人跑scrum
Agile taichung 50個人跑scrumTerry Wang
 
那些年我不在 Scrum team 的日子
那些年我不在 Scrum team 的日子那些年我不在 Scrum team 的日子
那些年我不在 Scrum team 的日子Ken Kuan
 
Scrum gathering 2014sharing v4
Scrum gathering 2014sharing v4Scrum gathering 2014sharing v4
Scrum gathering 2014sharing v4Jen-Chieh Ko
 
敏捷软件开发——一个实践者的思考V1.2
敏捷软件开发——一个实践者的思考V1.2敏捷软件开发——一个实践者的思考V1.2
敏捷软件开发——一个实践者的思考V1.2Zhang Yongji
 
一個 agilist 的獨白
一個 agilist 的獨白一個 agilist 的獨白
一個 agilist 的獨白Terry Wang
 

Semelhante a 從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup (20)

Agile scrum in startup
Agile scrum in startup  Agile scrum in startup
Agile scrum in startup
 
Scrum essential
Scrum essentialScrum essential
Scrum essential
 
银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011银弹!银弹! 徐毅@Italk salon 2011
银弹!银弹! 徐毅@Italk salon 2011
 
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
 
现代化敏捷测试工作者
现代化敏捷测试工作者现代化敏捷测试工作者
现代化敏捷测试工作者
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.com
 
Djt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.comDjt22 justinliu djt.qq.com
Djt22 justinliu djt.qq.com
 
需求怎麼估 20150424新竹scrum社群分享
需求怎麼估 20150424新竹scrum社群分享需求怎麼估 20150424新竹scrum社群分享
需求怎麼估 20150424新竹scrum社群分享
 
Agile introduction
Agile introductionAgile introduction
Agile introduction
 
Scrum Agile Development
Scrum Agile DevelopmentScrum Agile Development
Scrum Agile Development
 
Getting Real
Getting RealGetting Real
Getting Real
 
SCRUM
SCRUMSCRUM
SCRUM
 
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
 
關於產品經理的角色與職責
關於產品經理的角色與職責關於產品經理的角色與職責
關於產品經理的角色與職責
 
Agile taichung 50個人跑scrum
Agile taichung 50個人跑scrumAgile taichung 50個人跑scrum
Agile taichung 50個人跑scrum
 
那些年我不在 Scrum team 的日子
那些年我不在 Scrum team 的日子那些年我不在 Scrum team 的日子
那些年我不在 Scrum team 的日子
 
Scrum培训
Scrum培训Scrum培训
Scrum培训
 
Scrum gathering 2014sharing v4
Scrum gathering 2014sharing v4Scrum gathering 2014sharing v4
Scrum gathering 2014sharing v4
 
敏捷软件开发——一个实践者的思考V1.2
敏捷软件开发——一个实践者的思考V1.2敏捷软件开发——一个实践者的思考V1.2
敏捷软件开发——一个实践者的思考V1.2
 
一個 agilist 的獨白
一個 agilist 的獨白一個 agilist 的獨白
一個 agilist 的獨白
 

Mais de Wen-Tien Chang

⼤語⾔模型 LLM 應⽤開發入⾨
⼤語⾔模型 LLM 應⽤開發入⾨⼤語⾔模型 LLM 應⽤開發入⾨
⼤語⾔模型 LLM 應⽤開發入⾨Wen-Tien Chang
 
Ruby Rails 老司機帶飛
Ruby Rails 老司機帶飛Ruby Rails 老司機帶飛
Ruby Rails 老司機帶飛Wen-Tien Chang
 
A brief introduction to Machine Learning
A brief introduction to Machine LearningA brief introduction to Machine Learning
A brief introduction to Machine LearningWen-Tien Chang
 
淺談 Startup 公司的軟體開發流程 v2
淺談 Startup 公司的軟體開發流程 v2淺談 Startup 公司的軟體開發流程 v2
淺談 Startup 公司的軟體開發流程 v2Wen-Tien Chang
 
RSpec on Rails Tutorial
RSpec on Rails TutorialRSpec on Rails Tutorial
RSpec on Rails TutorialWen-Tien Chang
 
ALPHAhackathon: How to collaborate
ALPHAhackathon: How to collaborateALPHAhackathon: How to collaborate
ALPHAhackathon: How to collaborateWen-Tien Chang
 
Git 版本控制系統 -- 從微觀到宏觀
Git 版本控制系統 -- 從微觀到宏觀Git 版本控制系統 -- 從微觀到宏觀
Git 版本控制系統 -- 從微觀到宏觀Wen-Tien Chang
 
Exception Handling: Designing Robust Software in Ruby (with presentation note)
Exception Handling: Designing Robust Software in Ruby (with presentation note)Exception Handling: Designing Robust Software in Ruby (with presentation note)
Exception Handling: Designing Robust Software in Ruby (with presentation note)Wen-Tien Chang
 
Exception Handling: Designing Robust Software in Ruby
Exception Handling: Designing Robust Software in RubyException Handling: Designing Robust Software in Ruby
Exception Handling: Designing Robust Software in RubyWen-Tien Chang
 
從 Classes 到 Objects: 那些 OOP 教我的事
從 Classes 到 Objects: 那些 OOP 教我的事從 Classes 到 Objects: 那些 OOP 教我的事
從 Classes 到 Objects: 那些 OOP 教我的事Wen-Tien Chang
 
Yet another introduction to Git - from the bottom up
Yet another introduction to Git - from the bottom upYet another introduction to Git - from the bottom up
Yet another introduction to Git - from the bottom upWen-Tien Chang
 
A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩
A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩
A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩Wen-Tien Chang
 
Ruby 程式語言綜覽簡介
Ruby 程式語言綜覽簡介Ruby 程式語言綜覽簡介
Ruby 程式語言綜覽簡介Wen-Tien Chang
 
A brief introduction to SPDY - 邁向 HTTP/2.0
A brief introduction to SPDY - 邁向 HTTP/2.0A brief introduction to SPDY - 邁向 HTTP/2.0
A brief introduction to SPDY - 邁向 HTTP/2.0Wen-Tien Chang
 
RubyConf Taiwan 2012 Opening & Closing
RubyConf Taiwan 2012 Opening & ClosingRubyConf Taiwan 2012 Opening & Closing
RubyConf Taiwan 2012 Opening & ClosingWen-Tien Chang
 
那些 Functional Programming 教我的事
那些 Functional Programming 教我的事那些 Functional Programming 教我的事
那些 Functional Programming 教我的事Wen-Tien Chang
 
RubyConf Taiwan 2011 Opening & Closing
RubyConf Taiwan 2011 Opening & ClosingRubyConf Taiwan 2011 Opening & Closing
RubyConf Taiwan 2011 Opening & ClosingWen-Tien Chang
 
BDD style Unit Testing
BDD style Unit TestingBDD style Unit Testing
BDD style Unit TestingWen-Tien Chang
 

Mais de Wen-Tien Chang (20)

⼤語⾔模型 LLM 應⽤開發入⾨
⼤語⾔模型 LLM 應⽤開發入⾨⼤語⾔模型 LLM 應⽤開發入⾨
⼤語⾔模型 LLM 應⽤開發入⾨
 
Ruby Rails 老司機帶飛
Ruby Rails 老司機帶飛Ruby Rails 老司機帶飛
Ruby Rails 老司機帶飛
 
A brief introduction to Machine Learning
A brief introduction to Machine LearningA brief introduction to Machine Learning
A brief introduction to Machine Learning
 
淺談 Startup 公司的軟體開發流程 v2
淺談 Startup 公司的軟體開發流程 v2淺談 Startup 公司的軟體開發流程 v2
淺談 Startup 公司的軟體開發流程 v2
 
RSpec on Rails Tutorial
RSpec on Rails TutorialRSpec on Rails Tutorial
RSpec on Rails Tutorial
 
RSpec & TDD Tutorial
RSpec & TDD TutorialRSpec & TDD Tutorial
RSpec & TDD Tutorial
 
ALPHAhackathon: How to collaborate
ALPHAhackathon: How to collaborateALPHAhackathon: How to collaborate
ALPHAhackathon: How to collaborate
 
Git 版本控制系統 -- 從微觀到宏觀
Git 版本控制系統 -- 從微觀到宏觀Git 版本控制系統 -- 從微觀到宏觀
Git 版本控制系統 -- 從微觀到宏觀
 
Exception Handling: Designing Robust Software in Ruby (with presentation note)
Exception Handling: Designing Robust Software in Ruby (with presentation note)Exception Handling: Designing Robust Software in Ruby (with presentation note)
Exception Handling: Designing Robust Software in Ruby (with presentation note)
 
Exception Handling: Designing Robust Software in Ruby
Exception Handling: Designing Robust Software in RubyException Handling: Designing Robust Software in Ruby
Exception Handling: Designing Robust Software in Ruby
 
從 Classes 到 Objects: 那些 OOP 教我的事
從 Classes 到 Objects: 那些 OOP 教我的事從 Classes 到 Objects: 那些 OOP 教我的事
從 Classes 到 Objects: 那些 OOP 教我的事
 
Yet another introduction to Git - from the bottom up
Yet another introduction to Git - from the bottom upYet another introduction to Git - from the bottom up
Yet another introduction to Git - from the bottom up
 
A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩
A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩
A brief introduction to Vagrant – 原來 VirtualBox 可以這樣玩
 
Ruby 程式語言綜覽簡介
Ruby 程式語言綜覽簡介Ruby 程式語言綜覽簡介
Ruby 程式語言綜覽簡介
 
A brief introduction to SPDY - 邁向 HTTP/2.0
A brief introduction to SPDY - 邁向 HTTP/2.0A brief introduction to SPDY - 邁向 HTTP/2.0
A brief introduction to SPDY - 邁向 HTTP/2.0
 
RubyConf Taiwan 2012 Opening & Closing
RubyConf Taiwan 2012 Opening & ClosingRubyConf Taiwan 2012 Opening & Closing
RubyConf Taiwan 2012 Opening & Closing
 
Git Tutorial 教學
Git Tutorial 教學Git Tutorial 教學
Git Tutorial 教學
 
那些 Functional Programming 教我的事
那些 Functional Programming 教我的事那些 Functional Programming 教我的事
那些 Functional Programming 教我的事
 
RubyConf Taiwan 2011 Opening & Closing
RubyConf Taiwan 2011 Opening & ClosingRubyConf Taiwan 2011 Opening & Closing
RubyConf Taiwan 2011 Opening & Closing
 
BDD style Unit Testing
BDD style Unit TestingBDD style Unit Testing
BDD style Unit Testing
 

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

  • 1. 從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup CTO PassionBean ihower@gmail.com 2012/9/11
  • 2. About me • 張⽂文鈿 a.k.a. ihower • http://ihower.tw • 熱情⾖豆⾏行動樂活科技 CTO
  • 3. 本來我也是不屑 Lean Startup 的,我⼜又不是創業家...
  • 4. 本來我也是不屑 Lean Startup 的,我⼜又不是創業家... 第⼀一名竟然是 The Lean Startup ?!!
  • 5. 本來我也是不屑 Lean Startup 的,我⼜又不是創業家... 這個作者 Eric Ries 竟 然是CTO技術出⾝身!! 第⼀一名竟然是 The Lean Startup ?!!
  • 8. Lean Startup • ⼀一套管理創業過程的⽅方法 • 透過 Build -> Measure -> Learn 的循環過程,快 速、低成本的科學實驗⽅方法,不斷調整來驗證 產品跟市場的契合度 • 開發任何功能前,都必須先有假設,然後當做 實驗來驗證學習。任何和學習無關的功能開發 都是浪費。 • 直到找出 Business Model 營利模式,才開始進 ⾏行規模擴張。
  • 9. ⼀一開始⺫⽬目標客⼾戶跟產品特性 都是不確定的 • Scrum/XP 等敏捷⽅方法論 • Problem 已知 (PO和Client會告訴你要建造什麼) • Solution 未知 (透過Iteration開發) • Lean Startup • Problem 未知 (透過BML循環逼近) • Solution 未知 (透過continuous deployment開發)
  • 11. 對我最⼤大的啟發 • 敏捷和精實開發強調開發有效率、不浪費 • 但是最⼤大的浪費是做出沒⼈人⽤用的東⻄西 • Lean Startup != 創業才能⽤用,只要開發新 產品,就值得⼀一看 • 我開始跨界了
  • 12. Scrum 跟 Lean Startup 不速配嗎?
  • 13. 我覺得有疑慮的幾點 • 不夠均衡的⾓角⾊色定義 • ⾃自找⿇麻煩的固定開發週期 • 只強調⼯工程品質 • 不必要的估算 • 無法照顧全局的流程
  • 14. 1. Scrum 不均衡的⾓角⾊色定義 決定做什麼 決定怎麼做 Problem Team PO SM Cross-functional Solution Team Dev Dev Dev Dev Dev Dev
  • 15. Cross-functional? • 採⽤用 Scrum,你其實有兩個 Team,⽽而 cross- functional 和 self-organized 講的都是右邊的Team。 • 決定做什麼是 startup 最關鍵的事情,但是 Scrum 裡都交給書裡篇幅最少的PO • Scrum 常站在⼯工程團隊的⾓角度去凸顯 Problem team 和 Solution team 之間的衝突 (例如 SM 要保護右邊 Team 的⼈人不受干擾,⽼老把⽼老闆跟PO當成敵⼈人。建議 PO 和 SM 最好不要同⼀一⼈人因為⾓角⾊色衝突)
  • 16. ⺫⽬目標不⼀一致 也許是不同部⾨門,或是外包的情況 • Problem team: 盡量壓榨 Solution Team 做 更多的事情 • Solution team: 可以如期 (Sprint) ⾼高品質的 完⼯工
  • 17. Startup 應該只有⼀一個 Team Problem/Solution Team Dev Design Marketing
  • 19. ⼈人⼈人都要參與產品規劃 • 在 startup 裡,PO也不知道做什麼才是對 • 在 startup 裡,要做什麼,scope 有多⼤大,⾮非常彈 性可以商量,可以也應該要納⼊入⼯工程端的想法 • 因此,參與新產品開發,不要把⼯工程師只當做⼯工 ⼈人,⽽而是⼀一起積極參與產品規劃。 • ⼤大家都透過 Lean Startup 的 BML 循環來學習驗證
  • 20. 2. ⾃自找⿇麻煩的固定開發週期 • 已知:營運 Operation team 不適⽤用 • Op team 是 Event-driven,每天都有問題需 要優先處理 • 無法事先計畫⼀一週不被打擾的 Sprint • ⼀一天的 Sprint 也不⾏行,有的任務會超過⼀一 天
  • 21. Startup 就只有⼀一個 Team 同 時負責開發和營運啊! • Scrum 似乎假設了你會有分開的 Development Team 和 Ops Team • 只有⼀一個 Team,Developer 就是 DevOps • Product is Living,⽽而採⽤用 Sprint 的平均反應 時間會是週期的⼀一半,太慢了。
  • 22. UI 設計要在 Sprint 裡嗎? • 設計算是 Problem team 需求範圍還是 Solution team 範圍? • 如果放 Solution 範圍,在 Sprint 內完成的話 • planning meeting 時可能會發⽣生⼯工程師會無法估計⼯工時的情況 (UI 複雜度可 能會影響施⼯工難度) • Sprint 裡容易發⽣生 Developer 在空等設計的情況 • 好吧,那把設計提前⼀一個 Sprint?
  • 23. 你需要 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 作為⾼高優先權....
  • 24. 錯置的 Deadline ⺫⽬目標 • 容易發⽣生為了開發⽽而開發的情況,為了 塞滿這兩週開發週期的能量,不讓⼯工程 師閒著,⽽而找事情給⼯工程師做。 • 設定 sprint 也會偏向讓⼤大家計較完成的 deadline,⽽而不是產品真正的⺫⽬目標。
  • 25. Apple Store 審核時間 不固定 • 審核時間從幾天到兩週不固定 • ⼀一個版本上架後,希望⾺馬上送審下⼀一個 版本
  • 26. Iteration 裡不能 變更規格 • 本意很好,但這是從 Problem team 和 Solution team 拆開的情況下,⽤用⼯工程師 的⾓角度來看... PO 好邪惡,要改規格.... • 對 startup 來說,⼤大家的⺫⽬目標⼀一致,需要 變更就變更啊... • 不是每個⼈人都介意修改
  • 27. 同⼀一個開發週期嗎? • 我的產品有 iOS, Android, Web 三個版本 • Scrum ⼤大師說,要 cross-functional,每個 ⼈人都要會 coding iOS, Android, Web 才是 同⼀一個 Team...
  • 28. Continuous Deployment http://radar.oreilly.com/2009/03/continuous- deployment-5-eas.html • Lean Startup 提倡的作法 • fail often fail early 才是最有效率降低發佈⾵風 險的辦法 • 持續性的發佈產品,從每個 sprint 發佈⼀一 次,縮短到每天,甚⾄至是每個 commit 就可 以發佈。 • 要怎麼跟固定週期的 Sprint 搭配呢?
  • 29. 到底哪些東⻄西要放 Sprint 前或後,要下⼀一個 Sprint 還是這⼀一個 Sprint? 我們是來解決問題 的,不是製造問題!!
  • 30. 3.只強調⼯工程品質 • Lean Startup 講的低品質,跟 Scrum 講的⾼高品 質,講的是兩回事 • 前者主要講功能完善和作法 • 後者主要講⼯工程品質,會定義於 Done 的條件 • Lean Startup ⼀一樣不認同產品缺陷 Defect,產 品發佈後才修正,的確是⼀一種浪費
  • 31. 有⼀一些品質,其實是可以商量的, 在 Lean Startup 如果和學習驗證無 關,就是浪費。 • 例如: • 跨瀏覽器 • 效能更快 • ⼿手機和Web是否需要資料同步 • 節省空間 • 有多 Scale • 其他⼀一些使⽤用者不容易察覺,但是⼯工程上可以 偷⼯工減料的⽅方法
  • 32. 4.不必要的估算 • 估算在 Problem team 和 Solution team 的 情境下很重要... • 但是其實只有在 delay 的成本超過估算的 成本時,才需要做估算 • 簡單的估計可以幫助團隊凝聚共識,但 多了就浪費時間了
  • 33. 5.無法照顧全局的流 程 • Scrum 只照顧了 “開發 Solution” 的流程, 局部最佳化了⼯工程⾯面。 • 施⼯工前的要做什麼,施⼯工後的營運,著 墨甚少。 • 以為導⼊入 Scrum 可以得到產品開發的流 程,是錯誤的幻想。導⼊入 Lean Startup 還 ⽐比較有⽤用... (⾮非戰之罪,本來就不是 Scrum 的⽤用途⿇麻)
  • 36. 最輕量的流程管理⽅方法 • Kanban 抓住最重要的流程關鍵原則 • 局部最佳化的總和效益不等於整體最佳化效益,系統的產出應等於 系統中最弱⼀一環的產出:系統之最⼤大有效產出決定於瓶頸資源或產 能受限資源。 • Kanban 的作法很簡單 • 視覺化看板 + 限制 WIP + 關注平均完成時間 • Kanban 可以讓你包含整個全局流程
  • 37. Kanban 適應性強! 正是變化 最⼤大的 Startup 時期所需。 適 規 應 範 性 性 較 較 強 強
  • 38. 跟 Scrum 的相同點 • 都是經驗主義(Empirical): Inspection 和 Adaptation,團隊不斷⾃自我調整找出最適 合的作法 • 都是 Lean 和 Agile
  • 39. 相異點 • Kanban ⽤用每個流程狀態定 WIP 上限, Scrum ⽤用 Sprint 定 WIP • 沒有定義好的 Roles,每個⼈人沒有⼀一定要 cross-functional • 沒有⼀一定要”固定週期不能改變”的 iteration • 開發週期、發佈週期、retrospective 週期都可以依照需求設定 • 沒有⼀一定要做估算
  • 41. 結論: 勿以器馭⼼心 • Agile 不⼀一定就是要⽤用 Timeboxed Iteration • 先從 Kanban 出發,再從 Scrum 和 XP 中 依現實需求來組合使⽤用 • 別讓框架框住你了 「勿以器馭⼼心」是宮本武藏的名⾔言,出⾃自簡體版的 Kanban and Scrum 翻譯
  • 42. 推薦資料 • The Lean Startup • Kanban and Scrum - making the most of both, InfoQ