最近、統一プロセスの多様性／諸相に関する議論がここに紹介された。InfoQ読者の間でおきたオープン統一プロセス（オープンUP）に関する論争の中には、より広い領域における論争を映し出しているものがある。
UPメンタのMark Lines氏は「アジャイル開発がUPを成長させる」と題された記事を書いている。その中で氏はScott Ambler氏を引用し、アジャイルの世界にいる多くの人が企業における現実を過小評価しているか無視していると主張している。
- 私たちの多くはコロケーション（"co-location"）の恩恵に預かっていません。これはチーム全体が近い場所（理想的には同じ部屋）で作業するというものであり、ユーザの代表者も質問に答えるために常に同じ場所にいるというものです。
- ペアプログラミング、つまり２人のプログラマが１つのキーボードを共有するという出費は、ほとんどの経営陣が承認しようと思わないものです。
- 適切に詳細化された要件（ユーザストーリー以上のもの）を作らずにシステムを提供することは、テストやトレーニング教材の作成、製品サポートという観点から見ると受け入れられるものではありません。
- 最初にアーキテクチャ的な設計を行わず、進行と共にアーキテクチャを修正する（つまり、リファクタリング）ということは、大規模エンタープライズシステムにとって好ましいことではありません。
- ほとんどのプロジェクトは完全に独立したものではなく、別々の場所に構築することはできません。他のシステムとの依存関係と統合が必要なのであり、そこには何らかの調整が必要になります。
- 組織には通常何らかのガバナンスプラクティスがあります（例えば、PMOやISO、CMMIなど）。そしてこれは一定の役所仕事と文書作成を必要とするものです。
- １、２週間ごとにユーザに向けてソフトウェアをデプロイするということは、ほとんどの組織において現実的ではありません。開発、テスト、システムテスト、ユーザ受入、製品環境といったものが主な取り組みとしてあります。多くのプロジェクトにおいてこれを１週間単位で平行させることを実現するのは、単純に不可能なのです。
氏はオープンUPの概要について続いて語り、このオープンUPがより広範囲にわたる企業の課題を扱うのに十分なフレームワークかつプロセスであり、同時にアジリティの中核を保っていると主張している。
オープンUPと一般的な統一プロセスのアプローチを対比させた視点は、Michael Dubakov氏による応答に見ることができる。この「安心しなさい、アジャイル開発は成長している」において、氏はそれぞれの課題に取り組んでいる。
コロケーションについて
もちろん、チームが同じ場所にある方が良いことは誰もが分かっています。コンサルタントがチームメンバに同じ場所で作業させるようにアドバイスするのも驚くことではありません。レースに勝ちたければ、フォードのフォーカスよりもBMWのM3に乗った方が良いということです。分散アジャイルに関して、今年は多くの議論が繰り広げられました。遠隔地でどうアジャイルを実践するのかについては、アイデアと体験レポートが多くあります。アジャイルはチームが離れていても機能するのです。
ペアプログラミングについて
これは実に奇妙な議論です。多くの経営者は、継続的インテグレーションやイテレーティブな開発、そしてふるまい駆動開発（BDD）を支持しないでしょう。しかし、だからと言ってこういったプラクティスが悪いということではありません。コンテキストが全てなのです。いくつかの企業やプロジェクトにおいて、ペアプログラミングが生産性を向上させることもあるでしょう。一方でプロジェクトによっては、恩恵がないだけでなく悪化することもあるでしょう。アジャイルのコーチで、ペアプログラミングを強く主張し、「ペアプロをしなければアジャイルではない」と言う人がどれほどいるでしょうか。そう多くありません。この議論をアジャイルコミュニティ全体に広げることが間違っているのです。
詳細な要件について
ちょっと！ユーザストーリーは「とても」詳細化できるものなのです。たとえば、BDDスタイルのユーザストーリーフォーマットを利用し、ある別のフォーマットで記述されることになるであろう多くの機能を記述すると、それが直接ユニットテストに変換されるのです。正直に言って、これは信じられないことです。 http://www.targetprocess.com/blog/2009/10/bdd-and-user-story-specification-examples.html
アーキテクチャについて
アジャイルコミュニティのほとんどの人々は、アーキテクチャにある程度の時間を割く必要があると信じています。しかし、これもコンテキストによるのです。シンプルなアプリケーションを作るのであれば、１日あれば重要な決定事項をすべて見極めることができるでしょう。複雑なシステムを作る場合には、数ヶ月かかるかもしれません。一般常識がここで重要な要因になるのです。過度なアーキテクトという危険性は常にあり、動作するソフトウェアこそが最善の概念実証（"proof of concept"）です。同様に “発生的なアーキテクチャ（"emergent architecture"）”と呼ばれるものが開発されています。私はこの考え方が好きですし、正しい方向に向かっていると思います。http://www.infoq.com/emergent_architecture
プロジェクトの独立性について
アジャイルの適用は急速に広がっており、実際にはこの問題を解決するための共通で標準的なアプローチは存在しません。しかし、アジャイルの企業への適用が進む過程で解決されて行くと信じています（そして私たちはすでにこのフェーズに入っています）。
ガバナンスと標準について
これは、PMOやISO、CMMが優れていて、これらのルールに従うためにはあきらめなければいけないという意味でしょうか？アジャイルコミュニティは激しく戦おうとしており、私は個人的にそのことをとても好ましく感じています。文章化のプロセスは、ソフトウェア開発プロジェクトの成功にとって何も意味しません。９割方、ドキュメントはあなた方をクモの巣にとらえ、創造性を阻害するのです。創造性なしにできるソフトウェア開発など「一切ありません」。目を覚まして下さい、Mark。私たちはこれらの標準と生きてはいますが、戦うべき相手なのです。
頻繁なリリース
この議論はきわめて一般的なもので、「ほとんどの組織において現実的ではない」というフレーズは本当に傑作です。統計的なデータがあるんですか？Markはエンタープライズ規模の古いJavaアプリケーションの世界から離れて何かをデプロイしようとしたことがあるのでしょうか。多くのSaaSサービスは何事もなく毎週更新しています。サービスによっては、何事もなく毎日アップデートしています！信じられないことですが、私はそれが好きです。顧客もそれが好きなのです！
あなたはどちら側に賛成だろうか。読者のフィードバックを共有されたい。