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でチケット駆動開発を実践する~チケットに分割して統治せよ」 »
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント