TiDDを実践して気付いたことpart7～繰り返し開発を制する者はSW開発を制す

先日、S-OpenでRUPで有名なクールシュテン博士によるアジャイル開発の講演があった。
Agile開発は大規模プロジェクトでは難しい、アーキテクチャを重視するプロジェクトでは難しい、などの話を聞いて、そんな話は昔から聞いていた、と正直聞き飽きた。

そんな違和感を感じながらも、チケット駆動開発を実践して、アジャイル開発の難しさが何となく分かってきた気がする。
考えたことをメモ。

【元ネタ】
TiDDを実践して気付いたことpart6～TiDDでAgile開発を実践して分かってきたこと: プログラマの思索

TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略: プログラマの思索

以前書いたように、Agile開発が難しい理由は、その最大の特徴である「超短期間の繰り返し開発」を実現するハードルが高いことにある。
その内容は次の3つに言い換えられる。

１・繰り返し開発はイテレーション管理が難しい
２・繰り返し開発において、インクリメンタル型開発と反復型開発を混同してる
３・繰り返し開発は並行開発でもあるため、並行開発の制御が難しい

１は、変化を受け入れる技術、プロジェクト管理、開発環境がなければ、アジャイル開発は絵に描いた餅だ。
当初の計画になかったタスクの追加、イテレーション内におけるタスクの優先順位の変更は、頻繁に起こるが、確実に対応するのはやはり難しい。
タスクから成果物まで追跡できるインフラがなければ、ほんの少しの仕様変更の対応なのに、バグを混入させてしまい、品質を劣化させてしまう。

３は、実は、繰り返し開発には並行開発というプロセスが実は隠れているという指摘。
短期間にリリースしていくと、一度リリースしたシステムは生き続けるが、裏では次バージョンに向けて機能改善していく。
大規模プロジェクトになるほど、複数のサブチーム、サブシステム、製品ファミリーで同じような現象が起きるから、どんどん制御が難しくなる。

２で提起した「漸進型開発(インクリメンタル)」と「反復型開発(イテレーティブ)」の使い分け戦略こそが、違和感の根源だと思う。
「アジャイル開発では、アーキテクチャ重視や品質重視のプロジェクトでは有効でなかった」と講演で話していたが、それは漸進型開発のみで解決しようとして失敗するだけであって、2種類の繰り返し開発を切り替える発想がないだけだと思う。

一定の期間で機能拡張しながら小刻みにリリースしていく漸進型開発は、開発者にとってとても楽しい。
リリースするたびに作ったものが動くので、ユーザが確認できるだけでなく、開発者にとっても、開発のゴールはリリースなのだ、といつも再確認できる。
イテレーションのリズムで開発するのは、開発者のモチベーションアップにつながるし、楽しい。
試行錯誤しながらリリースしていくというスタイルには、漸進型開発がとてもやりやすい。

でも、アーキテクチャを作りこんでから機能追加していくスタイルや、とにかく稼動するシステムへ更に品質を作りこんでいくスタイルには、漸進型開発だけでは物足りない。
アーキテクチャや品質は1個のイテレーションだけで実現できるわけがない。

例えば、性能などの非機能要件は、全てのイテレーションで実現せねばならないが、解決方法は、試行錯誤しながら分かる時が多い。

また、作った機能の殆どは単体テストを通過しているから動くけれど品質に不安がある場合、システムテストや受入テスト、モンキーテストなどで、システム全体をテストして細かなバグを潰していく。

あるいは、ソフトウェアプロダクトラインのように、製品ファミリーの共通部品をコア資産として抽出し、各製品の特徴はアプリケーション資産で開発するスタイルの場合は、どうしてもアーキテクチャ重視になる。
そのアーキテクチャは試行錯誤しながら、決めていくことが多い。

品質もアーキテクチャも反復型開発で、システム全体を俯瞰して少しずつ作りこんでいく方がやりやすい。
でも、反復型開発の弱点は、スコープが発散しがちなこと。
実際の開発では、テストしながら仕様変更にも対応したり、割り込み作業が入ったり、変化が発生する。
更に、アーキテクチャや品質はいくらやっても、終わりがない作業だから、それらに対応するたびに、どんどん工数も作業の範囲も膨らむ。
だから、反復型開発はスコープを意識しなければ、とても難易度が高いと思う。

逆に、漸進型開発では、リリースと言うとても強い制約条件のおかげで、スコープがあまり広がることはない。
リリースというゴールがあるから、開発チームだけでなく、ユーザにも強い制約をかけることができる。

他に、大規模プロジェクトに繰り返し開発を適用する場合、サブチーム内部では漸進型開発で開発させて、複数のサブチームの結果を統合するイテレーションでは反復型開発に切り替える手法が最も現実的だと思う。
例えば、Webシステムの結合テストや、組み込み製品開発でSWチームとHWチームが連携する工程は、反復型開発に切り替えて、品質をまず確保する戦略を取る。
特に、チームのスケールアップには、反復型開発の方がやりやすいように思う。

チームのスケールアップでは、並行開発のインフラがあることも重要だ。
つまり、サブチーム単位にブランチがあるわけだから、そのブランチ間で最新機能を相互に確実にマージできるインフラがなければ、すぐに統制が取れなくなる。
多分、MercurialやGitのような分散バージョン管理がその解決方法になるだろう。

反復型開発をどの場面で使うべきか、漸進型開発をどの場面で使うべきか、戦略がはっきりしていないから、未だにアジャイル開発は難しい、と言っているだけなのだ。
それらの問題は、分散バージョン管理とチケット駆動開発を組み合わせれば、開発インフラに関してはほぼ解決できると思う。

今のSW開発は、常に新しい技術を取り込んで、定期的にバージョンアップする宿命を持つ。
変化を取り入れるのはSW開発の宿命。
繰り返し開発は「変化を受け入れる」ことができるのが最大の特徴。
繰り返し開発を制する者はSW開発を制するのだ。