この記事はAtlassian Advent Calendar 2012の11日目です。
Greenhopperではboardを作成できますが、このときにScrum boardにするか、Kanban boardにするか選択できます。
同じフィルタ条件でいくつでも作成できるので、二つ作って比べてみるのが手っ取り早いのですが、両方使ってみてなんとなく適したやり方が見えてきたので、一例として紹介します。
Kanban Board
Kanban boardは、Scrum boardと下記の点が違います
- sprintがないので、planメニューがない
- sprintがないので、バーンダウンチャートがない
- sprintがないので、story pointがない
Kanbanを見て現在のタスクの状態を確認しつつ、ベロシティに相当する速度は、Cumulative flow diagramで確認することになります。
使い始めてすぐ気がつくのは、KanbanでDoneにしたタスクが消えずに積み上がることです。これは、Doneレーンの右上から、Releaseをすると消えます。基本的な考え方は、Releaseの間は同じboardを使い続けるということだと思います。
ただDoneの所に積み上がっちゃうのが嫌で、Releaseよりももうちょっと短い単位で綺麗にしていきたいという事もあるでしょう。その場合はフィルタ条件に適当な条件を追加すればOKです。
使いどころ
ところで、Kanbanの機能は、全部Scrum boardがもっています。じゃあScrum boardだけで足りるんじゃないの？ と普通思います。
実際ちゃんとしたScrum（顧客側Product Ownerがチームに寄り添ってくれる）ならばScrum boardだけで良いと思います。
しかしここは日本（いや海外だからって理想的なケースばかりだとは思いませんけど）、顧客がオンサイトじゃない場合や、ステークホルダーが入り組んでいるケースも多々あります。また、証跡としてコミュニケーションのログを求められるケースもあります。
そんな場合に、JIRAでQ&Aやリスク一覧、課題一覧も統合しようとするのは自然な流れです。
その場合、それら（総称して「課題」と呼びましょう）の解決サイクルと、タスクの解決サイクルの違いが問題になります。
Scrumでしたら基本的にはスプリントを単位としますが、課題やリスクはスプリント単位でアクションを起こすのが難しいものもあります。
そういうときに、Kanban boardを使います。具体的には、Issue Typeでフィルタ条件を分け
- 課題やリスクやQ&A - Kanban board
- それ以外 - Scrum board
という感じで、使い分けます。
メリット
課題をKanban boardで管理したのは、先の解決サイクルの違いのためでしたが、運用してみると、
- 課題の状況が一発で分かる。例えば回答待ちの課題がいくつ以上になったら催促するといったアクションに結びつけられる
- Cumlative flow diagramやControl chartにより、課題のサイクルタイムや、その健全性が分かる。
- ずーっと居座り続けている課題について、分割して少しでも先に進める機運が出てくる
という利点がありました。課題を全部解消してboardをリリースしてまっさらに戻すという達成感があり、表形式で管理したときには得られない充実感があります。
まとめ
Kanban boardは、leanを採用していない場合でも、課題管理にリズムを付ける道具として利用することができます。
それにより、課題管理が受け身から攻めの姿勢に変わるのが実感できるのでオススメです。