プログラマーWikiの保守[終了]

https://stackoverflow.com/questions/247967

wiki

05-07-2019
|

質問

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

開発チームが内部ウィキに使用するベストプラクティスは何ですか？
開発ウィキで重要な情報は何ですか？
開発チームのwikiにアクセスする場合、どのような情報が表示されますか？
良いアイデアのように思えても、wikiに載せるべきではない情報はありますか？

-編集-

また、情報を整理する良い方法はありますか？（レイヤー（data、ui）、porject、その他）など

解決

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

私が普段そこに置くものは他にもあります

計画/仕事リスト
他の人が読むのに興味深い情報
共有すべきだと思う他のすべて

他のヒント

開発ウィキがあり、素晴らしいツールでした。 すべてに使用しました！

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

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

開発ウィキが私たちと同じくらい便利であることを願っています！

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

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

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

分解図
開発環境の共通のセットアップ情報（新しい人が開始するときに最適）
仕様
開発ツールに関する既知の問題と回避策

ある種のスタイルガイドを用意し、他の人にスタイルの作り方を教えます。私が企業のWikiを担当していたとき、他のすべての開発者はかろうじてフォーマットされたひどい見た目で散文を書きました。

議論を必要とするものから遠ざけてください。本のレビューセクションで靴べらを試してみましたが、他の人に物事についてコメントしてもらうのは難しすぎました。

社内図書館の例は良いです。および/または「ストーリーボード」 MethodXが呼び出されたときにプロセスをユーザーに案内します。

開発チームが内部ウィキに使用するベストプラクティスは何ですか？

見栄えを良くします。それは重要ではないように聞こえますが、ブランド化に少し時間を費やせば、実際にそれを使用している人々の観点から見返りが得られます。そして、取り込みが重要です。そうでなければ、枯れてしまいます。

開発ウィキにはどのような情報が重要ですか？

プロジェクトに関する一般情報、マイルストーン、納期など
設計決定/会議の概要。重要なのは、同じエリアを何度も再訪しないようにすることです。
現在のプロジェクトの一般的な開発に関するハウツーガイド（たとえば、新しいプラグインの開発方法）

開発チームのwikiにアクセスする場合、どのような情報が表示されますか？

プロジェクト情報、誰が何に取り組んでいるかなど。設計上の決定。また、ベストプラクティスと便利なサイトへのリンク。

良いアイデアのように思えても、wikiに掲載すべきでない情報はありますか？

低レベルのタスクリストは変動する傾向があり、最新に保たれないため、誤解を招く可能性があります。また、部門間の重要な通信は電子メールに適しているため、会話をウィキにコピーできます。それ以外の場合は無視するのは簡単です！

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

たとえば、「現在のバーンダウンチャート」ではなく、ページで、「2008年10月27日の週のバーンダウンチャート」のページを作成します。そして、人々がチャートにコメントすることを奨励し、それが何を意味するのか、そしてその週あなたがなぜそんなにうまくいかなかったのか。

最も難しいのは、開発者にウィキを使用させることです。ここに長年の提案があります： http://possibility.com/wiki/index。 php？title = GettingYourWikiAdopted

Wikiの採用は難しい

チャンピオンを獲得

異議の削除

コンテンツの作成

Wiki in Companyプロセスでメッシュを取得

福音化

あきらめないでください

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

Just Do It！予算を待つな

移行計画を立てる

Wikiのプロモーション

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

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

私の意見では、Wikiを成功させるための鍵は、チーム全体を参加させることです。それは、人々を知識リポジトリとして他のリソース（特に電子メールアーカイブ）から遠ざけ、人々が貢献するためのインセンティブを提供することを意味します。

ただし、フォーマットツァーにならないことも重要です。たとえば、MS WORDで生成するドキュメントが多数ある場合は、Wikiフォーマットですべてを実行するのが理想的かもしれませんが、時間がかかり、ダイアグラム、ドキュメントなどがある場合は迷惑です。これらの場合、最新バージョンにアクセスする唯一の方法がWikiを介している限り、妥協して、人々がそれを単語形式で保持できるようにする方がよいでしょう。

マネージャーでない場合は、「執行」が必要になるため、マネージャーを乗せる必要があります。

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

私たちは、チームWikiを収容および社内に保管しています。そして、開発中の各プロジェクトに必要なすべての情報を入力します。

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

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow