繰り返し開発の罠

萩本さんがアジャイル開発と反復開発について記事を書かれていたのでメモ。
#以下はあくまでもメモ書きです。

【元ネタ】
アジャイル開発と反復開発の落とし穴 － ＠IT自分戦略研究所

「現状のソフトウェア開発は間違っていないか？」（プロセス編） － ＠IT自分戦略研究所

裏プロセスは並行プロセス: プログラマの思索

「塹壕よりScrumとXP」

TiDDを実践して気付いたことpart3～繰り返し開発の戦略: プログラマの思索

Mercurialによるチケット駆動開発は強力だ！: プログラマの思索

「反復開発は、管理重視型開発」「アジャイル開発は、価値重視型開発」と書かれていて、なるほどと参考になったのと同時に違和感があった。
確かにその傾向はあるけれど、本質はそこだけでは無い気がする。

RUPのような反復開発は、アーキテクチャや品質を作り込むためにプロセスを反復する。
しかし、1回の反復だけではリリースできるレベルまで開発できないし、リリースは普通最後の1回だけだから、結局ウォーターフォール開発と何ら変わらない感覚がある。

アジャイル開発は漸進型開発であり、小規模リリースを基本とする。
1回のイテレーションでリリース出来る機能を実装しながら、小刻みにリリースしていく。
だから、アジャイル開発ではリリース計画やイテレーション計画を作るのが非常に重要になってくる。
その意味では、アジャイル開発はリリース計画駆動と言ってもいい。

でも、僕がチケット駆動開発を実践してみて、小規模リリースの戦略だけでは不足していると経験した。
やはり、品質を作り込むイテレーションが別途必要な状況が存在するのだ。
例えば、複数のサブチームが並行して、イテレーションを繰り返してモジュールをリリースしていき、最後にそれらを結合する場合、結合テストのようなイテレーションが必要だ。
この状況が発生するのは、組み込み製品でソフトウェア部隊とハードウェア部隊が連携する場合や、大規模プロジェクトで複数のモジュールを結合する場合が相当する。

この時、TestLinkを使って、結合テストやシステムテストを行い、品質を作り込む。
その手法は、反復開発に切り替えているのだ。
つまり、繰り返し開発は漸進型開発と反復開発を切り替える戦略が重要だと思う。

そして、繰り返し開発を使いこなすには、並行開発のインフラが必要になってくる。
つまり、「塹壕よりScrumとXP」にもあるように、ブランチを上手に使いこなす必要がある。

漸進型開発であれ、反復開発であれ、繰り返し開発を行うと、必ずブランチが発生する。
漸進型開発ならば、リリースしたソースは本番ブランチとして、次のメジャーバージョンまで生き続ける。
反復開発ならば、検証中のソースはタスクブランチとして、trunkへコミットされるまで生き続ける。

すると、ブランチとtrunk間のマージ作業が発生し、並行する複数のブランチをどのタイミングでマージするか、難しくなる。
デグレが起きないようにマージするのは、たとえチケット駆動開発であろうとも簡単ではない。

ブランチとtrunk間のマージ作業の問題に対する一つの解決方法として、MercurialやGitのような分散バージョン管理を上手に使いこなすのがあげられる。
そのやり方は、Mercurialによるチケット駆動開発は強力だ！: プログラマの思索に書いた。

つまり、繰り返し開発が難しい理由は、漸進型開発と反復開発を切り替える戦略が無いこと、そして、並行開発を制御する構成管理のインフラがないことにあるのだと思う。

繰り返し開発は試行錯誤しながら問題を解決する仕組みだとすれば、別にソフトウェア開発だけの代物ではないし、どんな人でもその利点は理解できる。
しかし、繰り返し開発に関するソフトウェア開発特有の問題を認識していないから難しいのではないか、と思ったりする。