No Ticket, No Commitの効果

No Ticket, No Commitの効果について考えたことをメモ。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

明日からできる！バージョン管理システムへのコミット粒度を最適化するトレーニング方法 - 刺身☆ブーメランのはてなダイアリー

Twitter / @yusuke_kokubo:RedmineのリポジトリをウォッチしてるとJPLのコミットの粒度の適切さに感心する。Redmineの使い方はredmine.orgに学ぶことが多い。(それにくらべてBacklogsプラグインは…ゴニョゴニョ)

Twitter / @yusuke_kokubo: @akipii コミットの粒度とコミットメッセージあたりですね。

まちゅさんのスライドにもあるように、チケット駆動開発の最も基本的な運用ルールは「チケット無しのコミットは禁止」。
この運用ルールは、結合テストやシステムテスト、受入テスト、本番運用などでバグ修正した時に、必ず障害報告票とリンクづけて、修正理由を明確にするのが本来の目的だった。
何故なら、テスト工程では、どのバグ修正がどのバージョンのモジュールに含まれているか、きちんと管理しなければすぐにデグレが発生するし、せっかく直したバグが検証されなかったりするからだ。
また、ソース修正とバグの変更理由が紐づいていれば、コードレビューもやりやすい。
つまり、バグの変更管理が本来の目的だった。

チケット駆動開発では、No Ticket, No Commitをバグ修正の追跡だけでなく、プロジェクトで発生する成果物一般の追跡に使う。
つまり、SCMリポジトリに格納されているソースだけでなく、Excelの設計書、Wordの議事録、ビルドスクリプト、環境構築の初期データやDDL、共通ライブラリのコンポーネントなどの成果物を変更する場合は、チケットに紐付けるようにする。
この運用によって、何故こんな汚いパッチに変わったのか、とか、何故この要件がこんな複雑な仕様へ変わったのか、をチケット経由で追跡できる仕組みが出来上がる。

また、No Ticket, No Commitの副次的効果も幾つかある。
一つ目は、ソースに書かれた無駄なコメントはチケットに集約されるので、ソースがきれいになること。
CobolやVBなどの過去のソースは、「20yy/9/ddに障害管理No.XXで直した」などの無駄なコメントがとても多く、修正が入る度にガラクタのコメントアウトが増えて見苦しい。
修正履歴のようなコメントは、SCMやBTSの機能が貧弱だった時代には必要だったかもしれないが、今の時代は不要だと思う。

レガシープログラマかどうかを判断する基準: プログラマの思索

SVNのコミットログの書き方: プログラマの思索

No Ticket, No Commit! #tidd: プログラマの思索

二つ目は、コミットに明確な理由がつくので、コミットの粒度が分かりやすくなること。
新人プログラマのソースを見ると、Javaのmainメソッドに1000行も書いて、まともに動かないのにコミットしている場面を見た時がある。
バージョン管理は単なるソースのバックアップではない。
特にtrunkへcommitする時は、コンパイルエラーがないのはもちろん、TDDで単体テストもクリアして、コードレビューも完了しなければコミットできない。
そうでなければ、trunkは常時リリース可能なコードラインにならないからだ。

実際にプログラムを書いている時、チケットや仕様は頭の片隅に追いやって、ひたすらプログラムを綺麗に書いて動かすことに専念する。
そして、コミットログにチケット番号を付ける時に、今の自分はこの理由で修正したんだよな、と思い出す。
つまり、詳細な情報はチケットに書いておけば、それを忘れてプログラミングに専念できる環境がある。

また、XPJUG関西の山根英司さんは以前、駄目なプログラムはソース修正の意図が見えない、と言っておられた。
駄目なプログラマは、リファクタリングと機能追加を一緒に混ぜ込んでコミットするから、後で問題発覚した時にロールバックできない。
No Ticket, No Commitを意識すると、今はリファクタリング、次は機能の追加、次はバグの修正、などのように、意図を明確にしてcommitするようになる。
平鍋さんのプロペラ帽子のように、今はリファクタリングの帽子、次は機能追加の帽子のように、頭を切り替えて作業する単位でコミットしていけばいい。

三つ目は、新人プログラマに良い習慣を身に付けてもらえること。
プログラムを書くというのは、単にコンパイルエラーがないだけではない。
TDDのように仕様を満たすように書くことも大事だし、バグ管理やコードレビューで他人の指摘を反映していく作業も大事。
SVN・Git・Mercurialのようなバージョン管理ツールで修正履歴を残していくのも重要。

特に、バージョン管理で修正履歴を残す時、意味ある単位でコミットしていって欲しい。
その時に、No Ticket, No Commitでチケットにソース修正履歴を残しながら、自分が今書いているソースはどんな理由で書いているのか、を意識して欲しい。
単体テストしていないソース、ビルドが通らないソース、コードレビューしていないソースは、コンパイルエラーのソースと同レベルなのだと認識して欲しい。
実際、顧客に価値あるシステムを納品するというAgile開発の理念から考えれば、テストせずにまともに動かないソースは、顧客から見ればコンパイルエラーのソースと同じだ。

そうすれば、リファクタリングのテクニック、TDDのテクニックも自然に身に付くと思う。
下記でも書いた。

チケット駆動開発は仕事をさばく仕組み　#agileto2010 #tidd: プログラマの思索

No Ticket, No CommitのようにBTSに由来した運用ルールは、ソフトウェア開発の作業を効率化するために長年蓄えられたノウハウ。
TiDDはBTSの機能をAgile開発に流用した経緯もあり、BTSのベストプラクティスもそのまま流用すればいい。

【追記】
No Ticket, No Commitの運用ルールを早とちりして、1コミット＝1チケットと思う人がいますが、そんなことはない。
ITSチケットとSCMリビジョンの関係は多対多が普通だ。
実際、1個の仕様変更のチケットに対して、複数回のコミットはあるし、コミットの意図には機能追加もあればリファクタリングもあるだろう。
あるいは、2件のバグのチケットは同類バグでバグの原因が同じならば、1回又は複数回のコミットで一括修正してもいい。
よくある状況は、長年の運用保守でプログラムが複雑になって、新規機能の追加が難しい時だ。
仕様変更に対応するにはまずリファクタリングで綺麗にしないと対応すらできない場合、リファクタリングのチケットと仕様変更のチケットを分ける。
僕の経験では、リファクタリングが1人日もかかるならば別チケット化して、開発者が作業しやすい単位でチケットを分けている。

Redmineを使って気づいたことpart3～チケット分割のタイミング: プログラマの思索

つまり、状況(コンテキスト)に応じて、チケットとコミットの関係は異なる。