すくすくスクラム #19 に行ってきた
@ebacky さんによる、Agile 2010 で行なわれた、
"KANBAN AND SCRUM - MAKING THE MOST OF BOTH" の再演に参加してきました。
http://kokucheese.com/event/index/4912/
珍しく飲まれなかったんで自分用メモをばw
メモ
正確ではないです。誤りがあればご指摘下さい。
Kanbanの効果
- 信号システム
- 可視化
- 仕事量を制限
Kanbanの特徴
- Kanbanボードは複数チームで使っても良い
- Scrumボードは1チームに1つ(であるべき?)
- 手法にルールが少ない分、自分達なりにカスタマイズ、合わせて使って行くことが大事
- プロセス(ルール数)： RUP(120+), XP(13), Scrum(9), Kanban(3), 何でも(0)
- KanbanもScrumも現状の問題の透明性を高める それにより、より改善を促す
- Scrumでは、開発チームだけ改善となり、部分最適に落ちいる可能性があり、これは良く無い
- Kanbanは、仕掛りを制限する
- 制限(仕掛りの上限)は自分達の経験をもとに出す*1
- 仕掛りの数が少ない： チームに怠け者が出る
- 仕掛りの数が適切： ときどきゆとりがある状態。タスクの流れが気持ち良い状態になる(らしい)
- 仕掛りの数が多い： 開発者にゆとりが無い。ただただ過酷で、製品に対する気持ちが入らない
- Kanban は進化させていく
- ルールが少ないが故に、Kanban自体を進化させて行くことが大事
- 自分達流のKanbanを作るのが大事
Kanban と Scrum
| Scrum | Kanban | |
|---|---|---|
| ロール | チーム、プロダクトオーナー、スクラムマスター | 特に定めない |
| アウトプットのタイミング | タイムボックス毎に出す*2 | チームの能力により出すタイミングは異なる |
| タスクの明白さ | スプリント毎に収まるように、分割したり調整する(?) | タスクのありのままが見える |
| 明示的に仕掛りの数を制限出来る | ||
| 変更要求 | スプリント中は変更を受け付けない | 常に受けいれる*3 |
| 完了タスクの状態 | スプリント毎にリセット | 常に残る(?) |
| 適するチーム | 機能横断チームを好む(?) | 専門家チーム、総務チームも好む(?) |
| 見積りの仕方 | フィーチャはストーリーポイント、タスクは日数 | フィーチャは大、中、小で、 タスクは数だけ数える |
| バックログ | 必須 | 置いても良い*4 |
大事なこと
- ゴールを把握する
- ツールに良し悪しは無い
- 状況によって使い訳が大事
- その時の状況が悪いからと言って、駄目と判断するのは良くない
- ツールも1つにこだわらない
- 自分の世界を狭くするよ
- 挑戦することを諦めない、失敗も悲観しない
- 大切なのは、プロセスじゃなく、プロセスを改善すること
ワーク1
リードタイム(1つのタスクが完成する時間)が3 のチームと 20 のチームのどちらに改善をするべきか。
ワーク2
- ゲーム1)
- 参加者(グループメンバー)の名前を1文字ずるを並行に書いていく。リードタイムをはかり、良かった点と改善点を出す
- ゲーム2)
- 参加者(グループメンバー)の名前を1人ずつを順に書いていく。リードタイムをはかり、良かった点と改善点を出す
- ゲーム1、ゲーム2を比較して、違いを討論する
ワークのアウトプット
感想、チーム内での話合いなど
印象としては、講演中何度も言葉を変えて出た、
"ツールに縛られるな"と"自分達に合うように改善していく"という事。
また、元々"vs" とされていたのは、
それぞれの特徴や違い、類似点を明確に説明するためで、決して戦わせるという訳では無いのでしょう。
そういう意味では、個人的には、"and" よりもしっくりくる。
グループ内に、Kanbanを実践されている方がいましたので、
話を聞かせてもらいました。
- Q. 見積りは大、中、小 だけど、お客さんに納得して頂けるものなのか?
- A. お客さんにも、だいたいの大きさで説明して、それで納得して頂いている。開発チームへの信頼が大事
- Q. 仕掛りの制限はどのようにしていますか?
- A. リソースを用いている。5人チームだと5つまで。
帰りがけに、 @haru01 先生が、"WFでもKanbanは使えるよ" とおっしゃってました、
今度、詳しく聞きたいです。
