対応完了予定日はイテレーションである
チケットに対応完了予定日を入れたい要望を受けたが、対応完了予定日はRedmineの対象バージョンで代用できます、と返答した。
その理由について考えたことをメモ。
【1】システムの運用保守では、既にシステムが稼動しており、本番障害や改善要望の対応で追いまくられる。
これらタスクをRedmineでチケット化すると、状況の変化をチケットで追跡できるので、見通しが良くなる利点がある。
だが、チケットに対応完了予定日(または対応期限)を入れたい要望を受けた。
その理由は、チケットの開始日・期日は作業実績であり、作業予定も別途入れたいから。
つまり、顧客の改善要望に対応する期限ないし対応完了予定日をチケットの属性として別途保持し、作業の優先順位付けに使いたいらしい。
【2】でも、僕は対応完了予定日はRedmineの対象バージョンで代用できると思っている。
なぜなら、対応完了予定日は、将来の本番リリース日だからだ。
つまり、それはイテレーションやリリースタグに同一視できる。
実際、チケットに対応開始予定日を入れたい要望はない。
なぜなら、作業の開始予定日はどうでもよく、作業の期限こそが重要で、その期限に遅れると、顧客の業務に支障が出るからだ。
【3】Redmineの対象バージョンには、期限日しか設定できないようになっている。
Redmineの使い方が分からない人は、なぜ対象バージョンに開始日が無いのか、不自然に感じるようだが、対象バージョンは本番リリース日そのものである性質からして、期限しか設定できないのはとても自然だ。
対応完了予定日を対象バージョン、つまりイテレーションに同一視すると、本番リリース日が同じチケットは全て、その日に一括リリースされる。
すなわち、対応完了予定日が同一のチケット群、つまり、そのチケットに基づいて修正されたソースや成果物は、リリース予定バージョンとしてタグ付けされる。
そして、構成管理の配下にある成果物を対応完了予定日ごとにスナップショット(構成管理ツールの特定のリビジョン)が残り、履歴が積み重なっていく。
チケット駆動開発では、ITSチケットとSCMリビジョンは必ず紐づいているので、成果物の変更履歴を追跡しやすくなる利点がある。
その利点のおかげで、過去のパッチの理由調査や、仕様変更における影響調査がやりやすくなる。
特に結合テストや受入テストのようなテスト工程でのバグ管理、本番システム稼働中の運用保守では、No Ticket, No Commitの運用ルールは重要な意味を持つ。
変更理由があいまいな修正ソースをコミットしてデグレしたり、正当な理由のない修正モジュールをリリースして障害を起こす危険があるからだ。
チケットの由来である障害管理票には、対応完了予定日の属性も含む時があるが、リリース予定バージョンに同一視すれば、多分その属性は不要だ。
実際、Mantisのチケットに対応完了予定日の属性はない。
チケットの他の属性として、解決状況や重要度、優先度などがあるが、それらについては下記で考察した。
チケットのそれら属性の歴史や必要性をたどると、チケットとはそもそも何なのか?ということが分かってくるような気がする。
BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索
障害管理における重要度と優先度の使い分け: プログラマの思索
【4】チケット駆動開発の発端である障害管理は、ソフトウェア開発の基本プロセス。
どの開発チームであれ、障害管理プロセスを観察すれば、そのチームの習熟度が分かる。
駄目なチームほど、バグ修正のスピードが遅く、どんどんバグを溜め込んでデスマーチに陥るパターンがとても多い。
障害管理には、ソフトウェア開発がなぜ難しいのか、という問題の本質が隠れているような気がしている。
| 固定リンク
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント