チケット駆動開発がもたらした新しい観点part2~トレーサビリティの拡張
Redmine・Trac・Mantisでチケット駆動開発を実践してみて、技術的に一番面白いのは、ツールの連携によるトレーサビリティの強化であり、その拡張だ。
この考え方は「ソフトウェア構成管理とはそもそも何なのか?」という問題に行き着くと思う。
以下ラフなメモ書き。
【1】チケット駆動開発の基本的な運用ルールは「No Ticket, No Commit!」だ。
実際の運用方法は、SVNやGit、Mercurialのコミットログに「refs #チケットNo」「fixes #チケットNo」を付けてcommitすると、自動的にチケットとリビジョンが相互リンクするやり方。
この運用ルールは、障害管理において、障害報告票に基づいてどのようにソースが修正されたのかをレビューしたり検証したり、リリース後に確認できるようにしたい発想から生まれた。
この単純な運用ルールこそが、従来のAgile開発には無かった強力なトレーサビリティによる変更管理を実現してくれる。
つまり、ソフトウェア開発全般の作業において、ソースだけでなく、バージョン管理のリポジトリにある全ての成果物の変更履歴がチケットに記録されることによって、何故こんな汚いパッチが過去に実施されたのか、何故こんな複雑な仕様に行き着いたのか、などの理由を追跡できるようになる。
【2】チケット駆動開発の本来のトレーサビリティは、バージョン管理のリビジョン単位のソースや設計書の変更管理だ。
チケット駆動開発を実践してみて、このトレーサビリティを拡張した考え方は二つある。
一つは、ITSチケットだけでなくITSのプロジェクト、バージョンにもバージョン管理の概念を対応付けること。
もう一つは、CIツールの機能にトレーサビリティの概念を対応付けること。
前者は、下記のWikiに書いた。
RedmineとSCMの機能の関連表~BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索
つまり、ITSチケットとSCMリビジョン、ITSバージョン(マイルストーン)とSCMのタグ(リリースバージョン)、ITSプロジェクトとビルドモジュール(製品)の3種類に対応付けることができる。
ITSのバージョン(マイルストーン)とSCMのタグ(リリースバージョン)を対応付けるだけでなく、アジャイル開発のイテレーション(スプリント)に対応付ければ、自然に小規模リリースを実現できる。
ITSプロジェクトとビルドモジュールを対応付けることは、例えばRedmineの設計思想において、1プロジェクト=1リポジトリであることから必然だ。
この対応関係によって、バージョン管理のリポジトリにある成果物の全ての変更作業は、対応するITSプロジェクトのいずれかのチケットに必ず起票され、記録される。
すなわち、バージョン管理のリポジトリからビルドされてリリースされるモジュール(製品)に関する作業履歴は、対応するITSプロジェクトのいずれかのチケットに必ず記録されている。
だから、製品のリリース履歴がITSのロードマップに自然に対応付けられ、そのロードマップこそが製品の今後の開発の方向性をユーザに提示するものになる。
後者は下記のWikiに書いた。
Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd: プログラマの思索
HudsonやJenkinsには、Redmine・Trac・MantisなどのBTS/ITSと連携するプラグインが提供されているので、それらITSに紐づくバージョン管理のコミットログをCIツールのビルドログと関係付けることができる。
この性質によって、どのビルドモジュールにどんなソースの修正が入っているのか、を確認出来る仕組みができあがる。
つまり、ビルドモジュールのビルドNoからSCMリビジョン、ITSチケットを経由することで本来の要件や仕様まで辿ることができる。
また、HudsonやJenkinsにはSubversion(CVS) Tagging pluginがあり、これを使うと、指定したTagをチェックアウトしてビルドする作業が簡単になる。
すなわち、SCMタグをビルドモジュールのリリースバージョンに厳格に対応付けることが可能なことを意味する。
更に、ビルドモジュールのリリース予定バージョンは、ITSのロードマップに書かれたバージョン(マイルストーン)に一致するように運用すれば、バージョン単位の変更履歴を追跡することが楽になる。
どのバージョンが品質が安定しているのか、どのバージョンで仕様変更されたのか、を追跡するときに役立つだろう。
そして、CIツールのジョブをSCMリポジトリに対応付けるのは当たり前の作業。
これらの対応関係によって、CIツール・SCM・ITSが密接に連携できるようになり、ソフトウェア開発の3種の神器の概念を更に強化してくれる。
【3】トレーサビリティの概念が重要な理由は、変更管理や構成管理を実際に運用する時に使うからだ。
仕様を変更する時にきちんと手続きを経て決めたのか、修正履歴は必ず残されているか、をサポートするためにトレーサビリティが必要。
実際の修正履歴は、ITSチケットとSCMリビジョンの連携によって記録される。
だが変更管理で重要な概念はベースラインだ。
つまり、顧客や会社の上司など全てのステークホルダーが承認した時点の成果物のスナップショットがベースラインとして順次記録されていく。
このベースラインという概念は、Agile開発のイテレーション、システムのリリース済バージョン、SCMタグと同一視できるのがポイントだ。
そのアイデアについては以前書いた。
イテレーションはSW開発で何故重要なのか?: プログラマの思索
チケット駆動開発の本質はバージョン・ファースト: プログラマの思索
悪いウォーターフォル型開発では、工程がベースラインになっているため、手戻り作業が発生するともう一度過去の工程の作業にさかのぼらなくてはならない。
その時、ITSバージョンを工程単位(例:設計・開発・テストなど)に作っていると、過去にリリース済みのバージョンをReOpenして修正する羽目になってしまう。
だから、手戻り作業が発生する度にバージョンをReOpenしてしまい、いつまで経ってもどのバージョンもリリースできなくなる。
そもそもITSバージョンがベースラインと同一視されるならば、過去のベースラインを改ざんすることはシステム監査上ありえないはずだ。
逆にアジャイル開発では、イテレーションが終了したら、リリースしたモジュールの過去の履歴は触らず、次のイテレーションに向けて要件や作業を決めていく。
アジャイル開発ではイテレーションがベースラインに自然に同一視されるから、未来のベースラインに向けて機能改善を積み重ねていく。
これが本来のソフトウェア開発のあり方だと思う。
すると、ソフトウェア構成管理とは一体何なのか?という話になる。
ソフトウェア構成管理は単なるバージョン管理だけでなく、ソースや設計書の修正だけでなく要件や仕様の変更をコントロールする仕組みを提供するものであるはずだ。
そのアイデアについては下記に書いた。
構成管理、変更管理、プロジェクト管理の密接な関係: プログラマの思索
ソフトウェア構成管理の定義はIEEEやCMMIに書かれているけれども、僕には何となくピンとこなかった。
その理由は、変更管理の実装方法がきちんと書かれていないために変更管理をイメージできていなかったからだと思う。
だからこそ、チケット駆動開発で構成管理や変更管理について色々試してみて、ようやく腑に落ちるものがあった。
但し、上記はあくまでも僕が経験した内容に過ぎず、もっと深い意味が隠れているのかもしれない。
色々考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「Redmine」カテゴリの記事
- 第24回redmine.tokyo勉強会の感想 #redmineT(2023.06.03)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「ソフトウェア工学」カテゴリの記事
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- 「ゲームをテストする バグのないゲームを支える知識と手法」の感想(2023.06.10)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
「廃止Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「構成管理・Git」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
コメント