Kanban! お客さんの視点に立った アジャイルなやり方
-
Upload
hiroki-kondo -
Category
Documents
-
view
2.318 -
download
1
description
Transcript of Kanban! お客さんの視点に立った アジャイルなやり方
Kanban!お客さんの視点に立った
アジャイルなやり方
2011/12/13 @ PASONA TECHShibuya.trac #13
1
2011年12月10日土曜日
何者?
@kompiro こんぴろこと近藤寛喜と申します。
Change Vision.Inc,のエンジニア
アジャイルコーチではありません。
チームを率いるリーダーでもありません。
1プログラマでござる。
とある事情でKanban本の翻訳に携わってます。
時間がかかってすみません。
Tracに出戻りました。2
2011年12月10日土曜日
Kanban本とはこれ。
3
2011年12月10日土曜日
Kanban本の著者
David J.Anderson師
@agilemanager
Lean & Agile
日本に何度かいらしてます
元々はTOCの人みたい
4
2011年12月10日土曜日
なので、
翻訳中なので意図的に最近のAgile本を読んでません。
翻訳がブレるのを防ぐため。
最近のScrumは良く知りません。
一応5年前に2年くらい実践してました。
会社を代表して話をしている訳ではありません。
Kanbanを全て実践している訳でもないです。
5
2011年12月10日土曜日
今日お伝えしたいこと
Kanbanってなに?
見積に関するお話
この先は時間があればやります。
プロジェクトのゆらぎとサービスクラス
お客さんの視点に立ったプロジェクト運営とは?
6
2011年12月10日土曜日
Kanbanの解説に入る前にいくつか質問を
7
2011年12月10日土曜日
http://www.flickr.com/photos/oregondot/4132135156/sizes/o/in/photostream/
Scrumを知っていた人?
8
2011年12月10日土曜日
http://www.flickr.com/photos/oregondot/4132135156/sizes/o/in/photostream/
Scrumをやったことがある人?
9
2011年12月10日土曜日
http://www.flickr.com/photos/oregondot/4132135156/sizes/o/in/photostream/
プランニングポーカーが大好きな方?
10
2011年12月10日土曜日
http://www.flickr.com/photos/oregondot/4132135156/sizes/o/in/photostream/
プロジェクトに作業見積がないなんてありえない!?
11
2011年12月10日土曜日
どーん!!
12
2011年12月10日土曜日
見積を無くしたら上手く行った事例あり〼。
13
2011年12月10日土曜日
後ほどとりあげます。
14
2011年12月10日土曜日
Kanbanってなに?
15
2011年12月10日土曜日
http://www.flickr.com/photos/oregondot/4132135156/sizes/o/in/photostream/
Kanbanってよく分かんない方?
16
2011年12月10日土曜日
Kanbanとは?
17
アジャイルな開発のやり方の一つです。
今から簡単な例を使って見ていきましょう。
登場人物は
お客さんはTwitterのクローンを作りたい!と考えていた・・・。
2011年12月10日土曜日
実現したい機能はこんな感じ
18
2011年12月10日土曜日
これをKanban Systemを使って開発します。
19
2011年12月10日土曜日
最初にお客さんが3つ選びます。
20
選ぶ
2011年12月10日土曜日
開発スタート
21
作業をPull
2011年12月10日土曜日
WIP制限
22
一度に3つの作業は行えない
2011年12月10日土曜日
作業が完了(DONE)していれば次の作業へ
23
完了
作業をPull
2011年12月10日土曜日
空なので作業を補充
24
選ぶ
2011年12月10日土曜日
テストでバグ見つかる
25
戻す
作業できないので赤札に
2011年12月10日土曜日
テストでバグ見つかる
26
戻す
作業できないので赤札に
WIPオーバーなので赤札優先
2011年12月10日土曜日
フローが安定してきた
27
2011年12月10日土曜日
フローが安定してきた
28
なかなか補充されない
2011年12月10日土曜日
WIPが空いたので改善
29
2011年12月10日土曜日
DONEが溜まったのでリリース
30
2011年12月10日土曜日
フィードバックを次のキューへ
31
2011年12月10日土曜日
Kanban用語ケイデンス
32
補充→リリースの回数
2011年12月10日土曜日
Kanban用語リードタイム
33
補充→リリースまでの平均時間
2011年12月10日土曜日
Kanban用語スループット
34
補充→リリースできた量
2011年12月10日土曜日
見積りを無くしたら上手く行ったプロジェクト編
35
2011年12月10日土曜日
某M社の事例
36
アメリカに本社を置く最大手の某M社
2004年のことでした。
CMMI Lv5のインドのソフトウェアベンダを下請け
お願いした仕事は完璧に仕上がります。
定義した通りに仕事が納品され
品質は最高でした。
でもこのプロジェクト、社内の評判は最悪でした
2011年12月10日土曜日
最悪のプロジェクトとなぜ言われたのか?
リードタイムとスループットが最悪
要件定義から納品まで5ヶ月(リードタイム)
1月あたり、7個の要件を解決(スループット)
欲しいと思った機能が届くのが半年後
しかも、できあがる量が少ない
37
2011年12月10日土曜日
原因(1)作業割り込みが多い
製品マネージャからの割り込みが多かった
見積り依頼の割り込み
要求が産まれると見積りが依頼された。
その度に開発作業を中断した。
仕様書変更の割り込み
テスト時の検証のため
38
2011年12月10日土曜日
行った対策(1)
仕掛かり中(WIP)の仕事を制限した。
開発者は作業を完了するまで次の仕事に手をつけないようにした。
仕事の流れの整理を目的にしていた。
要求が届く→開発する→仕様書修正→テスト
手元の作業が無くなったら新たに仕事に手をつける、プル型の開発にやり方を変えた。
要求を一時的に溜めるキューを用意した
バックログのように要求を全部つっこむのではなく、依頼者が空になるタイミングで追加
39
2011年12月10日土曜日
これはいわゆるKanbanと言われるやり方
40
2011年12月10日土曜日
原因(2)
定義した要件をインドに見積を依頼
インドからは48時間以内に返答
インド側はできる限り正確に返答していた。
ただし、仕事時間の3割以上が見積りに
41
2011年12月10日土曜日
行った対策(2)
見積りを止めさせた
ただし、投資対効果の計算に問題がありそう
直感で15日以上かかりそうな要求には連絡を求めた
どの要求も25日以内にリリースするように保証を求めた
42
2011年12月10日土曜日
実績
43
リードタイム
0 37.50 75.00 112.50 150.00
対策前 対策後
スループット
0 7.50 15.00 22.50 30.00
対策前 対策後
3倍以上 9割削減2011年12月10日土曜日
そんでもってバックログも無くなったんだってさ
44
2011年12月10日土曜日
でも僕らみたいな凡人がそんな風にはなかなか
できないよ
45
2011年12月10日土曜日
某M社の事例
46
Kanbanの最初の事例(2004年)
CMMI Lv5のインドのソフトウェアベンダを下請け
リードタイムとスループットが最悪
要件定義から納品まで5ヶ月(リードタイム)
1月あたり、7個の要件を解決(スループット)
だけど、品質は最高。
定義した通りに納品。バグはない。
2011年12月10日土曜日
僕らがこの事例から学ぶべき事
47
2011年12月10日土曜日
常識にとらわれない
48
2011年12月10日土曜日
本当に必要なプロセスか?を考えませう
49
2011年12月10日土曜日
ちなみにこの事例では
50
まずは対策を考えるために、作業の流れをスケッチに書き出しまとめてみた。
→見積りや、仕様書の修正に無駄が発生している事が可視化された。
対策を打ってみた→上手く行った(ただし15ヶ月かかった)
2011年12月10日土曜日
ここまででご質問はありますか?
51
2011年12月10日土曜日
ここまでのまとめ
52
WIPの制限と作業をプルするように運営する事がKanbanの第1原則
コンテキストスイッチを減らし、作業の流れが整理されます。
リードタイムが短くなり、フィードバックを受け付けやすくなります。
見積りは必須とは言えない場合もある。
プロジェクト管理の常識が正解とは限らない。
2011年12月10日土曜日
Kanban翻訳本レビューを受け修正中
53
2011年12月10日土曜日
ご清聴ありがとうございました。
54
2011年12月10日土曜日
と言う事で、続きましてプロジェクトのゆらぎとサービスクラスについて
55
2011年12月10日土曜日
Kanbanはなぜうまく行くのか?
56
2011年12月10日土曜日
見積→計画でうまくいかないのはなぜか?
57
2011年12月10日土曜日
プロジェクトのゆらぎとは?(1)
58
プロジェクトには「ゆらぎ」がある
例えばメンバーが
事故に遭うかもしれない
結婚してハネムーンに行くかもしれない
病気になるかもしれない
不幸な事があるかもしれない
辞めるかもしれない
等々、プロジェクトのリスクと呼ばれるもの
2011年12月10日土曜日
プロジェクトのゆらぎとは?(2)
作業にも「ゆらぎ」がある
思ったよりサクサク進んだ。→OK
やり始めた。スマートな方法あるやん。→OK
やり始めた。考慮漏れあるやん。→NG
以前の実装がクソすぎて使えない。作り直しじゃない><→NG
等々、作業の進捗と呼ばれるもの
59
2011年12月10日土曜日
プロジェクトのゆらぎとは?(3)
作業には「大きさ」があり、ゆらぎます。
製品の特徴と言う「フィーチャやエピック」
ユーザから見た機能と言う「ストーリー」
日々の作業という「タスク」
エピックレベルだと月単位、ストーリーだと週単位、タスクだと日単位で遅れ/進みがある
60
2011年12月10日土曜日
こういった「ゆらぎ」がプロジェクトの計画を狂わして
きたのです。
61
2011年12月10日土曜日
Kanbanではこれらのゆらぎとは戦いません。
62
2011年12月10日土曜日
代わりにお客さんを裏切らないようにします。
63
2011年12月10日土曜日
それがサービスクラスの導入です。
64
2011年12月10日土曜日
飛行機のサービスを例に説明してみましょう
65
2011年12月10日土曜日
ファーストクラス
66
By garybembridge
By garybembridge
By garybembridge
専用のチェックインゲートとかありますよね
2011年12月10日土曜日
エコノミークラス
67
By nekotank
シートとか全然違うじゃないですか。
2011年12月10日土曜日
シート代に対して提供サービスが異なりますよね。
68
2011年12月10日土曜日
この考えを応用したものがサービスクラスです。
69
2011年12月10日土曜日
サービスクラス毎にサービスレベルを保証します。
70
2011年12月10日土曜日
お客さんになって考えると
71
実は、納期はそれほど重要ではない場合も多い
システムの稼働が遅れると困る場合の代表例
広告を打つ日付が決まっている
外部システムと連携があれば、そちらに迷惑がかかる
etc...
それよりも、約束していた事が守られない事が腹立たしい。
2011年12月10日土曜日
「納期」以外の契約の方がお客さんにとって望ましい
事もあります。
72
2011年12月10日土曜日
その一つがサービスレベル保証契約
(SLA)です。
73
一昔前のレンタルサーバーでありましたよね
2011年12月10日土曜日
Kanbanのサービスクラスの例
74
特急クラス
締切クラス
スタンダードクラス
ブロックしているクラス
その他
2011年12月10日土曜日
クラス毎に一定期間内のサービスレベルを保証し、
契約します。
75
2011年12月10日土曜日
では、それぞれのクラスについて見ていきましょう。
76
2011年12月10日土曜日
特急クラス
即対応が必要な要求や作業に割り当てます。
何でもかんでもすぐにできる訳ではありません。
カードウォール上に唯1つというWIP制限
お客さんはすぐに必要なものを依頼できますが、依頼できるのは開発チームに唯一つ、という状態を保てます。
特急クラスがどの程度迅速に対処されるかは、サービスレベル保証契約によります。
77
2011年12月10日土曜日
締切クラス
一般に言われる「納期」とは異なります。
ここで言う「締切」は、それを守れなかった時に具体的なコストが発生する場合を指します。
例えば「確定申告」や「連携する外部システムの停止が分かっている」とか、「JavaのEOL」とか。
ペナルティがあったり、自前で脆弱性など全てサポートしていかなければならなくなったり、と言った「コスト」が発生するクラスです。
WIPは制限し辛いですが、直近の状況や忙しさが見える化されます。
78
2011年12月10日土曜日
スタンダードクラス
緊急性のない要求に対するクラス
1ヶ月など、一定の期間内にどれだけ実施されたか、スループットを測定し、保証します。
サイズによるゆらぎが起きやすいので、それぞれのサイズごと(エピック、ストーリー、タスク)にサービスレベルを保証するパターンも考えられます。
79
2011年12月10日土曜日
ブロックしているクラス
他の作業をブロックしている要因を書いたクラス
WIPが制限されているので、ブロックされると他の作業に手をつけられない。
そのため、このクラスの作業が発生すると、優先度高めに対処したくなる。
80
2011年12月10日土曜日
その他のクラス
作業者の手が空いてしまった時のための要求
例:新しいビルドツールを試す
プロジェクトの運営には必須と言えないが、投資をすることで効率化を図れそうな要求のためのクラス
81
2011年12月10日土曜日
ところでKanbanと聞くとこんなのをイメージしてたのではない
でしょうか?
82
2011年12月10日土曜日
83
2011年12月10日土曜日
カードを貼った壁をKanbanではカードウォールと
呼んでいます。
84
2011年12月10日土曜日
アナログは、視覚に訴えるのでとてもいいです。
85
2011年12月10日土曜日
86
2011年12月10日土曜日
カードに書かれた作業に注釈を追記するのも簡単
です。
87
2011年12月10日土曜日
こんな感じで、サービスクラス毎に異なる色のカードを用意し、作業を明記していきます。
88
2011年12月10日土曜日
Kanbanプロジェクトでは毎月Kanbanの運用状況をレ
ビューし、サービスレベルを保証できたか、検証するそ
うです。(未)
89
2011年12月10日土曜日
今日のまとめ
90
見積りは必須とは言えない場合もある。
プロジェクト管理の常識が正解とは限らない。
WIPの制限と作業をプルするように運営する事がKanbanの第1原則
コンテキストスイッチを減らし、作業の流れを整理する
プロジェクトにはリスクや進捗のゆらぎがある。
Kanbanではサービスクラスと契約によってゆらぎからの影響を極力避けている。
2011年12月10日土曜日
Kanban翻訳本レビューを受け修正中
91
2011年12月10日土曜日
ご清聴ありがとうございました。
92
2011年12月10日土曜日