ペアプログラミングはいつ機能しますか？いつそれを避けるべきですか？

常にプログラムをペアリングするのではなく、チームでペアプログラミングを選択的に使用します。次のような状況で最適に機能すると思います。

• プロジェクトの新しいチームメンバーを増やします（ドキュメントやコードを自分で歩くのではなく）。
• ジュニアとシニアの人々が一緒に働くことは（より経験豊富な開発者のスキルとトリックの一部を示すのに役立ちます。また、老犬が時々新しいトリックを学ぶことができます）。
• 誰かが欠陥を追跡しようとするとき、それはしばしば新鮮な目のセットとペアリングするのに役立ちます。

ペアプログラムを使用するタイミングとその理由

ペアプログラミングを回避する場合 どうして？

ローリー・ウィリアムズがまとめた研究は、ペアプログラミングが産業チームで最もうまく機能することを示しています。

• ペアは、仕様、設計、および複雑なプログラミングタスクで機能します。実験では、ペアで単純なタスクを操作する場合、品質の改善は示されませんが、速度が改善される場合があります。また、ペアの「プログラミング」には、コードの作成以外のアクティビティが含まれることが多いことに注意してください。
• ペアリングの各個人は、ほぼ同じレベルの専門知識を持っています -ペアプログラミングはトレーニングには最適ですが、ペアはほぼ同じレベルにいるときに最も関与します。
• 役割は定期的に回転します-個人が運転するか、運転しようとしていると感じるときに最も貢献する傾向があるため、定期的に回転することで現在の副操縦士を引き付けることができます。
• ペアは定期的にローテーションします -チームは、構築しているシステムのさまざまな部分を知っていることに安心感を示しています。ペアローテーションは、プロジェクト内の特定のリスクを軽減する知識の伝達に役立ちます。アカデミックな環境では、ペアが割り当てられることがよくありますが、業界では通常、スタンドアップ時に頻繁に割り当てられます。どちらの場合も、ペアリング活動に価値がある参加者が両方とも喜んでいる場合、ペアは最も効果的です。

私の経験では、XPチームは開発時間ペアプログラミングの平均約60％を費やしていることがわかりました。残りの時間は、個々の開発に費やされます。ペアを組んで初期設計を作成し、数時間だけ設計に取り組んでから、一緒に戻ってコードの難しい部分や難しい部分を仕上げることは珍しくありません。

また、ペアプログラミングが約1.5〜2.5時間のブロックで最も効果的であることもわかりました。はるかに少ないものはセットアップするのにあまりにも多くのオーバーヘッドを必要とする傾向があり、多くの場合、ペアは不機嫌になり疲れます。不機嫌で疲れているということは、コミュニケーションがうまくいかず、システムに欠陥が入り込む可能性があることを意味します。

ペアプログラミングは、非常に少ない状況で機能しました。

ペアプログラミングが失敗する場所

短い話は、ペアプログラミングはソフトウェア開発の主要な方法としては機能しないということです。特定の問題に焦点を当てている場合は特に、プログラムを1日または1週間ペアリングできます。しかし、その後？私はこれで終わりです。トースト。私は誰にも会いたくなく、誰とも話したくありません。また、人間の会社に再びふさわしい状態になるまで、少なくとも数日は洞窟で過ごす必要があります。

悲しい話ですが、おもしろいのは、それがどのように終わったのか、今ではとても幸せだということです。自宅やコーヒーショップで仕事をする契約に喜んで雇われており、新しい友達を作り、今まで考えられなかったほどサンフランシスコを探索しました。自転車とラップトップを持っています。締め切りに間に合い、定期的にコードをチェックインしている限り、自分の時間は自分のものです。

ペアプログラミングに関する大きな問題を前もってリストし、後で詳細と逸話を説明します。

1. 分割フォーカス。
2. 実験なし。
3. 高音はありません。
4. 所有権に誇りはありません。
5. 逃げ場はありません...

...同僚に私が見たものを見たかどうか、何かが足りない場合、何かを尋ねました-これがどのように機能するのか、人々がこれをどのように続けることができるのか見ていませんでした。彼らは、私が元気で、順応して調整するのに時間がかかったと言っていました。最初はみんなにとって大変だったこと。

最終的に、私は自分自身に後退しました。目がくらむような頭痛、不眠症、そしてドキドキする、満たされていないコードを書く必要性の間で、私は入力に応答しなくなりました。私はスクリーンを見つめることができ、何も見えませんでした。誰かが予期せずに私に話すことができ、私はそれらを聞くことはありませんでした。私は自分の仕事の必要条件を満たしていましたが、そこにはいませんでした。私はちょうどその日に現れていたすべてを使い果たしました。他のパートナーが入力しているときにiPhoneのチェックを開始しました。

最後に-わずか3か月後、そして初めて-ペアプログラミングのときにチームにふさわしくないという理由で解雇されました。

一人じゃない

私はそれを理解するためだけでなく、それについて話すことができるようにこれを書きました。ペアプログラミングはほとんどの人にとって有効であり、ソロプログラミングよりもはるかに簡単で高速であるという推定があります。これはそうである場合もそうでない場合もありますが、長期的な慣行として、ペアプログラミングは私にとってはうまくいきません。ペアプログラミングがどちらにも機能しない人は他にもたくさんいます。私たちも重要です...

私のチームは、私がそこで働くずっと前から、ほとんど「極端なプログラミング」スタイルのショップの一部として、ペアプログラミングを始めました。ペアプログラミングはデフォルトの状態です。奇数の場合、または調査のために時折、特に敵対的な機器をいじり、それを機能させようとする場合、人々は本当にシングルトンになります。

