改訂 Trac 入門も無事発売になったことですし、不定期に Trac ネタを書いていきたいと思います。
今回は、イテレーティブ(繰り返し型)開発におけるイテレーションの扱いについて。
業務アプリ開発でも 1-2 週間という短めのサイクルでタイムボックスを区切るイテレーション(Scrum だと スプリント) を導入している現場はけっこうあるのではないでしょうか。イテレーション終わりに最終顧客に対する出荷を行わないまでも、チームの生産性や品質を短いスパンで見直し改善策を講じたりできるというメリットがあります。
ところで Trac でイテレーションを扱う時ってマイルストーンで管理するでしょうか？
1チームですべての開発が完結している場合は、マイルストーンでもよいと思います。ですが、ある程度の規模のプロジェクトで複数チーム連携して開発を進める場合、チームのイテレーションとプロジェクトのマイルストーンは分けて考えた方がよいでしょう。
例えば、フレームワークや共通部品を提供するチームが先行して組織されてアプリ構築の基盤を構築し、その後アプリチームがイテレーションを開始して個別の業務アプリを構築するような場合、各チームの成果物を結合してテストやユーザー受け入れ試験に向けて出荷していくことになります。
各チームは作っているものこそ違えど、プロジェクトで設定されたイベントに向けてコードを書きテストを重ねて行きます。チームのイテレーションはタイムボックスであり、プロジェクトのマイルストーンと違ってチームの裁量が効くものです。開発対象の機能は他のチームの計画にも影響しますのでプロジェクトで決定された期日には間に合わせる必要がありますが、どのイテレーションで作業するかということは各チームの事情で決められるケースが多いはずです。
ですのでプロジェクトのマイルストーンをマイルストーンで扱い、イテレーションは専用のカスタムフィールドで扱うとプロジェクト全体の観点とチーム都合の観点に分離してスコープの管理ができるのです。
