アジャイル開発者の習慣－acts_as_agile

第3回　スケール間に連続性を築く

初出：WEB+DB PRESS Vol.41（2007年10月24日発売）

アジャイル開発

この記事を読むのに必要な時間：およそ 5 分

プラクティス「スケール単位でのバーンダウンチャート」

バーンダウンチャートは，プロジェクトの進行状況を把握するための2次元のチャートです。横軸に時間，縦軸に残作業量をプロットします（図3⁠）⁠。

図3　デイリーバーンダウンチャート

図3　デイリーバーンダウンチャート

バーンダウンチャートは「これまでにどれだけ作業をしたか」ではなく「タイムボックス満了までにあとどれだけ作業が残っているか」を把握することを徹底します。

バーンダウンチャートはスケールごとに作成します。今回はよく作成される例として，イテレーションバーンダウンチャートとデイリーバーンダウンチャートを紹介します。

イテレーションバーンダウンチャート

イテレーションバーンダウンチャートは，リリースのレベルで作成します。チャートの時間軸の単位はイテレーション，残作業量の単位にはストーリポイントや，受け入れテストの残りケース数を使います。

チャートはイテレーションの完了のタイミングで更新します。チャートの更新はイテレーションのふりかえりの前に済ませておきます。

イテレーションバーンダウンチャートは，マネージャや顧客側の取締役などの利害関係者に，プロジェクトの進行状況の概要を示すのにも使えます。

デイリーバーンダウンチャート

デイリーバーンダウンチャートは，イテレーションのレベルで作成します。時間軸の単位はイテレーションの稼動日，残作業量の単位はタスクポイントです。更新頻度は1日1回で，1日の作業終了時（たとえば前回の連載で紹介した夕会）に更新します。

今回のまとめ

今回の内容を，前回までのまとめを拡張して図4にまとめました。

図4　今回のまとめ

図4　今回のまとめ

アジャイル開発では，ほかにも複数スケールの自己相似構造を見いだせます。今回は紹介できませんでしたが，テストコードを構造化する技法や，連載の第1回で紹介した「まずは自分，それからチーム」といった考え方にも自己相似性を見いだせます。アジャイル開発者として振る舞えばさまざまな自己相似構造を発見できるはずです。

それでは，また次回お目にかかりましょう。acts_as_agile!

コラム1　見積りは作業量の相対サイズで

ストーリやタスクの見積りは「X日かかります」や「m月d日までにできます」といった所要時間ベースではなく，可能であれば「ポイント」のような抽象的な単位を用いて，過去に取り組んだストーリやタスクとの相対的なサイズで行うことが望ましいです。こうした作業量の単位を「ストーリポイント」「⁠タスクポイント」と呼びます。

たとえば「このタスクは以前にやった2ポイントの○○というタスクの2倍の作業量だから4ポイント」といったようにです。所要時間は，過去の実績から割り出される導出項目です。

この場合，初回はどうすればよいでしょうか。結論だけ言えば「鼻をつまんでエイヤ！」で決めるしかありません。初回は誤差も大きいので，フィードバックを早く得るためにタイムボックスを短めにします。たとえば，イテレーションのサイズを基本は1週間（5稼動日）と決めていても，初回に限ってはこれをさらに2日と3日に分割して実施するといったようにです。

アジャイル開発における見積りと計画づくりの詳細は洋書『Agile Estimating and Planning』（⁠注）を参照してください。

注）
『Agile Estimating and Planning』（⁠Mike Cohn（著⁠）⁠，Prentice Hall）

アジャイル開発

著者プロフィール

角谷信太郎（かくたにしんたろう）

（株）永和システムマネジメント，サービスプロバイディング事業部所属プログラマ。「『楽しさ』がシステム開発の生産性を左右する」と信じてRubyによるアジャイル開発を現場で実践するテスト駆動開発者。目標は達人プログラマ。好きな言語はRuby。好きなメソッドはextend。著書に『アジャイルな見積りと計画づくり』（共同翻訳），『JavaからRubyへ』（翻訳），『アジャイルプラクティス』(共同監訳)，『インターフェイス指向設計』（監訳）。

URL：http://kakutani.com/

著書