チケット駆動開発は進捗報告作りをどのように解決しようとするか？

【1】管理者は、プロジェクトの進捗報告のためのくだらない作業が必要になる。

まず、初期段階で、WBSとして必要な成果物、作業を洗い出す。
そこから、工数を見積もり、MSProjectやExcelでスケジュールを作っていく。

しかし、実際に作業していくと、そのスケジュールの保守は面倒きわまりない。
当初は分からなかったタスクを追加したり、仕様変更で対応すべきタスクを入れたり、実際は不要になったタスクを削除するなどを、逐一スケジュールへ反映しなければならない。

スケジュールで、先行・後行の関係まで考慮したり、工数の標準化などを行おうとすると、もはやExcelで手作業で管理するのはもはや人間の手を超える。
MSProjectでは、そのような作業をアプリでやってくれるが、だからと言って、スケジュール保守が楽になるわけではない。

そのスケジュールを管理者が常に保守し続けなければならない理由は二つあると思う。
一つは、顧客や上層部へ進捗を報告する元ネタになるから。
もう一つは、プロジェクトのリスクがスケジュールでしか見えないから。

前者の作業は、保守されたスケジュールにあるWBSを、顧客向けの観点で集計し直す。

週次報告のために、毎週、その集計用のExcelを作る時も多い。
その場合、機能単位で、ステータス(未着手・作成中・レビュー中・テスト中・完了)ごとのクロス集計を作り、先週・今週の実績・来週の予定を作ることが多いだろう。

更に、ステータス(作成中・レビュー中・テスト中)ごとのスケジュールを作り、別のExcelで管理する時も多い。
何故なら、レビューのスケジュール、テストのスケジュールも別途必要だからだ。

すると、一つの作業のステータスを確定するために、作成中・レビュー中・テスト中の3つ全てのスケジュールを開かないと分からない。

駄目な管理者は、作業のステータスを管理するためのファイルをあちこちに分散して作ってしまったり、忙しくなるとそのファイルさえも保守しなくなる。
結局、プロジェクトの現状を的確に現す資料がなくなる。

デスマーチ・プロジェクトは特にこのような状況になりがち。
火消し役で入った現場リーダーは、まず現状の作業の棚卸しから始めることが多い。
それは即ち、全ての残タスクの洗い出しと現状の作業のステータスを確認すること。

いかに、スケジュール保守が難しいか、という観点を示していると思う。

後者は、タスクの遅延や、開発速度の変化、開発者ごとの生産性の変化などから、今後大きな問題に発展しそうな現象を確定し、現場リーダーが判断する必要がある。

しかし、上記のように、プロジェクトの現状をリアルタイムに把握できる資料がなければ難しい。
その資料は、ステータスごとの進捗の集計や要件ごとの進捗の集計だったりする。

それらは、元ネタとなるスケジュールから、それらの観点で集計する。
だから、元ネタとなるスケジュールが毎日の作業進捗をリアルタイムに反映して精度が高くなければ、集計結果の数値も当てにならない。

【2】チケット駆動開発を運用してみて気付いたことは、進捗報告は手作業で集計してExcelに綺麗にまとめる必要は無いこと。
進捗報告はチケットのステータスを自動集計してくれるインフラがあるから。

例えば、Redmineでは、開発者が自分担当のチケットを1日の終わりに更新すれば、サマリ欄で集計結果を見ることができる。
更には、工数レポート画面で、バージョンと月別のクロス集計で実績工数を表示できる。

例：
SKIP - サマリ - Redmine

Ruby 1.9 - サマリ Ruby Issue Tracking System

つまり、チケットを自動集計するインフラがあるから、チケットへ毎日の作業状態を入力する運用が徹底できれば、プロジェクトの現状をリアルタイムに把握できる。
Redmineのサマリはバージョン・トラッカー(ワークフロー)・カテゴリ(機能)の単位でステータスごとに集計してくれるので、そこからリスクを嗅ぎ取り、リスク対策を取ることができる。

【3】しかしながら、顧客向けの進捗報告は、Redmineサマリをそのまま出すことはできない。
理由は、チケットがタスクカードの観点で作られているから。

つまり、チケットは、アウトプットを作るための作業を管理するために作られているから。
一つの機能をリリースするまでに、複数のチケットが必要。
顧客向けの進捗報告は、ストーリーカードの観点で作成すべきなのだ。

