チケット駆動開発は進捗報告作りをどのように解決しようとするか？ - プログラマの思索

【1】管理者は、プロジェクトの進捗報告のためのくだらない作業が必要になる。 まず、初期段階で、WBSとして必要な成果物、作業を洗い出す。 そこから、工数を見積もり、MSProjectやExcelでスケジュールを作っていく。 しかし、実際に作業していくと、そのスケジュールの保守は面倒きわまりない。 当初は分からなかったタスクを追加したり、仕様変更で対応すべきタスクを入れたり、実際は不要になったタスクを削除するなどを、逐一スケジュールへ反映しなければならない。 スケジュールで、先行・後行の関係まで考慮したり、工数の標準化などを行おうとすると、もはやExcelで手作業で管理するのはもはや人間の手を超える。 MSProjectでは、そのような作業をアプリでやってくれるが、だからと言って、スケジュール保守が楽になるわけではない。 そのスケジュールを管理者が常に保守し続けなければならない理由は二つある

[Nagise]

チケットは顧客からの要望の単位と食い違う。進捗報告で用いられる機能の単位とも食い違う。この間をうまく繋ぐ機能が現行のTracやRedmineには欠けていて、それをどう補うかがひとつのポイント。

[ohsuga]

報告用スケジュールとチケット消化の紐付けを行う方法。（別プロジェクトとして立ち上げておき、チケット消化を報告用スケジュールに反映していく）

[oinume]

工数管理とか

[kmachu]

「チケット駆動開発は、進捗報告作りをチケットの自動集計という機能で置き換える。」