kanban vs scrum日本語版

1

カンバン vs スクラム

09/9/2

Henrik Kniberg

Henrik Kniberg - Crisp ABAgile coach & Java guy

Cofounder / CTO of Goyada (mobile services)30 developers

Lead architect at Ace Interactive (gaming)20 developers

Chief of development at Tain (gaming)40 developers

Agile coach at various companies

Future of Agile, StockholmMay 27, 2009

[email protected]+46 70 4925284

実践ガイド

2

最初に

Henrik Kniberg

このプレゼンテーションの目的:

カンバンとスクラムを比較することではっきりさせること。.. . そして、あなたの環境でこれらのツールをどのように使えそうか、わかるでしょう。

Henrik Kniberg 22

3

スクラムを一言で表すと

Henrik KnibergHenrik Kniberg 33

1月 4月

組織を分ける

製品を分ける

時間を分割

ビジネスの価値を最適化プロセスを最適化

$

$$$

Burndown

Unplanned items

Notchecked out Done! :o)

Write failing test

DAO

DB design

Integr test

Migration tool

Write fa iling test

GUI spec

Tapestry sp ikeImpl.

migration

2d

Code cleanup

Deposit

2d1d 0.5d1d

2d

8d

1d 2d

2d

BackofficeLogin

BackofficeUser admin

Write failing test

3d

2d

1d2d

Impl GUI

1dIntegr. with

JBoss2d

Write fail ing test

3d

Impl GUI

6d

Clarify require-ments

2d

GUI design (CSS)

1d

Fix memory leak(JIRA 125)2dSales support

3d Write whitepaper

4d

SPRINT GOAL: Beta-ready rel ease!

Next

WithdrawPerf testWithdraw

checked out

Write failing test

大きなグループでは大きなモノの構築に長い時間を費やす。小さなチームは小さいモノの構築に短い時間を費やす。…でも全体を眺めるために定期的に統合します。

4

カンバンを一言で表すと…

Henrik Kniberg

仕事の流れを見える化作業中(WIP:work in progress)を制限測定、そして流れの最適化

Henrik Kniberg 44

To do Dev Release

FH CI

2Test

35Done!

3

DG

JK

EA

B

FLOW

5

カンバンのルーツ(トヨタ)

Henrik Kniberg

買い手納入業者

Henrik Kniberg 55

受取消費取り外し出荷割当製造

看板

トヨタ生産方式の父大野耐一氏

必要な時に必要なだけ生産という考え方(Just-in-time)と、自律と人間味のある自動化(自働化)がトヨタ生産方式の二つの柱です。これらの仕組みを運営するためツールがカンバンです。

6

ソフトウェア開発におけるカンバン


7

カンバンとスクラム、どちらもプロセスの(仕事を流す)ためのツール


食事しながらミーティング

ペアプロ

プロダクトオーナー

物理的なツールプロセスのツール別名 ”組織のパターン”

8

前もって決められているか vs 適応か

Henrik Kniberg

前もって決められている方向より適応する方向

Henrik Kniberg 88

XP(13)

スクラム(9)

カンバン(3)

なんでもする(0)

RUP(120+

)• Architecture Reviewer• Business Designer• Business-Model Reviewer• Business-Process Analyst• Capsule Designer• Change Control Manager• Code Reviewer• Configuration Manager• Course Developer• Database Designer• Deployment Manager• Design Reviewer• Designer• Graphic Artist• Implementer• Integrator• Process Engineer• Project Manager• Project Reviewer• Requirements Reviewer• Requirements Specifier• Software Architect• Stakeholder• System Administrator• System Analyst• Technical Writer• Test Analyst• Test Designer• Test Manager• Tester• Tool Specialist• User-Interface Designer• Architectural analysis• Assess Viability of architectural

proof-of-concept• Capsule design• Class design• Construct architectural proof-of-

