チームのスプリントをAsanaで毎回作っているのだけど、いくつか気に入らないことがある。
ひとつが運用の難しさ。Asana自体には「次のスプリント」という概念がないので、前のプロジェクトを複製するけどタスクは引き継がず、手作業で次のプロジェクトにタスクを持ち運んでいた。
ふたつめが数値を取りにくいということ。スプリントで切れるのは区切りが良いけど、本当のスクラムでいうインクリメントがユーザーのもとに出荷されるという区切りとは紐づいておらず、なんちゃってスクラムと呼ばれているような状況。そうなると、ただ2週間ごとに世界を作り直しているだけで、継続的な数値や、流れを追いにくい。毎回のベロシティはSpreadsheetに手でコピーしてグラフにしていた。
2週間毎の作り直しをやめて、1プロジェクトでやりませんかという話をした。概念的にはスプリントプロジェクトにはToDoとかDoingとかDoneとかがあるのだけど、それをずっとやるということはカンバンに近づいていく。
本気でカンバンをやったことってないなと思って本を読んでおいた。
www.oreilly.co.jp
カンバンはメタフレームワークで、「カンバンをやる」ということはできない。
カンバンをどう運用し、どう改善するかはチームに委ねられている。
カンバンにすればスクラムイベントをなくせるとか、計画不要になる、ということはなく、タイムボックスを設けて計画する考え方もあれば、タスクが足りなくなったら計画するという考え方も紹介されていた。
おもしろかったのが、Doneが15個たまったらケーキを買ってもらう、みたいなセレモニーと組み合わせたアイデアも紹介されていた。
ひとつ気づきがあったのが、個別の開発チケットではなくて、同時に扱うユーザーストーリーとして考えたほうがうまくいきそう、ということ。章でいうと6.6.1に書かれている。
チームが作業項目をタスクに分割しているのをよく目にする。（中略)
タスクは作業項目の一部であり、列のなかで作業項目を完了させるのに必要なものであると考えることができる。(略)
多くのチームが、作業項目の数にWIP 制限をかけている。タスクの役割は作業項目を完了するために何をするかを記録するだけであり、それ自体は顧客の価値にならない。タスクがボード上で速く流れたところで、顧客の待ち時間が変わらないなら、まるで意味がないのである。
この本でいう作業項目とタスクは、スクラムでいうとプロダクトバックログとスプリントバックログに相当するものとして理解した。
プロダクトバックログ（銀行にスマホログイン機能をつけたい）に対して、スプリントバックログ（ログインページのView作成）が多数作られるというもの。
いま、チーム内の仕事が大量のタスクリストになっていて、スプリント内で終わらなかったものは持ち越しを続けていてステータスがよくわからなくなっている、という側面があるので、並行して進めているどのプロジェクトがどのフェーズにいるかは一度落ち着いて可視化してみたいと思う。
