7

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

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

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

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

4

10 に答える 10

11

信頼。

「ばかげているように見える」ことは許されますが、わからない場合や、私の言っていることが完全に理解できない場合は、質問してください。間違っていたら教えてください（私も同じようにバカなので気がつきませんでした。）

于 2009-03-26T21:00:21.880 に答える
6

私はある会社で働いていました。そこでは毎週金曜日に開発者向けの昼食会がありました。開発者が知識を共有しなければならない間、経営者は食糧を提供するでしょう。最近学んだツールやテクニックを紹介したり、取り組んでいるプロジェクトのデモを行ったりします。当時チームが使用していたテクノロジーに限らず、開発者は新しいテクノロジーを学ぶように促されました。チームにデモを提供します。

そして、私の現在の仕事では、毎月ITグループ会議があり、さまざまなチームの開発者が、取り組んでいるプロジェクトのデモを行うことがあります。

于 2009-03-26T21:03:12.203 に答える
2

  1. 内部のtwitter風のユーティリティ。ウィキを機能させることができれば、個人的には少し多すぎると思います。しかし、ツイッターは違います。「rowfilterのlike句をエスケープする拡張メソッドを追加しただけです」など。

  2. 一部の人々はそれを少し圧倒するかもしれませんが、ユーティリティの一般的な場所なので、どこを見て文字列を作成するかを知っています。CountOccurrencesはコードベース全体に散らばっていません。

于 2009-03-26T21:16:30.673 に答える
2

さらにいくつか追加します

  • 適切な人を雇う-これは、素晴らしいダイナミックを作りたい場合に不可欠です（社会人はもっと多くの努力を必要とします）
  • 死前および死後。これにはwikiを使用し、プロジェクトごとにページを作成し、それを繰り返し発生するもの（商品と不良品の両方）のセクションに分割します。各マイルストーンの終わりに、チームに会議を開いて事後分析を行います。プロジェクトの最後に（または一定の時間が経過した後）、プロジェクトコーディネーターにこれを後世のために読みやすいものにコンパイルしてもらいます（そしてそれをあなたのウィキに載せます）
  • 毎日のスタンドアップは必見です！あなたはすでにそれを言いました、しかし私はそれがとても役に立ちます！
  • 会社に複数のチームがある場合は、それらの最大の成果の1つについて会議を開催します。可能であれば、定期的に、部門を含めても、アーティストがプログラマーの仕事にどのように興味を持っているかに驚くでしょう。
  • 昼食は共有する良い機会です。私たちの会社では、社長の朝食、プロジェクトリーダーの昼食、プロジェクトの終わりの夕食を用意しています。私はそれらすべてを愛し、より良い結果を得るために混ぜ合わせます。
  • 会社全体とのオフサイトミーティングは素晴らしいです。少なくとも年に1回はそれを行います（午前中は将来の予定を発表し、午後はプロジェクトについて学ぶ活動です）
  • Wikiはすばらしいですが、時間の経過とともに誤ってしまう可能性のある情報に注意してください（これは、書かれた情報で繰り返し発生する問題です）
于 2009-03-26T21:18:48.950 に答える
2

私の心にさらにいくつかのこと：

  • パターンとプラクティスの会議 - 毎週である必要はありませんが、チームがさまざまな未解決の質問について話し合い、多くの人々の頭痛の種を救う可能性のある事柄について合意を得るための時間を割く必要があります。

  • 文化的要因 - 職場は、チームの結束を助けるのに十分な社交を提供しているか、または障害物コースや一緒に料理をするなどのチームビルディングの演習が、ダイナミクスを確立するのに役立つか. 問題になる可能性のある大きなエゴがないように、開発者の間に謙虚さがありますか。ここでのもう 1 つの要因は、これにどのように答えるかを考えることです。地元のパブに行って、仲間のチームメイトと飲み物を飲みますか? はいの場合は、ここにいくつかの良い点がありますが、そうでない場合は、ここで行う調査があるかもしれません.

  • ふりかえりフォローアップ - ふりかえり中に提示されたアイデアはどのように検討され、実装されますか? 会議は一般的にどのように処理されますか?

  • チーム内でのデモ - いくつかのストーリーが完成し、いくつかの大きなコード ポイントが関係している場合は、チームが何が行われたかを確認し、他の人が何が行われたかを確認できるように、知識が広まるように、おそらくこれについて少しデモンストレーションを行う必要があります。その周り。これは、コミュニケーションをさらに促進するものであるという点で、私の最初のポイントと一致する可能性があります。

于 2009-03-26T23:29:17.547 に答える
1

私は多くのアプローチを試しましたが、プロジェクトでペアで作業したり、チームと定期的に話し合ったり会議を行ったりするのが大好きです。

