問題タブ [pair-programming]

• コード ピア レビューに参加するか、ペア プログラミングを実践しますか、あるいはその両方ですか?
• これらのプラクティスを使用して、ソフトウェア品質の向上を実証できましたか?
• 実践の過程でどのような利点と欠点が見られましたか?
• 実装に向けてどのようなハードルに直面しましたか?

私の場合、開発チームはさまざまなソフトウェア アーティファクト (要件分析、テスト計画、コードなど) のピア レビューを行いました。ピアプログラミングはオプションとさえ考えられていませんでした。

ピア レビューの慣行は上から押し下げられ、開発者はそれを受け入れることはありませんでした。アクティビティからメトリックを収集する外部の SQA グループがありましたが、努力が中途半端だったため、数値はほとんど価値がありませんでした。これが何年にもわたって「公式」の方法であった後、開発者は所定の手順を集合的に無視するようになりました。

現在、バグがライフサイクルに割り込んでいる時期が見えにくくなっています。また、ピア レビューを行わないことで、チームの専門性が高まり、システムの専門分野以外のコンポーネントの要件/ロジックを誰も本当に知らないという状況に陥っています。

ピア レビューやペア プログラミングの経験、特にサクセス ストーリーを知ることは価値があります。

私の友人は、職場で TDD とピンポン ペアリングを行う方法を説明していました。つまり、テスト作成者がキーボードを実装者に渡すと、実装者はテストに合格するために最も単純な (そして時には間違ったことを) しようとします。

たとえば、GetName() メソッドをテストしていて、テストが「Sally」をチェックする場合、GetName メソッドの実装は次のようになります。

もちろん、これは（単純に）テストに合格します。

彼は、これにより、コンポーネントの実際の動作や期待される状態をテストするのではなく、特定の定型値をチェックする単純なテストをなくすことができると説明しています。また、より多くのテストを作成し、最終的には設計を改善してバグを減らすのにも役立ちます。

いい感じですが、彼との短いセッションでは、1回のテストを通過するのに他の場合よりもはるかに時間がかかったように見え、多くの余分な価値が得られたとは感じませんでした.

あなたはこのアプローチを使用していますか?

チームの一部のメンバーは、一緒にプログラミングするのに問題があります。異なる性別、異なる文化、異なる年齢。それらの問題にどのように対処するのですか？-それらを一緒にペアリングしないでください、または-それらを一緒にペアリングして「ゴールデンミドル」に来させてください

Windows (Vista x64、Server 2008) のペア プログラミングやコード レビュー セッションに適した、優れた無料の (推奨) 画面共有プログラムを探しています。どちらの人でも画面を制御できるようにし、まともなブロードバンド接続を介してテキスト編集にかなり反応できるようにする必要があります。他の人の画面に描画/マーク/注釈を付ける機能などの追加機能があれば便利です。

編集：これは、遠隔地の開発者によって使用されます。

XPの本を読んでいると、私は対処できないという考えがあり、皆さんが助けてくれるかどうか疑問に思っています。

XPは、インデックスカードにストーリーを書き、それらを開発者に割り当て、タスクにかかる時間を見積もり、ペアプログラミングを使用してコーディングビットを実行すると言います。

したがって、彼女と彼女がペアを組む開発者は、自分のタスクを実装することを選択する必要があります。その選択に基づいて、彼らが実行する作業は、彼女がそのタスクに対して行った見積もりにカウントされます。彼女が誰と一緒に働いているかに依存しているように見えるので、その見積もりはまだ有効ですか？

私はエクストリーム プログラミング チームで働いており、毎日ペア プログラミングを行っています。最近はフィードバックが遅くなるようなことをすることが多くなってきました。3分程度です。例: 何かを変更し、再コンパイルし、実行して、パフォーマンスが向上するかどうかを確認します。ペア プログラミングの質を調整していると思いますし、ソロ プログラマーよりもペアに影響を与えると思います。私が一人なら他のこともできますが、ペアプログラミングの場合はどうなりますか? どのように対処しますか？

一般的に、ピア レビューは開発プロセスの非常に良い部分であると思います。コードが最初に書かれたときには明らかでなかった事柄を見つけたり質問したりすることが多く、自分自身を意識させて、フォーマットを改善したり、コメントを入れたりすることができます。

しかし、ペア プログラミングを行っている場合、事実上ライブ ピア レビューが行われます。ペアレビューはできますか？

私が働いている場所でペア プログラミングが行われ始めているので質問します。一般的に、これはピア レビューの代わりと見なされます。確かではありませんが、開発者がペア プログラミングとピア レビューに費やす時間は、生産性を損なう可能性があると思います。

しばらく前に同様の質問がありましたが、重点が異なり、明確なコンセンサスはありませんでした

私たちの会社は、面接手順を廃止し、各候補者を何人かのプログラマーと4〜5時間座らせて、ペアプログラミングを行うことを検討しています.

理論的にはこのアイデアは気に入っていますが、どのようにして各候補者にとって本当に公平にできるかはわかりません. それらをどのように評価しますか？彼らの入力は、各プログラマーがその日に取り組んでいた内容に大きく依存するのではないでしょうか?

これが良いアイデアか悪いアイデアか、またはそれを機能させる方法についての考えは、私がここで探しているものです。

乾杯！

編集：

結果 - 要求どおり

インタビューの最初のステップはこれまでと同じように実施します。電話の次は対面。彼らを 3 回目の最終的なグリルに戻す代わりに、3 人の開発者をチームの 7 人のメンバー全員と一緒に座らせることにします。誰を採用するかはチームに任せることにしました。

いくつかの理由から、この結論に達しました。これにより、誰と仕事をするかを選択できるようになり、開発者に力を与えることができると信じています。2 番目の理由は、グループ ダイナミクスです。私たちは、優れたグループのダイナミクスを持つことが非常に重要であると考えており、人を雇うまでは、その人が適合するかどうかを判断するのは困難です.

したがって、最終的には、ペア プログラミング セッションを進めることになりますが、当初の意図とはまったく異なる方法で、まったく異なる方法で行うことになります。

このアプローチについての考えや批判は大歓迎です!! （この編集は以下の回答として投稿されているため、これが最善のアプローチではないと思われる場合は、遠慮なく反対票を投じてください）

開発者が共通の知識 (遭遇した問題の解決策、クールなヒント、よくある間違い、特定の目標を達成するためのショートカット、構成の問題、部分的な要件など) を共有しない状況を避けたいと考えています。私は、そのようなコミュニケーションの欠如が偶発的 (誤解または不適切な管理の結果) である状況について考えています。開発者が意図的に知識を自分自身のために保持している状況については考えていません。

開発者チーム内の情報の流れを改善するには、次の手法が非常に役立つと思います。

• XP ペア プログラミング - ペア内での知識の交換 (および定期的なペアの混合による)。
• スタンドアップ ミーティング - 自分が取り組んでいることや遭遇した問題について他の人に話す機会があるためです。
• 主任開発者がチーム/部門の他のメンバーに対して準備したトレーニング/プレゼンテーション/コーチング。
• 「web 2.0 ツール」 - 会社/部門の技術者ブログ、チーム リーダー専用の Twitter アカウント、wiki など。

さらにアイデアはありますか？あなたの会社ではどのようなテクニックを使用していますか (または使用していましたか)? 開発者同士で知識を共有することをどのように奨励しますか?