Kanban Vs Scrum日本語版

Kanban Vs Scrum日本語版 - Presentation Transcript

カンバン 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 henrik.kniberg@crisp.se +46 70 4925284 1

最初にこのプレゼンテーションの目的: カンバンとスクラムを比較することではっきりさせること。 ... そして、あなたの環境でこれらのツールをどのように使えそうか、わかるでしょう。 Henrik Kniberg 22 2

組織を分けるスクラムを一言で表すと製品を分ける大きなグループでは大きなモノの構築に長い時間を費やす。小さなチームは小さいモノの構築に短い時間を費やす。 …でも全体を眺めるために定期的に統合します。プロセスを最適化ビジネスの価値を最適化 $$$ 時間を分割 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

カンバンを一言で表すと… 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

カンバンのルーツ(トヨタ) 看板買い手納入業者消費取り外し受取出荷割当製造必要な時に必要なだけ生産という考え方(Just- in-time)と、自律と人間味のある自動化(自働化) がトヨタ生産方式の二つの柱です。これらの仕組みを運営するためツールがカンバンです。トヨタ生産方式の父大野耐一氏 Henrik Kniberg 55 5

ソフトウェア開発におけるカンバン Henrik Kniberg 66 6

カンバンとスクラム、どちらもプロセスの(仕事を流す)ためのツール物理的なツールプロセスのツール別名 ”組織のパターン” プロダクトオーナーペアプロ食事しながらミーティング Henrik Kniberg 77 7

前もって決められているか 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

スクラムの定義する役割 P SM O Henrik Kniberg 99 9

スクラムが定義するイテレーションスクラムチーム 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

