ドライバーとオブザーバーのスキルレベルと経験が異なる場合のペアプログラミング


30

ペアプログラミングは、2人のプログラマが1つのワークステーションで連携するアジャイルソフトウェア開発手法であることを知っています。一方のドライバーはコードを記述し、もう一方のオブザーバーは入力されたコードの各行をレビューします。

しかし、私はこの戦略がこのケースでまだ機能しているのだろうかと思う。例えば

  • プログラミングスキルレベルがまったく異なる場合。
  • ある人が問題の領域で経験したことがなく、別の人が経験した場合。
  • プログラミングのスキルレベルが低い場合でも大丈夫ですか?

上記の場合のペアプログラミング戦略を提案できますか?


13
どちらがより高いスキルレベルを持ち、もう一方をコーチすることになっているのかについて、2人が同意していることを確認します。これらの役割/スキルレベルが明確でない場合、ペアプログラミングはおそらく機能せず、競合につながります。
ジョルジオ

しかし、あなたが提案するように行われた場合、それは途方もない学習機会になる可能性があります。
-Mawg

回答:


27

ペアの経験豊富な人が他の人を指導する気質を持っていると仮定すると、言語または問題領域の経験が少ない人を経験のある人とペアリングすると、知識の伝達が促進されます。経験の浅い人は、言語、ドメイン、アプリケーション、およびチームのベストプラクティスや慣習について指導するメンターがいます。

C2 wikiには、ペアプログラミングを使用した知識の伝達に関する興味深い概要があります。チームのメンターとして採用された上級者は、ジュニアプログラマーから多くのことを学び、より若く経験の浅いソフトウェア開発者とペアになった結果、彼の知識はさらに向上しました。専門のプログラマーがドメインの専門家とペアになっているという話もあります。


同意した。私はチームに後輩がいて、ペアプログラミングによりコードの品質が劇的に向上しました。ただし、彼のコードをペアでレビューすることも非常に役立ちました。
サルタン

2
高齢者が100%のドライバーではないことに注意する必要があります。
HLGEM

13
@HLGEM私は、経験の浅い人がほとんどの場合ドライバーになるべきだと主張しますが、経験のある人はコードの欠陥やスタイルをレビューしたり、テストケースを書いたりします。
トーマスオーエンズ

1
@ThomasOwensに同意します。経験の浅いパートナードライブを持つことで、他のどの方法よりも速く「経験」を育てると同時に、より上級のパートナーと独自のアイデアや洞察を共有することができます。彼らの習熟レベルがずっと近くなるのに時間がかかりません。
エリックキング

1
これにより、上級開発者は彼らが説教することをより実践する義務を負うのだろうか?
ジェフ

16

これは、プログラミングが行われたペアユースケースです。古いひげと若いバッタの間で経験を共有します。

これは双方向の共有です。アジャイル昆虫はリウマチの脳に多くのことを教えます。


1
あなたは、おそらく...私は「リウマチ頭脳」にlol'd、私の1を検討したいけれども
マージャンVenema氏

1
ここでは、「ユーザーストーリー」という用語は当てはまらないと思います。ユーザーストーリーは、ソフトウェアのビジネス要件を説明します。
コンラッドルドルフ

ええ、彼は「ユースケース」を意味すると思います。
ヨルグWミットタグ

Downvoted:言及されたケースをどのように処理するかという戦略についての言葉はありません。
のtry-catch-最終的に

10

現在のチームに昇格したとき、私はJ2EEの初心者でしたが、この分野の専門家でした。私のシニア(新しいチームリーダー)はJ2EEに精通していましたが、プラットフォームには精通していませんでした。

本を読むよりもペアプログラミングでこの4か月間にJava2EEについて多くのことを学び、チームリーダーもプラットフォームについて学びました。

2つの間の経験のギャップは、ペアプログラミングの私見の鍵です。


2
同意した。私は自分でペアプログラミングを想像できましたが、それはまったく無意味だと思います。ギャップは、4つの目が可能性のvin図のより広い範囲をカバーすることに関連するさまざまな視点を作成するものです。同一のスキルと経験を持つ2人は、お互いに同じものを見て利益を得ません。
ジミー・ホッファ

5

私の経験を説明し、そこから「戦略」を引き出すようにします。

私はかつて完全な非プログラマーとペアプログラミングしました。彼は、開発したソフトウェア製品の主題に関する専門家でした。それどころか、問題の領域での経験はありませんでした。また、彼は現時点で私のスーパーバイザーでした(これは奇妙に聞こえるかもしれませんが:)

この方法論の主な利点は、彼の知識領域から多くの事柄の実装を説明する必要があったことです。したがって、実装の正確さとプロセスの理解を確保しました。

もう1つの利点は、作業に集中できることです。気を散らすことはありません(ははは、上司の前でTwitterを開くことを想像してください)。

しかし、ティーブレイクでさえ「仕事から気をそらす」ものになったので(時には彼の観点からではなく、ブレイクなどを求めるのは不便でした)、それは時には非常に威圧的でした。

したがって、入力されたコードをほとんどレビューできなかったため、これは実際にはペアプログラミングではありません。ただし、(少なくともしばらくの間)健全な戦略であるように見えました。開発方法論(つまり、OOPパターンのような複雑なソフトウェア設計手法は含まれていなかった)と主題の両方が比較的単純だったため、最終的にはまったく機能しました。これは、コンパイラを開発する必要がある場合には機能しません。プログラマーではないオブザーバーが明確に定義された小さな作品の開発プロセスに参加している場合でも、それはまだ機能すると考えています。たとえば、「与えられたアルゴリズムによってYとZからパラメータXを計算する」関数のプログラミングを見てもらうことは問題ありませんが、システム設計プロセス全体(ソフトウェアアーキテクチャの開発、つまりクラス、

「配列とは何か」を説明する必要はないので、彼が基本的なプログラマーのスキルを持っている場合は、さらにうまくいくと思います。

それが役に立てば幸い :)


経験豊富な説明です!
サカレス

2

私の経験では、両方のプログラマーのスキルレベルが低い場合、問題になる可能性があります。その場合、多くの場合、コピーと貼り付けのプログラミングを試みる傾向があります。チームが決定した特定のレベルに達するまで、2人の初心者プログラマーをペアにしないことをお勧めします。

それ以外の場合、ペアプログラミングは、もちろん2人の男が自分が知っていることを共有する準備ができていると仮定すると、素晴らしいアイデアになります。すべての人にソースコードを通知するのに最適な方法であるだけでなく、新しいアイデアや議論のための良い場所としても機能します。


低スキルレベルの開発者は、自分でプログラミングするときにコピーアンドペーストする可能性が低くなりますか?これは通常、誰も見ていないときに起こることです。
ジェフ

1

チームメンバーがお互いに敬意を持っている限り、プログラマの経験レベルに関係なく、ペアプログラミングは有益です。経験の浅いプログラマーが、経験豊富なプログラマーの前にいくつかの構文エラー(私たち全員が犯す!)を見つけたとしても、コードのコンパイルにかかる時間は節約されます。

また、特に他のメンバーがオープンマインドを持ち、誰もが何かを教えることができると期待している場合、チームの他のメンバーの能力に対するプログラマーの態度を開くことができると思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.