タグ付けされた質問 「pair-programming」

私のチームメンバーの1人であるジュニアプログラマーは、彼の経験レベルに対して優れたプログラミングスキルを持っています。 また、コードのレビュー中に、間違いを指摘するのではなく、学習を重視することを信じています。 しかし、若いプログラマーは、より上級のプログラマーのコードレビューに関与すべきでしょうか？または、コードレビューには、対応する経験を持つプログラマーのみが参加する必要がありますか？

55 teamwork  code-reviews  pair-programming 

常にプログラムをペアリングするのではなく、チームでペアプログラミングを選択的に使用します。次のような状況で最適に機能すると思います。 プロジェクトの新しいチームメンバーを増やします（ドキュメントやコードを自分で歩くのではなく）。 ジュニアとシニアの人々が一緒に働くことは（より経験豊富な開発者のスキルとトリックの一部を示すのに役立ちます。また、老犬が時々新しいトリックを学ぶことができます）。 誰かが欠陥を追跡しようとするとき、それはしばしば新鮮な目のセットとペアリングするのに役立ちます。 ペアプログラムを使用するタイミングとその理由 ペアプログラミングを回避する場合 どうして？

51 agile  pair-programming 

Webでいくつかの記事を読んで、アジャイル、XP、スクラム、ペアプログラミングが互いにどのように異なり、互いに関連しているかを調べ、次の行を導き出しました。 スクラムとXPはほぼ同じです。XPのリリース期間はスクラムよりも短い ペアプログラミングは、アジャイルとXPの両方の方法論で採用されています しかし、アジャイルがXPとどのように異なるかを特定できませんでした。 URLを提供するだけでなく、これに関するあなたの経験と考えを読んで喜んでいるでしょう。

32 project-management  agile  scrum  pair-programming  extreme-programming 

ペアプログラミングは、2人のプログラマが1つのワークステーションで連携するアジャイルソフトウェア開発手法であることを知っています。一方のドライバーはコードを記述し、もう一方のオブザーバーは入力されたコードの各行をレビューします。 しかし、私はこの戦略がこのケースでまだ機能しているのだろうかと思う。例えば プログラミングスキルレベルがまったく異なる場合。 ある人が問題の領域で経験したことがなく、別の人が経験した場合。 プログラミングのスキルレベルが低い場合でも大丈夫ですか？ 上記の場合のペアプログラミング戦略を提案できますか？

30 agile  pair-programming 

私は興味深い仕事を提供されましたが、私にとって大きな警告があります：彼らはペアプログラミングを使用します。 私はペアプログラミングのアイデアが嫌いで、おそらくそれには向いていません：私は頻繁にポーズをとるのが好きです、誰かのプログラミングを見ることは嫌いです（自分でコーディングするために絶えずペアを突っ込んでしまいます）私が取り組んでいるマシンのコントロール、音楽を聴くのが好きで、基本的に他の誰かに縛られるのは好きではありません。私は社交的な人間でもありません。 しかし、実際にペアプログラミングを行ったことはありません（他の人を支援したり、複雑なタスクを一緒に解決したりするために、短い時間を数回使用します）。そして、私の態度を考えると、仕事を拒否すべきですか、それとも現在の仕事を辞めて試してみるべきですか？ それについて尋ねた人々のために：私は、私たちが「荒野でコーディング」している私の現在の仕事が嫌いなので、正式な設計と開発が使用される仕事を探しています。会社は私の技術的なプロファイルに非常に興味を持っているので、ペアプログラミングで仕事をしたことはないと指定したとしても、彼らはそれを好まないだろうと主張しました（社交的でない孤独なプログラマーであるだけでなく、ペアプログラミング）。

28 agile  pair-programming 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 ペアプログラミングは、今日では非常に有名です。 以下のようないくつかの利点があります。 バグの少ないプログラム。 ポストプロダクションのメンテナンスコストははるかに低くなります。 確立された慣行は挑戦され、新しいアイデアが生まれます。 プログラマーはお互いから学びます。 プログラマーはソフトスキルを開発します。 しかし、ペアプログラミングの欠点は何ですか？

