すでにメンタリングがあり、お互いに情報を共有し、定期的に技術セッションを開催しています。ただし、記録と将来の新しいチームメンバーのために、これらのことを書き留めておきたいと思います。現在、約 30 人の開発者がいます。
社内ブログとウィキを考えています。
公開ブログで情報を共有できれば (また、公式の公開開発者ブログもあるかもしれませんが) 素晴らしいことですが、今のところは内部にとどめておきたいと考えています。私たちのショップは、製品ではなく、ほとんどがオーダーメイドのプログラミングを行っているため、そこには独自の顧客情報がたくさんあります. 公開ブログの自己検閲は、私たちを遅くするだけです.
Wiki はコンセプトとしては優れていますが、より多くの構成と編集が必要であるため、それが持続可能であるとは確信していません。
あなたの組織はそれをどのように行っていますか。
ウィキは素晴らしいです。それらは構造化する必要がありますが、ウィキを機能させる上での最大の障害は、人々に実際にウィキを使用して関連情報を書き留めてもらうことだと思います。
私の前職では、マイクロコミュニケーションに非常に役立つ内部 IRC チャネルがありました。私の現在の仕事では、これはまったく機能しません。仕事目的でチャットプログラムを使用する習慣を持っている開発者はほとんどいません。
まあ、どんな技術や製品を使うことに決めたとしても、それらは問題にはなりません。コーヒーマシンで十分に共有されていないすべての知識には注意が必要です。
何を使用しても、これに役立つテクノロジーはありません。そのためには、チームが何かを書き留めたり、他のチーム メンバーに電話をかけたり (そして中断したり) する前にまずリポジトリ内のものを読み上げたり、間違っている場合は修正したりするようにチームをやる気にさせる必要があります。
私の経験では、SharePoint と Wiki のパフォーマンスはほぼ同じです。人々がそれを使いたいと感じるまで、人々がそれを使用するのを打ち負かす必要があります。なぜなら、彼らはある時点で、そのようなタイプの情報共有が時間を節約できることを経験するからです。
すでに情報を共有する習慣があるので、これはそれほど難しい問題ではないかもしれません。1 つ (多すぎるよりは少数) で (予備の) 初期構造を提供してから、入力を開始することをお勧めします。完全な分類は存在しないため、あまり心配する必要はありません。
私たちは、wiki、scm、およびチケット発行用のTracと、相互に対話するためのプライベートJabber /IRC サーバーを組み合わせて使用しています。
以前の仕事では、ドキュメントを整理するために SharePoint を使用していました。これはかなり成功しましたが、サイトを最新の状態に保ち、関連性があり、適切に設定する必要があることは明らかです。しかし、SharePoint のアーキテクチャは柔軟で、コーディングに頼らずにニーズに合わせてカスタマイズできました。私が提案したいのは、あなたがどんな解決策を求めようとも、それを管理するための時間を取っておくことです. メンテナンスを行わないと、ドキュメント リポジトリが古くなったり、まとまりがなくなったりするのは非常に簡単です。私たちは、作業の各スプリントの終わりにチームのフォルダーを更新することを強調しました (スクラム アジャイル手法を使用しました)。
Wiki は、あまり形式張らない方法で知識を共有するための優れたアイデアです。WetPaint のプライベート wiki を使ってみましたが、経営陣からの同意は得られませんでした。ただし、試してみる価値はあります。編集のコントロールを必要とせずに済むわけではありませんが、この側面をチーム間で共有する責任にしたり、ラウンドロビン方式で行ったりすることには何の問題もありません。
私がお勧めするのは、カレンダーに知識交換セッションの時間を予約することです。大規模な開発会社がサイロに分割され (意図的にではなく、ほとんど必要な専門化の副産物として)、その結果、2 つ以上のチームが同じ問題の多くに取り組むことになりがちです。グループ全体での毎月または隔週のセッションは非常に役立ちます。ビデオによるプレゼンテーションも別のアイデアですが、技術的な詳細を記録することと、これを効果的に行うために必要な準備との間でバランスを取る必要があります。（以前の仕事では、これを軌道に乗せることはありませんでした。）
小さなチームに分かれている場合は、全員が前日に達成したことと今日行う予定のことを検討する、毎日のスタンドアップ ミーティングをお勧めします。これはスクラムの鍵の 1 つであり、全員が非常に迅速に最新の状態に保たれ、不必要な会議やレビューを大幅に節約できます。
これが役立つことを願っています。
簡単な情報にはYammerを使用します。これは Twitter に似たサービスですが、メール ドメイン内では非公開です。Web アプリケーション、Windows および Mac クライアント、さらには iPhone バージョンもあります。
ドキュメントについては、オープン ソース Wiki ( ASP.NET プラットフォームのScrewturnWiki ) を使用します。とても好評でした。
私が働いていたある場所では Wiki も使用していましたが、十分な頻度で更新されていないことがわかりました。人々にそれを使うよう促し続けなければなりませんでした。
明らかに、私たちは、プロジェクト コミュニケーション用の共有電子メール フォルダーを備えたクレイジーな共有ファイル システムです。
また、社内のインスタント メッセージング システムを使用して、オフィスで一斉にメールを送信することを回避しましたが、Fog Creek のように、プライベート Twitter のクローンを実装することになるでしょう。
私たちが行ったことの 1 つは、すべての開発者がオフィスの外のどこかに集まり、見つけた/行った興味深いことについてお互いに発表する日を毎年設けたことです。ある時はプロジェクトから、ある時は個人的な仕事から、そしてある時は月に 1 日から好きなことに取り組むことが許されました (Google の 20% の時間のように)。
コンテンツ管理には、 PloneとZWikiでZopeサーバーを使用していました。現在、SharePoint 2007を使用しています。
IM にもJabberを使用しています (私たちは分散型チームです)。IM は、チームとすばやく情報を共有するのに便利ですが、乱用しないように注意する必要があります。
私たちはウィキ、ディスカッション グループ、および特定のケースに焦点を当てたディスカッションにFogbugzを使用しています。インスタント メッセージングには、Sametimeを使用します。この組み合わせは、私たちに多くのインターフェースを強いることなく多くの機能を提供するため、私たちにとって非常に強力であることが判明しました. ローセレモニーいいですね。
注 - インスタント メッセージングは、私たちが使用する Sametime の唯一の機能です。他にも多くのクレイジーなことができると思いますが、私たちはまったく興味がありません。
メッセンジャーとメール
チャットにはCampfireを使用し、画像や短いビデオのデモンストレーションにはJingを使用します。彼らは非常に貴重であることが証明されています。
ウィキは過去に私のためにうまく機能しました。小さなVMで実行されている無料のScrewTurnwikiを使用しました。速くてとても使いやすく、人々はそれを気に入っているようだったので、実際に使っていました。
自宅で仕事をするプログラマとして (「オフィスに」行くという選択肢はありません) - 私たちの主な通信手段はプライベート IRC チャネルです。私たちは 3 人の開発者の小さなチームなので、うまく機能しています。
Skype は、情報を共有したり、簡単な質問をしたりするのに適しています。長期的なノウハウについては、Wiki を使用します。
私たちのチームはそれほど大きくない (11 人の開発者) ので、知識を共有するためのミーティングを毎月開催しています。それに加えて、興味深いドキュメントをイントラネットに追加するのに忙しくしています。
そして、私たちはよくお互いに質問をしに行きます。