24

私は小さなチーム (4 ～ 5 人の開発者) で 1 つのプロジェクトに取り組んでいます。私たちのチームの各メンバーは、私たちのプロジェクトとは異なる機能を開発しており、彼らは非常に独立しています. 実際、一部のメンバーは、他のメンバーが知らない技術を使用しています。これはまだ 1 つのプロジェクトであり、共通のビジネス ロジックが多数含まれています。

さらに、ほとんどのメンバーは、他のメンバーが何をどのように行っているかをまったく知りません。どういうわけか、コードの複製を回避することができました (チームリーダーの功績ですが、彼でさえ何が起こっているのかを完全には認識していません)。チーム全体が何が起こっているかを追跡するための良い習慣は何だろうか。たとえば、重要な修正を行う必要があるときに、チームの誰かが辞めたり、行方不明になったりした場合、他の人が対処するのは困難です。

コードレビューを実施するためのポリシーがありますが、それに参加するのはチームリーダーとチームのメンバー 1 人だけです。他の「レギュラー」メンバーは参加しません。

また、メンバーによってソース管理でコミットされたチェックインの「ニュースリスト」がありますが、これは退屈すぎて対処できず、他の人がコミットしたばかりのものを読むのに時間をかけている人はいないようです (そして効果的ではありません。公平であるために）。

それで、私はこの問題の良い習慣は何だろうと思います. どんな経験がありますか？解決策はありますか？

編集：少し明確にさせてください。私たちのチームは 2 年以上働いており、プロジェクトはほぼ 5 年前のものです。したがって、アジャイル開発を開始することはできませんが、いくつかのアジャイル プラクティス (スタンドアップ ミーティングなど、非常に便利だと思います) を紹介することはできます。

また、私たちのチームは大企業の一員であるため、チームビルディングの慣行を確立しています。そして、私たちはお互いを嫌いません:) - 私たちは友人であり、社会生活や活動について話しています. 私たちが見逃しているのは専門家の話です。

4

8 に答える 8

17

  • 全員が出席する毎日のスタンドアップ ミーティング(短くしてください) は、全員がお互いに何をしているかを理解するのに役立ちます。これはまた、マネージャーが管理者を邪魔にならないようにするのにも役立ち、スラッシングを防ぐのにも役立ち、マネージャーがしなくても各個人に少しのプレッシャーをかけることができます。（明日の朝、仲間の前で見栄えがするように、何かをやりたいと思っています）。スクラムのようないくつかの方法論は、これを形式化しています。

  • さまざまなチーム メンバーとコード レビューを行います。マネージャー以外のチーム メンバーの 1 人がより経験豊富ですか? この人に他の人とコード レビューをしてもらうとよいでしょう。彼/彼女は彼らの経験を共有し、何が起こっているかをほとんど知っている (マネージャー以外の) 誰かになります。ピア レビューでは、ある人物が他の人物よりも年長で、コードが正しいか間違っているかを宣言しなければならないという法律はありません。2 人の「ピア」がコード レビューを行う場合、最初はペア プログラムを実行するだけでよいと思います。

  • 質の高いコードを書こうとしている場合、特定のコードのビットがペアプログラミングに役立つ可能性があります。XP の人々は、常にこれを行うべきだと言いますが、私は、その方が役立つ場合もあると信じています。たとえば、ある開発者が他の開発者よりも経験豊富な場合、これはメンタリングに役立ちます。また、知識を広めたい特定の分野がある場合。(システムの一部を理解しているのは 1 人だけです。次に修正が必要になったときは、その人に他の人が入力してもらいます。 ) また、システムの一部が非常に重要な場合もあり、それを正しく作成することの方がはるかに重要です。 1 分あたりのコード行数よりも少ない。これは、問題について 2 つの頭を持つ絶好の場所であり、最終的には2 人で1 つではなく、このキー コードの詳細な知識を持っています。

  • 週に 1 回、誰かが行っている興味深いことについて、昼食時に短い話をしてもらいます。これは素晴らしい議論を生み出し、自信と相互尊重を促進しますが、ここで私たちが興味を持っているのは、それが認識を促進することです.

  • 優れたコードを評価し、サポートし、信じます。一部のショップ (主にマネージャー) は、良いコードを本当に信じていないため、開発者が優れたコードを作成できたとしても、人々が (くだらない) コードを破棄することにつながります。開発者が作成しているコードに満足している場合、新しいテクノロジを時々実装している場合、および質の高い仕事がキャリアに役立つ場合は、コードに関するコミュニケーションがはるかに簡単になります。