どちらも作業中(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

どちらも経験に基づいている速度リードタイム品質予測可能性 (aka ベロシティ) (akaサイクルタイム) (障害の割合等) (SLAの達成,等) カンバンは、より再構成しやすいすごい！たくさんのうわぁ、もっと複雑に多くの小さなチーム 2,3の大きなチーム選択肢がある！なってしまった! 作業中制限(少) 大きい作業中制限ワークフローの状態(少) ワークフローの状態(大) イテレーション(短) イテレーション(大) 計画回数(少) 計画回数(大) .... etc ... .... etc ... Henrik Kniberg 1212 12

例: 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

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

スクラムボードはどのイテレーション間でもリセットします。 Scrum スプリントの最初の日スプリント中スプリントの最終日 Kanban いつでも Henrik Kniberg 1515 15

スクラムはなんでも屋チームで規定されます。スクラムカンバン – 例 1 カンバン – 例 2 専門家専門家なんでも屋のなんでも屋のチームなんでも屋のチームチームチーム Henrik Kniberg 1616 16

スクラムのバックログ要素はスプリントに合わければなりません。スクラム Sprint 1 Sprint 2 Sprint 3 Sprint 4 カンバン期間を跨ったタスク WIPの制限 = 3 期間を跨ったタスク Henrik Kniberg 1717 17

スクラムでは、見積もりやベロシティは規定されています。 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

どちらも同時に複数の製品に携わることができます。スクラムの例 1 カンバンの例1 製品毎のチーム色で意味づいたタスク緑の製品黄の製品緑チーム黄チームスクラムの例2 スクラムの例 3 カンバンの例2 製品をまたいだ全ての製品製品をまたいだレーンで意味づいたタスク全ての製品チームチーム Henrik Kniberg 1919 19

1. 短期的財務目標を犠牲にしてでも長期的な考えで経営判断する。 2. 淀みのない流れをつくって、問題を表面化させるどちらもリーン 3. プルシステムを利用して、つくり過ぎのムダを防ぐ 4. 生産量を平準化する(ウサギではなく、亀のペースで仕事をする) でアジャイル 5. 問題を解決するためにラインを止め、品質を最初からつくり込むカルチャーを定着させる。 6. 標準化作業が絶え間ない改善と従業員の自主活動の土台になる。 7. すべての問題を顕在化させるために目で見る管理を使う 8. 技術を使うなら、実績があり、枯れた、人や工程に役立つ技術だけを利用する。 1. プロセスやツールより 9. 仕事をよく理解し、思想を実行し、他人に教えるリーダーを育成する人と人同士の相互作用を重視する。 10. 会社の考え方に従う卓越したヒトとチームを育成する 2. 包括的なドキュメントより 11. パートナーや部品メーカ等の社外ネットワークを尊重し、改善するのを助ける動作するソフトウェアを重視する。 12. 現地現物を徹底的に理解するように自分の目で確かめる(現地現物) 3. 契約上の交渉よりも顧客との協調を重視する 13. 意思決定はじっくりコンセンサスをつくりながら、あらゆる選択肢を十分検討するが、実行は素早く行う(根回し) 4. 計画に従うことよりも変化に対応することを重視する。 14. 執拗な反省と絶え間ない改善により学習する組織になるリーン人ジャス品質ライント・コスト改善イン・をタイムリードタイム止める無駄を省く Henrik Kniberg 2020 いつでも使える状態を保つ 20

小さな違い: スクラムにはプロダクトバックログがあるスクラム: カンバン: プロダクトバックログは必ず存プロダクトバックログは必ずしも存在する。在しない。プロダクトバックログの変更はプロダクトバックログは着手可能次のスプリントに影響する。であればすぐに変更できる (現在のスプリントではない) あらゆる優先度を順付ける枠組プロダクトバックログはビジネみを使える。例えば: ス価値が大きいものから順にどの項目からでも並べられるいつも一番上の項目からいつも一番古い項目から 20%は保守項目から、 80%は新機能から ... だけど多くのチームではこれらのアプローチを組み製品Aと製品Bを均等に合わせてつかってるけどね緊急の項目を先に Henrik Kniberg 2121 21

小さな違い: スクラムには朝会がある ... だけど多くのカンバンチームもそうしているね。 Henrik Kniberg 2222 22

小さな違い: スクラムにはバーンダウンチャートがある。 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

例: スクラムボード 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

シナリオ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

シナリオ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

シナリオ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

シナリオ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

シナリオ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

シナリオ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

シナリオ 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

シナリオ 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

シナリオ 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

シナリオ 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

シナリオ 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

シナリオ 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

シナリオ 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

シナリオ 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

シナリオ 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

カンバン vs スクラム www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf 概要にているところちがうところスクラムカンバンどちらもリーンでアジャイルである時間を区切ったイテレーション(タイム時間を区切ったイテレーションは必須どちらもプルスケジュールを基にしているボックス)が定義されている。ではないイテレーション内の仕事量を具体的にするコミットメントは必須ではないどちらもWIPの制限があるため、チームでコミットする。どちらも透明性に基づいて、改善をよりしやベロシティを計画づくりとプロセス改善のリードタイムを計画づくりとプロセス改善すくしているための標準の測定基準として使うのための標準測定基準として使うどちらもソフトウェアを早く、頻繁にリリース職制を横断したチームが規定されてい職制を横断するチームはオプション。専門可能にすることに注力する。る家のチームが許される。どちらも自己組織的なチームに基づく 1スプリントに完了できる大きさにタスタスクの大きさに特に決まりがない。クを分割する. どちらも作業を細かく分割することを求めるバーンダウンチャートが定義されてい図の種類について特に決まりがない。どちらもリリース計画を実証されたデータ(ベる。ロシティ/リードタイム)を継続的に最適にしてWIPの制限が間接的 (スプリントごと) WIPの制限が直接的 (ワークフローの状いる態ごと) 見積もりをする。見積もりは必須ではない。進行中のスプリントにタスクを追加でき着手可能な時タスクを追加できる。ない。スプリントバックログは特定のチームカンバンボードは複数のチーム、もしくからのみ所有される。は人々が共有できる。 3つの役割 (PO/SM/Team) 役割は特に規定されないスプリントごとにスクラムボードはリカンバンボードにリセットするタイミングセットはない優先順位付けされたプロダクトバックロ優先順位付けは必須ではないグが規定されている Henrik Kniberg 4040 40

一番大切なこと: ふりかえりと共にはじめよう! より自分たちにあったプロセスに進化させよう. 最初は間違えてもいいじゃないいいことは道具箱に追加しよう。試そう! Henrik Kniberg 4141 41