ペアプログラミングはいつ機能しますか？いつそれを避けるべきですか？
常にペアでプログラムを組むのではなく、チームでペアプログラミングを選択的に使用します。次のような状況で最適に機能すると思います。
- プロジェクトでまったく新しいチームメンバーをどんどん増やしていきます（自分でドキュメントやコードを確認するのではなく）。
- ジュニアとシニアの人々が一緒に作業すること（より経験豊富な開発者のスキルとトリックのいくつかを示すのに役立ち、さらに、古い犬が新しいトリックを時々学ぶことができます）。
- 誰かが欠陥を追跡しようとしているとき、それはしばしば新しい目とペアを組むのに役立ちます。
ペアプログラムを使用するタイミングと理由は？
ペアプログラミングを避けるべき時は？どうして？
ローリー・ウィリアムズによって編集された研究 は、ペアプログラミングが産業チームで最もうまく機能することを示しています。
- ペアは仕様、設計、およびcomplexプログラミングタスクで機能します-実験により、単純なタスクでの作業では品質の向上が見られないことが示されていますペアになりますが、速度が向上する場合があります。また、ペアの「プログラミング」には、コードの作成以外のアクティビティが含まれる場合が多いことに注意してください。
- ペアリングの各個人は、ほぼ同じレベルの専門知識を持っています-ペアプログラミングはトレーニングに最適ですが、ペアがほぼ同じである場合に最も関与しますレベル。
- 役割は定期的に回転します-定期的に回転することで、現在の副操縦士を従事させ続けることができます。
- ペアは定期的にローテーションします-チームは、構築しているシステムのさまざまな部分を知ることに安心感を表明しています。ペアローテーションは、プロジェクト内の特定のリスクを軽減する知識の伝達に役立ちます。アカデミックな設定ではペアが割り当てられることがよくありますが、業界では通常、スタンドアップ時に頻繁に割り当てられます。どちらの場合も、ペアリングは、両方の個人がペアリングアクティビティに価値を見出す参加者を喜んで受け入れる場合に最も効果的です。
私の個人的な経験では、私のXPチームは平均して開発時間ペアのプログラミングの約60％を費やしています。残りの時間は個別の開発に費やされています。それは珍しいことではありませんペアリングして最初のデザインを作成し、数時間デザインに一人で取り組み、その後一緒に戻ってコードのトリッキーまたは難しい部分を完成させます。
また、ペアプログラミングは約1.5〜2.5時間のブロックで最も効果的であることがわかりました。はるかに少ないものはセットアップに多くのオーバーヘッドを必要とする傾向がありますが、はるかに多くのものはペアが不機嫌で疲れる傾向があります。不機嫌で疲れていると、コミュニケーションがうまくいかなくなり、システムに欠陥が入り込む可能性があります。
ペアプログラミングは、ごくわずかな状況で機能しました。
簡単に言えば、ペアプログラミングはソフトウェア開発の主な方法としては機能しません。特に特定の問題に焦点を当てている場合は、プログラムを1日または1週間ペアにすることができます。しかし、その後？私はこれで終わりです。トースト。私は誰にも会いたくないし、誰かに話しかけたくもありません。また、人間の会社にふさわしい状態になるまで、少なくとも2日間は洞窟にいる必要があります。
悲しい話ですが、おもしろいのは、それがどのように終わったのか、今とても幸せになったことです。私は家で、またはコーヒーショップで働く契約を結んで幸せに働いており、私は新しい友達を作り、今までにないほどサンフランシスコを探索しました。私は自転車とラップトップを持っていて、締め切りに間に合い、定期的にコードをチェックインしている限り、私の時間は自分のものです。
ペアプログラミングで発生する大きな問題を前もってリストアップし、後で詳細と逸話を紹介します。
- フォーカスを分割します。
- 実験はありません。
- 高音はありません。
- 所有権に誇りはありません。
- 逃げ場はありません...
...私は同僚に私が見たものを見たのか、何か欠けているのか、何かを尋ねました-これがどのように機能するのか、人々がこれをどのように続けることができるのかわかりませんでした。彼らは私がうまくやっていると言った、落ち着いて調整するのに時間がかかっただけだ。最初は誰にとっても難しいことでした。
結局、私は自分自身の中に後退しました。目がくらむような頭痛、不眠症、そしてドキドキする、満たされていないコードの必要性の合間に、私は入力に応答しなくなりました。画面を見つめても何も見えない。誰かが突然私に話しかける可能性があり、私はそれらを聞きません。私は自分の仕事の重要な要件を満たしていましたが、そこにはいませんでした。その日に出てきたばかりのすべてを使い果たしてしまった。他のパートナーが入力しているときに、iPhoneのチェックを始めました。
最後に、3か月後の恥ずかしがり屋で、初めてのことですが、ペアプログラミングをしているときにチームフィットではなかったために解雇されました。
一人じゃない
私はそれを理解するだけでなく、それについて話すことができるようにするためにこれを書きました。ペアプログラミングはほとんどの人にとって機能し、ソロのプログラミングよりもはるかに簡単で高速であるとの仮定がありました。これは当てはまる場合とそうでない場合がありますが、長期的には、ペアプログラミングはうまくいきません。他にもペアプログラミングがうまく機能しない人がたくさんいます。私たちも重要です...
私のチームは、最初からペアプログラミングを行っており、そこで働く前に、ほとんど「極端なプログラミング」スタイルのショップの一部として働いていました。ペアプログラミングはデフォルトの状態です;人々は本当に奇数がある場合にのみシングルトンに行きます、あるいは時々調査のために、特に敵意のある機器をいじり、それを働かせようとすることを含むものは本当に行きます。
「ジュニア/シニア」が唯一の方法ではありません。 「中級/ジュニア」は便利です。中級レベルの人が、他の人にそれを伝えるように強制することで、彼が得た知識を統合するのに役立ちます。 「中級/中級」は、2人が協力して知識を共有し、コミュニケーションを取り、チームの一員として働くことを課題としています。そして、あなたが2人の本当に年上の男性がいる場合でも、彼らは専門分野が異なり、異なるアプローチを考え出す可能性があります。知識共有の側面は、誰かがプロジェクトについて漠然と「スピードアップ」した後でも終わりません。むしろ、ペアプログラミングは 学習組織 の縮図です。新しい技術とベストプラクティスは急速に広まりました。
ペアプログラミングは、コードの品質（欠陥が少ない）とコードの健全性を維持するのにも役立ちます（意図したことを行うだけでなく、すべきこと）。 ..理想的には、数週間のうさぎの穴を下ることなく、間違ったこと、または激しく競合する2つの異なる正しいことをします）。プログラマーが集中力を維持するのに役立ちます。ここでは週80時間稼働のシリコンバレーの中心部で、1日8時間の集中的なコーディングを行っているため、週40時間しか作業できません。お互いにオフ。 （また、ペアプログラミングを長く続けた場合は、おそらく逆転するでしょう。または少なくとも燃え尽きます。）これは、仕事と生活のバランスに優れており、また、迅速なターンアラウンド（特に低レイテンシのターンアラウンド）が重要な場合の組織。
完全に100％の桃とクリームではありません。ペアプログラミングは、特定の問題に役立つ直感的な脳のプロセスの私のアプリケーションへの障害になることがあります。最近では、メモリリークタスクで、ペアを使用する場合と使用しない場合の両方である程度の時間を費やしました。誰もいなかったので、自分が何をしていたのかを正確に説明する方法を正確に知らなくても、いじり回ったり実験をしたりするのが自由になりました。シングルトンの作業にはいくつかの利点もあります。接線から離れ、気まぐれに特定のワイルドリファクタリング（XP方法論で評価））を実行できることです。
しかし、結局のところ、利点はコストをはるかに上回っており、ペアリングは私たちにとって見事にうまくいきました。つまり、立ち上げ段階から大企業による買収、そしてその後の統合までです。 （そういえば、ペアプログラミングは、少しの離職にもかかわらず、拡張を通じて文化の継続性を維持するのに役立ちました）。
（ソフトウェアアプライアンスはPerlで開発されており、定価は$ 4,000〜$ 40,000です。）
私は「ペアプログラミング」の設定で働いたことはありませんが、あなたが挙げた3つの状況の一部であったと主張できます。あなたが言及するシナリオは、支援/トレーニングのフェーズが投入された、より「通常のプログラミング」のようです。「ペアプログラミング」が実現する前に、これらすべてを実行しませんでしたか？ペアプログラミングでは、チーム内で共有するプロセスが、当面のタスクまたは問題に取り組む分を止めない、よりコミットされたアプローチが必要になると思います。しかし、これは私が「知っている」ものではなく、私が「考える」ものです。
個人的にはペアプログラミングのために、自分の知識を学び、共有する機会が得られるチームで働きたいです。あなたが働いているすべての人があなたのすぐ先にいるアンバランスなチーム、またはそれから標準をはるかに下回ると、かなりすぐに興味をそそることがなくなります。また、自分の信念に固執し、説得するのが難しい人たちと一緒に仕事をすることを恐れます。
私たちは過去数ヶ月間、チームでペアプログラミングを実験してきました。何か新しいもの（新技術、新機能など）に取り組んでいるときは、チームの他の人とアイデアをすばやくバウンスして、それらを検証/無効化できるので、とても便利だと思います。また、サイドバイサイドのピアレビューは、バグを防ぐのに役立ちます。
別のチームメートがATDDを行うためにテストとペアプログラミングを使用してみましたが、彼らは結果に非常に満足しています（彼の計算によると、20％の開発コストの増加はテスト時間の約50％の減少につながりました）
おやすみなさい
エクストリームプログラミングとペアプログラミングの実践について何度も議論してきました。プログラマーは集中力と孤立が必要だったので、プログラミングはソロ活動であることを過去にさかのぼって理解できます。当時のプログラマーはzoneという精神状態にあり、コードに効率的に集中し、ニースで創造的な決定を下すことができました。
1人のプログラマがお互いに割り込むと想定すると、ペアプログラミングも危険に思われます。一方、一緒に作業している2人のプログラマに割り込むのはより困難です。たとえば、ソロプログラミングでは、中断が容易になるため、ソロプログラマが「ゾーン」に留まることはほとんど不可能です。
デッドラインが間近に迫っている場合、コードの品質はもう1つです。人々は常に急いでいる、ペアプログラマーまたはソロプログラマーです。彼らは特定のベストプラクティスを適用せず、ユニットテストを忘れます。
私はペアプログラミングに固執します。なぜなら、リスクになると、あるプログラマーがいなくなったときに、プロセスを文書化し、それがどのように機能するかを他の全員に教えるために、常に別の担当者が必要になるからです。
複雑でないものに取り組むことはペアプログラミングの良い候補となる傾向があり、コードベースの一部を知っている1人の開発者だけでなく、複数の人々がコードを理解できます。別のケースは、誰かがいくつかのスキルを転送したい場合です。ここでの例としては、ユニットテストに非常に優れた人物と、コンセプトにあまり詳しくない人物とのペアがあり、何かに最初の習慣をつけるのに役立つ場合があります。
ペアプログラミングを回避する場所については、作業を2つのグループに分け、各開発者が作業の一部を個別に実行して作業を完了するのが適切である場合は、単純明快な作業タスクを実行します。一部のタスクはかなりのタイピングを必要とする場合がありますが、それほど大きくないため、各開発者がブルートフォースアプローチをいくつか実行する場合に実行できるため、数時間かけてそれを行うためのより良い方法を見つけることは価値があります。時間。