私はアジャイルとペアのプログラミングに精通しています( http://en.wikipedia.org/wiki/Pair_programming )。複雑な要件がある場合、つまり2組の目が1組よりも優れている場合は、ペアプログラミングが使用されると思いました。
ペアプログラミングは、経験の浅い開発者を訓練し、それらをスピードアップするためにも使用されますか?
また、どのくらいの頻度で使用されていますか。常に、つまり2人の開発者が1つの画面で恒久的に、またはおそらく週に1日一緒に作業するでしょうか?私はこの概念について述べているアジャイルの本を読みましたが、それは使用頻度については触れていません。
ペアプログラミングはではなく、経験の浅いまたはスキルの低い開発者を訓練するために使用されるべきです。
Studies and meta-studies 一般的な概念レベルでペアプログラミングをサポートしますが、ほとんどの場合、品質と生産性の向上は、両方のプログラマーがほぼ同じスキルレベルにある場合にのみ、追加コストを上回ります。
実際、これは学術的設定においてほとんど「ルール」となっています。実践も推奨する大学 学生は同じスキルレベルのパートナーを見つける必要があることを明示的に述べてください 。良くも悪くもない-同じ。
ここでの「スキルレベル」はドメインとタスクに固有であることに注意してください。優れたUI開発者と優れたアルゴリズムデザイナーまたはデータベース開発者をペアリングすることは、優れたUI開発者と完全にグリーンなUI開発者をペアにすることと同じです。
研究(私自身の個人的な経験によって裏付けられた)は、経験の浅い開発者(一部の領域)がペアになっているとより早く学習できることを示しています。
ただし、最もスキルの低い開発者と最もスキルの高い開発者の生産性はほぼ10倍の勾配があります。高度に熟練した人と非常に環境に優しい人のペアリングは、運転教官と学生のペアリングと非常によく似ています。あなたは本当の協力関係を持っていません、あなたは運転手と乗客、マスターと見習いを持っています。見習いが「運転」する場合、マスターはエラーの監視と修正で忙しすぎて、自分の作業を完了できません。一方、マスターが「運転」し、見習いに見習うように指示された場合、中断のためにマスターの生産性が低下し、見習いはあまり効果的に学習しません。
これは勝てない状況です。新しい開発者をトレーニングする必要がある場合は、スペードをスペードと呼び、trainします。または、彼らに見習いをして、しばらくの間、より経験豊富な開発者に「シャドウ」してもらいます。しかし、それを「ペアプログラミング」と呼ばないでください。良い結果が得られると期待してください。これらは、両方のパートナーが同様のスキルセットを持っている場合にのみ発生します。
注:研究を見ることができない人のために、これは同様の主張をしている別のものです:
システムの複雑さとプログラマーの専門知識を考慮したペアプログラミングの評価 。
要約を引用するには:
複雑なシステムの正確さに関してペアプログラミングの観察された利点は主にジュニアに適用されますが、単純なシステムでタスクを正しく実行するための期間の短縮は主に中間者とシニアに適用されます
シニアとジュニアをペアリングすると、シニアに適用される時間のメリットが無効になります。ジュニアが通常生成するものよりも正確性はまだ改善されていますが、シニアが自分で生成するものより優れていることは証明されていません。
最初の研究は実際のmeta分析であり、いくつかの異なるものを組み込んでいるのに対し、これは単一の研究であることを覚えておいてください研究。これは私が見つけた中で最高のリソースです。実際の研究について本当に興味がある人は、ACMメンバーシップの取得を検討する必要があります。これは、これらの研究すべてが公開されている場所だからです。
この答え に強く同意しない。
私は以前、ペアプログラミングを通じてジュニア開発者と新しいジョイナーを指導してきました。レビューで、彼らはそれが非常に有用であるとわかり、一人で放置された人々よりもはるかに速くスピードアップしました。
私が運転していたとき、IDEの範囲内でさまざまなショートカットを使用することがわかりました。これにより、私の生産性が大幅に向上します。運転中に、同じショートカットを使用するように勧めました-数日のうちに、より生産的。
単体テストも別の分野でした。ジュニア開発者の多くは、ユニットテストに触れていませんでした。テストの書き方、命名規則、および優れた単体テストの外観を示すことができました。私が「ナビゲート」しているとき、彼らがテストを書いているときに「ドライバー」にアドバイスすることができました。
この答え に同意しません。
同じレベルか異なるかに関係なく、ペアプログラミングは多くの理由で非常に役立つことがわかりました。
経験の浅いプログラマーをトレーニングするために(質問に直接回答するために)使用されることは間違いありません。
私はそれがうまくいくと思います:
プログラムの知識を伝え、さまざまな部分が何を意味し、何を行うかは、ペアプログラミングの期間を通して行うのが最善です。
経験や背景などにより、プログラマーのスキルと経験レベルにはほとんど常に違いがあります。したがって、私の経験では、「ほぼ同じレベル」が実際に適用されることはほとんどありません。
優れたプログラマーは、他の人から学び、ペアリングを通じて自分の知識を教え、伝えることを知っています。
ペアリングが適切であれば、多くの場合、両方の人がキーボードに同点で費やすことになります。ペアリングするのが好きな人で、以前は「ああ、行き詰まっている(1人目)」と呼ばれていました。 !)」
最高のプログラマーでさえ、彼らが働いているドメインを学ぶ必要があり、それがコードとデータによってどのように表現されているか、ペアプログラミングは多くの場合、そのための優れた方法です。
私はPPを同様の方法で私の仕事で使用します-新規参入者(必ずしも経験のないプラグラマーではない)。通常、これは1週間です。この後、以下にリストされているすべての目標通常満たされます。
目標:
ほとんどのアジャイルと同様に、私は答えは「依存する」と感じます。
経験の浅い人が新しい言語(または他の基本スキル)を習得しようとしているのですか、それともすでに必要なスキルがあり、新しいアプリケーションを習得する必要があるだけですか?彼らが新しい言語やスキルを習得しようとしている場合、私はメンターシップがより適切かもしれないと主張します。あなたがスキルを持っているチームに新しい誰かをオンボーディングしているなら、ペアリングが私が行く方法でしょう。
マスターと新しいグリーンデベロッパーをペアにしないという点には同意しますが、それらが同じスキルレベルである必要があることには同意しません。重要なのは、同じスキルレベルに近い人をペアにすることです。
使用頻度に関しては、あなたのチームメンバーがあなたを助けることができるはずだと思います。おそらく、開発者がペアを組むことを望む、特にトリッキーなストーリーがあるかもしれません。また、誰かが自分で解凍する時間があることを望んでいる、かなり単純なストーリーがあるかもしれません。
最後に、ペアリングするときは、キーボードの経験者が最も少なくなるようにしてください。より経験のある人が運転する場合、その人は「私はそれをすぐに説明します、ちょっと待ってください」の説明とともに、コードの束全体を書く傾向があります。経験の浅い人が運転している場合、何をすべきか/どのようにコードを進めるかについての会話は、よりタイムリーに行われる傾向があります。
乾杯!
ペアプログラミングはそれ自体がスキルであり、ペアプログラミングの利点は、いつどのように使用するかに応じて、非常に広く多様になり得ます。
まったく経験のないプログラマーのチームを管理するときに、新しいプログラマーがチームに参加するときのオリエンテーションツールとして使用しました。 (私は最初のタスクで私がやっていることについて話し、次に2番目のタスクで彼らがやっているとき彼らが何をしているかについて話し、3番目のタスクで彼らの意図した実装と彼らのコードのレビュー-目標:コードの方向付けと彼らの仕事に対する期待の設定。
また、新しいテクニックを誰かに紹介するトレーニングテクニックとしても使用しました。この場合、彼らはキーボードから離れて概念を紹介され、それから数時間または数日後、私たちはペアで設計フェーズをプログラムし、彼らは実装をリードするプログラマーとなり、ガイダンスを提供します必要なところ。 -目標:マルチスレッドコード/非同期コールバックを導入し、短期間で生産的なものを生成する。