対応完了予定日はイテレーションである

チケットに対応完了予定日を入れたい要望を受けたが、対応完了予定日はRedmineの対象バージョンで代用できます、と返答した。
その理由について考えたことをメモ。

【1】システムの運用保守では、既にシステムが稼動しており、本番障害や改善要望の対応で追いまくられる。
これらタスクをRedmineでチケット化すると、状況の変化をチケットで追跡できるので、見通しが良くなる利点がある。

だが、チケットに対応完了予定日(または対応期限)を入れたい要望を受けた。
その理由は、チケットの開始日・期日は作業実績であり、作業予定も別途入れたいから。
つまり、顧客の改善要望に対応する期限ないし対応完了予定日をチケットの属性として別途保持し、作業の優先順位付けに使いたいらしい。

【2】でも、僕は対応完了予定日はRedmineの対象バージョンで代用できると思っている。
なぜなら、対応完了予定日は、将来の本番リリース日だからだ。
つまり、それはイテレーションやリリースタグに同一視できる。

実際、チケットに対応開始予定日を入れたい要望はない。
なぜなら、作業の開始予定日はどうでもよく、作業の期限こそが重要で、その期限に遅れると、顧客の業務に支障が出るからだ。

【3】Redmineの対象バージョンには、期限日しか設定できないようになっている。
Redmineの使い方が分からない人は、なぜ対象バージョンに開始日が無いのか、不自然に感じるようだが、対象バージョンは本番リリース日そのものである性質からして、期限しか設定できないのはとても自然だ。

対応完了予定日を対象バージョン、つまりイテレーションに同一視すると、本番リリース日が同じチケットは全て、その日に一括リリースされる。
すなわち、対応完了予定日が同一のチケット群、つまり、そのチケットに基づいて修正されたソースや成果物は、リリース予定バージョンとしてタグ付けされる。
そして、構成管理の配下にある成果物を対応完了予定日ごとにスナップショット(構成管理ツールの特定のリビジョン)が残り、履歴が積み重なっていく。

チケット駆動開発では、ITSチケットとSCMリビジョンは必ず紐づいているので、成果物の変更履歴を追跡しやすくなる利点がある。
その利点のおかげで、過去のパッチの理由調査や、仕様変更における影響調査がやりやすくなる。
特に結合テストや受入テストのようなテスト工程でのバグ管理、本番システム稼働中の運用保守では、No Ticket, No Commitの運用ルールは重要な意味を持つ。
変更理由があいまいな修正ソースをコミットしてデグレしたり、正当な理由のない修正モジュールをリリースして障害を起こす危険があるからだ。

チケットの由来である障害管理票には、対応完了予定日の属性も含む時があるが、リリース予定バージョンに同一視すれば、多分その属性は不要だ。
実際、Mantisのチケットに対応完了予定日の属性はない。

チケットの他の属性として、解決状況や重要度、優先度などがあるが、それらについては下記で考察した。
チケットのそれら属性の歴史や必要性をたどると、チケットとはそもそも何なのか？ということが分かってくるような気がする。

BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索

障害管理における重要度と優先度の使い分け: プログラマの思索

【4】チケット駆動開発の発端である障害管理は、ソフトウェア開発の基本プロセス。
どの開発チームであれ、障害管理プロセスを観察すれば、そのチームの習熟度が分かる。
駄目なチームほど、バグ修正のスピードが遅く、どんどんバグを溜め込んでデスマーチに陥るパターンがとても多い。

障害記録票と問合せ管理簿の2重管理問題: プログラマの思索

障害管理の泥沼から脱出するには: プログラマの思索

障害管理には、ソフトウェア開発がなぜ難しいのか、という問題の本質が隠れているような気がしている。