そして、ペアプログラミングについて。この議論におけるペア プログラミングの重要な部分は、ペア プログラミングが共有コードと相互知識を促進することです。ペア プログラミングが特に役立つ特定の場所について言及する理由は、「ペア プログラミングを行う」という方針が約 10% の確率で成功するためです。残りの 90% のプラクティスの支持者は、大きなマネージャーが「なぜこれらすべての人々が同じデスクに座っているのですか?」と尋ねても、十分な答えを出すことができません。ペア プログラミングの利点は、1 人のプログラマーが行うよりも 200% 以上でなければなりません。適切なタイミングでペア プログラミングを行うことで、ソリューションと収益の比率を高めることができます。間違ったタイミングでそれを減らすことができます。

于 2010-02-23T20:48:16.570 に答える
8

ペア プログラミングや毎日のスタンドアップ ミーティングなどのアジャイル手法は、コミュニケーションを円滑に行うための適切な方法です。

しかし、あなたが本当にしなければならないことは、人々が互いに話し合うようにすることのように思えます. 開発者は内向的な傾向があるため、これに取り組む必要があります。一緒に昼食をとります。お互いの肩越しに見てください。お互いにアドバイスを求めてください (たとえそれが必要ない場合でも)。誰もが理解しているわけではない奇妙なテクノロジーについてお互いに質問してください。統合テストのために収集します。

于 2010-02-23T20:48:13.377 に答える
3

ここに私の頭から離れたいくつかの考えがあります（小さな会社、3人のプログラマー;約20人のチームで働いていました）。

  • ある種の進捗レポート。他の人が何に取り組んでいるのかを誰もが確認できます。「私が取り組んできた」会議は一部の人にとってはうまくいきますが、私は彼らのファンではありません。彼らはあまりにも管理されており、この目的のための座り込み会議はしばしば時間の無駄になる可能性があります。または、ラットホールから消える傾向があります。私の現在の仕事では、毎週の進捗メールを送信するように通知するcronジョブがあります。これらの中で、達成したこと、ToDoリストの次のいくつかの項目（適切な場合は見積もりを含む）、問題があればそれを伝えることが期待されます。遭遇しました。
  • 選択的コミット通知。全社的なコミットメールにざっと目を通す人はほとんどいませんが（私の小さなチームでも）、各開発者が自分が取り組んでいる分野だけを監視できるようになれば、おそらくそれを追跡できます。（とにかく、一度に同じコードで作業する人が多すぎないようにする必要があります。料理人が多すぎるなどです。）
  • ToDoリストを提供するためのある種のチケットシステムが役立つ場合があります。ただし、これがどのように管理されているか、特にチケットの発信と終了のプロセスについては、非常に明確にする必要があります。
  • 内部ドキュメント。これは難しい問題です。一部の開発者はそれを嫌い、一部の開発者は書きすぎ、一部の開発者は十分に書き込みます。問題の少なくとも半分は、索引付けと表示にあります。必要な情報が「ヒョウに注意」というタイトルの不可解な文書の5層の深さに埋もれているのは良くありません。とても使いやすいので、私はこの目的のためのwikiのかなりのファンです。
  • チームの特定のサイズを超えると、誰かがドキュメントを管理するためのフルタイムの仕事になることがあります。以前の職場では、検索エンジンアプライアンスにお金を費やし、イントラネットサイトを継続的にクロールしていました。これはすばらしいことでした。
