アジャイルはチームメンバ内のコラボレーションを奨励している。コラボレーションを向上させる方法のひとつがペアプログラミングだ。だがそれで十分なのだろうか？ Valentin Tudor Mocanu氏が先日，自身のブログ記事"re-interpreting pair programming"で，ペアプログラミングの進化形について説明している。
ペアプログラミング，それは高度に効果的なプラクティスです。しかしそれが，チーム内に必要な共同作業であると言えるほど十分なカバレッジを持っているのかどうか，という点には疑問が残ります。
氏はペアプログラミングがあまりにも文字通りに，あたかも直接的なコーディング作業だけを対象としているように解釈されていると言う。XPにおけるプログラマとは，計画やアーキテクチャ設計，コーディングやテストにも関与する，複数の役割を持った開発者だ。従って"ペア開発"という方が，はるかに適切な用語だろう。
ペアリングはもっとも一般的なアプローチだが，共同開発という場合には，２人より多い開発者が含まれる可能性もある。
DAD(Disciplined Agile Delivery)ではScott Ambler + AssociatesのシニアコンサルティングパートナであるScott W. Ambler氏が，この広義の共同開発アプローチを表現するために，非単独開発(non-solo development)というプラクティスを取り入れている。
非単独開発はプログラミングやコーディングを越えたアジャイルのプラクティスであり，ペアリングと個人の開発技術を組み合わせた混合アプローチといってよいだろう。
非単独開発について氏が示す見解は，次のようなものだ。
私は非単独開発を強く信じていますが，重要なのは，それがプログラミングだけのものではないという点です。アジャイルのモデリングにおいて，私たちは，共同で行うモデリングのプラクティスを促進してきました。これはXPのペアプログラミングを発展させたものです。ペアプログラミングは２人で行うものですが，モデリングをもっと多い人数で行うことはもちろん可能です。
いずれにせよ，私たちがDADで非単独開発を勧めている理由のひとつは，それが非常に多くの状況で機能するものだからです。
Valentinはさまざまなプロジェクトや製品，チーム，そして開発事例での，自身の作業経験を語っている。このプラクティスは複雑な要件の明確化やアーキテクチャ構築，設計上の判断において有用だ，と氏は言う。
非単独開発の例として，氏は次のようなアジャイルプラクティスを挙げる。
-
- プランニングポーカー，スプリントの計画と再計画などは，目標は計画の立案ですが，アクティビティのタイプは混合されている(要件，解決策，計画)という意味で，非単独プラクティスであると言えます。
- モデルストーミング(DADより) - 主要なアクティビティのタイプは設計です。
さらに氏は，個々の用語についても，次のように明確化している。
- ペアプログラミング - コアアクティビティである"コーディング"を効率化したい場合のプラクティス。
- ペア開発 - 開発全般をおもにペアリングで実施するプラクティス。
- 非単独開発 - 一般的には，複数のタイプを組み合わせたアクティビティに対して，2人より多い人々が関与すること。
さらに氏は，単独開発と(２人あるいはそれ以上による)ペアリングとの混合アプローチによる共同開発についても説明している。このアプローチを自身のチームに適用することで，製品知識の学習曲線も大きく改善されて，よい結果を得られたということだ。