Knibergによる、かんばんを用いたプロジェクト運営の事例紹介。発表スライドは、Henrikのブログから入手できるので、参照してほしい。Dallas実物のかんばんが登場するため、話にリアリティがある。Henrikのトークスタイルは、ライトニングトーク的な忙しさで聴き手を惹きつけているように感じた。party!!Henrikがコーチとしてプロジェクトに参加したとき、プロジェクトメンバーが30人から60人へと増えたところであった。人数が倍になったことで、課題はお互いのコミュニケーションをどのように行うか、そのコーディネートにあった。そこで、Henrikがまず行ったことは、チームの再編成であった。Trenches』より。このプロジェクトは、要求アナリストチームと開発チーム、テストチームに分かれていたようだ。各チームが役割ごとに分かれていると、チーム間のコミュニケーションにかかる負荷が大きくなる。そこで、チームを役割ごとに分けるのではなく、クロスファンクショナルなチームに再編成する。役割間にあった距離は縮まり(要求アナリスト、開発者、テスターでOneチーム)、コミュニケーションに必要な負荷を下げることができる。チーム編成の次に、さらに具体的なプロジェクト全体のコミュニケーションパスをデザインする。partyと呼ばれるプラクティスだった。プロジェクトは、毎朝3パターンのミーティングを行う。各チームごとに朝会を開いた後、チームに参加しているエキスパートがそれぞれの役割別で集まり、ミーティングを行う。要求アナリストは要求アナリストで、開発者は開発者で、テスターはテスターで。それぞれの特定領域について、チームを越えた情報の共有を行う。役割別のミーティングの後で、さらにプロジェクト全体のミーティングを行う。これで、チーム内、特定領域、チーム間のコミュニケーションを補完することができるようになった。partyの名前の由来は、至るところでさまざまな目的でスタンドアップミーティングが開かれており、その間を練り歩く様子からきている。partyでは、かんばんの前に立ってミーティングを行う。このかんばんは、プロジェクトメンバーがそれぞれの役割で必要とする情報を全て管理しており、プロジェクトのバリューストリームそのものになっている。受入テスト状況リリース状況を表す。各状況は、さらに2つのエリアに分かれており、最初のエリアに入れば該当の対応をしていることになり(例えば「開発中」)、対応が完了したらDoneのエリアに移す。Doneのエリアは、同時に次の状況に移ることができる状態、Readyを表すことになる(例えば「開発Done/システムテストReady」)。開発レーンはチームごとに分かれている。Boardとは別に、チームそれぞれのかんばんを持っている。フィーチャーでは開発する単位として大き過ぎるため、フィーチャーを分割するタスクかんばんをチームごとに保有している、という具合だ。Boardがあれば、ボトルネックがどこにあるか非常に分かりやすくなる。この例では、システムテストのレーンが溢れていることが分かる。この状況でいくら実装を進めてもリリースには乗らない。プロジェクト全体のアジリティは、ボトルネック箇所の進捗に制約されている。このときの対応策は、2つ。新しいフィーチャーの開発を止めること。これ以上フィーチャーを増やしても、システムテストフェーズでただ滞留するだけなので、フィードバックまでの時間がかかる一方となり、リスクになりかねない。1つの対応策は、システムテストの自動化であった(※注)。その仕組み化を、開発チームで行う。フィーチャーの開発を止めたため、対応が可能となる。(※注:テストの自動化をするには遅すぎるが、Henrikは、このプロジェクトに最初から居たわけではなく、参加したときには自動化されていなかったということだろう。Story」も同じかんばんの上で管理をしている。バグ管理も、同じかんばんで行う。致命的なバグの場合、付箋を貼ってそれを表し、開発者がすぐに対応を行うようにする。(もちろん、バグに対する対応基準は、各プロジェクトで適宜決めるとよい。)2つのメトリックスを計測することで、実績に基づくプランニングと改善を図ることができる。ベロシティ:1週間あたりに完了したフィーチャーサイクルタイム:1フィーチャーを完了するのに要した時間ベロシティが分かると、リリースプランニングができる。完了した日付(受入テストReady)を記録しておくことで、サイクルタイムを算出することができる。■最後にHenrikのスライドの最後の1枚はこれだった。大切なことは、どのように仕事をするかではない。仕事のやり方をどのように改善するかだ。WowThemes.netFacebookTwitter。