しかし、私ができる唯一の最善のことは、開発者間の絶え間ないコミュニケーションの文化を育むことであることもわかりました。私は、開発者全員が仕事をしながら互いにコミュニケーションをとるように努めています。必ずしも毎週または毎月の会議まで待つ必要はありません。

私の場合、ほとんどの開発者が同じ場所にいないため、これは少し注意が必要です。そのため、XMPPチャットルームを1つ設定し、プロジェクトに取り組んでいるときは常に全員がログインしています。一部の開発者（私を含む）は、営業時間外にもログインします。

私は私のオフィスの人々にも同じことをします-私たちはかなり静かな集団になる傾向がありますが、私は人々が質問でお互いに割り込んだり、椅子をつかんで座っていつでもブレインストーミングをしたりすることを非常に受け入れています。

ただし、これが機能する理由の1つは、コミュニケーションを手元の作業や特定のプロジェクトに限定しないようにしていることです。私の気持ちは、私がそれを促進するかどうかにかかわらず、人々は他の仕事に関係のないことについて話すだろうということです。でも、外ではなく、公式チャンネルで「ウォータークーラー」の話をしたいです。

これにより、誰もが「明らかなように見える」質問をするのがより簡単になります。また、人々はすぐそこにいて、みんなと話すことに慣れているので、継続的に質問をします。必要に応じて無視するのは簡単ですが、一般的な質問を投げて、誰かが苦痛などを感じることなくアイデアを持っているかどうかを確認するのもはるかに簡単です。

私の経験では、中断によって失われる時間は、目の前の問題の解決を常に熱心に支援するグループを持つことによって節約される時間よりもはるかに短いです。

于 2009-03-26T21:15:58.193 に答える
1

チームが十分に小さい場合、SVNコミットコメントを適切に使用し、それらを活用することで、RSSフィードを生成するツール（たとえばTracなど）を使用して、コミュニケーションを促進する簡単で効率的な方法を利用できます。

これが機能するためのいくつかの要件があり、それらは非常に簡単に達成できます。-頻繁にコミットする（これは、各プログラマーのローカルな変更から誰もが恩恵を受け、問題を早期に特定できるため、それ自体は良いことです）。-詳細なコメントを使用します（何かが故障した場合に、変更されたものをより簡単に追跡できるため、これは良いことです）。-全員が実際にフィードを読んでいることを確認します（RSSリーダーを介して投稿を続けます）。

もちろん、そのようなコメントに「返信」する方法はありませんが、誰かが本当に返信する必要がある場合は、おそらくその人とコミッターの間にあるので、通常はメールで十分です。

他の便利なツールは、各開発者に、たとえば、週に1回、仲間のコーダー向けの推奨事項の10程度の箇条書きリストを、彼/彼女が本当によく知っているトピックについて書くように依頼することです。

于 2009-03-26T21:17:38.500 に答える
1

時間。

正式

ほこりの多いオフィスから出て頭をすっきりさせたり、講義やトレーニングに時間を割いて参加したりすることは、知識を広めるのに役立ちます。

また、予算を立てるのも簡単です。N 人の開発者が T 時間会議に出席します。

非公式

「オン・ザ・ジョブ」研修…具体的な仕事に必要なことは、その仕事を知っている人にしか教えられません。

現在の状況では、現在の圧力 (今すぐ出荷しなければならない) の下で、誰も何かを完全に説明するのに時間をかけません。人々がリラックスしているときだけ、情報共有の準備が整います。人は時間があるとリラックスします。

それとは別に、実際に考え始める前に、特定のリンカ エラーに遭遇する必要があります。考えたり、質問したり、読んだりする時間がなければ、知識を得ることはできません。公式のリンカトレーニングまで延期することはできません。

予算を立てるのが難しい: 開発者の Mary は、開発者の Sophie に動的リンクについて 1 時間半にわたって尋ねました。翌日、彼女はいくつかの質問をして戻ってきました。経験豊富な開発者は配布により多くの時間を費やしますが、若い開発者は学習により多くの時間を必要とします。

于 2009-03-27T09:24:51.280 に答える
1

私はペアで作業することの大きな支持者です。これは、知識を伝達し、コミュニケーション ラインを開いたままにしておく良い方法です。各プロジェクトのペアも混ぜてみてください。

于 2009-03-26T21:00:39.587 に答える
-1
  • 壁なし - すべての開発者を、壁のない 1 つの大きな部屋に配置します。そこでは、誰もがお互いを見て話し合うことができます。
  • 共通の目標 - チームが自己改善の目標を含む目標をよく理解できるようにする
  • やりがい - やりがい - コミュニケーション以上のものではなくても - あなたが達成しようとしていることを強化します

社会化と共通の目標は、常に情報交換を促進します。

于 2009-03-27T18:29:09.957 に答える