はじめに
かんばんプロジェクトについてレクチャーを受けた。学んだことをまとめる。
かんばんを導入することのメリット
- タスクの可視化
- WIPの制限
- 流れをコントロール
かんばん作成時のルール
- 「かんばん」に参加しない人を作らない。
全員に参加してもらう。 - DoingにはWIP(Work in progress)制限を設ける。
- WIPは人数 x 2倍からはじめて、少しづつ減らして行くとよい
可能な限り、終わらせることを優先させる。
次のものが空いている人は、次のものを取りに行く仕組み。 - Doingが外的要因により進行できなくなった場合、上から別の付箋を付けてブロック状態を表示する。
- ブロックされていることを明示させる
- ブロックされてて手が止まっていても、WIP制限に例外を作ったり、制限を緩めたりしない。
- 優先順は、上が高、下が低。
- Todoだけじゃなく、Doingも基本的にこの順に並べる
- Todoには直近のタスクだけを作る。
- いきなり全部作ると大変なので、Todoは全部で２０個に制限するなどルールを作り、なくなったら足して行くなどするのもよい。
- 振り返りで必ず見直す
レーンについて
- 業務に合わせてレーンを作る。
緊急レーンを作るケースもあり、その場合はかならず１個までというルールも併せて導入する。
かんばんで取得すべきメトリックについて
- 以下の日付を記入することで、それぞれのリードタイムを計測出来る。
- Doingに入った際に「開始日」
- Doneに入った際に「完了日」
- デプロイ後に「デプロイ日」
- 上記計測することで、デプロイの数がスループットになる
- スループットを計測することで、リードタイムの平均が取得出来る。
ふせんについて
- 色に意味を持たせる。
- 同じ内容で違う色を使わない。
- 例えば、一般的なタスクを黄色
- CSから上がってくるものはピンク
- ブロックはオレンジ
- 改善・リファクタリングタスクは緑など
- 誰もがわかる見出しをつける。
- 詳細はRedmineやJIRAとかで良い
- フォーマットを決めて書き方の見本を書いて置くと良い。
- 粒度は半日〜１日で終わるくらいが望ましい。
- タスク単位ではなく、ユーザーストーリーに紐づく形が望ましい。
- APIだけ作っても、使うフロントがあって初めてユーザに価値を提供出来る。
- 明確に担当者が決まっているのであれば、担当者を書く
運用上のルール
- DoingからTodoへ基本戻さない。
- 完了させることを優先する。
- 次のものが空いている人は次のものを取りに行く。
- 誰でも取りにいけるように、人依存にさせない。
よくある質問
どのくらいの規模に向いているのか？
- 規模は100人超えても使っている所もあるが、人数・規模の制限はない。
チームが２つにわかれている場合どうするか？
- プロダクトで区切るのか。チームで区切るのかは対象・内容次第。
- 今回は複数のプロダクトをまたいでやるケースがある為、チーム毎の方が良い。
急ぎのバグ対応やCS問い合わせのタスクがある場合は？
- 緊急レーンで対応するチームもある。
- ただし１個だけといった絶対的なルールを作る。
アナログとデジタルの共存について
- リアルでは「ふせん」、デジタルではJIRAやredmineを使うとなると、２重管理になってしまう。
しかし、それは仕方がないと割り切る。
それぞれの特性を生かして使う
アナログの方は状況の把握・見える化と優先順の調整のみ。
細かい管理はデジタル（redmineやJIRA）で行う。