![Kanban @ Toyota
Buyer Supplier
Consume Detach Receive Ship Allocate Manufacture
The tool used to operate the
[Toyota Production] system is
kanban.
Taiichi Ohno
Adapted from Kiro Harada’s slide
Father of the
Toyota Production System
Henrik Kniberg 23](https://image.slidesharecdn.com/henrik-kniberg-kanban-and-scrum-agile2010-j-100829193019-phpapp02/85/Scrum-Kanban-23-320.jpg)
Scrum & Kanban
- 1. Copyright notice These slides are licensed under Creative Kanban and Scrum Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere. Making the most of both For licensing details see: http://creativecommons.org/licenses/by/3. 0/ Agile 2010, Orlando All slides available at: August 12, 2010 http://www.crisp.se/henrik.kniberg/ Henrik Kniberg Agile/Lean coach www.crisp.se Board of directors [email protected] +46 70 4925284
- 2. Copyright notice These slides are licensed under Creative Kanban と Scrum Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere. 翻訳ドラフト版 2010/8/30 両者を最大限に活用する For licensing details see: http://creativecommons.org/licenses/by/3. 0/ Agile 2010, Orlando All slides available at: K. Harada [email protected] August 12, 2010 http://www.crisp.se/henrik.kniberg/ Henrik Kniberg Agile/Lean coach www.crisp.se Board of directors [email protected] +46 70 4925284
- 3. Purpose of this presentation To clarify Kanban and Scrum by comparing them ...so you can figure out how these may come to use in your context. Henrik Kniberg 3
- 4. プレゼンテーションの目的 Scrum と Kanban を比較して、両者をよりよく理解する あなたが、自分のコンテキストで、 Scrum や Kanban をどう活用できるか自分で考えられるように Henrik Kniberg 4
- 5. Your knowledge? Veteran Use Tried Scrum Kanban Seen Read 5 Henrik Kniberg
- 6. 知識レベル? ベテラン 使った 試した Scrum Kanban 見た 読んだ 6 Henrik Kniberg
- 7. Scrum in a nutshell Henrik Kniberg 7
- 9. Split your organization Scrum in a nutshell Split your product Large group spending a long time building a huge thing Small team spending a little time building a small thing ... but integrating regularly to see the whole Optimize process Optimize business value $$$ Split time January April $ Nt o ch cke o e d ut D ne :o o ! ) S R T G A B t a a re a ! P IN OL: e -re dy le se ch cke o e d ut D p sit Write eo failing test Burndown 2d DAO Code Integr p DB cleanu test 2d 0.5d design 1d 2d 1d GUI Write igra n M t io spec 2d failing 2d test 1d 3d tol o Tapes try spike Impl. 1d 2d migration 8d a ffice Bcko Write failing test Login Integr. Impl GUI 2d U la d it e s np nne m N xt e 1d with JBoss 2d P it ht e w W dra Fix memo Write Write leak (JIRA ry Sales support e st W rfdra it h w Bcko a ffice failing test 3d 2d failing test 125) 3d Write U r a in se dm whitepaper 4d GUI Clarify design Impl require- (CSS) ments GUI 1d 2d 6d Henrik Kniberg 9
- 10. 組織を分割 Scrum 超入門 製品を分割 大きなグループが長い時間をかけて、巨大なものを作る 小さなグループが短い時間に、小さなものを作る ただし、しょっちゅう統合して、全体を見る プロセスを最適化 ビジネス価値を最適化 $$$ 時間を分割 １月 ４月 $ Nt o ch cke o e d ut D ne :o o ! ) S R T G A B t a a re a ! P IN OL: e -re dy le se ch cke o e d ut D p sit Write eo failing test Burndown 2d DAO Code Integr p DB cleanu test 2d 0.5d design 1d 2d 1d GUI Write igra n M t io spec 2d failing 2d test 1d 3d tol o Tapes try spike Impl. 1d 2d migration 8d a ffice Bcko Write failing test Login Integr. Impl GUI 2d U la d it e s np nne m N xt e 1d with JBoss 2d P it ht e w W dra Fix memo Write Write leak (JIRA ry Sales support e st W rfdra it h w Bcko a ffice failing test 3d 2d failing test 125) 3d Write U r a in se dm whitepaper 4d GUI Clarify design Impl require- (CSS) ments GUI 1d 2d 6d Henrik Kniberg 10
- 11. The bottom line Core Scrum the unofficial If you achieve these you can ignore the rest of the checklist. Your process is fine. Delivering working, tested These are central to Scrum. Without these you probably shouldn’t call it Scrum. Retrospective happens after Scrum Checklist software every 4 weeks or less every sprint Results in concrete Henrik Kniberg Delivering what the improvement proposals Recommended but not always necessary business needs most Some proposals actually get Process is implemented Most of these will usually be needed, but not always all of them. Experiment! continuously improving Whole team + PO Team has all skills needed to PBL items are broken into tasks participates bring backlog items to Done within a sprint Clearly defined product owner PO has a product backlog Team members not locked into (PO) (PBL) Sprint tasks are estimated specific roles PO is empowered to Top items are prioritized by Iterations that are doomed to Estimates for ongoing tasks prioritize business value fail are terminated early are updated daily PO has knowledge to Top items are estimated prioritize PO has product vision that is in Velocity is measured sync with PBL PO has direct contact with Estimates written by the team team PBL and product vision is highly All items in sprint plan have visible an estimate PO has direct contact with Top items in PBL small stakeholders enough to fit in a sprint Everyone on the team PO uses velocity for participates in estimating release planning PO speaks with one voice PO understands purpose of (in case PO is a team) all backlog items PO available when team is Velocity only includes estimating items that are Done Team has a sprint backlog Have sprint planning meetings Estimate relative size (story Team has a sprint burndown points) rather than time chart Highly visible PO participates Whole team knows top 1-3 Highly visible impediments Updated daily PO brings up-to-date PBL SM has strategy for how to Updated daily fix top impediment Owned exclusively by the Whole team participates team SM focusing on removing Daily Scrum is every day, same impediments time & place Results in a sprint plan Escalated to management PO participates at least a Daily Scrum happens Whole team believes plan is when team can’t solve few times per week achievable Whole team participates Team has a Scrum Master (SM) Max 15 minutes PO satisfied with Problems & impediments priorities Each team member knows are surfaced SM sits with the team what the others are doing Timeboxed iterations Demo happens after every sprint Iteration length 4 weeks or Scaling Positive indicators less Shows working, tested These are pretty fundamental to any Leading indicators of a software Always end on time Scrum scaling effort. good Scrum implementation. Feedback received from You have a Chief Product Team not disrupted or Having fun! High energy level. stakeholders & PO Owner (if many POs) controlled by outsiders Dependent teams do Scrum of Overtime work is rare and Team usually delivers what Scrums happens voluntarily Have Definition of Done (DoD) they committed to Dependent teams integrate Discussing, criticizing, and 11 DoD achievable within within each sprint experimenting with the process Team members sit together each iteration PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done Team respects DoD Max 9 people per team http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)
- 12. 最低限のチェック コア・スクラム the unofficial (非公認) この項目ができていたら、残りのチェックリス ト項目は無視していい。あなたのプロセスはう まくいっている。 定期的(4週間以内)に動作する、テスト済 スクラムの主要要素。これらを抜きにして、 スクラムと呼ぶことはできないだろう スプリントごとにふりかえりを Scrum Checklist みのソフトウェアを提供している 行えている スクラムチェックリスト Henrik Kniberg 結果として具体的な改善提 ビジネスニーズに基づいたものを最優先し て提供している 案を行っている 実際に、実現できた提案が 推奨項目(いつも必要というわけではない) ある ほとんどの項目は必要になる事が多い、すべて常に必要というわけではない。試してみて! プロセスを継続的に改善している チームとプロダクトオーナ チームは、バックログ項目を完了させ プロダクトバックログは、1スプリン ーの全員が参加している るために必要なスキルを全て持つ ト以内のタスクに分割されている はっきりと定義されたプロダクトオー プロダクトオーナーはプロダクトバッ チームメンバは特定の役割に固 スプリントタスクの見積りが行 ナー(PO) クログ(PBL)を持っている われている 定されていない プロダクトオーナーは、優先度 上位項目はビジネス価値に基づ 失敗が避けられないイテレーションを 実行中のタスクの見積りは 付けをする権限をもつ いて優先度付けされている 早めに強制終了している 毎日更新されている プロダクトオーナーは、優先度 上位項目は見積り済み 付けをする知識をもつ である POは プロダクトバックログと連動す るプロダクトビジョンをもつ ベロシティが計測されている プロダクトオーナーは、直接 チ 見積りはチームが ームと話している 行っている プロダクトバックログとプロダクトビ スプリント計画で、対象の ジョンを見える化している 項目が見積りを持っている プロダクトオーナーは、直接 ス 上位項目は１つのスプリントに テークホルダと話している 収まる規模になっている チームの全員が見積もりに参加 POはベロシティを用いて リリース計画を作成している プロダクトオーナーがすべての している プロダクトオーナーは、同じこ とをいう(複数人いる場合) 項目の目的を理解している チームが見積っている間、 ベロシティは完了した項目だけ プロダクトオーナも待機している をカウントしている スプリント計画ミーティングを チームはスプリントバックログを持っ 時間ではなく、相対規模(ストーリーポ ている 行っている チームはスプリントバーンダウンチャ イント) で見積っている ートを持っている プロダクトオーナーが参加して 見える化している いる チーム全員が上位3つの障害 見える化されている プロダクトオーナーが最新のプ について認識している 毎日更新されている ロダクトバックログを提示 最上位の障害解決について、 毎日更新されている SMが戦略をもっている 完全にチームの持ち物である チーム全員が参加している スクラムマスターは、障害を取 デイリースクラムは、毎日・同じ時間 り除くことに集中している 結果がスプリント計画に ・同じ場所で行っている 盛り込まれている チームが解決できないときは 管 デイリースクラムを行っている 最低でも週の何日かはプロダク 理層に報告されている トオーナが参加している チーム全員が計画は達成可能だ と考えている チームの全員が参加している チームにスクラムマスター(SM) がいる 長くても15分まで プロダクトオーナーは、優先度 を含め満足している 問題と障害を表面化できている スクラムマスターは、チームと 各チームメンバは他のメンバが 同じ場所に机がある 何をしているか知っている イテレーションを タイムボックス化している 毎スプリント終了後にデモを行 っている イテレーションの長さは スケーリング よい兆候 4週間以内 動作する、テスト済みのソフト スクラムの規模を拡大する取り組みの よいスクラムを実施している事を示す ウェアを見せている いつも期限どおりに うち、ごく基本的なもの 先行指標 終了する ステークホルダとプロダクトオ チーフプロダクトオーナーがいる (た ーナからフィードバックを得て チームは部外者に妨害や くさんのPOがいるとき) 楽しんで! みんな活発に いる 指図を受けていない 所属するチームを集めてスクラムのス チームは通常、何にコミッ クラムを行っている 残業は稀。残業を強制されない 完了の定義(DoD)を持っている トするかを明言している 所属するチームはスプリント内で プロセスについて議論、批評、 12 DoDはイテレーションごとに 達 チームメンバは同じ場所に机が インテグレーションを行っている 実験を行っている 成可能なものになっている ある ひとつのチームは最大でも9 PO = プロダクトオーナー SM = スクラムマスター PBL = プロダクトバックログ DoD = 完了の定義 チームはDoDを尊重している 人まで http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17) 日本語訳 rev.1 (2009-09-01)
- 13. Kanban in a nutshell Henrik Kniberg 13
- 14. Kanban 超入門 Henrik Kniberg 14
- 15. Which team needs Managers who don’t know how to measure what they want settle for most improvement? wanting what they can measure Russel Ackoff Team 1 Team 2 Todo Doing Done Todo Doing Done this week this week orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse ctetur sit amet, co nse ctetur ctetur orem ipsum dolor orem ipsum dolor orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse sit amet, co nse sit amet, co nse ctetur orem ipsum dolor ctetur ctetur ctetur sit amet, co nse orem ipsum dolor orem ipsum dolor orem ipsum dolor ctetur sit amet, co nse sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor ctetur orem ipsum dolor sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse sit amet, co nse orem ipsum dolor ctetur ctetur ctetur sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse Avg lead time:20 Avg lead time: 3 ctetur days days Henrik Kniberg 15
- 16. 欲しいものを、どうやって計測す どっちのチームが るかを知らないマネージャは、結 局計測できるものを欲するように 改善が必要？ なる。 Russel Ackoff チーム 1 チーム 2 Todo Doing Done Todo Doing Done this week this week orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse ctetur sit amet, co nse ctetur ctetur orem ipsum dolor orem ipsum dolor orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse sit amet, co nse sit amet, co nse ctetur orem ipsum dolor ctetur ctetur ctetur sit amet, co nse orem ipsum dolor orem ipsum dolor orem ipsum dolor ctetur sit amet, co nse sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor ctetur orem ipsum dolor sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse sit amet, co nse orem ipsum dolor ctetur ctetur ctetur sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse 平均リードタイム: 20 日 3 ctetur 平均リードタイム: 日 Henrik Kniberg 16
- 17. Kanban @ Imperial Palace Gardens Henrik Kniberg 17
- 18. Kanban @ Imperial Palace Gardens Henrik Kniberg 18
- 19. Kanban 看板 ”Visual Card” Signaling system Visual Limited in supply Henrik Kniberg 19
- 20. Kanban 看板 ”Visual Card” 通知システム 見える 量の制限 Henrik Kniberg 20
- 21. Kanban in your wallet Darn. Forgot to limit. Henrik Kniberg 21
- 22. 財布の中のKanban あ、量の制限を 忘れてる！ Henrik Kniberg 22
- 23. Kanban @ Toyota Buyer Supplier Consume Detach Receive Ship Allocate Manufacture The tool used to operate the [Toyota Production] system is kanban. Taiichi Ohno Adapted from Kiro Harada’s slide Father of the Toyota Production System Henrik Kniberg 23
- 24. トヨタのかんばん Buyer バイヤー Supplier サプライヤ Consume Detach Receive Ship Allocate Manufacture 使用 外れ 受領 出荷 引当 製造 「トヨタ生産方式」を運用するの につかわれるツールは、かんばん である 大野耐一 原田騎郎氏のスライドより引用 トヨタ生産方式の父 Henrik Kniberg 24
- 25. Kanban in SW development Visualize the workflow Pioneered by David Anderson in 2004 Limit WIP (work in progress) Measure & optimize flow Explicit policies (definition of Done, WIP limits, etc) Backlog Dev UAT Deploy Done 5 3 2 3 orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur FLOW 12 Avg lead time: days Henrik Kniberg 25
- 26. ソフトウェア開発における Kanban ワークフローの見える化 David Anderson が2004年に開始 仕掛品(WIP: work in progress)の制限 流れの計測と最適化 明示的なポリシー (完了の定義, WIPの制限,他) Backlog Dev UAT Deploy Done 5 3 2 3 orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse ctetur 訳注: ctetur Kanban は、もちろん 「看板・かんばん」 に由来しますが、TPS フロー 平均リードタイム 12 日 における「かんば ん」と相違が多いた め、誤解をさけるた め Kanban としてい ます。 Henrik Kniberg 26
- 27. Kanban example Board shared by 2 teams (16 people in total) Henrik Kniberg 27
- 29. Compare for understanding, not judgement Henrik Kniberg 29
- 31. Thinking tools a.k.a. ”mindsets” or ”philosophies” Tool Agile Systems Thinking Toolkits ”anything used as a means of Lean a.k.a. ”frameworks” accomplishing a task or purpose.” Theory of Constraints - dictionary.com RUP XP Scrum Physical tools Kanban Process tools a.k.a. ”organizational patterns” Product Owner role Pair programming Visualize the workflow To do Dev Test Release Done! 5 3 2 3 H D C A G B K FLOW Henrik Kniberg 31
- 32. 思考ツール a.k.a. ”マインドセット” 、”哲学” ツール アジャイル システム思考 ツールキット リーン タスクや目的を達成するために使われ a.k.a. ”フレームワーク” る手段であれば何でも 制約理論 - dictionary.com RUP XP Scrum 物理的なツール Kanban プロセスツール a.k.a. ”組織パターン” プロダクトオーナ という役割 ペアプロ 見える化 To do Dev Test Release Done! 5 3 2 3 H D C A G B K FLOW Henrik Kniberg 32
- 33. Compare for understanding, not judgement More prescriptive More adaptive RUP XP Scrum Kanban Do Whatever (120+) (13) (9) (3) (0) • Architecture Reviewer • Business use case realization • Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow • Business-Model Reviewer • Business vision • Coding standard • Product Owner • 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 Do not develop an attachment • System Administrator • Programming guidelines • System Analyst • Quality assurance plan • Technical Writer • Reference architecture • Test Analyst • Release notes to any one weapon • Test Designer • Requirements attributes • Test Manager • Requirements • Tester management plan • Tool Specialist • Review record or any one school of fighting • User-Interface Designer • Risk list • Architectural analysis • Risk management plan • Assess Viability of architectural • Software architecture proof-of-concept document • Capsule design • Software development • Class design plan • Construct architectural proof-of- • Software requirements • • concept Database design Describe distribution • • specification Stakeholder requests Status assessment Miyamoto Musashi • • Describe the run-time architecture Design test packages and classes • Supplementary business specification 17th century samurai • Develop design guidelines • Supplementary specification • Develop programming guidelines • Target organization assessment • Identify design elements • Test automation architecture • Identify design mechanisms • Test cases • Incorporate design elements • Test environment configuration • Prioritize use cases • Test evaluation summary • Review the architecture • Test guidelines • Review the design • Test ideas list • Structure the implementation • Test interface specification model • Test plan • Subsystem design • Test suite • Use-case analysis • Tool guidelines • Use-case design • Training materials • Analysis model • Use case model • Architectural proof-of-concept • Use case package • Bill of materials • Use-case modeling guidelines • Business architecture document • Use-case realization • Business case • Use-case storyboard • Business glossary • User-interface guidelines Henrik Kniberg 33 • Business modeling guidelines • User-interface prototype • Business object model • Vision • Business rules • Work order • Business use case • Workload analysis model
- 34. 判断のためでなく、理解のための比較 より記述的 より適応的 RUP XP Scrum Kanban なんでもいい (120+) (13) (9) (3) (0) • Architecture Reviewer • Business use case realization • Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow • Business-Model Reviewer • Business vision • Coding standard • Product Owner • 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 Requirements attributes 武器や流儀にこだわらない • • • Test Manager • Requirements • Tester management plan • Tool Specialist • Review record • User-Interface Designer • Risk list • Architectural analysis • Risk management plan • Assess Viability of architectural • Software architecture proof-of-concept document • Capsule design • Software development • Class design plan • Construct architectural proof-of- • Software requirements • • concept Database design Describe distribution • • specification Stakeholder requests Status assessment 宮本武蔵 • • Describe the run-time architecture Design test packages and classes • Supplementary business specification 17th century samurai • Develop design guidelines • Supplementary specification • Develop programming guidelines • Target organization assessment • Identify design elements • Test automation architecture • Identify design mechanisms • Test cases • Incorporate design elements • Test environment configuration • Prioritize use cases • Test evaluation summary • Review the architecture • Test guidelines • Review the design • Test ideas list • Structure the implementation • Test interface specification model • Test plan • Subsystem design • Test suite • Use-case analysis • Tool guidelines • Use-case design • Training materials • Analysis model • Use case model • Architectural proof-of-concept • Use case package • Bill of materials • Use-case modeling guidelines • Business architecture document • Use-case realization • Business case • Use-case storyboard • Business glossary • User-interface guidelines Henrik Kniberg 34 • Business modeling guidelines • User-interface prototype • Business object model • Vision • Business rules • Work order • Business use case • Workload analysis model
- 35. Lean & Agile process toolkits Values & Principles Lean, Agile, Theory of Constraints, Systems Thinking, etc Kanban Other lean tools XP (Value Stream Mapping, Root Cause Analysis, etc) Scrum Henrik Kniberg 35
- 36. リーンとアジャイルのプロセスツールキット 価値と原則 リーン、アジャイル、制約理論、システム思考、他 Kanban XP 他のリーンツール (バリューストリーム マッピング, 原因分析, 他) Scrum Henrik Kniberg 36
- 37. Any tool can be misused The old tool was better! Don’t blame the tool! 37 Henrik Kniberg 37
- 38. どんなツールの間違った使い方ができる 昔のツールが よかった ツールを責めない! 38 Henrik Kniberg 38
- 39. Why limit WIP? (work in progress) Henrik Kniberg 39
- 41. Multitasking name game 準備 4 – 6人の顧客 1 開発者 Dave Lisa Bob Eric Maria Henrik Kniberg 41
- 42. Multitasking name game Round 1: Ordering process Developer Customer Jeff 1 Order 2 Deliver JEFF 28 JEFF 3 Log delivery time Henrik Kniberg 42
- 43. Multitasking name game ラウンド 1: 注文プロセス 開発者 顧客 Jeff 1 注文 納品 2 JEFF 28 JEFF 納入時間を計測 3 Henrik Kniberg 43
- 44. Multitasking name game Round 1: Development process 28 Policy DAV E Dave Never keep a L IS Lisa customer waiting BO B Bob Start early = Finish early ERI Eric MAR Maria Henrik Kniberg 44
- 45. Multitasking name game ラウンド 1: 開発プロセス 28 ポリシー DAV E Dave 顧客を待たせない L IS Lisa 早く始める BO B Bob = 早く終わる ERI Eric MAR Maria Henrik Kniberg 45
- 46. Multitasking name game Round 2 – Development process Policy DAV E Dave Limit WIP L IS A Lisa (work in process) Bob Current limit = 1 customer at a time Eric Maria Henrik Kniberg 46
- 47. Multitasking name game ラウンド 2 – 開発プロセス Policy DAV E Dave WIPを制限 L IS A Lisa (WIP: 仕掛品) Bob 現在のリミット= 顧客対応は、 一人づつ Eric Maria Henrik Kniberg 47
- 48. Multitasking name game Round 2: Ordering process Developer Customer Jeff 0 Request order 5 1 Log start time Submit order 5 2 Deliver product JEFF 5 15 JEFF 3 10 Henrik Kniberg Log delivery 48 time Calc project length
- 49. Multitasking name game ラウンド 2: 注文プロセス 開発者 顧客 Jeff 0 発注 5 1 開始時刻を記録 発注 5 製品の納品 2 JEFF 5 15 JEFF 3 10 Henrik Kniberg 納入時刻を記録 49 かかった時間を計算
- 50. Multitasking name game Typical results Henrik Kniberg 50
- 51. Multitasking name game よくある結果 Henrik Kniberg 51
- 52. Causes of unnecessary multitasking 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 Fix hole Hole in boat Henrik Kniberg 52
- 53. 不必要なマルチタスクの原因 開始することに集中して、終了を意識し ない WIPを制限しない 人を忙しくしておくことに集中する(ゆとり 時間を恐れる) 症状を直すことと“理由”を受け入れて、 問題を気にしない。 水をかき出す 浸水 穴を直す ボートに穴 Henrik Kniberg 53
- 56. Case study Design-ready games Production-ready games Game backlog 15 12 8 Lisa Concept Graphics Sound Integr. & Sam assigns Dev pres. design design deploy resources 2d 1m 6m 1w 6m 6m 2h 4h 1d 1m 3w 3m 3w (1m+2m) 3 m value added time Process = 12% cycle 25 m cycle time efficiency 56
- 57. ケーススタディ デザイン完了ゲーム 製造可能 ゲーム ゲームバックログ 15 12 8 グラ コンセ Lisa がリ サウン フィッ 統合 & 配 Sam プト作 ソース割 ドデザ 開発 クデザ 布 成 り当て イン 2d 1m 6m 1w イン 6m 6m 2h 4h 1d 1m 3w 3m 3w (1m+2m) 付加価値作業 3分 プロセス = 12% サイクル サイクルタイム 25分 効率 57
- 58. Limit work to capacity Input: 3 customers / hour Output capacity: 2 customers / hour Henrik Kniberg 58
- 59. 仕事の量を能力容量に合わせる 入力: 3 顧客 / 時 出力容量: 2 顧客 / 時 Henrik Kniberg 59
- 60. Case study Design-ready games Production-ready games Game backlog 15 12 8 Lisa Concept Graphics Sound Integr. & Sam assigns Dev pres. design design deploy resources 2d 1m 6m 1w 6m 6m 2h 4h 1d 1m 3w 3m 3w プロセス (1m+2m) 付加価値作業 3分 = 12% サイクル サイクルタイム 25分 効率 Cross-functional game team Game team (graphics, sound, dev, integrate) 3-4 m cycle time = 6-8x faster 3-4 months 60 Henrik Kniberg 60
- 61. Case study デザイン完了ゲーム 製造可能 ゲーム ゲームバックログ 15 12 8 グラ コンセ Lisa がリ サウン フィッ 統合 & 配 Sam プト作 ソース割 ドデザ 開発 クデザ 布 成 り当て イン 2d 1m 6m 1w イン 6m 6m 2h 4h 1d 1m 3w 3m 3w プロセス (1m+2m) 付加価値作業 3分 = 12% サイクル サイクルタイム 25分 効率 機能横断ゲームチームCross-functional game team ゲームチーム (グラフィック, サウ ンド, 開発, 統合) サイクルタイム3～4分= 6～8倍速い 3～4 か月 61 Henrik Kniberg 61
- 62. Typical evolution to Scrum/Kanban combo Scrum step 1 Scrum step 2 Scrum + Kanban Feature Feature Feature Feature Feature Feature Feature Feature Feature team 1 team 2 team 2 team 1 team 2 team 2 team 1 team 2 team 2 Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Operations / support team Operations / support team Scrum Kanban Henrik Kniberg 64
- 63. Scrum/Kanban 組み合わせのよくある改善例 Scrum ステップ 1 Scrum ステップ 2 Scrum + Kanban Feature Feature Feature Feature Feature Feature Feature Feature Feature team 1 team 2 team 2 team 1 team 2 team 2 team 1 team 2 team 2 Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum 運用サポートチーム 運用サポートチーム Scrum Kanban Henrik Kniberg 65
- 64. One day in Kanban land Henrik Kniberg 66
- 66. ”One day in Kanban land” http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 68
- 67. シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 69
- 68. シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 70
- 69. シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 71
- 70. Scenario 1 – one piece flow Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 72
- 71. シナリオ 1 – 一個流し Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 73