小さな会社でのペアプログラミング/コラボレーション
私は小さな開発会社で主任開発者として働いています。他にも2人の開発者と、開発者である上司がいますが、実際のコーディングの多くは実際には行っていません。
私が克服しようとしている問題は多面的です。私たちは皆、私たちの間であまり協力することなく、自分のプロジェクトに取り組む傾向があります。実際、私は（最も高度な開発者として）外部の目からの入力を重視しているため、他の人の意見や助けを他の人よりも求めています。
私は私たちのコラボレーションを増やしたいと思い、彼らにそれを表明しました。大部分は、より良い開発者になり、より良い実践に従う方法についていくつかのことを彼らに示したいからです。しかし、他の開発者の性格タイプを考えると、彼らは一人で作業する方がより快適だと思います。
私はペアプログラミングについて読んでいますが、あるフォーラムでは、ある開発者が他の開発者（私）よりも進んでいるとうまく機能しないことを読んだことがあります。それでも、私たちが共同作業を開始して、私たちの仕事がそれほどバラバラにならないようにすることが不可欠だと感じています。
私の質問は、誰もが同じような状況にあったことがあるかどうか、そしてそれらのために何がうまくいったのですか？
私はこれが万能の状況ではないことを認識していますが、私は複数のアプローチを試してみたいと思っています。
私たちは皆、共通の領域で働いています。開発者は、個別のオフィス/キュービクルを持っていません。
この質問を提起してから数か月後、私は結果に満足していると言わざるを得ません。しかし、それは私が最初に受け入れたものとは正確には異なります。これは小さなチームであるため、このソリューションは全員に適しているわけではないことに注意してください。
みんなに自分の仕事を任せるのが一番だと思いました。そして、時間の経過とともに、お互いに信頼関係を築いてきました。問題が発生した場合、他のユーザーに助けを求めます。誰かが肩越しに見ている人と一緒に働きたいとは思わないでしょう。私は時々誰かの後ろに座りますときどき勧誘されることなく問題を通して彼らを助けます。時々私は何も追加しなくても、私はそれらを少しイライラさせるかもしれません。しかし、彼らは私が彼らをハープするためにそこにいないことを理解しています。私は主に私がやっていることから少し離れて、少しのコラボレーションを紹介するためにそこにいます。
私が見つけたのは、時間の経過とともに（小さなチームで）正しい人たちが、他の人たちがやっていることを拾い上げて同期することです。彼らがいつも間違っていることをマイクロマネージメントしたり誰かに伝える必要はありません。
時々、誰かと一緒に座り、あなたが専門家であるか、学習している誰かであるか、またはその両方であるか、問題に取り組みます。別の方法ではなく、ある方法を実行する、またはしない理由を説明してください。他の人が取り残されている間、良いアイデアは通常通りに行きます。そして結局のところ、さまざまなことに取り組んでいるが共通の目的を共有している、生産的でまとまりのある人々のグループがあります。
それは他の回答ですでに議論されているので なぜペアプログラミングはあなたのための解決策ではないのですか 、私たちが現在実験しているものについて議論し、結果に満足します。
私の考えでは、コラボレーションを強化するためにできることは、各プロジェクトに2人の人を一緒にすることです。それぞれがプロジェクトの異なる部分で機能しますが、これらの部分を統合する必要があるため、2人の開発者が協力する必要があります。これには、2人のプログラマーがプロジェクトのアーキテクチャ（レイヤーとインターフェイス）について話し合い、異なる役割を引き受けることも必要です。
また、このアプローチにより、会社が一度に処理できるプロジェクトの数が制限される場合は、このコラボレーションペアに2つのプロジェクトを同時に割り当てることができます。
私たちは最近このアプローチを実験し、そのうちの1人にmodels+ apiとの統合と他のプログラマーの処理ビューを開発させましたおよびcontrollers。この設定には、次の利点があります。
- コード構造は、1つだけがプロジェクトのすべての側面に取り組んでいる場合よりもはるかに優れた方法で結果を出します。
- リポジトリなどにコードをコミットすることを思い出させる必要はありません。
- 専用のQAだけに頼るのではなく、他のコードのテストに少し努力する必要があります。
私の意見では、ペアプログラミングはあなたが提起した問題の解決策ではありません。
ペアプログラミングには2つの異なる役割があります。 observerは、driverによって記述されたコードを確認し、フィードバックするためのものです。ジュニアプログラマーが下す決定を改善するためのアイデアを伝えようとしている場合、ドライバーの役割を実行しているときに、作成しているコードを批評的にレビューする能力がどれほど効果的であるかを疑います。
このダイナミックがなければ、ペアプログラミングのメリットは失われます。
シニアプログラマーとして、上司とのより強力な従業員のトレーニングと能力開発のプログラムを検討することをお勧めします。ジュニアプログラマーには、スキルを向上させるためのフレームワークを与える必要があります。通常、啓発、コーディング標準ドキュメントの作成、自己完結型タスクを自分の作業から分離し、適切なコードレビュープロセスを実施するなどの方法を使用できます。
TL; DR：ペアプログラミングがうまくいくとは思いません。代わりに、コードの長期的な品質について人々に懸念を抱かせ、回答を見つけたいwantようにしてください。これは非公式に行われる必要があります。
文化と品質について
この問題はプログラミング方法論ではなく、cultureに関係していると思います。私の経験では、文化は監督することが可能ですが、それを人々に伝えることはめったにありません。つまり、自然に進化しなかった、または既存のプラクティスから離れすぎている人々に特定のワークフローを強制しようとすると、マイナスの結果が生じることになります。
言い換えれば、あなたがsuitのようになりたくないのです。私が知っているほとんどのプログラマーはあなたに精神的に背景ノイズとしてタグを付けるでしょう。 企業の蜂にならないでください。
私の意見では、あなたが自問すべき主な質問は「私の組織が出したコードの品質とビジネス価値に満足していますか？」それに対する答えが否定的である場合は、「どうすればこれを好転させることができますか？」と尋ねる必要があります。
結局のところ、品質と価値はhumanの定義であり、あなた自身または組織内の他の誰かだけが考えることができます（考えるべきです）。
ペアプログラミングとマイクロマネージメント
ですから、少し前向きで過酷に聞こえるリスクを冒して、ペアプログラミングについて読むと、実際には何らかの形のmicromanagementについて考えるようになったようです。またはその逆。 MMは、ほとんどの人を遠ざけるための確実なレシピです。
ペアプログラミングの防御：ペアプログラミングは、他の人の肩越しに見ている人に関するものではありません。 それは、経営陣が得るのと同じくらいミクロです。 PPは、2つの心を使って2つのレベルを同時に考えることです。1人がhigh-levelを扱います、全体像の問題、他の問題はナットとボルトを処理実用的なコードを生成するために必要です。そして私の控えめな意見では、2人の参加者が場所を入れ替える立場にない場合、めったにうまく機能しません。同様の経験を積んで、同じような概念の専門家と共有の専門用語を持っている必要があります。 （私たちはマインドリンクされていません-まだ、muhahaha）。
あなたの状況では、私はあなたが小さなチームであり、あなたが実際の経験を持っている唯一の人であると私は言うでしょう（それはあなたの投稿が私にどのように聞こえるかです）、ほとんどの場合、ほとんどのコードをペアプログラミングまたはレビューすることはできません動作しません。 24時間しかありません。代わりに、検討できるいくつかのソリューション：
SOに適切な言語タグで参加するか、コードレビューSEでレビューするためにコードスニペットを投稿することを奨励します。誰が最も多くを獲得できるかについての非公式のコンテストを開始しますSO週あたりの担当者ポイント。
SOは常にフィードバックを提供し、コミュニティのハートビートをフォローするため、初心者の開発者にとっては不思議なことです。
彼らがチェックインするコードのいくつかを見て、その長期的な進化に関するいくつかの質問で非公式に挑戦してください。ほとんどの初心者プログラマーは、自分のコードを読み取り可能にして保守可能にすることを考えることに慣れていません。あなたがそれらの問題を彼らの頭の中に入れると、彼らはあなた自身や他の情報源から彼ら自身でより多くの情報を求めます。
私はペアプログラミングがあなたの環境であなたを助けるものだとは思いません。経験の浅い開発者のスキルを向上させるのに役立たないわけではありません。 プログラマーがスキルレベルの異なるエンジニアとのペアプログラミングについて質問する もあります。知識の共有やエラーの減少などの利点がありますが、ペアプログラミングにはより多くの時間を投資する必要があります。 3人の開発者のチームと開発の背景/経験を持つ4人だけのチームでは、ペアのプログラミングルーチンを維持することは難しいようです。
あなたの状況でより良い代替案は、特に適切にそれらを調整する場合、コードレビューであると思います。コードレビューは、1人の担当者が少しのコードを調べ、1〜2時間部屋で複数の人（チーム全体を含む）にフィードバックを提供して、コンポーネント全体の設計と実装を確認することで構成できます。これらは、特にチームの知識、経験、およびニーズに基づいて、実行中の作業に応じて適宜変更できます。問題を発見し、提案を提供し、レビューの出力を読んでコメントを自分の作業に組み込んでレビューする前に、複数の人にレビューに参加して知識を共有することで、知識を共有することができます。 。これには、他の開発者が自分の仕事が完了すると考えるまで個別に作業できるという利点もありますが、チーム全体の知識とスキルを活用しながら、希望の目標を達成するための場が提供されます。
私の質問は、誰かがこれまでに同じような状況にあったことがあるかどうか、そしてそれらのために何がうまくいったかです。
あなたが経験を招いているので、ここで私がやったことです。私は低リスクのアプローチを選択し、私よりも何十年も若い誰かに一緒に作業する時間を費やすように頼みました。アクティビティにはラベルを付けませんでした。私を除いて誰も、私たちが新しいテクニックを試していることを知りませんでした。
関連する詳細は正確にはわかりませんが、プロセスは非常にうまくいきました。彼はメンターになりたいと思っていました。そのため、非常にポジティブな方法で双方向のコミュニケーションが可能になりました。
実際、私は（最も高度な開発者として）外部の目からの入力を重視しているため、他の人の意見や助けを他の人の意見よりも求めています。
これを、現在実行していることの論理的な進行として組み立てることができるようです。