カンバン

2015-06-302016-11-17マネージメント

この記事は最終更新日から1年以上が経過しています。

自分のチーム向けにカンバン方式をまとめます。
カンバン方式を採用する上で重要な点は下記3点。

ワークフローの見える化(Visualize the workflow)
WIPの制限(Limits WIP)
リードタイムの測定と最適化(Measure and optimize lead time)

1.ワークフローの見える化(Visualize the workflow)

一点目、ワークフローを見えるようにしなければなりません。
タスクボードの左から順にタスクが流れるようにするやり方が一般的です。
現在弊チームでは

Icebox
Backlog
Selected
Doing
Done

と5つのステータスで管理しています。
他にも拡張の必要があれば下記のようなステータスを
タスクの性質によって追加することもあります。

■プロダクトバックログ(what)

Icebox
Selected
On Going
Review
Done

■スプリントバックログ(how)

Todo
Ready
Chore
Pending
Wait
Calendar
In Progress
Done

■ストーリーの種類

feature
chore
bug
release

■パネル

current
backlog
icebox
epic
done

2.WIPの制限(Limits WIP)

二点目。Work In Progressの制限です。
タスクを並行に動かすことは非効率であるため、
一度にできる量を抑えて流量をコントロールします。
一般的には人数＊2～3つのタスクがDoingに入るよう調節します。

3.リードタイムの測定と最適化(Measure and optimize lead time)

三点目。スループットを計測することによって生産性を計測し最適化します。
タスク投入のルールとして、ポイントを付与しています。
ポイントの算出方法は1ポイントが最小の複雑さをもつタスクで
2ポイントは1ポイントに比べて2倍の複雑さを持っているということになります。
最小のポイントは人数の増加や習熟度によって常に変化します。
ポイントの区切りは一般的なプランニングポーカー的フィボナッチ数列(1,2,3,5,8,13,20～)を採用しています。

弊チームでは1ポイントが軽いHTMLの修正～更新で
13ポイントがモデルの修正～改修といった感じです。
ベロシティとしては一週間に一人100ポイントを消化できる見積もりです。

また、我々がカンバン方式を始めるにあたってscrumblrを採用しました。
http://scrumblr.ca/
https://github.com/aliasaria/scrumblr
採用の決め手になったのは「自由度」です。
他にもtrelloやpivotaltrackerやasanaなどを比較検討しましたが
規模感との兼ね合いで不採用としました。

この記事を書いた人

鈴木juke / footworker: 和服とvapeとСистемаと醗酵とたまごふわふわとカッティングシェイプスとジャージークラブとjuke/fwkに傾倒する人です

最近書いた記事

2015-06-302016-11-17マネージメント

タスクの処理方法あれこれ