Redmineを使って気づいたことpart3～チケット分割のタイミング

Redmineを運用して気づいたことを書いてみる。

【元ネタ】
Martin Fowler's Bliki in Japanese - 支払利息の見積もり

PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス）

【1】登録したチケットを分割するタイミングがある。

WBSから初期スケジュールを作成した時、機能追加だけの実装内容のチケットの工数は3人日を見積もったとする。
しかし、実際にチケットを担当した開発者の実績は5人日をオーバーする時がある。

何故遅延しているのか、開発者に聞いてみると、機能追加する前のリファクタリングに時間がかかっている。
理由は、元々のソースはロジックが余りにも入り組んでいるため、リファクタリングしないと機能追加できないから、と言う。

そんな時、僕は、そのチケットからリファクタリングだけの目的の別チケットを新規登録し、リファクタリングは別チケットへ、機能追加は元々のチケットへコミットするように準備する。

そうすると、開発者もリファクタリングに専念できるし、SVNコミットのタイミングがリファクタリングと機能追加の2回に分割できるから、コードレビューしやすい。

チケットの実績工数が膨れ上がっている時、そのチケットはボリュームが大きすぎるのだ。
だから、開発者がプログラミングしやすいような観点でチケットは分割すべき。

この例の場合は、リファクタリングは、M.ファウラーの言う技術的負債に当たる。
元々のソースが綺麗ならば、リファクタリングと言う無駄な作業は不要だったはず。

SW開発では、このような技術的負債を当初見積もることができず、納期間際になって判明してあたふたするリスクをいつも抱えている。

他には、チケットの作業内容が曖昧で、お客様に逐一仕様確認しないと実装できない状況も頻繁にある。
そんな時は、担当者をPGからSEへアサインを変更したりして、質問と回答のやり取りを追跡できるように必ずコメントを履歴で残す。
RedmineのチケットDBに履歴があれば、全文検索できるから、運用保守後に非常に役立つから。

チケット駆動開発は、チケットの進捗具合からそのリスクを嗅ぎ取る。
この経験を元に、初期登録したチケットを積極的に分割するように運用している。

【2】登録したバージョンを分割するタイミングがある。

現在のプロジェクトは、Ver2.0を本番リリースして、Ver3.0に向けて開発中だと仮定しよう。
この場合、Ver2.0のコードラインは保守ブランチ、Ver3.0へのコードラインはtrunkで開発しているだろう。

しかし、お客様から突然、大きな仕様変更がやって来て、今の開発に機能追加して欲しいという要求が来たとする。
その場合、プロジェクトリーダーはどんな判断を下すべきか？

「成功する要求仕様 失敗する要求仕様」に書かれているように、現在の開発はVer3.0でリリースし、仕様変更をVer4.0(もしくはVer3.1)と2回のバージョンに分けて短い間隔でリリースするのが一番リスクが少ないと考える。

こういう状況では、trunkの品質は、ビルドできているが、まだ細かなバグがたくさん残っていて、本番リリースできる品質まで辿り着いていないだろう。
なのに、仕様変更のソースまで混ぜてしまったら、バグの原因が複雑になってしまって、いくらバグを潰しても、もぐら叩きのように品質を歩溜りまで到達させるのは非常に難しい。

「成功する要求仕様 失敗する要求仕様」のやり方は、タスクブランチを作ることだ。
つまり、突然の仕様変更は次の次のバージョンをターゲットとして、その機能追加を実装したコードラインはtrunkから分岐して、タスクブランチを作り、そのコードライン上で実装していく。
当然、trunkからタスクブランチへのマージは頻繁に行い、同期する。
Ver3.0をリリース後、trunkへタスクブランチをマージして、Ver4.0へ向けてバグFixしながら品質を高めていく。

このタスクブランチの開発戦略は非常に難易度が高いけれども、機能を疎結合に分割する設計が巧みならば、成功する確率は高い。

このタスクブランチの手法は、SQLインジェクションやセキュリティパッチなど緊急のバグ修正、バグ調査用のモジュール作成など、意外と頻繁に使う時が多い。

チケット駆動開発は、任意のバージョンにどんな機能やバグ修正を混ぜ込んでリリースするか、という観点でプロジェクトをコントロールできる。
つまり、チケット駆動開発は、trunkとbranchの２つのコードラインで開発するメインラインモデルと密接に関係している。

チケット駆動開発は、当初の見積もりに無かった突発の作業が発生した場合にいかに柔軟に対応するか、という決断と戦略能力が求められる。

チケット管理こそがチケット駆動開発の一番の肝。