22 design  programming-practices  pair-programming 

私は小さな開発会社で主任開発者として働いています。私たちには他に2人の開発者と、開発者である上司がいますが、実際のコーディングは実際にはあまり行いません。 私が克服しようとしている問題は多面的です。私たちは皆、私たちの間の多くのコラボレーションなしに、私たち自身のプロジェクトに取り組む傾向があります。実際のところ、私は（最も先進的な開発者として）他人の意見/助けを彼らが私のものよりも求めています。 私たちのコラボレーションを増やしたいと思い、彼らにそれを表明しました。大部分は、より良い開発者になり、より良いプラクティスに従う方法についていくつかのことを見せたいからです。しかし、他の開発者の性格タイプを考えると、彼らは単独で作業する方が快適だと思います。 私はペアプログラミングについて読んでいますが、あるフォーラムでは、ある開発者が他の開発者（私）よりも進んでいるとうまくいかないことを読みました。それでも、私たちの仕事がそれほどばらばらにならないように、私たちは協力し始めることが不可欠であると感じています。 私の質問は、誰かがこれまでに同様の状況にあったかどうか、そして何が彼らのために働いたのですか？ 私はこれが万能の状況ではないことを理解していますが、複数のアプローチを試してみたいと思います。 私たちは皆、共通の領域で働いており、開発者は個々のオフィス/キュービクルを持っていません。

20 teamwork  collaboration  team-leader  pair-programming 

私は最近新しい仕事に着手しましたが、ペアリングを行うことで非常に迅速に効果的になりました。ただし、ワークフロー中にAPIの機能、コード例、またはコマンドオプションをカバーする簡単な共同研究を行う必要がある場合、私は苦労しています。私のチームリーダーは、個々のラップトップではなくペアリングステーションですべての調査を行い、異なるWebリソース間で手順を口頭で交渉することで調査を同期することをお勧めします。 私はペアリングパートナーとは異なる方法で情報を調査、読み取り、吸収します。また、正確なペースと場所を維持しようとするのではなく、次のWebページに正確に行きたいときに調査のスレッドをたどることができると、生産性が大幅に向上します私のパートナーの読書。私たちは賢くて速いのですが、物事を考え出すとき、さまざまな方法で動き、瞬時の速度を出すことはできません。誰かが「私はそれを手に入れました」と言ってから、一緒に戻ってコードを書くまで、1分間個別に動き回るのは非常に簡単に思えます。 プログラムをペアリングするとき、短い研究タスクをどのように処理しますか？あなたに最適なものは何ですか？また、パートナーと同期を保つ方法は？

20 agile  pair-programming 

Flowは、Mihaly Csikszentmihalyiによって導入された概念です。要するに、それは「ゾーン」に入ることを意味します。集中して仕事に没頭しているように感じます。このタスクは困難ですが、同時に挑戦的です。人々がフローを達成すると、生産性が急上昇します。プログラミングでは、頭の中でいくつかのことを一度に処理する必要がある場合が多いため、精神的に集中する必要があります。多くの人は、仕事に全力を注ぐことができる静かな環境で働くのが好きです。中断された場合、フローに戻るまでに数分または数時間かかる場合があります。 アジャイル開発には、ペアプログラミングと呼ばれる極端なプログラミングのプラクティスがあることを理解しています。つまり、コミュニケーションがシームレスになるように、ソフトウェア開発チーム全体を1つの部屋に配置します。ペアでコードを書くのは、この方法ですぐにコードレビューを取得し、バグが少なくなるためです。 絶え間ない中断のため、ペアプログラミング中にフローを達成するのに常に問題がありました。私は問題について深く考えており、突然誰かが私に別のペアから質問をします。私の思考の流れが失われます。 ペアプログラミング中にどのようにフローを達成および維持できますか？

17 pair-programming  flow 

