[8/14] へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート(17)

セッション:Lean from the Trenches: Managing Large Scale Projects with Kanban & Scrum & XP

スピーカー:Henrik Kniberg

Henrik Knibergによる、かんばんを用いたプロジェクト運営の事例紹介。
この発表のベースは書籍があり、Pragmatic Bookshelf から出ている。また、発表スライドは、Henrikのブログから入手できるので、参照してほしい。

実物のかんばんが登場するため、話にリアリティがある。また、Henrikのトークスタイルは、ライトニングトーク的な忙しさで聴き手を惹きつけているように感じた。

 

■Daily cocktail party!!

Henrikがコーチとしてプロジェクトに参加したとき、プロジェクトメンバーが30人から60人へと増えたところであった。人数が倍になったことで、課題はお互いのコミュニケーションをどのように行うか、そのコーディネートにあった。

そこで、Henrikがまず行ったことは、チームの再編成であった。


発表スライド『Lean from the Trenches』より。以下同じ。

このプロジェクトは、要求アナリストチームと開発チーム、テストチームに分かれていたようだ。各チームが役割ごとに分かれていると、チーム間のコミュニケーションにかかる負荷が大きくなる。


そこで、チームを役割ごとに分けるのではなく、クロスファンクショナルなチームに再編成する。役割間にあった距離は縮まり(要求アナリスト、開発者、テスターでOneチーム)、コミュニケーションに必要な負荷を下げることができる。

チーム編成の次に、さらに具体的なプロジェクト全体のコミュニケーションパスをデザインする。
紹介されたのは、Daily cocktail partyと呼ばれるプラクティスだった。

プロジェクトは、毎朝3パターンのミーティングを行う。

各チームごとに朝会を開いた後、チームに参加しているエキスパートがそれぞれの役割別で集まり、ミーティングを行う。要求アナリストは要求アナリストで、開発者は開発者で、テスターはテスターで。それぞれの特定領域について、チームを越えた情報の共有を行う。役割別のミーティングの後で、さらにプロジェクト全体のミーティングを行う。
これで、チーム内、特定領域、チーム間のコミュニケーションを補完することができるようになった。

なお、Daily cocktail partyの名前の由来は、至るところでさまざまな目的でスタンドアップミーティングが開かれており、その間を練り歩く様子からきている。

 

■さいきょうのかんばん

Daily cocktail partyでは、かんばんの前に立ってミーティングを行う。プロジェクト全体の状況が一望できるかんばん、Project Boardだ。


このかんばんは、プロジェクトメンバーがそれぞれの役割で必要とする情報を全て管理しており、プロジェクトのバリューストリームそのものになっている。

左のレーンから、

  • アイデア(エピックレベルのフィーチャー)
  • フィーチャー(プロダクトバックログ)
  • 次に実装したい10のフィーチャー
  • 開発状況
  • システムテスト状況
  • 受入テスト状況
  • リリース状況

を表す。

各状況は、さらに2つのエリアに分かれており、最初のエリアに入れば該当の対応をしていることになり(例えば「開発中」)、対応が完了したらDoneのエリアに移す。Doneのエリアは、同時に次の状況に移ることができる状態、Readyを表すことになる(例えば「開発Done/システムテストReady」)。

また、開発レーンはチームごとに分かれている。各チームはProject Boardとは別に、チームそれぞれのかんばんを持っている。フィーチャーでは開発する単位として大き過ぎるため、フィーチャーを分割するタスクかんばんをチームごとに保有している、という具合だ。

Project Boardがあれば、ボトルネックがどこにあるか非常に分かりやすくなる。

この例では、システムテストのレーンが溢れていることが分かる。この状況でいくら実装を進めてもリリースには乗らない。プロジェクト全体のアジリティは、ボトルネック箇所の進捗に制約されている。

このときの対応策は、2つ。

まず、新しいフィーチャーの開発を止めること。これ以上フィーチャーを増やしても、システムテストフェーズでただ滞留するだけなので、フィードバックまでの時間がかかる一方となり、リスクになりかねない。

もう1つの対応策は、システムテストの自動化であった(※注)。その仕組み化を、開発チームで行う。フィーチャーの開発を止めたため、対応が可能となる。

(※注:テストの自動化をするには遅すぎるが、Henrikは、このプロジェクトに最初から居たわけではなく、参加したときには自動化されていなかったということだろう。)

なお、このようなフィーチャーではないが、プロジェクトのためにやらなければならない「Tech Story」も同じかんばんの上で管理をしている。

バグ管理も、同じかんばんで行う。

致命的なバグの場合、付箋を貼ってそれを表し、開発者がすぐに対応を行うようにする。(もちろん、バグに対する対応基準は、各プロジェクトで適宜決めるとよい。)

2つのメトリックスを計測することで、実績に基づくプランニングと改善を図ることができる。

  • ベロシティ:1週間あたりに完了したフィーチャー
  • サイクルタイム:1フィーチャーを完了するのに要した時間

ベロシティが分かると、リリースプランニングができる。

フィーチャーごとに、着手(「次に実装したい10のフィーチャー」から選ばれたとき) と、完了した日付(受入テストReady)を記録しておくことで、サイクルタイムを算出することができる。

 

■最後に

Henrikのスライドの最後の1枚はこれだった。

大切なことは、どのように仕事をするかではない。
仕事のやり方をどのように改善するかだ。


Agile2012現地レポーター隊「アジャイルクローバーZ市谷 聡啓

このエントリーをはてなブックマークに追加

[8/14] へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート(17)」への3件のフィードバック

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です