ペアプログラミングの理由
私はいくつかのショップで働いていて、経営陣がペアプログラミングのアイデアを自分または別のマネージャー/開発者に渡しましたが、それをまったく後回しにすることはできません。開発者の観点からは、このコーディングスタイルに移行することが有益である理由を見つけることができません。また、小規模なチームのマネージャーとして、何のメリットもありません。
基本的な構文エラーに役立ち、何かをハッシュする必要がある場合に役立つことは理解していますが、プログラミングループから外れたマネージャーは、デザイナーがFacebookやRedditに行くのではなく、FacebookやRedditに行くのを防ぐ方法として見続けているようです設計ツール。
開発フロアの近くにいる誰かが、主題についての本やwikiページを振り回した本からはまったく理解できないようです...上級管理職の立場から、スクラムまたはアジャイルを扱うときのペアプログラミングの利点は何ですか環境？
部分的には、ペアプログラミングの方法によって異なります。場合によっては、ペアのドライバーがコードを記述しているときに、ペアの2番目のメンバーがシステムの設計と実装の詳細を監視および議論しています。ペアプログラミングのもう1つの例は、2人が同時にコードを書くことです。1人は実装された機能を書き、もう1人はユニットと統合レベルでテストコードを積極的に開発して書き、システムの設計と実装の詳細を話し合います。
ペアプログラミングのタイプに関係なく、効果的に継続的な コードレビュー として機能します。コードを2人の目で見て、エラーが後のシステム/受け入れテスト環境またはフィールドにエスケープされる前に監視します。また、システムの特定の部分を非常によく理解している2人がいて、 バス係数 を最小限に抑えるための冗長性として機能しています。欠陥を早期に発見し、システムの知識をチーム全体に広げることにより、システム構築のコストが削減されます。
知識の普及は、チームの技術的な知識だけにとどまりません。ペアが誰であるかに応じて、コーディングスタイル、企業文化、期待など、プロジェクトの枠を超えた他の事柄について、会社のより上級のメンバーから新しいメンバーに情報を流すことができます。また、テクノロジーやツールに詳しいユーザーが、そのテクノロジーやツールに関する知識を実際の環境で共有することもできます。
あなたが述べたように、それはまた、開発者を集中させ、 flow に保つのに役立ちます。フローに加えて、多くの個人は、何かに取り組んでいる単一の個人よりも、何かに取り組んでいる複数の人々に割り込む可能性が低いです。あなたが誰かの机のそばを歩いていて、彼らが一人で働いているが、あなたが彼らと話す必要があるなら、あなたはノックして彼らと話すかもしれません。これは、2人以上の人が共同で作業したり、ディスカッションを行ったりしている場合は、起こりにくく、中断することはありません。中断には時間がかかり、より多くの時間を費やすことはより高いコストを意味します。従業員の生産性を最大化することは、ビジネスの最大の利益になります。
ただし、ペアプログラミングを実行可能にするために克服しなければならないいくつかの課題があります。パーソナリティの衝突やペアを選択して知識を適切に分配することなどを検討してください。ペアをローテーションするタイミングを正確に検討する必要もあります。無計画に行われたペアプログラミングは、計画されたものとしておそらく効果的ではありません。チームの構成によっては、ペアリングするのが効果的でない場合があります。
簡単な回答：ほとんどのメリットとコストは Wikipedia に掲載されていますが、少し異なる角度から見てみましょう。
ブログ投稿 から取得した、アジャイル/スクラム開発環境に適用されるペアプログラミングの利点の特定のケースについて述べたいと思います。
ソフトウェアの成否は品質に依存し、ペアプログラミングはさまざまな方法で品質を直接向上させます。 2人の開発者が共同で作業する場合、ペアが短く、バグが少なく、保守が簡単で保守しやすいコードを開発することで、設計パターンの品質が向上します。バグはソフトウェア開発における主要な品質問題です。 2つの目でコードを書くことで、より多くの間違いが発見され、開発コストが削減されます。開発プロセスの後半で発見されたバグは、修正にコストがかかることがよくあります。ソフトウェアの欠陥を早期に発見することは、将来の困難な問題を防ぎ、阻止するのに役立ちます。プログラミングはしばしば複雑になり、問題を一緒に解決しようとする2人の心が1つよりも多くのオプションを見つけ、結論をすばやく導き出すことができます。
要約すれば：
- チームのコミュニケーションを促進する
- 効率的なアプリケーション知識の伝達を促進
- 設計アプローチの説明責任を促進
- コードが改善され、保守が容易になります
- 初期段階でバグのあるコードを排除するのに役立ちます
- コーディング中にチームメンバーが細心の注意を払うため、チームの生産性が向上します
- チームメンバーのコミュニケーションとコラボレーションのスキルを向上させる
- 職場で仲間意識を築く
- 仕事をもっと楽しくする
最終コードでのエラーの減少（効率）
コードレビューを完全に置き換えるものではありませんが、早期に物事を正しく進めるために非常に効果的です。その方向を指す研究がそこにあります。迅速な完了（効果）
これを指摘するいくつかの研究があります。複雑な機能に関しては、2つのヘッドの方が効果的です。これにはペアリングの経験が必須です。
（注：これはマネージャーのセールスピッチです：バグの数を減らして効率を上げ、完了を早めることでより効果的になるため、財政的には健全な決定です）
- ジュニアを教える
経験豊富なプログラマに直接ジュニアを追加できます。絶対初心者のグループがいる場合は、簡単に固執して、ペアで基本を理解するのは簡単です。周りに固執し、アドバイスを与えます。コンセプトは明らかに非常に古く、職人の技に由来しています。
ペアプログラミングにはいくつかの利点があります。
- 2人のプログラマーが一緒に設計に協力して、より良いアーキテクチャー/コードを生成できる可能性があります-2組の目は間違いを見つけることができます
- 教育機関の知識はより適切に保存されます-あるプログラマーが去るか、または利用できない場合、他のプログラマーは生産性をそれほど失うことなく作業を継続できるはずです
- これは、新しい開発者をすばやくトレーニングする1つの方法です-開発者と経験豊富な開発チームのメンバーをペアにすると、チームのベテランの観点からコードベースを経験できます。
- 規律の改善-どちらか一方のアクティビティがバーストを引き継ぐことができるので、ペアのプログラマーはより長期間にわたって生産性が高い可能性があります。単体テストのような退屈な可能性のあるタスクは、単独の開発者よりも頻繁にスキップされない場合があります。
ウィキペディアには wikiエントリ にコストとメリットの素晴らしい要約もあります。