小規模企業でのペアプログラミング/コラボレーション

私は小さな開発会社で主任開発者として働いています。私たちには他に2人の開発者と、開発者である上司がいますが、実際のコーディングは実際にはあまり行いません。

私が克服しようとしている問題は多面的です。私たちは皆、私たちの間の多くのコラボレーションなしに、私たち自身のプロジェクトに取り組む傾向があります。実際のところ、私は（最も先進的な開発者として）他人の意見/助けを彼らが私のものよりも求めています。

私たちのコラボレーションを増やしたいと思い、彼らにそれを表明しました。大部分は、より良い開発者になり、より良いプラクティスに従う方法についていくつかのことを見せたいからです。しかし、他の開発者の性格タイプを考えると、彼らは単独で作業する方が快適だと思います。

私はペアプログラミングについて読んでいますが、あるフォーラムでは、ある開発者が他の開発者（私）よりも進んでいるとうまくいかないことを読みました。それでも、私たちの仕事がそれほどばらばらにならないように、私たちは協力し始めることが不可欠であると感じています。

私の質問は、誰かがこれまでに同様の状況にあったかどうか、そして何が彼らのために働いたのですか？

私はこれが万能の状況ではないことを理解していますが、複数のアプローチを試してみたいと思います。

私たちは皆、共通の領域で働いており、開発者は個々のオフィス/キュービクルを持っていません。

ペアプログラミングがなぜあなたの解決策ではないのかについては他の回答ですでに議論されているので、現在実験していることについて議論し、その結果に満足しています。

私の考えでは、コラボレーションを強化するためにできることは、各プロジェクトに2人の人を一緒に入れることです。それぞれがプロジェクトの異なる部分で機能しますが、これらの部分を統合する必要があるため、2人の開発者が協力する必要があります。これには、2人のプログラマーがプロジェクトのアーキテクチャー（レイヤーとインターフェース）について話し合い、異なる役割を引き受けることも必要です。

また、このアプローチにより、会社が一度に処理できるプロジェクトの数が制限される場合、このコラボレーションペアを2つのプロジェクトに同時に割り当てることができます。

私たちは最近、このアプローチを実験し、そのうちの1つがモデルを開発し、APIと他のプログラマーがビューとコントローラーを処理する統合を行いました。この設定には次の利点があります。

1. コード構造は、プロジェクトのすべての側面で作業しているのが1つだけの場合よりもはるかに優れた結果になります。
2. リポジトリなどにコードをコミットすることを思い出させる必要はありません。
3. 専用のQAだけに頼るのではなく、お互いのコードをテストするためにある程度の努力をする必要があります。

私の意見では、ペアプログラミングはあなたが提起する問題の解決策ではありません。

ペアプログラミングには2つの異なる役割があります。観察者はによって書かれたコードのレビューとフィードバックにそこにあるドライバ。ジュニアプログラマーが下している決定を改善するためのアイデアを伝えようとしている場合、ドライバーの役割を実行しているときに、書いているコードを批判的にレビューする能力をどれほど効果的に見つけることができるか疑問です。

この動的なしでは、ペアプログラミングの利点は失われます。

シニアプログラマとして、上司と一緒に従業員のトレーニングと開発を強化するプログラムを検討することをお勧めします。ジュニアプログラマには、スキルを向上させるためのフレームワークを提供する必要があります。通常、啓発、コーディング標準ドキュメントの作成、自己完結型のタスクを自分の作業から分離し、適切なコードレビュープロセスを確実に実施するなどの方法を使用できます。

TL; DR：ペアプログラミングはうまくいかないと思います。代わりに、コードの長期的な品質を人々に心配させて、答えを見つけさせたいと思うべきです。これは非公式に行わなければなりません。

文化と品質について

この問題はプログラミングの方法論ではなく、文化の問題だと思います。私の経験では、文化は監督することが可能ですが、めったにそれを人々に伝えることはできません。つまり、自然に進化していない人や、既存の慣行からあまりにも遠い人に特定のワークフローを強制しようとすると、マイナスの結果になります。

言い換えれば、あなたが最終的にあなたであっても、最新の流行語をぶんぶんぶん回ってくるスーツのようになりたくありません。私が知っているほとんどのプログラマーは、あなたを暗騒音としてメンタルにタグ付けします。企業の蜂にならないでください。

私の意見では、あなたが自問すべき第一の質問は「私の組織が出すコードの品質とビジネス価値に満足していますか？」です。そして、それに対する答えが否定的な場合、「どうやってこれを好転させるのですか？」と尋ねるべきです。

究極的には、品質と価値は人間の定義であり、あなたまたはあなたの組織内の他の誰かが考えることができます（そして考える必要があります）。

ペアプログラミングとマイクロ管理

そのため、少し前向きで耳障りな音を立てる危険性がありますが、ペアプログラミングについて読むことで、実際に何らかの形のマイクロマネジメントについて、またはその逆を考えるようになったように思えます。MMは、ほとんどの人を疎外するための確実なレシピです。