于 2010-02-23T21:30:28.633 に答える
3

私も職場で同じような状況です。あなたが言ったように、チームの一部のメンバーは非常に独立しており、チームの他のメンバーと洞察や実践を共有していません. これは非常に専門的ではなく、チームにとって全体的に有害であると思います。

もちろん、一部のメンバーが他のメンバーよりも優れていることは避けられません。また、プログラミングの世界では、エゴを脇に置くのに苦労するメンバーもいます。最善の方法は、スケジュールされた会議と全員が参加するコード レビューを行うことです。人々が使用する特定のテクニックを投稿できる中心的なドキュメント サイトを用意します。チームの他のメンバーに役立つと思われる何かを見つけたら、それをサイトにアップロードし、全員に知らせる電子メールを送信します。コミュニケーションが鍵です。

于 2010-02-23T20:50:45.533 に答える
3

あなたを助けることができるのは、（アジャイル開発からの）毎日のスタンドアップです。数分しかかからず、基本的にすべてのメンバーが自分の仕事の状況、対処している問題、明日の計画を他のメンバーに提示します。

スタンドアップはあなたにとって良いスタートだと思います。たとえば、 Martin Fowler - It's Not Just Standing Up: Patterns of Daily Stand-up Meetingsなどで、さらに詳しい情報を見つけることができます。

于 2010-02-23T20:52:41.590 に答える
3

私たちのチームでは、毎週進捗会議を行っています。これにより、他の人が何をしているか、それぞれが全体像のどこに配置されているかを発見できます。

手作りのケーキを分け合って、ミニの社交イベントが続くこともあります。進行会議の議事録には次回ケーキを持ってくる人の名前が書かれています。

于 2010-02-23T20:53:24.053 に答える
3

チームビルディング

一緒にバーベキューをしたり、フーズボールをしたり、仕事以外にみんなが好きなチーム活動を見つけましょう。これにより、人々は「独立」するのではなく、お互いを信頼するようになり、スクラム ミーティングやペア プログラミングなど、他の有用なチーム プラクティスの効果が 10 倍になります。

于 2010-02-23T20:56:44.533 に答える
1

私たちは似たような状況にあり (長いプロジェクトで、みんな友達です)、似たような問題を抱えていました。次のプラクティスにより、多くの改善が可能になりました。

  • 毎日のスタンドアップミーティングは必須です。私の経験では、チーム内のコミュニケーションを促進するには、毎日のスタンドアップを適切に実施することが最善の方法です。チームメンバー全員が何をしているかを誰もが知っており、どんな問題でも助けてくれます。
  • ウィキも不可欠です。チーム内で使用される標準的なプラクティスとテクノロジーを提示できます。全員が積極的に参加できるようにするために、リーダーはすべてのチーム メンバーに何かを割り当てて、wiki 内でそれについて書き、維持します。それぞれが特に好きなことや興味のあることについて書くと特に効果的です。
  • 要件/機能の分析、優先順位付けなどを行う会議には、チーム全体、または利用可能なすべてのメンバーを出席させるようにしてください。事業。これにより、全員にコンテキストが与えられ、プロジェクトのより広い視野が得られます。彼らが取り組んでいる部分だけに集中するのではなく、プロジェクト全体のこの議論に参加することを許可 (および奨励) します。このプラクティスは、多くの議論の動機となります。機会と知識が与えられたとき (ごくわずかな量で済みます)、私たち全員が意見を持ち、プロジェクト内のすべてのことについてコメントするのが好きです。
  • 多くの「ショップ」トークの動機となる最後の慣行は、2 週間ごとに一部のメンバーがテクノロジーやテクニックについて簡単なプレゼンテーションを行うことです。一般的に、それには実践的な演習が含まれており、時間について話し合い、質問をします。
于 2012-02-09T19:29:49.563 に答える