アジャイル開発はツールに依存している～SW構成管理を再考しよう

アジャイル開発とSW構成管理に関する記事を見つけたのでメモ。

【元ネタ1】
Kent Beck VSTSのホワイトペーパーの日本語訳

(前略)
アジャイル開発はツールに依存します。特にツールが異なる開発サイクルに合わせて最適化されている場合は依存度が高くなります。
(中略)
アジャイル ソフトウェア開発は、ツールを抜きにして語ることはできません。俊敏なプロジェクトでは毎日の作業量が非常に多く、以前は手動で行われていた非常に多くの手順が短い期間で繰り返されるようになるため、適切なツールが不可欠です。
(中略)
アジャイル開発は既に開発ツールに影響を与えています。
(中略)
今後もソフトウェア ツールに影響を与える傾向は、絶えず短くなっているリリース サイクルです。
以前はリリースに数年かかっていましたが、ますます多くのソフトウェア製品の新機能が、月単位、週単位、日単位、またはさらに頻繁に運用環境にリリースされるようになっています。
各フェーズが順番に実行されることを暗に想定したツールは、並行した (非常にすばやく切り替わる) 作業をサポートするツールに取って代わられるでしょう。
作業間のより頻繁な移行をサポートしようとする傾向は、今後も続くことが予想されます。状況は大きく変化せず、サポートされる作業の数が増加します。
(後略)

短いイテレーションによる繰り返し型開発では、高度な管理ツールを必要とする。
従来の手作業によるプロジェクト管理、チマチマとしたExcelによるタスク管理では、アジャイル開発をいくらやりたくても実現できない。

頻繁なリリースに耐えうるプロジェクト管理手法こそ、チケット駆動開発が目指す開発スタイル。

アジャイル開発をサポートするツールは最終的に、作業の透明化を目指す。
つまり、誰がどんな機能を実装してコミットしたか、誰がどんな仕様変更や障害対応でパッチを当てたのか、という作業を、他人にも自分にも説明できるように明確化すること。

デスマーチ・プロジェクトや風通しの悪い大規模プロジェクトでは、誰が何の作業をしているのか、メンバーだけでなくリーダーも、トップの管理職も把握できていない。
特に大規模プロジェクトになるほど、進捗管理という名のマネジメント工数が大きくなる理由がそこにある。

その工数は本質的に無駄だ。
その作業を自動化できるなら、マネジメント工数も、そして進捗管理だけしか脳のないリーダーも不要になる。

この考えを推し進めると、優秀なプログラマと優秀なテスターがいれば、マネージャ無しで開発できるようになるはず。

【元ネタ2】
大規模組織のためのアジャイルな構成管理 : 1～9
大規模組織のためのアジャイルな構成管理 : 10～14

次に、「構成管理」について説明します。これは「品質」と同様に定義の難しい概念で、以前から複数の異なる定義が存在します*1。
構成管理とはシステム内の項目を識別し、特定の項目とシステム全体の両方に対して変更管理を行うことであるというのは、誰もが同意するところでしょう。
構成管理を極めて狭義に定義すれば、「一般的な任意のソース管理システムを実装し、適切に使用すること」を指します。
逆に、極めて緩やかに定義すれば、「プロジェクト・チーム全体とそのすべての成果物」を指します。
成果物には、システムのあらゆる部分の正常動作を保証するためのすべてのコードやアクティビティー、すべての変更管理アクティビティー、さらにはチームの日々の手順における変更追跡などが含まれます。
この記事では、中間的なアプローチを採用し、構成管理の定義として、システムの各部品を整理し、システムの状態を常に把握し、その変化を管理し、開発プロセス全体を通してシステムの継続的かつ正常な機能を保証するためにプログラマーが行う作業を含めることにします。

変化を制御するためにツールが必要。
構成管理は、変更管理のインフラを提供する。

XPが優れているのは、ソース共同所有・テスト駆動開発・継続的インテグレーション・小規模リリースなどのように、ソフトウェア開発のインフラの自動化に着目した点にある。
チケット駆動開発もその流れにあると言っていい。

アジャイル開発の構成管理において、今の僕が思っている課題は、ビルドの並行化。
テスト駆動開発を実践すると、全てのJUnitを走らせるだけで何時間もかかり、結局デイリービルドできない。

下記のように、JUnitでテストクラスを並列に実行できるならば、見かけ上のビルド時間は半減できるはずだ。

JUnit4でテストクラスの並列実行 - cactusman日誌

おそらく、Hudsonによる並行ビルドとVMWareによるテスト環境の仮想化をうまく兼ね合わせないと、最終的にこの課題は解決できないと思っている。

GitやMercurialのような分散バージョン管理、Hudsonによる並行ビルド、VMWareによる本番環境の仮想化などのように、構成管理の技術はまだ進化の途中。

昨今のアジャイラーは、プロジェクトファシリテーションのように、人間系・マネジメント系の方面に目が行きがちだが、構成管理という基本的な技術をもっと洗練させないといけないのではないか？