アジャイル開発が並行開発になる理由

アジャイル開発が並行開発になる理由をメモ。

【元ネタ】
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂

変更要求に対する選択肢: プログラマの思索

派生開発プロセスXDDPの講演メモ: プログラマの思索

普通の受託案件で、アジャイル開発を実践していて、新規開発中だったと仮定する。
リリース計画としては、最終目的はver1.0をリリースするように作るだろう。
イテレーション計画としては、Ver1.0のイテレーションを作るか、マイルストーン単位に複数のイテレーションを作るだろう。

リリース予定のVer1.0に向けて開発中で、trunk以外にコードラインは存在しないだろう。
開発者は、trunkだけに集中してコミットしていく。

そして、Ver1.0をリリースするタイミングになったと仮定する。
リリース担当者は、trunkからver1.0のtagを切り、ver1.0のリリースブランチを作る。

その後、Ver2.0のイテレーションを作り、開発者は次のバージョンに向けてtrunk上で開発していく。
普通に考えるならば、アジャイル開発もWF型開発も並行開発にはならない。

しかし、実は、リリースしたVer1.0へ障害対応するために、Ver1.1のイテレーションを作り、ver1.0のリリースブランチ上で作業せざるを得ない。
つまり、Ver2.0に向けて機能追加に対応するtrunkと、Ver1.0のバグフィックスに対応するリリースブランチの2本の並行開発が自然に必要になる。

リリースしたバージョンに対するイテレーションは、引き続き保守のためのイテレーションが続いていくのだ。
だから、リリースブランチで本番運用中のソースを保守しながら、裏のtrunkで機能追加のソースをガンガン開発していく並行開発になる。

すなわち、システムはリリースしたら、それで終わりと言うわけではない。
むしろ、システムを育てていく観点が大事だ。

WF型開発は、Ver1.0のシステムをドカーンと一発リリースして、その後、大量のバグ修正や改善要望に忙殺されるのが殆どだ。
WF型開発があまりにも理想的な開発スタイルで現場の運用に馴染まない理由は、Ver1.0だけの開発プロセスに過ぎず、運用保守を含めた全体的なソフトウェアのライフサイクルの観点が漏れていることだと思う。

この並行開発は、組込み製品やパッケージ製品の開発で発生し、その構成管理や開発プロセスが非常に難しくなることは昔から知られていた。

並行開発の難点は二つあると思う。
一つは、1本のコードラインをリリースまで持っていくのも大変なのに複数のコードラインを保守せざるを得ず、品質維持が難しい点。
もう一つは、リリースブランチの障害修正をtrunkへマージする、あるいは、共通ライブラリの修正点を他の製品ラインへマージする作業が発生すること。

この並行開発に対し、SW工学の観点から、SWプロダクトラインが対応しようと試みている。
つまり、共通ドメインのコア資産と各製品特有のドメインをアプリケーション資産に分けて管理する発想。
しかし、並行開発の諸問題を全て解決できたとは聞いていない。

並行開発に関しては、いくつかのアプローチは知られている。
一つは、緊急の機能追加に対応する場合、タスクブランチを活用すること。
やり方は下記に書いた。

変更要求に対する選択肢: プログラマの思索

また、清水吉男さんが提唱する派生開発プロセスXDDPは、追加と変更の2本のタスクブランチを作る。
考え方は下記に書いた。

派生開発プロセスXDDPの講演メモ: プログラマの思索

つまり、いずれも故意に並行開発を選択することで、要求の変更に対応しようとする。
但し、いずれも難易度は高いと思っている。

そして、並行開発が難しいのは、根本的には構成管理の技術に落ち着くと思っている。
ブランチの品質保持とマージ作業の自動化が鍵。
CVSからSubversion、そして、GitやMercurialに至るバージョン管理の技術の流れも、並行開発の観点から整理できると思う。

従来の組込み製品やパッケージ製品だけでなく、昨今はWebシステムやオープンソースでも並行開発が当たり前の状況になったのに、並行開発の諸問題を解決する方法、特に構成管理の技術が意識されていないのは不思議だと思う。