More Related Content
What's hot (20)
More from Hiroki Kondo (20)
Recently uploaded (10)
Kanban Vs Scrum日本語版
- 1. カンバン vs スクラム 実践ガイド Future of Agile, Stockholm May 27, 2009 Henrik Kniberg - Crisp AB Agile coach & Java guy Cofounder / CTO of Goyada (mobile services) 30 developers 09/9/2 Lead architect at Ace Interactive (gaming) 20 developers Henrik Kniberg Chief of development at Tain (gaming) 40 developers Agile coach at various companies [email protected] +46 70 4925284 1
- 2. 最初に このプレゼンテーションの目的: カンバンとスクラムを比較することではっきりさせること。 ... そして、あなたの環境でこれらのツールをどのように使えそう か、わかるでしょう。 Henrik Kniberg 22 2
- 3. 組織を分ける スクラムを一言で表すと 製品を分ける 大きなグループでは大きなモノの構築に長い時間を費やす。 小さなチームは小さいモノの構築に短い時間を費やす。 …でも全体を眺めるために定期的に統合します。 プロセスを最適化 ビジネスの価値を最適化 $$$ 時間を分割 1月 4月 $ Not checked out Done! :o) SP INT G A : B R O L eta-ready rel ease! checked out Burndown Write Deposit failing test 2d DAO Code Inte gr cle anup DB test 2d 0.5d desig n 1d 2d 1d GUI Write Migration sp ec 2d fa iling 2d te st 1d 3d tool Tapes t ry sp ike Impl. 1d 2d migration 8d Backoffice Write failin g test Login I mpl GUI 2d Unpl anned items Next In tegr. 1d with JBoss 2d Write Fix memo leak ry Sal es sup port Withdraw P test erf Backoffice fail ing test WriteIRA (J failin g 2d te st 125) Withdraw 3d 3d Write User adm whitepap er in 4d GUI Clarify desig n req uire- Impl (CSS) ments GUI 1d 2d 6d Henrik Kniberg 33 3
- 4. カンバンを一言で表すと… To do Dev Test Release Done! 5 3 2 3 仕事の流れを見える化 H F D C A I G E 作業中(WIP:work in J B K progress)を制限 測定、そして流れの最適化 FLOW Henrik Kniberg 44 4
- 5. カンバンのルーツ(トヨタ) 看板 買い手 納入業者 消費 取り外し 受取 出荷 割当 製造 必要な時に必要なだけ生産という考え方(Just- in-time)と、自律と人間味のある自動化(自働化) がトヨタ生産方式の二つの柱です。 これらの仕組みを運営するためツールがカンバ ンです。 トヨタ生産方式の父 大野耐一氏 Henrik Kniberg 55 5
- 6. ソフトウェア開発におけるカンバン Henrik Kniberg 66 6
- 7. カンバンとスクラム、 どちらもプロセスの(仕事を流す)ためのツール 物理的なツール プロセスのツール 別名 ”組織のパターン” プロダクトオーナー ペアプロ 食事しながら ミーティング Henrik Kniberg 77 7
- 8. 前もって決められているか vs 適応か 前もって決められている方向 より適応する方向 RUP XP スクラム カンバン なんでもする (120+ (13) (9) (3) (0) • • • Architecture Reviewer Business Designer Business-Model Reviewer ) • • • Business use case realization Business use-case model Business vision • • Whole team Coding standard • • Scrum Master Product Owner • • Visualize the workflow Limit WIP • Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time • Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting • Change Control Manager • Configuration management plan • Customer tests • Daily Scrum • Code Reviewer • Data model • Pair programming • Sprint review • Configuration Manager • Deployment model • Refactoring • Product backlogt • Course Developer • Deployment plan • Planning game • Sprint backlog • Database Designer • Design guidelines • Continuous integration • BUrndown chart • Deployment Manager • Design model • Simple design • Design Reviewer • Development case • Sustainable pace • Designer • Development-organization • Metaphor • Graphic Artist assessment • Small releases • Implementer • End-user support mateirla • Integrator • Glossary • Process Engineer • Implementation model • Project Manager • Installation artifacts • Project Reviewer • Integration build plan • Requirements Reviewer • Issues list • Requirements Specifier • Iteration assessment • Software Architect • Iteration plan • Stakeholder • Manual styleguide • System Administrator • Programming guidelines • System Analyst • Quality assurance plan • Technical Writer • Reference architecture • Test Analyst • Release notes • • • Test Designer Test Manager Tester • • Requirements attributes Requirements management plan 武器や流派にこだわるな。 • • • Tool Specialist User-Interface Designer Architectural analysis • • • Review record Risk list Risk management plan (引用:アジャイルソフトウェア開発 • • Assess Viability of architectural proof-of-concept Capsule design • • Software architecture document Software development 著アリスター・コーバーン) • Class design plan • Construct architectural proof-of- • Software requirements specification • • concept Database design Describe distribution • • • Stakeholder requests Status assessment Supplementary business specification 宮本武蔵 • • Describe the run-time architecture Design test packages and classes • • Supplementary specification Target organization assessment 1584-1645 • Develop design guidelines • Test automation architecture • Develop programming guidelines • Test cases • Identify design elements • Test environment configuration • Identify design mechanisms • Test evaluation summary • Incorporate design elements • Test guidelines • Prioritize use cases • Test ideas list • Review the architecture • Test interface specification • Review the design • Test plan • Structure the implementation model • Test suite • Subsystem design • Tool guidelines • Use-case analysis • Training materials • Use-case design • Use case model • Analysis model • Use case package • Architectural proof-of-concept • Use-case modeling guidelines • Bill of materials • Use-case realization • Business architecture document • Use-case storyboard • Business case • User-interface guidelines • Business glossary • User-interface prototype • Business modeling guidelines • Vision Henrik Kniberg 88 8 • Business object model • Work order • Business rules • Workload analysis model • Business use case
- 9. スクラムの定義する役割 P SM O Henrik Kniberg 99 9
- 10. スクラムが定義するイテレーション スクラムチーム week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 カンバンチーム 1 スプリント 1 スプリント 2 計画 と合意 デモ ふりかえり (リリース?) カンバンチーム 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 ふりかえり (4w) 計画 周期 (2w) リリース周期 (1w) カンバンチーム 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 ふりかえり (4w) 計画 (必要時) リリース(必要時) Henrik Kniberg 10
- 11. どちらも作業中(WIP)を制限するが、方法が異 なる スクラムボード カンバンボード To do Ongoing Done :o) To do Ongoing Done :o) 2 A A B B C C D D FLOW FLOW 作業中を時間単位で制限 作業中を状態で制限 (iteration) 作業中:WIP(Work in Progress) Henrik Kniberg 1111 11
- 12. どちらも経験に基づいている 速度 リードタイム 品質 予測可能性 (aka ベロシティ) (akaサイクルタイム) (障害の割合等) (SLAの達成,等) カンバンは、より再構成しやすい すごい！たくさんの うわぁ、もっと複雑に 多くの小さなチーム 2,3の大きなチーム 選択肢がある！ なってしまった! 作業中制限(少) 大きい作業中制限 ワークフローの状態(少) ワークフローの状態(大) イテレーション(短) イテレーション(大) 計画回数(少) 計画回数(大) .... etc ... .... etc ... Henrik Kniberg 1212 12
- 13. 例: WIP制限による実験 Monday, Week 1 Monday, Week 2 Monday, Week 3 Monday, Week 4 To do Ongoing Done :o) To do Ongoing Done :o) To do Ongoing To do Ongoing Done :o) Done :o) 1 8 8 8 C B A C A D A D A B H B B D E D E E E F I F C L C F F G G G M ZZZZzzzzz H z N I 暇で暇でしょうがな 統合しているサーバ J い。WIP制限を8にし で問題があってDとE K てみよう。 が終わらなかったぞ。 代わりにFとGをやら ないと。 うわぁ。WIP制限に ひっかかった。すぐ に作業を止めて統 WIP制限を4にし Monday, Week 5 合しているサーバを てみよう。そして 直さないと! 次は早めに対処 To do Ongoing Done :o) 4 しよう。 N L J O M K P Henrik Kniberg 1313 13
- 14. Eが欲しくなったよ! スクラムはイテレーション中変更を許可しませ P ん。 O To Do のスロットが空く のを待ってください。そ 次のスプリントまで待っ れかCかDと交換してく てください ださい。 Scrum Kanban To do Ongoing Done :o) To do Ongoing Done :o) 2 2 C A C A D B D B FLOW FLOW Henrik Kniberg 1414 14
- 15. スクラムボードはどのイテレーション間でもリ セットします。 Scrum スプリントの最初の日 スプリント中 スプリントの最終日 Kanban いつでも Henrik Kniberg 1515 15
- 16. スクラムはなんでも屋チームで規定されます。 スクラム カンバン – 例 1 カンバン – 例 2 専門家 専門家 なんでも屋の なんでも屋の チーム なんでも屋の チーム チーム チーム Henrik Kniberg 1616 16
- 17. スクラムのバックログ要素はスプリントに合わ ければなりません。 スクラム Sprint 1 Sprint 2 Sprint 3 Sprint 4 カンバン 期間を跨ったタスク WIPの制限 = 3 期間を跨ったタスク Henrik Kniberg 1717 17
- 18. スクラムでは、見積もりやベロシティは規定さ れています。 V= 8 V= 7 V= 9 1 2 2 1 1 2 ベロシティは大体: 8 / sprint 2 3 1 3 1 2 2 1 (継続的なペースですか?) Sprint 1 Sprint 2 Sprint 3 Henrik Kniberg 1818 18
- 19. どちらも同時に複数の製品に携わることがで きます。 スクラムの例 1 カンバンの例1 製品毎のチーム 色で意味づいたタスク 緑の製品 黄の製品 緑チーム 黄チーム スクラムの例2 スクラムの例 3 カンバンの例2 製品をまたいだ 全ての製品 製品をまたいだ レーンで意味づいたタスク 全ての製品 チーム チーム Henrik Kniberg 1919 19
- 20. 1. 短期的財務目標を犠牲にしてでも長期的な考えで経営判断する。 2. 淀みのない流れをつくって、問題を表面化させる どちらもリーン 3. プルシステムを利用して、つくり過ぎのムダを防ぐ 4. 生産量を平準化する(ウサギではなく、亀のペースで仕事をする) でアジャイル 5. 問題を解決するためにラインを止め、品質を最初からつくり込むカルチャーを定着 させる。 6. 標準化作業が絶え間ない改善と従業員の自主活動の土台になる。 7. すべての問題を顕在化させるために目で見る管理を使う 8. 技術を使うなら、実績があり、枯れた、人や工程に役立つ技術だけを利用する。 1. プロセスやツールより 9. 仕事をよく理解し、思想を実行し、他人に教えるリーダーを育成する 人と人同士の相互作用を重視する。 10. 会社の考え方に従う卓越したヒトとチームを育成する 2. 包括的なドキュメントより 11. パートナーや部品メーカ等の社外ネットワークを尊重し、改善するのを助ける 動作するソフトウェアを重視する。 12. 現地現物を徹底的に理解するように自分の目で確かめる(現地現物) 3. 契約上の交渉よりも 顧客との協調を重視する 13. 意思決定はじっくりコンセンサスをつくりながら、あらゆる選択肢を十分検討する が、実行は素早く行う(根回し) 4. 計画に従うことよりも 変化に対応することを重視する。 14. 執拗な反省と絶え間ない改善により学習する組織になる リーン 人 ジャス 品質 ライン ト・ コスト 改善 イン・ を タイム リードタイム 止める 無駄を省 く Henrik Kniberg 2020 いつでも使える状態を保つ 20
- 21. 小さな違い: スクラムにはプロダクトバックログがある スクラム: カンバン: プロダクトバックログは必ず存 プロダクトバックログは必ずしも存 在する。 在しない。 プロダクトバックログの変更は プロダクトバックログは着手可能 次のスプリントに影響する。 であればすぐに変更できる (現在のスプリントではない) あらゆる優先度を順付ける枠組 プロダクトバックログはビジネ みを使える。例えば: ス価値が大きいものから順に どの項目からでも 並べられる いつも一番上の項目から いつも一番古い項目から 20%は保守項目から、 80%は新機能から ... だけど多くのチームではこれらのアプローチを組み 製品Aと製品Bを均等に 合わせてつかってるけどね 緊急の項目を先に Henrik Kniberg 2121 21
- 22. 小さな違い: スクラムには朝会がある ... だけど多くのカンバンチームもそうしているね。 Henrik Kniberg 2222 22
- 23. 小さな違い: スクラムにはバーンダウンチャートがある。 Burndown カンバンといえば「これ」といった 70 図はない。チームにとって必要で 60 あればどんなものでも使う。 Estim work 50 ated remaining 40 30 20 10 August 1 2 3 4 5 8 9 10 11 12 15 16 17 18 19 Date Henrik Kniberg 2323 23
- 24. 例: スクラムボード vs カンバンボード スクラム Product Sprint backlog backlog Committed Ongoing Done :o) E E F A F G B HG I C J H L K D M カンバン Dev Backlog Selected 3 In production :o) 2 Ongoing Done D B A X F R G E C H Q I J L M K Henrik Kniberg 2424 24
- 25. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 2525 25
- 26. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 2626 26
- 27. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 2727 27
- 28. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 2828 28
- 29. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 2929 29
- 30. シナリオ1 –ある仕事の流れ Dev Backlog Selected 3 In production :o) 2 Ongoing Done F D C A G B E H I J L M K Henrik Kniberg 3030 30
- 31. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 3131 31
- 32. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 3232 32
- 33. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 3333 33
- 34. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 3434 34
- 35. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done C A G D !? B F H I J L E M K Henrik Kniberg 3535 35
- 36. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done G !? A D B F E C H I J L M K Henrik Kniberg 3636 36
- 37. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 3737 37
- 38. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 3838 38
- 39. シナリオ 2 – 問題があったときの展開 Dev Backlog Selected 3 In production :o) 2 Ongoing Done D A G B E F C H I J L M K Henrik Kniberg 3939 39
- 40. カンバン vs スクラム www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf 概要 にているところ ちがうところ スクラム カンバン どちらもリーンでアジャイルである 時間を区切ったイテレーション(タイム 時間を区切ったイテレーションは必須 どちらもプルスケジュールを基にしている ボックス)が定義されている。 ではない イテレーション内の仕事量を具体的にする コミットメントは必須ではない どちらもWIPの制限がある ため、チームでコミットする。 どちらも透明性に基づいて、改善をよりしや ベロシティを計画づくりとプロセス改善の リードタイムを計画づくりとプロセス改善 すくしている ための標準の測定基準として使う のための標準測定基準として使う どちらもソフトウェアを早く、頻繁にリリース 職制を横断したチームが規定されてい 職制を横断するチームはオプション。専門 可能にすることに注力する。 る 家のチームが許される。 どちらも自己組織的なチームに基づく 1スプリントに完了できる大きさにタス タスクの大きさに特に決まりがない。 クを分割する. どちらも作業を細かく分割することを求める バーンダウンチャートが定義されてい 図の種類について特に決まりがない。 どちらもリリース計画を実証されたデータ(ベ る。 ロシティ/リードタイム)を継続的に最適にしてWIPの制限が間接的 (スプリントごと) WIPの制限が直接的 (ワークフローの状 いる 態ごと) 見積もりをする。 見積もりは必須ではない。 進行中のスプリントにタスクを追加でき 着手可能な時タスクを追加できる。 ない。 スプリントバックログは特定のチーム カンバンボードは複数のチーム、もしく からのみ所有される。 は人々が共有できる。 3つの役割 (PO/SM/Team) 役割は特に規定されない スプリントごとにスクラムボードはリ カンバンボードにリセットするタイミング セット はない 優先順位付けされたプロダクトバックロ 優先順位付けは必須ではない グが規定されている Henrik Kniberg 4040 40
- 41. 一番大切なこと: ふりかえりと共にはじめよう! より自分たちにあったプロセ スに進化させよう. 最初は間違えてもいいじゃ ない いいことは道具箱に追加し よう。 試そう! Henrik Kniberg 4141 41