concept• Database design• Describe distribution• Describe the run-time architecture• Design test packages and classes• Develop design guidelines• Develop programming guidelines• Identify design elements• Identify design mechanisms• Incorporate design elements• Prioritize use cases• Review the architecture• Review the design• Structure the implementation model• Subsystem design• Use-case analysis• Use-case design• Analysis model• Architectural proof-of-concept• Bill of materials• Business architecture document• Business case• Business glossary• Business modeling guidelines• Business object model• Business rules• Business use case

• Whole team• Coding standard• TDD• Collective ownership• Customer tests• Pair programming• Refactoring• Planning game• Continuous integration• Simple design• Sustainable pace• Metaphor• Small releases

• Scrum Master• Product Owner• Team• Sprint planning meeting• Daily Scrum• Sprint review• Product backlogt• Sprint backlog• BUrndown chart

• Visualize the workflow• Limit WIP• Measure and optimize lead time

宮本武蔵1584-1645

武器や流派にこだわるな。(引用:アジャイルソフトウェア開発著アリスター・コーバーン)

• Business use case realization• Business use-case model• Business vision• Change request• Configuration audit findings• Configuration management plan• Data model• Deployment model• Deployment plan• Design guidelines• Design model• Development case• Development-organization

assessment• End-user support mateirla• Glossary• Implementation model• Installation artifacts• Integration build plan• Issues list• Iteration assessment• Iteration plan• Manual styleguide• Programming guidelines• Quality assurance plan• Reference architecture• Release notes• Requirements attributes• Requirements

management plan• Review record• Risk list• Risk management plan• Software architecture

document• Software development

plan• Software requirements specification• Stakeholder requests• Status assessment• Supplementary business specification• Supplementary specification• Target organization assessment• Test automation architecture• Test cases• Test environment configuration• Test evaluation summary• Test guidelines• Test ideas list• Test interface specification• Test plan• Test suite• Tool guidelines• Training materials• Use case model• Use case package• Use-case modeling guidelines• Use-case realization• Use-case storyboard• User-interface guidelines• User-interface prototype• Vision• Work order• Workload analysis model

9

スクラムの定義する役割


PO

SM

10

スクラムが定義するイテレーション

Henrik Kniberg

スクラムチーム

Henrik Kniberg

week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

スプリント 1

計画と合意デモ(リリース?)

カンバンチーム 1

カンバンチーム 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

計画周期 (2w)

スプリント 2

ふりかえり

リリース周期 (1w)

ふりかえり (4w)

カンバンチーム 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

計画 (必要時)

リリース(必要時)

ふりかえり (4w)

11

どちらも作業中(WIP)を制限するが、方法が異なる


To do Ongoing Done :o)

B

C

A

D

FLOW


B

C

A

D

FLOW

2

スクラムボードカンバンボード

作業中を時間単位で制限(iteration)

作業中を状態で制限

作業中:WIP(Work in Progress)

12

どちらも経験に基づいている


多くの小さなチーム 2,3の大きなチーム

作業中制限(少) 大きい作業中制限

ワークフローの状態(少) ワークフローの状態(大)

イテレーション(短) イテレーション(大)

計画回数(少) 計画回数(大)

速度(aka ベロシティ)

リードタイム(akaサイクルタイム)

.... etc ... .... etc ...

品質(障害の割合等)

予測可能性(SLAの達成,等)

カンバンは、より再構成しやすい

すごい！たくさんの選択肢がある！

うわぁ、もっと複雑になってしまった!

13

例 : WIP制限による実験

Henrik Kniberg

ZZZZzzzzzz

Henrik Kniberg 1313


BC AD

1To do Ongoing Done :o)

CD

AE

8

EF

F

G


DE

A

F

8

G


DE

J

8

K

L

M

FGH

IN


LM

JN4

OP

B BC

ABC

HI

K

Monday, Week 1 Monday, Week 2

暇で暇でしょうがない。WIP制限を8にし

てみよう。

統合しているサーバで問題があってDとEが終わらなかったぞ。代わりにFとGをやら

ないと。うわぁ。WIP制限にひっかかった。すぐに作業を止めて統

合しているサーバを直さないと!

WIP制限を4にしてみよう。そして次は早めに対処

しよう。

Monday, Week 3 Monday, Week 4

Monday, Week 5

14

スクラムはイテレーション中変更を許可しません。



BC A

D

FLOW


B

C A

D

FLOW

2

Scrum Kanban

2

PO

Eが欲しくなったよ!

次のスプリントまで待ってください

To Do のスロットが空くのを待ってください。それかCかDと交換してく

ださい。

15

スクラムボードはどのイテレーション間でもリセットします。


Scrumスプリントの最初の日スプリント中スプリントの最終日

Kanbanいつでも

16

スクラムはなんでも屋チームで規定されます。


スクラムカンバン例 – 1 カンバン例– 2

なんでも屋のチーム



専門家チーム

専門家

17

スクラムのバックログ要素はスプリントに合わければなりません。


Sprint 1 Sprint 2 Sprint 3 Sprint 4

期間を跨ったタスク

期間を跨ったタスク

スクラム

カンバン

WIPの制限 = 3

18

スクラムでは、見積もりやベロシティは規定されています。


Sprint 1 Sprint 2 Sprint 3

ベロシティは大体: 8 / sprint(継続的なペースですか?)

2

2 3

1 2

31 1 2 2 1

1 1 2

V= 8 V= 7 V= 9

19

どちらも同時に複数の製品に携わることができます。


緑の製品緑チーム

黄の製品黄チーム

全ての製品製品をまたいだチーム

製品をまたいだチーム

スクラムの例 1

スクラムの例2 スクラムの例 3

全ての製品

カンバンの例1

カンバンの例2

色で意味づいたタスク

レーンで意味づいたタスク

製品毎のチーム

20

どちらもリーンでアジャイル

Henrik Kniberg

1. 短期的財務目標を犠牲にしてでも長期的な考えで経営判断する。

2. 淀みのない流れをつくって、問題を表面化させる

3. プルシステムを利用して、つくり過ぎのムダを防ぐ

4. 生産量を平準化する(ウサギではなく、亀のペースで仕事をする)

5. 問題を解決するためにラインを止め、品質を最初からつくり込むカルチャーを定着させる。

6. 標準化作業が絶え間ない改善と従業員の自主活動の土台になる。

7. すべての問題を顕在化させるために目で見る管理を使う

8. 技術を使うなら、実績があり、枯れた、人や工程に役立つ技術だけを利用する。

9. 仕事をよく理解し、思想を実行し、他人に教えるリーダーを育成する

10. 会社の考え方に従う卓越したヒトとチームを育成する

11. パートナーや部品メーカ等の社外ネットワークを尊重し、改善するのを助ける

12. 現地現物を徹底的に理解するように自分の目で確かめる(現地現物)

13. 意思決定はじっくりコンセンサスをつくりながら、あらゆる選択肢を十分検討するが、実行は素早く行う(根回し)

14. 執拗な反省と絶え間ない改善により学習する組織になる

Henrik Kniberg

1. プロセスやツールより人と人同士の相互作用を重視する。

2. 包括的なドキュメントより動作するソフトウェアを重視する。

3. 契約上の交渉よりも顧客との協調を重視する

4. 計画に従うことよりも変化に対応することを重視する。

2020

リーン

品質コスト

リードタイム

いつでも使える状態を保つ

無駄を省く

改善

人ジャス

ト・イン・タイム

ラインを

止める

21

小さな違い:スクラムにはプロダクトバックログがある

Henrik Kniberg

スクラム:

プロダクトバックログは必ず存在する。

プロダクトバックログの変更は次のスプリントに影響する。(現在のスプリントではない)

プロダクトバックログはビジネス価値が大きいものから順に並べられる

Henrik Kniberg 2121

カンバン:プロダクトバックログは必ずしも存在しない。プロダクトバックログは着手可能であればすぐに変更できるあらゆる優先度を順付ける枠組みを使える。例えば :

どの項目からでも

いつも一番上の項目からいつも一番古い項目から

20%は保守項目から、80%は新機能から

製品Aと製品Bを均等に緊急の項目を先に

... だけど多くのチームではこれらのアプローチを組み合わせてつかってるけどね

22

小さな違い: スクラムには朝会がある


... だけど多くのカンバンチームもそうしているね。

23

小さな違い:スクラムにはバーンダウンチャートがある。


Burndown

10203040506070

1 2 3 4 5 8 9 10 11 12 15 16 17 18 19August

Estimated work remaining

Date

カンバンといえば「これ」といった図はない。チームにとって必要であればどんなものでも使う。

24

例 : スクラムボード vs カンバンボード


Committed Ongoing Done :o)

B

C

A

D

Sprint backlog

EF

G

H

EFG

H IJ L

KM

Product backlog

SelectedDev

Done

B

C

ADE

F GH I

J LKM

Backlog 32

In production :o)Ongoing

XR

Q

スクラム

カンバン

25

シナリオ1 –ある仕事の流れ

Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 2525

B

C

A

D

E

F

G

H IJ L

KM

26


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 2626

BC

A

D

E

F

G

H IJ L

KM

27


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 2727

BC

A

D

E

F

G

H IJ L

KM

28


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 2828

B

C A

D

E

F

G

H IJ L

KM

29


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 2929

B

C A

D

E

F

G

H IJ L

KM

30


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3030

B

C AD

E

FG

H IJ L

KM

31

シナリオ 2 – 問題があったときの展開

Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3131

B

C

A

D

E

F

G

H IJ L

KM

32


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3232

BC

A

D

E

F

G

H IJ L

KM

33


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3333

B

C A

D

E

F

G

H IJ L

KM

34


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3434

B

C A

D

E

F

G

H IJ L

KM

35


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3535

B

C A

D

F

G

H IJ L

KM

!?

E

36


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3636

B

C

A

D

EF

G

H IJ L

KM

!?

37


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3737

B

C

A

D

EF

G

H IJ L

KM

38


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3838

B

A

D

EF

G

H IJ L

KM

C

39


Henrik Kniberg

SelectedDev

Done

Backlog 32


Henrik Kniberg 3939

B

AD

EF

G

H IJ L

KM

C

40

カンバン vs スクラム概要

Henrik Kniberg

どちらもリーンでアジャイルである

どちらもプルスケジュールを基にしている

どちらもWIPの制限がある

どちらも透明性に基づいて、改善をよりしやすくしている

どちらもソフトウェアを早く、頻繁にリリース可能にすることに注力する。

どちらも自己組織的なチームに基づく

どちらも作業を細かく分割することを求める

どちらもリリース計画を実証されたデータ(ベロシティ/リードタイム)を継続的に最適にしている

Henrik Kniberg 4040

スクラムカンバン時間を区切ったイテレーション(タイムボックス)が定義されている。

時間を区切ったイテレーションは必須ではない

イテレーション内の仕事量を具体的にするため、チームでコミットする。

コミットメントは必須ではない

ベロシティを計画づくりとプロセス改善のための標準の測定基準として使う

リードタイムを計画づくりとプロセス改善のための標準測定基準として使う

職制を横断したチームが規定されている

職制を横断するチームはオプション。専門家のチームが許される。

1スプリントに完了できる大きさにタスクを分割する.

タスクの大きさに特に決まりがない。

バーンダウンチャートが定義されている。

図の種類について特に決まりがない。

WIPの制限が間接的 (スプリントごと) WIPの制限が直接的 (ワークフローの状態ごと)

見積もりをする。見積もりは必須ではない。進行中のスプリントにタスクを追加できない。

着手可能な時タスクを追加できる。

スプリントバックログは特定のチームからのみ所有される。

カンバンボードは複数のチーム、もしくは人々が共有できる。

3つの役割 (PO/SM/Team) 役割は特に規定されないスプリントごとにスクラムボードはリセット

カンバンボードにリセットするタイミングはない

優先順位付けされたプロダクトバックログが規定されている

優先順位付けは必須ではない

ちがうところ

www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf

にているところ

41

一番大切なこと:ふりかえりと共にはじめよう!


より自分たちにあったプロセスに進化させよう.最初は間違えてもいいじゃないいいことは道具箱に追加しよう。試そう!

kanban vs scrum日本語版

Technology