チケット駆動開発が進むべき道 part3～BTSを中心に構成管理・テスト管理を含めたプロジェクト管理の枠組みを作る #tidd

チケット駆動開発について考えたことをメモ。

【元ネタ】
チケット管理システム比較

[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi: ソフトウェアさかば

チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

チケット駆動開発が進むべき道part2～プロジェクト管理サーバーは開発チームの資産: プログラマの思索

チケット駆動開発を開発プロセスへ理論化できるか？: プログラマの思索

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

今年に入ってデブサミまでの2ヶ月間、チケット駆動開発に関する講演をしてきて、講演を聞いた人から指摘された内容から新たな問題意識を持っている。

一つ目は、SEA関西の世話人の方から、「Redmineによるタスクマネジメント実践技法」はあきぴーさんとさかばさんの共著だが、二人の観点の違いがはっきり出ている。さかばさんの方は、チケット駆動の導入が直接現場にもたらす効果に焦点をあて、その適用についても「効果があれば使えばよいし、かえって大変になりそうだったら、やめておけばいい」という現実的なスタンスだが、あきぴーさんの方は、チケット駆動開発を軸にして、さらに構成管理・テスト管理とも連動した、より大きなプロジェクト管理の枠組みの構築を目指されているようだ、と言われたこと。

二つ目は、かおるんさんから、Scrumは9つの規律、かんばんは3つの規律があるがチケット駆動開発には規律はあるのですか？と質問されたこと。

前者は、さかばさんの立場は下記の記事で既に説明されている。

[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi: ソフトウェアさかば

僕の理解では、ソフトウェア工学は正しく使わなければ欲しい結果が得られないこと、つまりコンテキスト(問題の文脈)を明確に定めなければソフトウェア工学のノウハウを適用しづらいこと、そして、チケット駆動開発は現場のソフトウェア工学ゆえにコンテキストが現場にマッチしやすい特徴がある、と認識している。

ソフトウェア開発におけるコンテキストの話は森崎さんが最近よく話されているが、僕の認識では、ソフトウェア開発の現場で現れる諸問題を明確に区別して、それぞれの問題に対して最適な解決方法を見出す話なのだろうと推測している。

そして、コンテキストの話は最終的にはパターンランゲージでより包括的にまとめることができると思う。
何故なら、パターンとはコンテキスト(問題)に対する一つの解決方法をボトムアップで吸い上げたモデルだからだ。
例えば、GoFのデザインパターンは、オブジェクト指向プログラミングにおけるコンテキストの諸問題を解決する一つのアイデアで、とても有用だ。
実際、Stateパターン、Strategyパターン、Adapterパターンなどはどのような場面で使うと有効か、そして使いすぎるとどんな副作用があるのか、まで詳しく解説してくれている。

つまり、ソフトウェア工学のコンテキストの話は、パターン(成功例)やアンチパターン(失敗例)で綺麗にまとめられるはずだと思う。
だから、僕もチケット駆動開発のプラクティスをまとめる時、パターンカタログを作って「Redmineによるタスクマネジメント実践技法」にもまとめている。
その方がパターンがどんな問題に対して有効で、そのパターンの本質は何なのか、をよりはっきりさせてくれるからだ。

SEA関西の世話人の方の話を聞いて、さかばさんの観点がよく理解できたと共に、僕がやりたいことは、チケット駆動開発をベースとして、BTSを中心とした構成管理やテスト管理を含むプロジェクト管理の枠組みが作りたいのだと改めて自覚した。
それは最終的には、プロジェクトリーダーの意思決定をサポートするプロジェクト管理サーバーの概念を明確に実現することだ。

だから、最近はRedmineと構成管理、ビルド管理ツールHudsonとの連携に興味を持っている。
そのアイデアは、チケット管理システム比較に詳しく書いた。
言いたいことは、Redmineのプロジェクト・バージョン・チケットという概念が構成管理のコードライン(trunk, branch)、タグ、リビジョンと対比でき、更にはHudsonのジョブ、ビルド番号、ビルドログと対応付けることができるということ。
その対応づけによって、チケット駆動開発に現れる諸概念をソフトウェア工学の概念で補強できるし、現場で運用される構成管理やビルド管理、リリース管理、変更管理などのプロセスが何故そのように厳格に運用すべきなのかという理由を明確に理論付けできる。

僕がRedmineでチケット駆動開発を実践して改めて痛感したことは、アジャイル開発は手抜きの開発ではないことだ。
アジャイル開発は現物主義であるがゆえに、無駄なドキュメントや無駄な作業を嫌う。
だからと言って、すべてのドキュメントや厳格なワークフロー管理が軽視されていいわけではない。
やるべきプロセスを省略すると、本番リリース後の障害によって、手痛い仕打ちを食らう。
例えば、バグ修正とバグ検証は担当者を変えずに品質チェックがそのままスルーしてしまうとか、バグ修正後のコードレビューを省いてしまうなどのプロセスがあげられる。
バグ検証や同類バグ調査、コードレビューと言うプロセスを省くと、ファウラーの言う技術的負債として必ず現れて、プロジェクトを混乱させる原因になるからだ。

チケット駆動開発の利点の一つは、厳格なワークフロー管理、開発プロセスの管理を透過的にサポートしてくれること。
バグのチケットは複数人で切り替えて成果物をお互いにチェックし合うワークフローにすればいい。
バグのチケットを起票したら、開発者は同類バグ調査を必ず行ってから修正すればいいし、テスト担当者はデグレしていないか、他の機能に影響していないかの観点も含めてテストするように運用すればいい。

つまり、チケット駆動開発によってアジャイル開発に規律や組織力を導入することができる。
しかも従来のプロセスのようなExcelを印刷して承認する時に判子を押すような無駄なワークフローを排除して、必ずチケットに作業履歴が残るような仕掛けがある。
アジャイル開発にあるコミュニケーションや人間重視という利点をそのまま生かしながら、規律や組織力を導入してスケールアップしやすくできるはずだ。

二つ目のかおるんさんの指摘はまさにその通りで、チケット駆動開発の規律は何か、という問題は僕もまだ解決出来ていない。
最終的には数学の公理体系のように、最小の個数の規律(公理)から他の規律やプラクティス(定理)が導かれるような体系をチケット駆動開発にもたらしたいと思っている。
僕の直感では、「No Tikcet, No Commit!」というたった一つの規律でチケット駆動開発の全てのプラクティスを導出できると思っている。

実際、「プロジェクト内部の作業はチケットを起票してから始める」というTicket Firstという規律も、プロジェクト内部の作業は必ず成果物が求められるので、チケット無しで成果物を作ってはならないという規律から演繹できる。
又、BTSバージョンをリリース予定バージョンに同一視することでイテレーションに対応付ける小規模リリースというプラクティスも、成果物を作るチケットをバージョンというリリース単位でグループ化し、そのバージョンを2～4週間でリリースすれば、自然にアジャイルな開発として実現できる。
更に、BTSプロジェクトをビルドモジュールに同一視することで並行開発を実現するプラクティスも、プロジェクト内部の作業を表すチケットを開発チームやコンポーネントの単位でグループ化すれば、自然にビルドモジュールとBTSプロジェクトが紐づいて、それがリリース単位になる。

チケット駆動開発の他のプラクティスも同様に、最小の個数の規律から全てのプラクティスを演繹できるはずだ。
そうすれば、最低限の規律を守ってチケット駆動開発を実践すれば、自然にアジャイル開発を運用できて、その裏では厳格なプロセスが動いているという仕組みを作れるだろう。

今後はこの辺りをもっと理論的にまとめてみたい。