直近開催のScrum Alliance認定スクラムマスター研修のご案内
カンバンを導入する正しい理由5個
みなさんこんにちは。@ryuzeeです。
前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。
カンバンを導入する正しい理由5個
1. いつでもリリースできるようにする
スクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。
プロダクトオーナーから見るとこれができることは好ましいことだ。 重要なストーリーが実装できた？ よし、じゃあ明日v.2.15.2のバージョンとしてリリースしよう。 このプロダクトを使う顧客はこのリリースの恩恵にすぐあずかることができるだろう。 リードタイムを短くすれば顧客はハッピーになるのだ。
1つ言っておかねばならないことがある。 良い自動化されたテスト群を用意しておく必要がある。 さもないと良い品質でスモールリリースを繰り返すことはできず、問題を起こしてしまうだろう。
2. 自在に優先順位を変えられるようにする
スクラムにおいては、通常スプリントの途中でストーリーを追加することはできない。 途中でストーリーを追加することは簡単ではなく、開発チームはスプリントバックログのストーリーと入れ替えることにしばしば抵抗を示す。 ストーリーは議論され、見積もられている。 新しいストーリーが拙速で議論されもしいくつかの部分に見落としがあると、結果として、重大な再作業が要求されることになってしまう。
一方でカンバンにおいては、もし実装しなければならない緊急な、または本当に重要なユーザーストーリーへの開発要求を受けた場合には、ただキューの先頭にそれを持ってくれば良い。 それは空きスロットができれば直ちに取り掛かられる。 これはまさにプロダクトオーナーの夢だ！
3. イテレーションを無くす
何故イテレーションが必要なんだろうか？ 初期のイテレーションは開発プロセスにおける本当の問題を速やかに明らかにすることの助けになる。 ただ、プロジェクトのリズムやきまりごとが一旦できあがれば、ある時点からはイテレーションは必要ないんじゃないかと思う。
私の考えとしては、最初は繰り返しを行い、その後にフローにするということだ。 我々のバックログは今は曖昧で計画はしばしば変更になる。 我々は一般的にアジャイルではどのようにするのかということ、そしてイテレーションはこのような状況ではまったく役に立たないことを学んでいる。 イテレーションがなければ、イテレーション計画ミーティングもイテレーションのデモンストレーションを行うミーティングも必要がない。 それらはムダなんだ。 その代わりに我々はもっと小さなジャスト・イン・タイムのミーテイングを各ストーリーの開発の前にフィーチャーチームの人たちと行うことになる。 それで完全にうまくいく。
リズムを失ってしまう人もいるかもしれないが、これは習慣なんだ。 カンバンはより複雑なリズムを作り出し、開発チームにとってはそれを認識するまでには時間がかかるだろう。
4. 見積りを無くす
なんで見積りが必要なんだろうか？ 繰り返し型の開発においては次のイテレーションでどれだけのストーリーに対応することができるかを予測するために見積りが必要であった。 そして見積もられたバックログやイテレーションのベロシティによってリリース日も予測したかもしれない。 別の理由としてはプロダクトオーナーがそのストーリーはどのくらいのサイズなのかを知りたがるというのもある。 もしそれが十分に大きかったら、プロダクトオーナーは次のリリースからそのストーリーを外すことを考えるだろう。 もし小さかったらプロダクトオーナーは次のイテレーションにそのストーリーを入れることを決めるだろう。
明らかに繰り返し型の開発においては見積りなしに行うことは困難である。 しかしもしイテレーションをなくせば問題にはならない。 プロダクトオーナーは見積りなしに生きていけるか？ うん、大丈夫だ。 うちの会社ではユーザーストーリーは見積もっていない。 何故していないかって？ なぜなら私がプロダクトオーナーで我々はイテレーションをしていないからだ。 私が尋ねるのはせいぜい荒い規模で、「普通」「大きい」「とっても大きい」くらいのサイズだ。
我々の状況下においては(我々の状況下というのを強調するけど。。)見積りはムダだ。 我々は見積りに時間を使わない。 我々は優先順位付けされたバックログを持っており、最も重要なユーザーストーリーを選択し実装するだけだ。 これはある状況下ではうまくいかないかもしれないが、我々は成熟したプロダクトを持っており、多くの要求は顧客から寄せられる。 初期構築ではないので、リリース日は定められていない。 我々は単にそれが「Ready」になったらリリースするだけだ（多くの企業ではそうはしていないかもしれないが、我々は気に入っている）
5. 完全にフローを可視化する
カンバンボードは現在の作業の進行について非常にクリアに状況を明らかにしてくれる。 カンバンボードはフローを可視化し、素早い計画とトラッキングを可能にしてくれる。 これは本当に素晴らしいツールで我々は大好きだ。
これを踏まえて考えなければならないと思うことを挙げておきましょう。
- スクラムを利用してスプリントの終了までリリースを待った場合に起こる損失はどんなことなのか？それはどのくらいの金銭価値なのか？
- いつでもリリースするとした場合には例えばスクラムでのリリーススプリントの中でやっているようなことはどうするのか？
- イテレーションをなくす理由が初期はプロダクトバックログの優先度が頻繁に変わることだとすると、それは本当にプロダクトオーナーはプロダクトのVision、ROI等を考え切れているのか？
- 見積りをなくした場合、機能の重要度がROIに依存している場合はどうするのか？
- フローを可視化しなければならないのは何故？それはどんなコンテキスト？
なお、スクラムとカンバンの関係については、以下のスライドをよく読むことをお勧めします。 Henrik Kniberg氏が書いたスライドに@haradakiro氏が日本語化を行ったものです。
それでは。
