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の2つのコードラインで開発するメインラインモデルと密接に関係している。
チケット駆動開発は、当初の見積もりに無かった突発の作業が発生した場合にいかに柔軟に対応するか、という決断と戦略能力が求められる。
チケット管理こそがチケット駆動開発の一番の肝。
| 固定リンク
« Redmine 0.8.0 release candidate! | トップページ | 【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」 »
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント