Redmineによるチケット駆動開発はパッチ駆動開発と同じ

ソフトウェア開発をRedmineによるチケット駆動開発で進めていると、パッチ駆動開発のように思える時がある。

【1】まず、SubversionやGitのリポジトリにソースコードがあるとする。
そのソースに対して、チケットに書かれた内容をどんどん実装して、リポジトリへコミットしていく。

たとえば、チケットには以下の内容が書かれているだろう。

お客さんから、機能の追加要望があった。
方式設計に不備があり、フレームワークにパッチを当てる必要がある。
本番障害を調査したら、実は以前リリースしたソースにバグがあったので、すぐに直さなくてはいけない。
新機能の実装をしていたら、エラーメッセージの仕様の不明点があり、お客さんに仕様を決めてもらった。

それらチケットは作業指示書と同じ。
仕様をソースコードで表現したものが「パッチ」になる。

そのパッチがチケットの成果物だ。
チケットがCloseするタイミングで、そのパッチはリポジトリにある製品のtrunkにmergeされる。

パッチがトリガーとなって、リポジトリはどんどん最新化され、強化されていく。

【2】Gitが普及する以前は、CVSやSVNのtrunkと比較して、diff出力してパッチを作っていた。
shohinManager.diffみたいなパッチを作っていた。

開発者がそのdiffファイルというパッチをチケットに添付したら、レビューアはそのパッチをレビューし、OKならtrunkにmergeしていた。
コードレビューというプロセスも、Redmineのワークフロー機能で有効にカバーできた。

今なら、Git＋Redmineの運用が普通だろう。
すると、Git上で各チケットに対し、トピックブランチが作られ、トピックブランチ上でパッチが育まれる。
パッチが完成したら、Gitリポジトリに取り込まれる。

GitHubでは、パッチのやり取りがすべてWeb上で行われるから、すごく便利。
パッチをローカルPC上で、手作業で差分比較しながら作る必要もない。

gitのコマンドを駆使して、必要なリビジョンをつまみ食いしたり、複数のリビジョンを一括でまとめたり、色んなマージ方法を選択できる。
マージ用の別ブランチを作れば、パッチの色んな作り方を試すこともできる。

その開発プロセスは、git-flowやGitHub-flowで整理されて公開されており、そのプロセスを真似れば、ブランチ管理の方針も開発チーム内で共有できる。

Gitのおかげで、パッチ作りやパッチのmergeは非常に簡単になった。

【3】パッチ駆動開発とは、「チケットの成果物がパッチ」であること。

チケットは仕様書ではない。
チケットは成果物ではない。
チケットは作業指示書であり、チケットは課題やQAだ。

チケットの成果物がパッチ。
パッチはリポジトリのtrunkに取り込まれる。
リポジトリにあるソース、つまり製品は、常に最新の機能を持ち、いつでもリリースできるブランチでもある。

【4】パッチ駆動開発の意義は、「成果物と実際の作業内容は区別されて管理すべき」という主張だ。
チケットは、成果物のメタデータに相当する。
作業内容は、チケットに書かれるべきであり、ソースやパッチに書かれるべきものではない。

もし、チケットなしでパッチを作っていたら、そのパッチはそもそも何の目的で作っていたのか、を忘れてしまうだろう。
だから、一昔前のプログラミングでは、ソースコードの冒頭に、修正履歴をコメントで書く習慣があった。

チケット駆動開発を推進すると、ソースコードにある修正履歴や、無駄なコメントは、ソースコードから省かれる。
そんな修正履歴はチケットに記載し、いつでもソースのリビジョンから参照できるようにしておけばいい。
そうすれば、ソースコードは常に綺麗な内容になるし、短くできる。
ソースコードは常に最新の機能を持つ状態であればいい。

過去の経緯はソースコードに書く必要はない。
過去の経緯はチケットに書き、「No Ticket, No Commit」によるトレーサビリティによって、チケットからいつでも参照できればいい。

【5】この発想を突き詰めると、リポジトリにあるものがソースだけでなく、設計書やドキュメントも同じだと分かる。
なぜ、Excelの設計書には、変更履歴というシートが必要なのだろうか？

チケット駆動開発で設計書を作っていたら、修正の発端となったトリガーはチケットに記載されている。
チケットの内容に従って、設計書の修正部分を反映し、設計書を最新化する。
設計書の修正部分が「パッチ」に相当する。

ただし、Excelの設計書の場合、ソースのdiffファイルのようなパッチを明示的に作れないのが最大の弱点だ。

設計書の変更履歴に「チケットNo.123を参照」として書くのは、結局、リポジトリ画面にある一つの設計書のリビジョン履歴と同じだ。
コミットログにチケットNoを書いてコミットすれば、コミットログが設計書の変更履歴と同じ。

わざわざ、Excelの設計書に変更履歴シートを作る必要はないのだ。

そして、Excelの設計書も、修正パッチのようなファイルが作れるとなおよい。
そのパッチを積み重ねれば、設計書は常に最新機能を持つ状態として維持しやすくなるからだ。