「ジュニア/シニア」が唯一の方法ではありません。「中間/ジュニア」は便利です。それは、中級レベルの人が、他の人にそれを伝えることを強制することによって得た知識を統合するのを助けます。「中級/中級」とは、2人が協力して知識を共有し、コミュニケーションし、チームの一員として働くことです。そして、2人の本当に年上の人がいるとしても、彼らは異なる専門分野を持ち、異なるアプローチを考え出す可能性があります。知識共有の側面は、誰かがプロジェクトについて漠然と「スピードを上げて」いれば終わりません。むしろ、ペアプログラミングは学習組織の縮図です。新しい技術とベストプラクティスが急速に広まりました。

ペアプログラミングは、コードの品質（欠陥が少ない）とコードの健全性を維持するのにも役立ちます（意図したことを実行するだけでなく、本来行うべきことを実行します...間違ったことをしている穴、または乱暴に競合する2つの異なる正しいこと）。プログラマーが集中力を維持するのに役立ちます。ここでは、シリコンバレーの中心に位置し、週に80時間の仕事があります。1日8時間の集中的なコーディングを行っており、互いにオフ。（また、ペアプログラミングをより長く行った場合は、おそらく反転するでしょう。または、少なくとも燃え尽きます。） これは、ワーク/ライフバランスに最適であり、高速なターンアラウンド（特に低遅延のターンアラウンド）が重要な場合にも組織に役立ちます。

100％桃とクリームだけではありません。ペアプログラミングは、特定の問題に役立つ直感的な脳プロセスのアプリケーションの障害になることがあります。最近では、メモリリークタスクで、ペアを使用する場合と使用しない場合の両方で時間を費やしました。誰もいなかったので、私は自分が何をしていたかをいつでも正確に説明する方法を本当に知らなくても、いじくり回して実験をすることができました。シングルトンで作業することにはいくつかの利点もあります。接線に出て、気まぐれに特定のワイルドリファクタリング（XP方法論で評価）を行うことができます。

しかし、すべてが言ったように、利点はコストをはるかに上回り、ペアリングは私たちにとって見事にうまくいきました：スタートアップ段階から大企業による買収、そしてその後の統合まで。（そういえば、ペアプログラミングは、少しの売り上げにもかかわらず、拡張を通じて文化の継続性を維持するのに役立ちました）。

（ソフトウェアアプライアンスをPerlで開発し、リスト価格は4,000ドルから40,000ドルです。）

「ペアプログラミング」の設定で働いたことはありませんが、あなたがリストした3つの状況の一部であったと主張できます。あなたが言及するシナリオは、支援/トレーニングの段階が組み込まれた、より「通常のプログラミング」のように見えます。「ペアプログラミング」が生まれる前に、私たちはこのすべてをしませんでしたか？ペアプログラミングでは、チーム内で共有するプロセスが、当面のタスクや問題に取り組む分を止めない、よりコミットされたアプローチが必要だと思います。しかし、これは私が「考える」ことではなく、「知る」ことです。

個人的にペアプログラミングのために、私は自分の知識を学び、共有する機会を得られるチームで働きたいです。あなたが働くすべての人があなたよりも数マイル先に進んでいる不均衡なチームは、パーよりもずっと下の方が、非常に素早く面白くないものになる可能性があります。また、私は自分の信念に固執し、説得するのが難しい人々と働くことを恐れます。

過去数か月間、チームでペアプログラミングの実験を行ってきました。チームの別の人とアイデアをすばやくバウンスして検証/無効化できるので、新しいもの（新しいテクノロジー、新機能など）に取り組んでいるとき、私は非常に便利だと感じています。また、並んでピアレビューを行うと、バグを排除できます。

別のチームメイトは、テストでペアプログラミングを使用してATDDを実行しようとしましたが、結果に非常に満足していました（彼の計算によると、開発コストが20％増加するとテスト時間が約50％減少しました）

おやすみなさい

エクストリームプログラミングとペアプログラミングの実践について何度も議論してきました。過去には、プログラマーが集中と隔離を必要としていたため、プログラミングは単独の活動であることを理解できました。当時のプログラマーは、コードに効率的に焦点を合わせ、素敵で創造的な決定を下すことができる精神状態であるゾーンにいました。

1人のプログラマが互いに割り込んだと仮定すると、ペアプログラミングも危険なようです。一方、一緒に作業している2人のプログラマを中断することはより困難です。たとえば、ソロプログラミングでは、中断が容易になるため、ソロプログラマが「ゾーン」にとどまることはほとんど不可能です。

デッドラインがすぐそこにある場合、コードの品質は別です。人々はいつも急いでいて、ペアプログラマーかソロプログラマーです。彼らは特定のベストプラクティスを適用せず、ユニットテストを忘れます。

私はペアプログラミングに固執します。リスクが発生したとき、あるプログラマーがいなくなったとき、プロセスを文書化し、他のすべての人にその仕組みを教えるために、常に別の男がいるからです。

複雑ではないものに取り組むことは、ペアプログラミングの良い候補になる傾向があります。そのため、複数の人がコードベースの一部を知っているだけの開発者ではなく、コードを理解します。別のケースは、誰かがいくつかのスキルを移転したい場合です。ここでの例は、ユニットテストが本当に得意な人と、コンセプトにあまり詳しくない人とペアを組むことで、何かの最初の習慣を身につけるのに役立ちます。

ペアプログラミングを回避する場所については、作業を2つのグループに分割し、各開発者に作業の一部を個別に実行させて作業を完了させる方が簡単な、単純な作業タスクを退屈させます。一部のタスクはかなりのタイピングを必要とする場合がありますが、あまり大きくないので、各開発者が少数のブルートフォースアプローチをとる場合に実行できるより良い方法を見つけるために数時間を費やす価値があります時間。