Scrum & Kanban
-
Upload
kiro-harada -
Category
Technology
-
view
8.658 -
download
5
Transcript of Scrum & Kanban
Board of directors
Henrik KnibergAgile/Lean coach
www.crisp.se
Kanban and ScrumMaking the most of both
Agile 2010, OrlandoAugust 12, 2010
[email protected]+46 70 4925284
Copyright notice
These slides are licensed under Creative Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere.
For licensing details see: http://creativecommons.org/licenses/by/3.0/
All slides available at:http://www.crisp.se/henrik.kniberg/
Board of directors
Henrik KnibergAgile/Lean coach
www.crisp.se
Kanban と Scrum両者を最大限に活用する
Agile 2010, OrlandoAugust 12, 2010
[email protected]+46 70 4925284
Copyright notice
These slides are licensed under Creative Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere.
For licensing details see: http://creativecommons.org/licenses/by/3.0/
All slides available at:http://www.crisp.se/henrik.kniberg/
翻訳ドラフト版2010/8/30
3
Purpose of this presentation
To clarify Kanban and Scrum by comparing them
...so you can figure outhow these may come to usein your context.
Henrik Kniberg 3
4
プレゼンテーションの目的
Scrum と Kanban を比較して、両者をよりよく理解する
あなたが、自分のコンテキストで、
Scrum や Kanban をどう活用できるか自分で考えられるように
Henrik Kniberg 4
9
Scrum in a nutshell
Henrik Kniberg 9
January April
Split your organization
Split your product
Split time
Optimize business valueOptimize process
$
$$$
Burndown
Unplanned items
Not
checked out Done! :o)
Write failing test
DAO
DB design
Integr test
Migrat ion
tool
Write failing test
GUI spec
Tapestry spikeImpl.
migration
2d
Code
cleanup
Deposit
2d1d 0.5d1d
2d
8d
1d2d
2d
Backoffice
Login
BackofficeUser admin
Write failing test
3d
2d
1d2d
Impl GUI
1dIntegr. with
JBoss2d
Write failing test
3d
Impl GUI
6d
Clarify require-ments
2d
GUI design (CSS)
1d
Fix memory leak(JIRA 125)2d
Sales support
3d Write whitepaper
4d
SPRINT GOAL: Beta-ready release!
Next
WithdrawPerf testWithdraw
checked out
Write failing test
Large group spending a long time building a huge thingSmall team spending a little time building a small thing
... but integrating regularly to see the whole
10
Scrum 超入門
Henrik Kniberg 10
1月 4月
組織を分割
製品を分割
時間を分割
ビジネス価値を最適化プロセスを最適化
$
$$$
Burndown
Unplanned items
Not
checked out Done! :o)
Write failing test
DAO
DB design
Integr test
Migrat ion
tool
Write failing test
GUI spec
Tapestry spikeImpl.
migration
2d
Code
cleanup
Deposit
2d1d 0.5d1d
2d
8d
1d2d
2d
Backoffice
Login
BackofficeUser admin
Write failing test
3d
2d
1d2d
Impl GUI
1dIntegr. with
JBoss2d
Write failing test
3d
Impl GUI
6d
Clarify require-ments
2d
GUI design (CSS)
1d
Fix memory leak(JIRA 125)2d
Sales support
3d Write whitepaper
4d
SPRINT GOAL: Beta-ready release!
Next
WithdrawPerf testWithdraw
checked out
Write failing test
大きなグループが長い時間をかけて、巨大なものを作る小さなグループが短い時間に、小さなものを作る ただし、しょっちゅう統合して、全体を見る
11
Process is
continuously improving
Have Definition of Done (DoD)
DoD achievable within
each iteration
Team respects DoD
The bottom line
Delivering working, tested
software every 4 weeks or less
Delivering what the
business needs most
Demo happens after every
sprint
Shows working, tested
software
Feedback received from
stakeholders & PO
Retrospective happens after
every sprint
Results in concrete
improvement proposals
Some proposals actually get
implemented
Whole team + PO
participates
Team has a sprint backlog
Highly visible
Updated daily
Owned exclusively by the
team
Have sprint planning meetings
PO participates
Whole team participates
Results in a sprint plan
Whole team believes plan is
achievable
PO satisfied with
priorities
PO brings up-to-date PBL
Iteration length 4 weeks or
less
Always end on time
Team not disrupted or
controlled by outsiders
Timeboxed iterations
PO has a product backlog
(PBL)
Top items are prioritized by
business value
Top items are estimated
PO understands purpose of
all backlog items
Top items in PBL small
enough to fit in a sprint
Estimates written by the
team
Clearly defined product owner
(PO)
PO is empowered to
prioritize
PO has knowledge to
prioritize
PO has direct contact with
team
PO has direct contact with
stakeholders
PO speaks with one voice
(in case PO is a team)
Team members sit together
If you achieve these you can ignore the
rest of the checklist. Your process is fine.
These are central to Scrum. Without these
you probably shouldn’t call it Scrum.
Core Scrum
PO has product vision that is in
sync with PBL
PBL and product vision is highly
visible
Everyone on the team
participates in estimating
PO available when team is
estimating
Team members not locked into
specific roles
Team has all skills needed to
bring backlog items to Done
Team has a Scrum Master (SM)
Whole team knows top 1-3
impediments
SM has strategy for how to
fix top impediment
SM focusing on removing
impediments
Escalated to management
when team can’t solve
Velocity is measured
Velocity only includes
items that are Done
PO uses velocity for
release planning
Team has a sprint burndown
chart
PBL items are broken into tasks
within a sprint
Estimates for ongoing tasks
are updated daily
Highly visible
Updated daily
PO participates at least a
few times per week
All items in sprint plan have
an estimate
SM sits with the team
Daily Scrum is every day, same
time & place
Sprint tasks are estimated
Estimate relative size (story
points) rather than time
Max 15 minutes
Each team member knows
what the others are doing
Most of these will usually be needed, but not always all of them. Experiment!
Recommended but not always necessary
Daily Scrum happens
Whole team participates
Problems & impediments
are surfaced
You have a Chief Product
Owner (if many POs)
Dependent teams do Scrum of
Scrums
Dependent teams integrate
within each sprint
Scaling
Having fun! High energy level.
Overtime work is rare and
happens voluntarily
Discussing, criticizing, and
experimenting with the process
Positive indicators
Scrum Checklist
http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)
the unofficial
Henrik Kniberg
PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done
Team usually delivers what
they committed to
Leading indicators of a
good Scrum implementation.These are pretty fundamental to any
Scrum scaling effort.
Max 9 people per team
Iterations that are doomed to
fail are terminated early
12
プロセスを継続的に改善している
完了の定義(DoD)を持っている
DoDはイテレーションごとに 達成可能なものになっている
チームはDoDを尊重している
最低限のチェック
定期的(4週間以内)に動作する、テスト済みのソフトウェアを提供している
ビジネスニーズに基づいたものを最優先して提供している
毎スプリント終了後にデモを行っている
動作する、テスト済みのソフトウェアを見せている
ステークホルダとプロダクトオーナからフィードバックを得ている
スプリントごとにふりかえりを行えている
結果として具体的な改善提案を行っている
実際に、実現できた提案がある
チームとプロダクトオーナーの全員が参加している
チームはスプリントバックログを持っている
見える化している
毎日更新されている
完全にチームの持ち物である
スプリント計画ミーティングを行っている
プロダクトオーナーが参加している
チーム全員が参加している
結果がスプリント計画に盛り込まれている
チーム全員が計画は達成可能だと考えている
プロダクトオーナーは、優先度を含め満足している
プロダクトオーナーが最新のプロダクトバックログを提示
イテレーションの長さは4週間以内
いつも期限どおりに終了する
チームは部外者に妨害や指図を受けていない
イテレーションをタイムボックス化している
プロダクトオーナーはプロダクトバックログ(PBL)を持っている
上位項目はビジネス価値に基づいて優先度付けされている
上位項目は見積り済みである
プロダクトオーナーがすべての項目の目的を理解している
上位項目は1つのスプリントに収まる規模になっている
見積りはチームが行っている
はっきりと定義されたプロダクトオーナー(PO)
プロダクトオーナーは、優先度付けをする権限をもつ
プロダクトオーナーは、優先度付けをする知識をもつ
プロダクトオーナーは、直接 チームと話している
プロダクトオーナーは、直接 ステークホルダと話している
プロダクトオーナーは、同じことをいう(複数人いる場合)
チームメンバは同じ場所に机がある
この項目ができていたら、残りのチェックリスト項目は無視していい。あなたのプロセスはうまくいっている。
スクラムの主要要素。これらを抜きにして、スクラムと呼ぶことはできないだろう
コア・スクラム
POは プロダクトバックログと連動するプロダクトビジョンをもつ
プロダクトバックログとプロダクトビジョンを見える化している
チームの全員が見積もりに参加している
チームが見積っている間、プロダクトオーナも待機している
チームメンバは特定の役割に固定されていない
チームは、バックログ項目を完了させるために必要なスキルを全て持つ
チームにスクラムマスター(SM)
がいる
チーム全員が上位3つの障害について認識している
最上位の障害解決について、SMが戦略をもっている
スクラムマスターは、障害を取り除くことに集中している
チームが解決できないときは 管理層に報告されている
ベロシティが計測されている
ベロシティは完了した項目だけをカウントしている
POはベロシティを用いてリリース計画を作成している
チームはスプリントバーンダウンチャートを持っている
プロダクトバックログは、1スプリント以内のタスクに分割されている
実行中のタスクの見積りは毎日更新されている
見える化されている
毎日更新されている
最低でも週の何日かはプロダクトオーナが参加している
スプリント計画で、対象の項目が見積りを持っている
スクラムマスターは、チームと同じ場所に机がある
デイリースクラムは、毎日・同じ時間・同じ場所で行っている
スプリントタスクの見積りが行われている
時間ではなく、相対規模(ストーリーポイント) で見積っている
長くても15分まで
各チームメンバは他のメンバが何をしているか知っている
ほとんどの項目は必要になる事が多い、すべて常に必要というわけではない。試してみて!
推奨項目(いつも必要というわけではない)
デイリースクラムを行っている
チームの全員が参加している
問題と障害を表面化できている
チーフプロダクトオーナーがいる (たくさんのPOがいるとき)
所属するチームを集めてスクラムのスクラムを行っている
所属するチームはスプリント内でインテグレーションを行っている
スケーリング
楽しんで! みんな活発に
残業は稀。残業を強制されない
プロセスについて議論、批評、実験を行っている
よい兆候
Scrum Checklist
http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17) 日本語訳 rev.1 (2009-09-01)
the unofficial (非公認)
Henrik Kniberg
PO = プロダクトオーナー SM = スクラムマスター PBL = プロダクトバックログ DoD = 完了の定義
チームは通常、何にコミットするかを明言している
よいスクラムを実施している事を示す先行指標
スクラムの規模を拡大する取り組みのうち、ごく基本的なもの
ひとつのチームは最大でも9
人まで
失敗が避けられないイテレーションを早めに強制終了している
スクラムチェックリスト
15
Which team needsmost improvement?
Henrik Kniberg 15
Team 1 Team 2
Todo Doing Donethis week
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse
ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Avg lead time: days 3
Todo Doing Donethis week
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Avg lead time: days
20
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Russel Ackoff
Managers who don’t know how tomeasure what they want
settle forwanting what they can measure
16
どっちのチームが改善が必要?
Henrik Kniberg 16
チーム 1 チーム 2
Todo Doing Donethis week
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse
ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
平均リードタイム: 日3
Todo Doing Donethis week
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
平均リードタイム: 日20
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Russel Ackoff
欲しいものを、どうやって計測するかを知らないマネージャは、結局計測できるものを欲するように
なる。
23
SupplierBuyer
Kanban @ Toyota
Henrik Kniberg 23
ReceiveConsume Detach Ship Allocate Manufacture
Taiichi OhnoFather of theToyota Production System
The tool used to operate the [Toyota Production] system is kanban.
Adapted from Kiro Harada’s slide
24
SupplierBuyer
トヨタのかんばん
Henrik Kniberg 24
ReceiveConsume Detach Ship Allocate Manufacture
大野耐一トヨタ生産方式の父
「トヨタ生産方式」を運用するのにつかわれるツールは、かんばんである
原田騎郎氏のスライドより引用
バイヤー サプライヤ
使用 外れ 受領 出荷 引当 製造
25
Kanban in SW development
Henrik Kniberg
Backlog Dev Done
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse
ctetur
orem ipsum dolor sit amet, co nse
ctetur
UAT Deploy5 3 2 3
FLOW Avg lead time: days 12
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Visualize the workflow
Limit WIP (work in progress)
Measure & optimize flow
Explicit policies (definition of Done, WIP limits, etc)
Pioneered byDavid Andersonin 2004
26
ソフトウェア開発における Kanban
Henrik Kniberg
Backlog Dev Done
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse
ctetur
orem ipsum dolor sit amet, co nse
ctetur
UAT Deploy5 3 2 3
フロー 平均リードタイム 日12
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
ワークフローの見える化
仕掛品(WIP: work in progress)の制限
流れの計測と最適化
明示的なポリシー (完了の定義, WIPの制限,他)
David Andersonが2004年に開始
訳注:Kanban は、もちろん「看板・かんばん」に由来しますが、TPS
における「かんばん」と相違が多いため、誤解をさけるため Kanban としています。
31Henrik Kniberg 31
Pair programming
Product Owner role
Physical tools
Process toolsa.k.a. ”organizational patterns”
Thinking toolsa.k.a. ”mindsets” or ”philosophies”
Lean Agile Toolkitsa.k.a. ”frameworks”
Scrum XP
Visualize the workflow
To do Dev Release
H C
2Test
35Done!
3
D
G
K
A
B
FLOW
Kanban
Systems Thinking
Theory of ConstraintsRUP
Tool”anything used as a means of accomplishing a task or purpose.”- dictionary.com
32Henrik Kniberg 32
ペアプロ
プロダクトオーナという役割
物理的なツール
プロセスツールa.k.a. ”組織パターン”
思考ツールa.k.a. ”マインドセット” 、”哲学”
リーンアジャイル ツールキットa.k.a. ”フレームワーク”
Scrum XP
見える化
To do Dev Release
H C
2Test
35Done!
3
D
G
K
A
B
FLOW
Kanban
システム思考
制約理論RUP
ツールタスクや目的を達成するために使われる手段であれば何でも- dictionary.com
33
More prescriptive More adaptive
Compare for understanding, not judgement
Henrik Kniberg 33
XP(13)
Scrum(9)
Kanban(3)
Do Whatever(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
Miyamoto Musashi17th century samurai
Do not develop an attachmentto any one weaponor any one school of fighting
• 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 architecturedocument
• Software developmentplan
• 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
34
より記述的 より適応的
判断のためでなく、理解のための比較
Henrik Kniberg 34
XP(13)
Scrum(9)
Kanban(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
宮本武蔵17th century samurai
武器や流儀にこだわらない
• 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 architecturedocument
• Software developmentplan
• 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
35
Lean & Agile process toolkits
Henrik Kniberg 35
Kanban
Scrum
XP
Values & PrinciplesLean, Agile, Theory of Constraints, Systems Thinking, etc
Other lean tools(Value Stream Mapping, Root Cause Analysis, etc)
36
リーンとアジャイルのプロセスツールキット
Henrik Kniberg 36
Kanban
Scrum
XP
価値と原則リーン、アジャイル、制約理論、システム思考、他
他のリーンツール(バリューストリームマッピング, 原因分析, 他)
42
Round 1: Ordering process
Henrik Kniberg 42
JEFF
JEFF28
1
2
3
Multitasking name game
Developer Customer Jeff
Log delivery time
Deliver
Order
43
ラウンド 1: 注文プロセス
Henrik Kniberg 43
JEFF
JEFF28
1
2
3
Multitasking name game
開発者 顧客 Jeff
納入時間を計測
納品
注文
44
Round 1: Development process
Henrik Kniberg 44
D A V E
L IS
B O B
E R I
M A R
Never keep acustomer waiting
Start early= Finish early
Policy Dave
Lisa
Bob
Eric
Maria
Multitasking name game
28
45
ラウンド 1: 開発プロセス
Henrik Kniberg 45
D A V E
L IS
B O B
E R I
M A R
顧客を待たせない
早く始める= 早く終わる
ポリシー Dave
Lisa
Bob
Eric
Maria
Multitasking name game
28
46
Round 2 – Development process
Henrik Kniberg 46
D A V E
L ISLimit WIP(work in process)
Current limit =1 customerat a time
Policy Dave
Lisa
Bob
Eric
Maria
A
Multitasking name game
47
ラウンド 2 – 開発プロセス
Henrik Kniberg 47
D A V E
L ISWIPを制限(WIP: 仕掛品)
現在のリミット=顧客対応は、一人づつ
Policy Dave
Lisa
Bob
Eric
Maria
A
Multitasking name game
48
Round 2: Ordering process
Henrik Kniberg 48
1
2
3
Multitasking name game
Developer Customer Jeff
Log delivery timeCalc project length
Deliver product
Log start timeSubmit order
5
5JEFF
5JEFF
15
10
0
Request order
49
ラウンド 2: 注文プロセス
Henrik Kniberg 49
1
2
3
Multitasking name game
開発者 顧客 Jeff
納入時刻を記録かかった時間を計算
製品の納品
開始時刻を記録発注
5
5JEFF
5JEFF
15
10
0
発注
52Henrik Kniberg 52
Focusing on starting stuff rather than finishing
Not limiting WIP
Focusing on keep people busy (fear of slack)
Accepting the “reason” & solving the symptom instead of the problem
Bail water
Water in boat
Hole in boat
Fix hole
Causes of unnecessary multitasking
53Henrik Kniberg 53
開始することに集中して、終了を意識しない
WIPを制限しない
人を忙しくしておくことに集中する(ゆとり時間を恐れる)
症状を直すことと“理由”を受け入れて、問題を気にしない。
水をかき出す
浸水
ボートに穴
穴を直す
不必要なマルチタスクの原因
56
Case study
SamConcept
pres.
Lisa assigns
resources
Graphics design
Sound design
DevIntegr. & deploy
2d 1m4h
6m
8
Game backlog
1w 6m 6m
15
Design-ready games
12
Production-ready games
1m 3w 3m(1m+2m)
3w2h 1d
3 m value added time
25 m cycle time= 12%
Process cycle efficiency
57
ケーススタディ
Samコンセプト作
成
Lisa がリソース割り当て
グラフィックデザイン
サウンドデザイン
開発統合 & 配
布
2d 1m4h
6m
8
ゲームバックログ
1w 6m 6m
15
デザイン完了ゲーム
12
製造可能 ゲーム
1m 3w 3m(1m+2m)
3w2h 1d
付加価値作業 3分
サイクルタイム 25分= 12%
プロセスサイクル効率
58
Limit work to capacity
Henrik Kniberg 58
Input: 3 customers / hour Output capacity: 2 customers / hour
60
Case study
Henrik Kniberg 60
SamConcept
pres.
Lisa assigns
resources
Graphics design
Sound design
DevIntegr. & deploy
2d 1m4h
6m
8
Game backlog
1w 6m 6m
15
Design-ready games
12
Production-ready games
1m 3w 3m(1m+2m)
3w2h 1d
Cross-functional game team
3-4 m cycle time = 6-8x faster
Game team(graphics, sound, dev, integrate)
3-4 months
付加価値作業 3分
サイクルタイム 25分= 12%
プロセスサイクル効率
61
Case study
Henrik Kniberg 61
2d 1m4h
6m
8
1w 6m 6m
15 12
1m 3w 3m(1m+2m)
3w2h 1d
機能横断ゲームチームCross-functional game team
サイクルタイム3~4分= 6~8倍速い
ゲームチーム(グラフィック, サウンド, 開発, 統合)
3~4 か月
Samコンセプト作
成
Lisa がリソース割り当て
グラフィックデザイン
サウンドデザイン
開発統合 & 配
布
ゲームバックログデザイン完了ゲーム 製造可能 ゲーム
付加価値作業 3分
サイクルタイム 25分= 12%
プロセスサイクル効率
64
Operations / support team
Typical evolution to Scrum/Kanban combo
Henrik Kniberg 64
Featureteam 1
Featureteam 2
Featureteam 2
Featureteam 1
Featureteam 2
Featureteam 2
Scrum Scrum Scrum Scrum Scrum Scrum
Scrum
Operations / support team
Featureteam 1
Featureteam 2
Featureteam 2
Scrum Scrum Scrum
Kanban
Scrum step 1 Scrum step 2 Scrum + Kanban
65
運用サポートチーム
Scrum/Kanban 組み合わせのよくある改善例
Henrik Kniberg 65
Featureteam 1
Featureteam 2
Featureteam 2
Featureteam 1
Featureteam 2
Featureteam 2
Scrum Scrum Scrum Scrum Scrum Scrum
Scrum
運用サポートチーム
Featureteam 1
Featureteam 2
Featureteam 2
Scrum Scrum Scrum
Kanban
Scrum ステップ 1 Scrum ステップ 2 Scrum + Kanban
68
”One day in Kanban land”
Henrik Kniberg 68
http://blog.crisp.se/henrikkniberg/tags/kanban/
69
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 1 – 一個流し
Henrik Kniberg 69
B
C
A
D
E
F
G
H I
J L
KM
70
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 1 – 一個流し
Henrik Kniberg 70
BC
A
D
E
F
G
H I
J L
KM
71
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 1 – 一個流し
Henrik Kniberg 71
BC
A
D
E
F
G
H I
J L
KM
72
NextDev
Done
Backlog 32
In production :o)
Ongoing
Scenario 1 – one piece flow
Henrik Kniberg 72
B
C A
D
E
F
G
H I
J L
KM
73
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 1 – 一個流し
Henrik Kniberg 73
B
C A
D
E
F
G
H I
J L
KM
74
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 74
B
C
A
D
E
F
G
H I
J L
KM
PO
75
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 75
BC
A
D
E
F
G
H I
J L
KM
PO
76
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 76
B
C A
D
E
F
G
H I
J L
KM
PO
77
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 77
B
C A
D
E
F
G
H I
J L
KM
PO
78
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 78
B
C A
D
F
G
H I
J L
KM
!?
E
PO
79
NexetDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 79
B
C
A
D
EF
G
H I
J L
KM
!?
PO
80
NextDev
Done
Backlog 32
In production :o)
Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 80
B
C
A
D
EF
G
H I
J L
KM
PO
81
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 81
B
A
D
EF
G
H I
J L
KM
C
PO
82
NextDev
Done
Backlog 32
In production :o)
Ongoing
シナリオ 2 – 開発での問題
Henrik Kniberg 82
B
AD
EF
G
H I
J L
KM
C
PO
85
Kanban & Scrum are empirical
Henrik Kniberg 85
Many small teams Few large teams
Low WIP limits High WIP limits
Few workflow states Many workflow states
No iterations Long iterations
Little planning Lots of planning
Capacity(aka velocity)
Lead time(aka cycle time)
.... etc ... .... etc ...
Quality(defect rate, etc)
Predictability(SLA fulfillment, etc)
Kanban is more configurable
Great! More options! Oh no, more decisions!
86
Kanban & Scrum は経験的手法である
Henrik Kniberg 86
多数の小チーム 少数の大チーム
WIP 制限小 WIP 制限大
ワークフロー状態少 ワークフロー状態多
イテレーション無 長いイテレーション
最小限の計画 綿密な計画
容量(aka ベロシティ)
リードタイム(aka サイクルタイム)
.... etc ... .... etc ...
品質(バグ率, etc)
予測可能性(SLA 満足率, etc)
Kanban is more configurable
すばらしい!選択肢が広い!
まいるなぁそんな沢山決めることが!
2009-08-29
orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl
2009-09-01
orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
Analysis Development Acceptance ProdNext
Definition of Done:• Customer accepted• Ready for production
Ongoing Done
Definition of Done:• Code clean & checked in on trunk• Integrated & regression tested• Running on UAT environment
Ongoing DoneOngoing Done
Definition of Done:• Goal is clear• First tasks defined• Story split (if necessary)
2 3 3 2
Feature / story
= completed
= blocked
= who is doing this right now
2009-08-20 2009-09-30
(description)
• Panicfeatures(should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary)
• Priority features• Hard deadline features
(only if deadline is at risk)
• Oldest features
2009-09-02
orem ipsum dolor sit amet, co nse
2009-08-27
orem ipsum dolor sit amet, adi pis cing elit nisl
2009-08-20
orem olor sit amet, co nse ctetur adi pis cing elit nisl
2009-08-30
orem ipsum dolor sit amet, co adi pis cing elit nisl
2009-09-08
2009-08-25
orem ipsum dolor sit ctetur adi pis cing elit nisl
Task / defectHard deadline(if applicable)Date when added
to board
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
(description)
(description)
(description)Why
(description)
Who is analyzing / testing right now
= priority
= panic
What to pull first
xxxx kjd dj d xxx
Kanban kick-start exampleHenrik Kniberg www.crisp.se/kanban/example
version 1.22009-11-16
(description)
orem ipsum dolor sit amet, co nse ctetur
=task =defect
2009-08-29
orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl
2009-09-01
orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
分析 開発 受入 本番次
完了の定義:•顧客の受入合意•本番移行可能
実施中 完了
完了の定義:•きれいなコードをtrunkにチェックイン•統合テスト、回帰テストに合格•受入テスト環境で動作
実施中 完了実施中 完了
完了の定義:•ゴールが明確•初期タスクが定義済み•ストーリー分割(必要なら)
2 3 3 2
フィーチャー / ストーリー
= 完了
= 開始できない
= 現在作業中の担当者
2009-08-20 2009-09-30
(description)
• パニック(みんなで集まって、とにかく片づける。必要とあらば他のタスクを止めたり、WIP制限を破ってもよい)
• 優先• 最終納期があるもの
(納期内完了にリスクがある場合)
• もっとも古いもの
2009-09-02
orem ipsum dolor sit amet, co nse
2009-08-27
orem ipsum dolor sit amet, adi pis cing elit nisl
2009-08-20
orem olor sit amet, co nse ctetur adi pis cing elit nisl
2009-08-30
orem ipsum dolor sit amet, co adi pis cing elit nisl
2009-09-08
2009-08-25
orem ipsum dolor sit ctetur adi pis cing elit nisl
タスク / 障害
最終納期(オプション)
ボードに張られた日
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
(description)
(description)
(description)Why
(description)
現在作業中の担当者
= 優先
= パニック
どれから手をつけるか
xxxx kjd dj d xxx
Kanban kick-start exampleHenrik Kniberg www.crisp.se/kanban/example
version 1.22009-11-16
(description)
orem ipsum dolor sit amet, co nse ctetur
=タスク =障害
91
Optimizing the WIP limit
Henrik Kniberg 9191
To do Doing Done
orem ipsum dolor
sit amet, co nse ctetur
1
Too low WIP limit
To do Doing Done
orem ipsum dolor sit amet, co nse ctetur
2
Just Right WIP limit
To do Doing Done
orem ipsum dolor sit amet, co nse ctetur
5
Too high WIP limit
orem ipsum dolor sit amet, co nse ctetur
Zzzzzzzzz
orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse cteturPeople
often idle
Slow flow (end-to-end)
People sometimes idle
(slack)
Fast flowTasks
rarely idle
Slow flow
Tasks often idleLack of wall
space...
People never idle
92
WIP 制限の最適化
Henrik Kniberg 9292
To do Doing Done
orem ipsum dolor
sit amet, co nse ctetur
1
WIP 制限が低すぎる
To do Doing Done
orem ipsum dolor sit amet, co nse ctetur
2
WIP 制限がちょうど良い
To do Doing Done
orem ipsum dolor sit amet, co nse ctetur
5
WIP 制限が高すぎる
orem ipsum dolor sit amet, co nse ctetur
Zzzzzzzzz
orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur手待ちの
人が沢山
流れが遅い(全体で)
人はときどき手待ちになる
(ゆとり)
速い流れ待ちタスクは少ない
遅い流れ
待ちタスクが沢山壁のスペース
が足りない...
人は手待ちにならない
93
Evolve your own unique board!
Henrik Kniberg 93
Some of these photos courtesy ofDavid Anderson, Mattias Skarin,and various other people
99
Scrum prescribes timeboxed iterationsScrum team
Henrik Kniberg
week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Sprint 1
Plan & commit Review(release?)
Kanban team 1
Kanban team 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Planning cadence (2w)
Sprint 2
Retrospective
Release cadence (1w)
Retrospectives (4w)
Kanban team 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Planning (on demand)
Release (on demand)
Retrospectives (4w)
100
Scrum は、タイムボックス固定のイテレーションを指定Scrum チーム
Henrik Kniberg
week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
スプリント 1
計画 & コミット レビュー(リリース?)
Kanban チーム 1
Kanban チーム 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
計画ケイデンス(2w)
スプリント 2
振り返り
リリースケイデンス(1w)
振り返り(4w)
Kanban チーム 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
計画(オンデマンド)
リリース (オンデマンド
振り返り(4w)
101
Scrum backlog items must fit in a sprint
Henrik Kniberg 101
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Long running task
Long running task
Scrum
Kanban
WIP limit = 3
102
Scrum のバックログ項目は、1スプリントに収まる必要がある。
Henrik Kniberg 102
Sprint 1 Sprint 2 Sprint 3 Sprint 4
長いタスク
長いタスク
Scrum
Kanban
WIP 制限 = 3
103
Both limit WIP, but in different ways
Henrik Kniberg 103
To do Ongoing Done :o)
B
C
A
D
FLOW
To do Ongoing Done :o)
B
C
A
D
FLOW
2
Scrum board Kanban board
WIP limited per unit of time
(iteration)
WIP limited per workflow state
104
両方とも WIPを制限する。方法は異なる。
Henrik Kniberg 104
To do Ongoing Done :o)
B
C
A
D
フロー
To do Ongoing Done :o)
B
C
A
D
フロー
2
Scrum ボード Kanban ボード
単位時間(イテレーション)の間のWIP 制限
ワークフロー状態ごとのWIP制限
105
Scrum discourages changein mid-iteration
Henrik Kniberg 105
To do Ongoing Done :o)
B
C A
D
FLOW
To do Ongoing Done :o)
B
C A
D
FLOW
2
Scrum Kanban
2
PO
I’d like to have E!
Wait until next sprint!
Wait until a To Do slot becomes available!Or swap out C or D!
Policies
106
Scrum は、イテレーション途中の変更を避ける
Henrik Kniberg 106
To do Ongoing Done :o)
B
C A
D
フロー
To do Ongoing Done :o)
B
C A
D
フロー
2
Scrum Kanban
2
PO
I’d like to have E!
次のイテレーションを待って
ToDo が空くまで待って。それとも C か D
をやめる?
ポリシー
107
Scrum board is reset between each iteration
Henrik Kniberg 107
ScrumFirst day of sprint Mid-sprint Last day of sprint
KanbanAny day
109
Scrum prescribes cross-functional teamsKanban supports both specialists & generalists
Henrik Kniberg 109
Backlog Design
orem ipsum dolor sit amet, co nse ctetur
Fold Tape
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Trim Draw
3 2 2 1 4 3
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Scrum team
Cross-functionalteam
Kanban team 1
Kanban team 2
110
Scrum は、機能横断チームを指定Kanban は、専門家チームも、総務チームもサポート
Henrik Kniberg 110
Backlog Design
orem ipsum dolor sit amet, co nse ctetur
Fold Tape
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Trim Draw
3 2 2 1 4 3
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Scrum チーム
機能横断チーム
Kanban チーム 1
Kanban チーム 2
111
Scrum prescribes estimation and velocity
Henrik Kniberg 111
Sprint 1 Sprint 2 Sprint 3
Likely velocity: 8 per sprint(sustainable pace?)
2
2 3
1 2
31 1 2 2 1
1 1 2
V= 8 V= 7 V= 9
112
Scrum は、見積りとベロシティの利用を指定
Henrik Kniberg 112
スプリント1 スプリント2 スプリント3
想定ベロシティ: 8 / スプリント(持続可能なペース?)
2
2 3
1 2
31 1 2 2 1
1 1 2
V= 8 V= 7 V= 9
113
Estimation is flexible in both Kanban & Scrum
TasksFeatures
Henrik Kniberg 113
1. Don’t estimate features. Just count them.
2. Estimate features in t-shirt size
1. Skip tasks
2. Don’t estimate tasks. Just count them.
3. Estimate tasks in days
1d2d0.5d
4. Estimate tasks in hours
12h8h4h
S M LHours?
Days?
Weeks?
S M
L
3. Estimate features in story points
1sp 2sp5sp
4. Estimate features in ideal man-days
1d 3d6d
”Typical”Kanban
”Typical”Scrum
114
Scrum でも Kanban でも、見積は柔軟なもの
タスクフィーチャー
Henrik Kniberg 114
1. フィーチャーを見積もらない。数える。
2. フィーチャーをTシャツのサイズで見積もる
1. タスクをスキップする。
2. タスクを見積もらない。数える。
3. タスクを日数で見積もる
1d2d0.5d
4. タスクを時間で見積もる
12h8h4h
S M LHours?
Days?
Weeks?
S M
L
3. フィーチャーをストーリーポイントで見積もる
1sp 2sp5sp
4. フィーチャーを理想人日で見積もる
1d 3d6d
”普通の”Kanban
”普通の”Scrum
115
Both allow working on multiple products simultaneously (if you must…)
Henrik Kniberg 115
Green ProductGreen team
Yellow ProductYellow team
All products Cross-product team Cross-product team
Scrum example 1
Scrum example 2 Scrum example 3
All products
Kanban example 1
Kanban example 2
Color-coded tasks
Color-coded swimlanes
116
複数の製品を同時に扱うのは、どちらもで可能(どうしても必要ならね…)
Henrik Kniberg 116
Green 製品Green チーム
Yellow 製品Yellow チーム
全製品 製品横断チーム 製品横断チーム
Scrum 例 1
Scrum 例 2 Scrum 例 3
全製品
Kanban 例 1
Kanban 例 2
色分けタスク
色分けレーン
119
Minor difference:Scrum prescribes daily meetings
Henrik Kniberg 119
... but many Kanban teams do that anyway.
121
Minor difference:Scrum prescribes a prioritized product backlog
Scrum:
Product backlog must exist
Changes to product backlog take effect next sprint (not current sprint)
Product backlog must be sorted by “business value”
Henrik Kniberg 121
Kanban:
Product backlog is optional
Changes to product backlog take effect as soon as capacity becomes available
Any prioritization scheme can be used. For example:
Take any item
Always take the top item
Always take the oldest item
20% on maintainance items,80% on new features
Split capacity evenly between product A and product B
Always take red items first
Policies
122
小さな違い:Scrum は、優先度付けされたプロダクトバックログを指定してます
Scrum:
プロダクトバックログが必須
プロダクトバックログに対する変更は、次のスプリントで反映される (今のスプリントではない)
プロダクトバックログは、「ビジネス価値」順に並べる必要がある
Henrik Kniberg 122
Kanban:
プロダクトバックログは任意
プロダクトバックログに対する変更は、能力が空いた時点で反映される
優先度付けの方法は任意。例えば:
好きなものを選んでよい
一番上を常に選ぶ
一番古いものを常に選ぶ
20% は保守項目を、80% 新規フィーチャー開発を選ぶ
能力量を製品Aと製品Bで等分する
赤いものを常に選ぶ
ポリシー
123Henrik Kniberg 123
Backlog Dev Test
orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Day 4
Prod
Burndown
10
20
30
40506070
1 2 3 4 5 8 9 10 11 12 15 16 17 18 19August
Est imated work
remaining
Date
Common alternative in Kanban:
Cumulative flow diagram
Minor difference:In Scrum, burndown charts are prescribed
124Henrik Kniberg 124
Backlog Dev Test
orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor
sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Day 4
Prod
Burndown
10
20
30
40506070
1 2 3 4 5 8 9 10 11 12 15 16 17 18 19August
Est imated work
remaining
Date
Kanban で利用される代替:
累計流動数グラフ
小さな違い:Scrumでは、バーンダウンチャートの使用が指定
リードタイム6日
WIP9項目
127
Kanban & ScrumComparison summary
Both are Lean and Agile
Both based on pull scheduling
Both limit WIP
Both use transparency to drive process improvement
Both focus on delivering releasable software early and often
Both are based on self-organizing teams
Both require breaking the work into pieces
In both cases the release plan is continuously optimized based on empirical data (velocity / lead time)
Henrik Kniberg 127
Scrum Kanban
Timeboxed iterations prescribed. Timeboxed iterations optional.
Team commits to a specific amount
of work for this iteration.
Commitment optional.
Uses Velocity as default metric for
planning and process improvement.
Uses Lead time as default metric for
planning and process improvement.
Cross-functional teams
prescribed.
Cross-functional teams optional.
Specialist teams allowed.
Items broken down so they can be
completed within 1 sprint.
No particular item size is prescribed.
Burndown chart prescribed No particular type of diagram is
prescribed
WIP limited indirectly (per sprint) WIP limited directly (per workflow
state)
Estimation prescribed Estimation optional
Cannot add items to ongoing
iteration.
Can add new items whenever
capacity is available
A sprint backlog is owned by one
specific team
A kanban board may be shared
by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles
A Scrum board is reset between
each sprint
A kanban board is persistent
Prescribes a prioritized product
backlog
Prioritization is optional.
Differences
http://www.infoq.com/minibooks/kanban-scrum-minibook
Similarities
128
Kanban & Scrum比較のまとめ
リーンで、アジャイル
プルによるスケジューリングに基づく
WIP を制限する
プロセス改善を促進するために、透明性を活用する
早期かつ頻繁な使えるソフトウェアの提供に重点をおく
自己組織化したチームに基づく
ワークを部分に分割する
リリース計画は、経験データにもとづき絶えず改善され続ける(ベロシティ/リードタイム)
Henrik Kniberg 128
Scrum Kanban
タイムボックスを固定したイテレー
ションを指定
タイムボックス固定イテレーション
の選択は任意
イテレーションの中での作業量を、
チームがコミットする
コミットメントは任意
計画やプロセス改善に使う基本の指
標は、ベロシティ
計画やプロセス改善に使う基本の指
標は、リードタイム
機能横断チームが指定 機能横断チームは任意
専門家チームも可能
1スプリント内で完了するように、項
目は分割される
項目のサイズに制限はない
バーンダウンチャートが指定 特に指定のダイアグラムはない
間接的にWIPを制限 (スプリントあ
たり)
直接的にWIPを制限 (ワークフロー
の状態ごとに)
見積もりは必須 見積もりは任意
実施中にイテレーションに項目は足
せない
容量があるならいつでも項目を足せ
る
スプリントバックログは、特定の1
チームが保有
Kanban ボードは、複数のチームや個
人で共有することもできる
役割を3つ指定 (PO/SM/Team) 役割を指定していない
Scrum ボードは、スプリントごとに
リセットされる
Kanban ボードはずっと使われる
優先度付きのプロダクトバックログ
を指定
優先度付けは任意
相違点
http://www.infoq.com/minibooks/kanban-scrum-minibook
類似点
131
Don’t be dogmatic
Henrik Kniberg 131
Go away! Don’t talk to us!We’re in a Sprint.
Come backin 3 weeks.
Though ShaltLimit WIP
133
Essential skills neededregardless of process
Henrik Kniberg 133
Software craftsmanship
Splitting the system into useful pieces
Retrospectives
As a buyerI want to save my shopping cartso that I can continue shopping later
134
必須なスキルプロセスによらず
Henrik Kniberg 134
ソフトウェア職人芸
システムを利用可能な単位に分割する
振り返り
As a buyerI want to save my shopping cartso that I can continue shopping later
135
Take-away points
Henrik Kniberg 135
1. Know your goal
Hint: Agile/Lean/Kanban/Scrum isn’t it.
2. Never blame the tool
Tools don’t fail or succeed. People do.
There is no such thing as a good or bad tool. Only good or bad decisions about when, where, how, and why to use which tool.
3. Don’t limit yourself to one tool
Broaden yourself
Compare for understanding, not judgement.
4. Experiment & enjoy the ride
Don’t worry about getting it right from start – you won’t
The important thing is not your process.The important thing is your process for improving your process
136
お持ち帰り用のポイント
Henrik Kniberg 136
1. ゴールを知ること
ヒント: Agile/Lean/Kanban/Scrumはゴールではない。
2. ツールを非難しないこと
ツールが成功したり、失敗したりはしない。するのは、人。
ツールに良い悪いもない。ツールを使う時、場所、方法、目的、選び方などに、よい判断と悪い判断があるだけだ。
3. 一つのツールにこだわるな
自分自身を広げること
判断のためでなく、理解のために比較する
4. 実験して、ライドを楽しもう
はじめから正しくやろうと心配しすぎない。どうせできない。
大事なのはプロセスではない。大事なのは、プロセスを改善しようとするプロセスである。