私はeXtremeプログラミングチームで働いており、Windows環境で7年以上ペアプログラミングを行っています。私たちが最初にそれを始めたとき、誰かがWindowsの資格情報でログインするため、ドメインリソースへのすべてのアクセス、より具体的にはバージョン管理はそのWindowsユーザーに説明責任があります。最終的に、特定のペアリングステーション（ペアA、ペアB、ペアCなど）のWindowsペアリングアカウントを持つように進化しました。すべての開発者は、これらのアカウントのパスワードを知っています。コミット（チェックイン）の説明責任は、コミット中にプログラマーのイニシャルをコメントに入れることで実現されます。 これまではこれでうまくいきましたが、私の会社は現在ISO 27001監査を受けており、監査人によってリスクとしてフラグが立てられています。ペアの組み合わせごとにペアリングアカウントを作成するなど、可能な解決策がいくつかありますが、この問題に他の誰かが遭遇したかどうか、どのように解決したかを知りたいのですが。 審査員はどのような解決策を受け入れましたか？

16 pair-programming  iso 

私はいつもペアプログラミングに興味を持っていますが、12年の開発で、彼らがこのプラクティスを採用した場所で働いたことはないので、人々がそれをどう見るかについて常に懐疑的です。 これはお金/時間（同じコードで作業している1台のコンピューターで2人の人を見つけた先の尖った上司!!!!彼らはあえて！）または他の理由によるのだろうか？

16 development-process  pair-programming 

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

15 pair-programming  metrics 

ほとんどのアジャイル / XP理論家が支持している一般的な考え方は、ペアは定期的に交換する必要があるようです。たとえば、各プログラマは1日に1回ペアを交換する必要があります。一日の始めに人の半分、昼食後に人の半分が入れ替わります：会議、休日などの外部要因により、ほとんどの人は週に1、2回スワップ時間を反転させ、ペア構成が分散する傾向がありますチーム全体でほぼ均等に。 頻繁にスワッピングを行う理由の1つは、特定のスキルや知識が特定の個人に集中するのではなく、知識がチーム間で迅速かつ均等に分散することです。ペアプログラミング自体を取り巻くドグマの一種の帰結である別の理論的根拠は、誰かがあなたを交換するたびに、新しいペアの目で新しいコードレビューを取得しているため、コードの品質を向上させることです。 どちらの主張も理にかなっています。管理の観点から見ると、安定性と品質の両方が向上したように聞こえます。このような頻繁な交換は、私が見たほとんどのアジャイル / XPの本でかなり標準的な理論です。 だから、実際に実行するとき、人々は実際にペアスワッピングについて何を考えますか プログラマーの視点？ マネージャーの視点？ そして 誰かがペアから/にスワップするとき、何を決定する必要がありますか？

15 agile  pair-programming 

極端なプログラミングプロジェクトでは、プログラマはほとんどの場合ペアプログラミングを行います。 これらのペアも回転するため、つまり、プログラムをさまざまな人とペアにし、集団所有権の感覚があるため、ソースコードは頻繁にレビューおよび更新されています。 そうであれば、コードレビューが必要ですか？つまり、プログラミングを停止し、実際にコードレビューを行うだけです。

14 agile  code-reviews  pair-programming  extreme-programming 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 コーディングプロセス中に非IT担当者がプログラマーと連携する経験はありますか？ それはペアプログラミングのようなものですが、一人はビジネスについて多くのことを知っている非ITの人です。おそらく、物事の計算方法を知っており、非慣用的な手続きコードを理解できる数学のバックグラウンドを持つプロセスエンジニアです。 PL / SQLのような手続き型のドメイン固有言語は、IT以外のエンジニアでも非常に理解しやすいことがわかりました。これらの人物は最終的にコードの共著者となり、式、要因などの正確性を保証します。 この種のペアプログラミングは非常に生産的であり、この種のエンジニアリングタイプのユーザーは、コードの「所有者」および「作成者」であると感じ、コミュニケーションプロセスの誤解を最小限に抑えます。テストケースの設計にも役立ちます。 この慣習は一般的ですか？ 名前はありますか？ 同様の経験がありますか？

14 teamwork  requirements  client-relations  business-logic  pair-programming