チケット駆動開発の適用範囲

日本のSI企業がチケット駆動開発について記事を書かれていたのでメモ。
以下ラフなメモ書き。

【元ネタ】
「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL

補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索

[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば

ユーザの力を利用するアジャイル開発: プログラマの思索

チケット駆動開発の戦略: プログラマの思索

僕はチケット駆動開発がどこまで知名度が上がっているのか、正直知らない。
でも、チケット駆動開発のアイデアをアジャイル開発だけでなく、従来のWF型開発にも適用すればその恩恵が受けられるのではないか、という意見は、既に@sakaba37さんたちが色々試されている。

チケット駆動開発をWF型開発に適用する場合、「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOLの記事にもあるように、方法は二つあると思う。
一つは、WF型開発の一部の工程にチケット駆動開発を導入すること。
もう一つは、チケット駆動開発の特徴の一つである「チケットと構成管理情報の連携」機能やワークフロー管理機能を使って、変更管理を強化すること。

前者は、テスト工程の障害管理や設計工程や開発工程のレビュー管理に使う時が多い。
例えば、RxtStudy第1回勉強会で@ahyari氏が講演されたように、レビュー工程でRedmineを使って作業をスムーズに行えたという事例もある。
@sakaba37さんが提唱された補完チケット方式のチケット駆動開発は、WF型開発で予期していなかった作業の管理に適用するものだが、普通はテスト工程のタスク管理が当てはまりやすい。何故なら、テストしてどれだけバグが出るのか、というのは実際にテストしなければ分からないからだ。
つまり、テスト工程やレビュー工程では作業内容を計画的に予見することができないという特徴がチケット駆動開発と相性がいい。
チケット駆動開発はタスクの変更に強い、という特徴を生かすやり方だ。

後者は、障害管理におけるソース修正など成果物の変更を厳格に管理する時や、バグ検証やリリース作業、レビューのように複数人が連携する作業の管理で使う時が多い。
チケット駆動開発の醍醐味の一つは、バージョン管理のリポジトリにある全ての成果物の変更がチケットに記録されることによって、何故そのような変更がなされたのか、を後から追跡出来る点にある。
また、チケットのトラッカーをSW開発のワークフローと対応付けておけば、チケットの起票から終了まで、担当者がワークフローを意識しなくてもバックグラウンドでツールがワークフローを監視してくれる仕組みがある。
これらの特徴をSW開発の変更管理に適用することで、担当者が意識しなくても変更作業を透過的にモニタリングする仕組みが整う。
更に、HudsonやJenkinsのようなビルド管理ツールも連携すれば、ソース修正からビルド、リリースに到るまでの作業を全てツール上でコントロールできるようになる。

この変更管理の強化は、WF型開発だけでなくAgile開発にも適用でき、その恩恵を受けることによって、頻繁なソース修正があっても、常時リリース可能なコードラインを保持できるようになる。
この意味はとても大きい。

上記のように従来のWF型開発にチケット駆動開発を適用したいという要望はかなり多いように思う。
上記の記事によれば、日本のシステム開発モデルのうち「ウォーターフォール開発が全体の9割強をしめ、反復型開発およびその他の開発モデルは全体の3.9％程度にとどまっている」らしいからだ。
だから、昨今の高機能化したツールを上手く生かすことで開発プロセスを強化したいという動機につながっているのだろう。

僕は更に他の考えも持っている。
一つは、製品の開発者と製品を使うユーザの関係をサポートすることで、製品開発にユーザの力を利用できるようにすること。
ユーザの力を利用するアジャイル開発: プログラマの思索にも書いたけれども、現代ではソフトウェアだけでなく家電製品でも、そこそこの品質を確保できればいち早くリリースしてユーザに使ってもらい、ユーザのフィードバックを受けながら製品を小刻みにバージョンアップしていくビジネスモデルへ変化している。
これはまさにアジャイル開発における小規模リリースの発想と同じ。
その時に、製品開発のタスク管理だけでなく、製品を使うユーザが議論できるフォーラムや、ユーザからの障害報告や改善要望をチケットへ起票してもらう運用などがあれば、製品開発へダイレクトに生かすことが出来るだろう。
RedmineやTracを開発者とユーザがコミュニケーションできるポータルな場として提供し、チケット駆動開発の特徴を組み合わせて、ユーザの力を開発に利用できるようにしたいのだ。

もう一つは、チケット駆動開発の適用範囲について、ソフトウェア開発だけではなく、他業界の作業の管理や課題管理にも使えるのか、にも興味がある。
下記の記事にも書いたけれど、営業マンのタスク管理や情報システム部門・サーバー運用保守の課題管理、製造業や製薬業の作業の管理に使っている人達もいる。

RedmineのTime Trackerプラグイン運用の注意点: プログラマの思索

その場合の使い方が、SW開発におけるアジャイル開発のプロジェクト管理とどのように違うのか、という点を聞いてみたい。
僕の勝手な推測では、逆にチケット駆動開発のアジリティの特徴が出ていて、むしろアジャイルな作業管理になっているのではないかと思っている。
その人達はアジャイルという言葉を知らなくても、実際にアジャイルを実践しているのではないか、と期待しているのだ。

チケット駆動開発の適用範囲については、コミュニティで今後議論されると面白いだろうなあと思っている。