テストの役割（進捗管理その２）

Alistair Cockburn は、ソフトウェア開発の「1個流し」(*1)と進捗管理について、おもしろい例を出している。次の問題を考えてみて欲しい。

３０個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、１ヵ月というデッドラインを守れるか。 


ウォーターフォール的計画： 
１．最初の1週間で全部屋の掃除を行なう
２．次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や備品に貼る
３．次の1週間で全部屋のダンボール箱詰めを行なう
４．次の1週間で全部屋のチェックを行なう
５．４週間あるので、４週間後には全部屋のチェックまで終わる 

1個流し的（アジャイル的）計画： 
１．日割りで、１日に１つの部屋を、掃除、分類、箱詰め、チェックまで終える 
２．３０日あるので、３０日後には全３０部屋の箱詰めが終わる

さて、上記２つの方法で進捗を管理した場合、どちらが確実に遅れを察知でき、対策を取りやすいだろうか。 

ウォーターフォール的計画での見積もりは根拠が難しい。また、分類は実はすぐに終わるが、箱詰めに思ったより時間が掛かることが分かった場合、その知識を活かすことができない。分かったときには時既に遅しだ。

これに対して、「1個流し」は進捗をリニアに管理できる。そして、この1個流し戦略をビジュアルにマネジメントするツールが「バーンダウンチャート」だ。３０個が一個ずつ減っていく計画をたて、それを日々追っていく。以下の写真は、バーンダウンチャートの例。１イテレーションの中で完成させるべきソフトウェアの要求を縦軸にとっている。青が予定線、赤が実績線だ。

前回の繰り返しになるが、「テストで進捗を測る」のだ。テストの終了に到達していないものは「在庫」と考える。在庫状態にある成果物を減らし、バリューストリーム（価値の流れ）の速度を上げる。

(*1)「1個流し」は、トヨタ生産方式用語。ソフトウェアに対応づけると、ウォーターフォール式にすべての要求を１度にまとめて分析・設計・実装・テストと工程を進めるのではなく、要求を小さな単位で１つずつ、分析からテストまで流すこと。

さて、次の問題は、このメタファーと実際のソフトウェア開発の違いだ。各部屋はほぼ独立して箱詰めできる。しかし、ソフトウェアの機能は、「依存関係」を持っている。さあ、どうする？（つづく…予告：良い「ストーリー」とは、I-N-V-E-S-Tを高める） 

※写真提供＞Thanks かくさん

以下のトラックバックに、製造業の一個流しの例あり。参考になりました。

http://www.isisaka.com/blog/archives/2005/08/1_2.aspx