セッション:Lean from the Trenches: Managing Large Scale Projects with Kanban & Scrum & XP スピーカー:Henrik Kniberg |
Henrik Knibergによる、かんばんを用いたプロジェクト運営の事例紹介。
この発表のベースは書籍があり、Pragmatic Bookshelf から出ている。また、発表スライドは、Henrikのブログから入手できるので、参照してほしい。
- 書籍:『Lean from the Trenches: Managing Large-Scale Projects with Kanban』
- スライド:Lean from the Trenches @ Agile2012, Dallas
実物のかんばんが登場するため、話にリアリティがある。また、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」 市谷 聡啓
3 Comments
yoh nakamura (@yohhatu) · 2013年8月1日 at 12:19
@daiksy ふと、大人数のスクラムで・・・って話をしていたのを思い出して、朝会などはこんな風にやってるよって事例っぽいのです(Daily cocktail party!!)。 http://t.co/uBGXSBCLCj
@junsumida · 2014年4月24日 at 09:52
[8/14] へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート(17) (via @Pocket) http://t.co/xBmtxhQOD4
Sumida Jun (@junsumida) · 2014年5月17日 at 09:45
[8/14] へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート(17) (via @Pocket) – http://t.co/ilUjq5SiZ6
Comments are closed.