ペアプログラミング環境でパフォーマンスをどのように実証しますか？

最近、私の仕事でパフォーマンスのレビューが出てきて、私は興味深い立場に置かれました。私たちのチームは多くのペアプログラミングを行っていますが、これはチームメンバー間のスキルの差を平均化する傾向があります（特にペアをローテーションすることを考慮して）。一般に、パフォーマンスレビューを行うときは、行った作業を振り返り、達成したことと、昇給やその他のメリットを交渉しようとする期待をどのように上回ったかを示します。

このような環境で個々のパフォーマンスをどのように実証（または測定）しますか？

ペアプログラミングに追加した価値をパフォーマンスレビューに含めます。他のプログラマが役に立つことを学ぶのを助けましたか？（およびその逆、あなたは彼/彼女の賢明なアドバイスに耳を傾け、うまく協力しましたか？）

パフォーマンスレビューは競争ではなく、個人的な目標に関連するコーチング評価である必要があります（おそらく会社の目標に沿っており、年初に相互に合意します。それ以外の場合は任意です）

あるパフォーマンスの利点を他の科学的な効果よりも明確に証明するのは難しいでしょう。

あなたの仮説は、ペアプログラミングは開発者のパフォーマンスを向上させ、品質を向上させるというものです。テストでは、特定のアーキテクチャに制約された一連の要件をペアに与え、それを実装させる必要があります。

この場合の制御は、同等の地位、スキル、および経験を持つ1人の開発者（同僚から客観的に判断される）に同じ要件を与え、同じアーキテクチャ内に制約されることです。

時間パフォーマンスの仮説を検証するには、ペアプログラマはコントロールとして半分の時間で作業を完了する必要があります。品質に関する仮説を検証するには、実験ペアと制御コードを客観的な第三者がレビューし、客観的なQAグループに、どのチームが何を生み出したかを伝えることなく、両方のグループの結果をテストしてもらう必要があります。ペアプログラミンググループには、より良いコードと少ないバグが必要です。

これは完璧な実験ではありませんが、似たようなことを試みた人がいるかどうか聞いて魅了されるでしょう。

ただし、これに加えて、特定の機能においてペアプログラミングが単一のプログラマよりも優れていることを実際に証明する方法はわかりません。

パフォーマンスメトリックでは、1）個々の成長と開発、2）メンターシップとピアサポートを個別に呼び出します。各従業員が自己評価を行い、リードのフィードバックを取り入れることができます。あなたの会社の文化でそれが理にかなっているなら、ピアレビューまたは推薦状を考慮してください。

正しく行われた場合、ペアリングから最も教育的価値を得ている従業員はチームに貢献する長期的な能力に報われ、スピードを上げるのを助けている従業員は知識と経験を移転することに報われます。中間のどこかにいる（ジュニアからシニアに移行する代わりに新しいドメインを学習する）人は、方程式の両端で認識されます。

実際には、個々のパフォーマンスの評価は、最良の場合には注意が必要です。someみや競争を感じずにそれをするのはかなり難しい。しかし、チームへの個々の貢献を評価し、学習と教育の両方を重視する場合、多少の摩擦なしにそれを機能させる可能性があります。

ペアは頻繁に切り替わりますか？その場合、匿名のレビューを使用してゲージを作成できます。たとえば、AがBが仕事の60％を行い、Cが人物Bが仕事の30％を行い、Dが人物Bが仕事の90％を行うと言った場合、B作業の60％。人Bがペアで達成した仕事の相対係数が100ポイントである場合、人Bは60ポイントの仕事をしました！

しかし、これは（どこにでも）完璧ではありません。人々は他の人に与えるよりも多くのクレジットを自分自身に与える可能性が高いので、計算でこれを考慮する必要があるかもしれません。これは、ペアが互いに疑わしい環境につながる可能性もあります。計算は、作業している人を好まない人などによってシフトされる場合もあります。

私たち2人が協力してXを作成した場合、私たち2人はXを完成させて展開したことに対する称賛を得ます。問題が発生する可能性があるのは、ペアの一部がまったく機能しなかった場合です。この場合、マネージャーはこのことについてずっと通知されているはずなので、パフォーマンスレビューへのコメントを記入するときにそのフィードバックを使用する必要があります。

あなたは、私の先生が私たちのゲーム開発カリキュラムで生徒たちに課している正確な状況にいます。私たちはペアになっており（クラスの規模とプロジェクトの規模に応じて2、3、または4人）、最後に、各チームメンバーとプロジェクトに関連して自分自身を評価するように言われます。他のチームのプロジェクト全体。これらの評価に基づいてグレードが策定されます。

チームの編成中、教師は意図的に強力なプログラマーと弱いプログラマーを一緒に配置し、お互いに助け合ったり助けたりすることを望みますが、99％の時間、弱いプログラマーはすべって滑らず、ほとんど何もしません。彼らが何をしているかについての手がかりはありません（これは上級コースなので、非常にイライラします）。

評価は非公開であることになっていますが、言うまでもありませんが、誰もがもう一緒に仕事をすることを拒否している人がいます。

ペアプログラミングとは、1人が何をどのように行うべきかを考え、もう1人がコーディングモンキーを演じることを意味します。その後、ある時点で彼らは切り替えます（退屈、疲れなど）。両方が彼らの活動で中断されないので、それは良いです。

一部の人々はまた、「ステロイドに関するコードレビュー」と考えています。あなたはレビューされたコードを取得します。これはより高い品質を意味するはずです。

いい質問ですね。重要なのは、単にあなたが貢献したものではなく、同僚があなたの貢献をどのように見ているかです。あなたがより良い「何であれ」であるのに役立つのはこのフィードバックだからです。真剣に、あなたの仲間はあなたの貢献を理解することが重要であり、彼らはあなたとペアを組んでいる間に彼らがかなりの学習をしたときにのみそれを理解する。幸せなコーディング、共有、学習により、良い収益が得られます。

ペアプログラミングの短所は、経験豊富なプログラマの生産性が短期、中期的には経験の少ないプログラマの生産性に制限されることです。長期的には、ジュニア開発者の経験と生産性が向上します。