プログラマの思索

「開発インフラの三種の神器といえばSCM, BTS, CI」という言葉から、チケット駆動開発とアジャイル開発、更にはソフトウェア開発の関係についてもう一度考え直してみる。
ラフなメモ書き。

【元ネタ】
金曜日は分散バージョン管理勉強会。大物スピーカーも来るよ！ - watawata日記

【1】アジャイル開発は多分ソフトウェア開発をやっている人なら自然に理解できる概念だと思う。
イメージ的には、コーディング、コンパイル、実行を繰り返すプログラミングスタイルを開発プロセスへ抽象化すればいいだけだからだ。

でも、ソフトウェア開発は、プログラミング以外の雑多な作業が結構多い。
開発抽象化レイヤーを担う人: プログラマの思索にも書いたけれど、プログラマがプログラミングに専念してアジャイルに開発するには、雑多な作業を意識しなくても良い開発環境を必要とする。
その開発インフラはBTS、SCM、CIでほぼカバーできると直感している。

アジャイル開発の最大の特徴は小規模リリースだと思っている。
短期間に頻繁にリリースしながら品質を改善し機能を拡張していく開発スタイル。
でも、従来の開発プロセスやプロジェクト管理手法では、短期間に次々にリリースしていくのがとても難しい。
タスク管理、進捗管理、変更管理がその開発速度に追いつけていないからだ。

そして、アジャイル開発を実際に運用出来ていないチームの特徴としては、イテレーションという概念を自分たちで実装できていないことがあるだろう。
つまり、定期的にリリースしていく単位をうまく運用できず、従来のWF型開発のように、ただ1回のビッグバンリリースをやった後にデスマーチに陥る時が多いだろう。
リリースして初めて、ビルドエラーに気付いたり、顧客の要望と違っていた事実が判明するからだ。

更に、アジャイル開発が難しい原因として、繰り返し型開発は並行開発でもある事実を認識出来ていないこともあると思う。
小規模リリースを運用すると、リリースしたモジュールは本番環境で稼働中だが、その裏では開発チームが別のコードラインでガンガン機能追加していく開発スタイルになる。
そして、次のイテレーションでリリースする時、1個前のバージョンのモジュールは廃止されて新しいモジュールに入れ替わり、また裏では最新のコードラインが次のイテレーションに向けて開発されていく。

つまり、アジャイル開発はtrunkとリリースブランチという2本のコードラインを常時保守する並行開発になる。
だが、システムやが大規模になるほど、製品ファミリーが多いほど、並行開発を制御するのは難しい。

アジャイル開発を実現するにはそれなりの開発環境が必要になってくる。

【2】最近はソフトウェア開発をサポートするツールのうち、オープンソースのツールがとても優秀で使い易くなってきた印象がある。
バージョン管理(SCM)はCVSの頃から、SVN、そしてMercurialやGitのように進化している。
SCMがとても使い易くなった理由の一つは、TortoiseSVNのようにSCMクライアントが高機能になって、ユーザへの敷居が低くなったからだろう。
高機能なSCMのおかげで、構成管理パターンが普及して、並行開発を従来よりも楽に運用できるようになっている。

また、XPが提唱した継続的インテグレーション(CI)は、Hudsonという優れたツールが普及している。
Hudsonはビルド結果のレポート出力が充実している。
またプラグインを追加していけば、BTSやSCM、更には他ツールとも連携できる利点がある。
CIのおかげでコードラインは常時リリース可能な品質が保たれる。

そして、BTS自体もITSへ進化して、最近はRedmineやTracのようにアジャイル開発のプロジェクト管理に使う発想が生まれている。
チケット駆動開発はTracのチケット管理から生まれた。(まちゅさんが最初に提唱された)
そのアイデアをアジャイル開発のプロジェクト管理に応用できると気づいた人達が、いろんなアイデアを試している。

チケット駆動開発の発想は、チケットをXPのタスクカードのように扱うこと。
そこから、リアルタイムな進捗管理、成果物とチケットの連携が可能になる。
これによって、変化に強いタスク管理が可能になり、成果物のトレーサビリティも楽になる。

そして、BTSのワークフロー管理を使えば、チケットを通じて厳格な変更管理を透明に行うことが可能になる。
このおかげで、開発者は作業だけに専念すれば、自然に厳格なワークフローに即して作業できるようになる。

【3】チケット駆動開発で改めて理解した概念は「バージョン」だ。
リリース予定バージョンをイテレーションに紐づければ、自然に小規模リリースを実現できる。
更に、イテレーションをリリースモジュールのバージョンに紐づければ、CIツールと自然に連携できる。
これによって、どのモジュールにどんな修正が含まれているか、を簡単に追跡できるようになる。

バージョンを大規模プロジェクトに拡張すれば、アジャイルリリーストレインという概念にもつながる。
つまり、複数チームのイテレーションを同期させることによって、複数のチームの成果物の同期がスムーズになり、開発の遅延の伝播がなくなる。

又、バージョンをイテレーションに同一視すれば、そこから開発のリズムが生まれる。
チームのゴールがイテレーション終了時のリリースだとメンバー全員に通知できるから、メンバーのベクトルが一つに向く。
チームのゴールが分かるからこそ、チームは何をすべきか、自分の役割は何か、が自然に気づくようになる。

そしてリリース後に、BTSに貯められたリリース履歴を見ながらKPTでふりかえりをやると、とても効果的。
Keepとしてあげられた内容は、開発チームの運用ルールやプラクティスとして、次のイテレーションで使える。
Keepはまさにプロセス資産。

Problemとしてあげられた問題は、Tryに是正対策としてまとめられて、次のイテレーションで実験したり試行錯誤するきっかけになる。
その結果が次のイテレーションのふりかえりで評価されて、開発チームの運用ノウハウが溜まっていく。

KPTによるふりかえりは、開発チームの成長のために必要不可欠なプラクティス。
プロジェクトファシリテーションとチケット駆動開発の強い関連性はもっと研究されてもいいと思う。

【4】XPは元々、ソースの共同所有や継続的インテグレーションなどのアイデアで、SCMやCIの重要性は主張していたが、それだけでは物足りない気がしていた。
でも、高機能なBTSを基盤としてチケット駆動開発を運用する手法によって、アジャイル開発の最後のピースが埋まったような気がする。

RedmineやTracによるチケット駆動開発の上で、Scrumなどのアジャイル開発のプロジェクト管理のアイデアは全て実現できるはずと直感している。

【補足】
ITS・SCM・CIを3種の神器と命名した人は、@haru_iidaさんだそうです。

Twitter / @かぬ: TracLightning/Kanon使うと3分で導入できますね(^^ RT @changeworlds: ITSとCIと構成管理システムで解決しますよ。これ三種の神器と言います。命名は@haru_iidaさんです。 #aj11 #aj11toy