TracやRedmineでプロジェクト管理を始めると、進捗管理がやりにくいという話が出る。
話を聞くと、顧客向けの進捗管理と開発チーム内部の進捗管理を分けているかららしい。
どうやら、MSProjectで顧客向けスケジュールを作っているが、そのスケジュールとRedmine/Tracのスケジュール管理の間で同期を取りにくいようだ。

僕としては、MSProjectとTrac/Redmineで進捗管理の視点が異なるのは、下記の理由で当たり前だと考える。

3-1・管理者(PL)の視点
→ストーリーカード
→フィーチャー(機能)、工程、WBS
→MSProject

3-2・開発者(PG)の視点
→タスクカード
→成果物に対する作業
→Trac/Redmine

チケット駆動開発は、あくまでも開発者のタスク管理をサポートする。
開発者が作業する成果物(タスクカード)の進捗がチームの実質の進捗でもあるから、プロジェクトリーダーにとっては非常に重要と考える。

理由は、ストーリーカードの進捗は、個々のタスクカードの進捗の合計ゆえ、顧客向けの進捗報告の元ネタは、タスクカードの進捗管理にあるべきだから。

現状では、Redmineのデフォルト機能には、ストーリーカードを表現する機能はないが、ストーリーカードを同様にチケットとして扱うことはできる。

この時、ストーリーカードをチケットで表現した場合、ストーリーカードとタスクカードには下記の制約が少なくとも発生する。

3-3・ストーリーカードの開始・終了日は、タスクカードの開始・終了日のUnionである。
3-4・ストーリーカードのステータスは、タスクカードのステータスの共通集合である。
3-5・ストーリーカードの工数は、タスクカードの工数の合計である

これらをTrac/Redmine上で表現できれば良い。
つまり、1つの機能という実体をストーリーカードとタスクカードの別々の観点で進捗管理できればよい。

【4】今僕がRedmineの運用で現実的と考えるやり方は下記の通り。

4-1・ストーリーカード(顧客向け)とタスクカード(開発チーム向け)の2個のプロジェクトを作る。
4-2・ストーリーカードには、顧客向けに報告する単位の機能をチケットへ登録する。
4-3・タスクカードには、開発者が作業する単位、あるいは成果物単位でチケットへ登録する。
↓
4-4・タスクカードの属性に、タスクの発生源であるストーリーカードのチケット情報を登録しておく。
　ストーリーカードには、派生したタスクカードのチケット情報を関連づけておく。
4-5・タスクカードが更新されるたびに、発生源であるストーリーカードの実績工数・ステータスなどが更新される。
↓
4-6・顧客向けの進捗報告は、ストーリーカードのRedmineサマリから集計する。

ストーリーカードとタスクカードで別々に管理するのは、観点が違うから。
Redmineではプロジェクトの親子関係やプロジェクトをまたがるチケットの関係を簡単に設定できるので、特に問題無い。

【5】だが、ストーリーカードとタスクカードの関係については、さかばさんの指摘もあるが、いくつかの疑問点が残る。

5-1・複数のイテレーションをまたがるストーリーカードはあるのか？

→ストーリーが一つのイテレーションで実装できない場合、そのイテレーションはリリース可能なのか？
イテレーションはリリースできる単位と定義すると、ストーリーカードはイテレーション期間で実現できるサイズまで分割する必要があるだろう。

5-2・ストーリーカードにビルド環境構築のような非機能要求は入るのか？

→顧客から見ると、ビルド環境構築のような開発内部の作業は価値がない。
　顧客が知りたいのは、機能(要求仕様)の進捗だから。

ストーリーカードは顧客価値を表す。
顧客向けの進捗報告はストーリーカードの集計結果になるように、ストーリーカードのチケットを作るべきと考える。

しかし、このやり方では、ストーリーカードに含まれないタスクカードが存在できてしまうため、顧客向けの進捗報告にある実績工数と、開発チーム内部で把握する実績工数に狂いが出てくる。

おそらく、「その他」「内部課題」のような特殊なストーリーカードでビルド環境構築のようなタスクカードを管理するなどして、ストーリーカードとタスクカードが必ずリンクする方法の方が運用しやすいだろうと考える。

チケット駆動開発は、進捗報告作りをチケットの自動集計という機能で置き換える。
その意義はとてつもなく大きいと思う。