ペアプログラミングの防衛において：ペアプログラミングは、他の人の肩越しに見ている人のことではありません。それは、管理者が得るのと同じくらいミクロです。一人のお得な情報- PPは、同時に2つのレベルを考えるために2人の心を使用する方法についてであるハイレベル、大きな絵の問題を他のの世話をしながら、ナットとボルト動作するコードを生成するために必要。私の謙虚な意見では、2人の参加者が場所を入れ替える立場にない場合、うまく機能することはめったにありません。彼らは、同様の専門的な概念の武器庫と専門的な専門用語を共有するのに十分な経験を積む必要があります（私たちは心にリンクしていません - まだ、はははは）。

あなたの状況については、あなたは小さなチームであり、あなたは実際の経験を持っている唯一の人だからです（あなたの投稿は私にとってはそうです）、ペアプログラミングまたはほとんどのコードをレビューすることはほとんどないでしょう動作しません。1日24時間しかありません。代わりに、考えられるいくつかのソリューション：

• 適切な言語タグの下でSOに参加するか、Code Review SEでレビューするためにコードスニペットを投稿するように勧めます。誰が1週間あたりのSO担当ポイントを最も多く獲得できるかについて、少し非公式のコンテストを開始します。

  SOは、絶えずフィードバックを提供し、コミュニティの鼓動をたどるので、初心者の開発者にとって驚くべきことです。

• 彼らがチェックインするコードのいくつかを見て、その長期的な進化に関するいくつかの質問で非公式に挑戦してください。ほとんどの初心者プログラマーは、コードを読みやすく保守しやすくすることを考えることに慣れていないだけです。これらの問題を頭に入れると、彼らはあなたや他の情報源から自分自身でより多くの情報を求めます。

ペアプログラミングは、あなたの環境で役立つとは思いません。それは、経験の浅い開発者のスキルアップに役立たないということではありません。さまざまなスキルレベルのエンジニアとのペアプログラミングに関するプログラマーの質問さえあります。知識の共有やエラーの減少などの利点がありますが、ペアプログラミングにはより多くの時間を投資する必要があります。3人の開発者のチームと、開発のバックグラウンド/経験を持っている4人だけのチームでは、ペアのプログラミングルーチンを維持するのは難しいようです。

あなたの状況におけるより良い代替手段は、特に適切に調整する場合、コードレビューだと思います。コードレビューは、1人の人がほんの少しのコードを見て、1〜2時間部屋の複数の人（チーム全体を含む）にフィードバックを提供して、コンポーネント全体の設計と実装を確認することで構成できます。これらは、特にチームの知識、経験、ニーズに基づいて、行われている作業に応じて変更できます。問題を見つけ、提案を提供し、レビューの出力を読んでコメントを自分の作品に組み込むことで知識を得るために、複数の人々がレビューに参加することにより、知識共有の側面を得ることができます。

私の質問は、誰かがこれまで同様の状況にあったことがあるかどうか、そして何が彼らのために働いたのかということです。

あなたが経験を招待しているので、ここで私がやったことです。私は低リスクのアプローチを選択し、私よりも数十年若い人に協力して時間を過ごすように頼みました。アクティビティにラベルを付けませんでした。私以外の誰も、新しいテクニックを試していることを知りませんでした。

どの詳細を関連付けるべきか正確にはわかりませんが、プロセスは非常にうまくいきました。彼はメンターになりたかったのですが、それは私が事前に何も示唆していなかったものでした。そのため、非常に前向きな方法で双方向のコミュニケーションを開始しました。

実際のところ、私は（最も先進的な開発者として）他人の意見/助けを彼らが私のものよりも求めています。

これは、あなたが現在していることの論理的な進行としてフレーム化できるように思えます。

この質問を提起してから数か月後、私は結果に満足していると言わざるを得ません。しかし、それは私が最初に受け入れたものではありません。これは小さなチームであるため、このソリューションは全員に適しているわけではありません。

みんなに自分の仕事をさせるのが最善だと思いました。そして、時間が経つにつれて、私たちはお互いに信頼関係を築き、問題にぶつかった場合に、他の人たちを助けに呼びます。誰かが肩越しに見ている人と仕事をしたいとは思わない。私はときどき誰かの後ろに座り、ときどき頼まれることなく問題を手助けします。追加するものが何もない場合があり、少しイライラすることがあります。しかし、彼らは、私が彼らをハープするためにそこにいないことを理解しています。私は主に自分がやっていることから休憩を取り、少しのコラボレーションを紹介するためにそこにいます。

私が見つけたのは、時間の経過とともに（小さなチームで）右の人が他の人がやっていることに気づき、同期することです。常に自分が何を間違っているのかをミクロに管理したり、誰かに伝える必要はありません。

時々、誰かと一緒に座って、あなたが専門家であるか学習している人であるか、あるいはその両方であるかを問わず問題を解決します。別の方法ではなく、ある方法で何かをする、またはしない理由を説明してください。良いアイデアは通常は受け入れられますが、他のアイデアは取り残されます。そして、一日の終わりには、さまざまなことに取り組んでいるが共通の目的を共有している、生産的で結束力のある人々のグループができています。