19

私は最近、開発チームの wiki を担当しました。wiki はまだ初期段階にあるため、作業の余地がたくさんあります。目標は、開発チームの内部に収容することです。現在、ウィキが保持している主な情報はコーディング標準です。

  • 開発チームが内部 wiki で使用しているベスト プラクティスは何ですか?
  • 開発者 Wiki で重要な情報は何ですか?
  • 開発チームのために wiki にアクセスするとしたら、どのような情報が表示されると思いますか?
  • 良い考えのように思えても、wiki に載せるべきではない情報はありますか?

- 編集 -

  • また、情報を整理する良い方法はありますか？(レイヤー別 (データ、UI)、プロジェクト別など)
4

11 に答える 11

9
  • 新しいプログラマーのためのソース ベースの紹介
  • 一般的なドキュメント (API ドキュメント自体ではなく、チュートリアルのようなもの)
  • スタッフのリスト / 誰が何をしているか、どのように彼らに連絡するか
  • ソフトウェアで使用される概念を説明するメモ/リソース/記事
  • コードベースのビルド プロセスとファイル システム レイアウトのドキュメント

私が通常そこに置く他のものは

  • 企画・TODOリスト
  • 他の人が読むのに興味深い情報
  • 私が感じる他のすべては共有されるべきです
于 2008-10-29T18:56:15.553 に答える
6

Wikipatternsは、ウィキのベストプラクティスを文書化することを目的としたWebサイトです。また、アンチパターンについて説明し、それらに対処する方法について話します。私は彼らの本を読みましたが、150人以上の組織でウィキを立ち上げることは私にとって大きな財産でした。

于 2008-12-09T04:38:36.413 に答える
6

開発 wiki があり、それは素晴らしいツールでした。すべてに使用しました！

  • 新しいアイデアをブレインストーミングするときは、wiki でそれらをキャプチャします。wiki の摩擦が少ないという性質により、組織内の誰もが (私たちは小さなスタートアップでしたが) 思いついたアイデアを簡単に追加できました。各アイデアの完全な説明を含む詳細なページにリンクする、高レベルの「ブレーンストーミング」ページがありました。
  • 反復ごとに、「ブレインストーミング」リストからその反復の機能リストに機能のアイデア項目を「移動」します。機能の詳細は、設計と実装の詳細を含めるために洗い流されました。
  • 機能が完成すると、イテレーション ページがリリース ノート ページになりました。これには、バージョン管理システムからのリリース タグも含まれています。
  • 機能ページと非常によく似たバグ ページがありました。バグ修正は、作業中/完了時にイテレーション/リリース ページに追加されました。
  • また、Wiki でユーザー ドキュメントを作成し、それらのページをリリースと共にエクスポートしました。

時間が経つうちに。このツールはますます価値が高くなりました。会社が取り組んでいるさまざまな製品の新しい wiki を作成することになりました。

あなたの開発 Wiki が私たちと同じくらい役立つことを願っています!

于 2008-10-29T19:45:12.927 に答える
2

開発 wiki で強調していることの 1 つは、状況が変化すると更新されるということです。情報を提供し、収集された知識の中心的な情報源となることを目的としたウィキが、時代遅れになりすぎて役に立たなくなることは望ましくありません。コードが更新されると、開発者は wiki 上の関連情報を更新するように要求されます。

コーディング標準の他に、コード ベースを操作するためのヒントやコツ、新規採用者向けのセットアップ情報、および一般的な環境情報を保持しています。

于 2008-10-29T19:00:51.253 に答える
2

最も難しい部分は、開発者にあなたの wiki を使ってもらうことです。ここに長年の提案があります: http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted

Wiki を採用するのは難しい

チャンピオンを持つ

反対意見を削除

コンテンツの作成

会社のプロセスに Wiki を巻き込む

伝道する

あきらめてはいけない

会話に Wiki を使用しないことを検討する

早くやれよ！予算を待つ必要はありません

移行計画を立てる

ウィキの宣伝

良い方法の 1 つは、各ビルドのドキュメント全体とソース コードを Wiki から入手できるようにすることです。その後、開発者は wiki にアクセスしてビルド情報にアクセスし、それが非常に貴重になります。

于 2008-10-29T19:56:10.517 に答える
2

Wiki はソフトウェア開発チームにとって貴重なリソースになる可能性がありますが、特効薬ではありません。急速に使われなくなったり、著しく時代遅れになったりする Wiki を作成するのは非常に簡単です。

私の意見では、Wiki を成功させる鍵は、チーム全体を参加させることです。つまり、人々をナレッジ リポジトリとしての他のリソース (特にメール アーカイブ) から遠ざけ、人々が貢献するための何らかのインセンティブを提供することを意味します。

ただし、フォーマットの専門家にならないことも重要です。MS WORD などで大量のドキュメントを生成する場合、それらをすべて Wiki フォーマットで作成するのが理想的かもしれませんが、時間がかかり、煩わしい場合があります。そのような場合、最新バージョンにアクセスする唯一の方法が Wiki である限り、妥協して Word 形式で保持することをお勧めします。

あなたがマネージャーでない場合は、何らかの「強制」が必要になるため、マネージャーを参加させる必要があります。

Wiki とそのソフトウェア エンジニアリングでの使用に関する研究と経験が蓄積されています。たとえば、ACM デジタル ライブラリを検索できます。私は SE のためのウィキに関する年次ワークショップの共催者であり、いくつかの興味深い経験報告があり、ウィキに関する国際シンポジウムには追加の資料があります。

于 2008-10-29T19:56:25.383 に答える
1

私たちは、社内チームwikiを収容しています。そして、そこに私たちが開発している各プロジェクトに必要なすべての情報を入れます：

  • リポジトリ
  • 仮想マシンのアドレス
  • パスワード
  • プロジェクトのドキュメント
  • プロジェクトの概要
  • プロジェクトのステータス

そして、私たちが記入する他のものはすべてプロジェクトに書く必要があります。そして、それは私たちが実行している最も便利なWebアプリケーションです（Mantisを除く）。より一般的なページには、使用しているすべての分類法、一般的なプロジェクトガイドライン、ポリシー、コーディング、および使用しているプラ​​クティスの開発の定義を記載しています。それはそこにあり、シンプルで効果的であり、すべてのチームがそれらの1つを持つべきだと思います。

于 2008-10-29T22:09:15.820 に答える
1

開発チームが内部 wiki で使用しているベスト プラクティスは何ですか?

見栄えを良くします。重要ではないように聞こえますが、ブランディングに少し時間を費やすと、実際に使用する人という点で見返りが得られます. そして、取り込みが重要です。そうしないと、枯れて死んでしまいます。

開発者 Wiki で重要な情報は何ですか?

  • プロジェクト、マイルストーン、納期などに関する一般情報。
  • 設計上の決定事項/会議の概要。何度も同じ場所に行かないようにすることが重要です。
  • 現在のプロジェクトの一般的な開発に関するハウツー ガイド (たとえば、新しいプラグインの開発方法)

開発チームのために wiki にアクセスするとしたら、どのような情報が表示されると思いますか?

プロジェクト情報、誰が何に取り組んでいるかなど。デザインの決定。また、ベスト プラクティスと役立つサイトへのリンクも含まれています。

良い考えのように思えても、wiki に載せるべきではない情報はありますか?

低レベルのタスク リストは変動する傾向があり、最新の状態に保たれず、誤解を招く可能性があります。また、部門間の重要なコミュニケーションは電子メールに適しています。その後、会話を wiki にコピーできます。そうしないと、無視するのは簡単すぎます。

于 2008-10-29T19:07:23.080 に答える
1
  • バーンダウンチャート
  • 開発環境の共通セットアップ情報 (新しい人が始めるときに便利)
  • 仕様
  • 開発ツールに関する既知の問題と回避策
于 2008-10-29T19:00:31.613 に答える
1

ある種のスタイルガイドを考え出し、他の人にスタイリングの仕方を教えましょう。私が企業の wiki を担当していたとき、他の開発者は皆、かろうじて書式設定された見栄えの悪い散文を書いていました。

議論が必要なものから離れてください。書評欄で靴べらを試してみたのですが、他人にコメントしてもらうのが難しすぎました。

社内ライブラリの例は良いです。および/または MethodX が呼び出されたときにプロセスをユーザーに説明する「ストーリーボード」。

于 2008-10-29T19:00:59.083 に答える
1

Wiki はインタラクティブであることを忘れないでください。バーンダウン チャートを公開する場合のように、公開について考えている場合は、十分に考えていません。その情報の配布はその一部にすぎません。

たとえば、「現在のバーンダウン チャート」ページを作成するのではなく、「2008 年 10 月 27 日の週のバーンダウン チャート」のページを作成し、そのチャートとその意味、およびその理由について人々にコメントしてもらいます。その週はうまくいきませんでした。

于 2008-10-29T19:48:58.303 に答える