私は古い雇用主を辞任して新しい仕事を始めました。私は引き継ぎの準備をする必要があります[まだ到着していない新入社員が提出する書類で、職務に就いてから数週間後になります。再び]。
だから重要なポイントをカバーしなければならない、
私はいくつかのiOSアプリ、[90%完了]、およびWebポータル[60%完了]を作成していました
他のITエンジニアがここにいるので、パスワードなどを更新できます。
Wikiのようなシステムを使用して、そこにアクセスできるようにする必要がありますか?それとも通常のドキュメントですか?
他に何を考慮すべきですか?
ドキュメントの形式を気にする必要はありません。私はwikiではなくプレーンドキュメントに固執します。機械的な問題に気を取られて、ドキュメントの作成に費やす価値のある貴重な時間を無駄にしがちです。
文書化する重要なポイント:
ドキュメントで回答する最も重要な質問:
チームに関する情報を含めることもおそらく良いことですが、これが必要かどうかは状況によって異なります。
なんらかのバグと機能の追跡があると思います。そうでない場合は、通常そこに置くすべてのものを含める必要があります。
特定の関数の特定の癖など、コードの特定の部分に関する詳細情報は、ソースコード自体のコメントに残すのが最適です。それらが完全で正確で有用であることを確認してください。そして、あなたがそれにいる間:未使用/コメントアウトされたコードを削除し、一般的なクリーンアップを行い、これまでに取り組んだすべてを再検討します(それが可能であれば)。
これに取り組む最良の方法はあなたの視点からです。あなたのプロジェクトについてあなたが今知っていることを考えて、あなたが仕事を始めた最初の日にあなたがあなたが何を知っていたかったかを自問してください。次に、その情報がwikiで記述されているか、ワープロを使用しているかに関係なく、構造化文書に編成します。現在の同僚がプロジェクトに参加する場合は、彼らと協力して、彼らが何を求めているかを確認してください。
また、既存のドキュメントを更新する必要がありますが、古くなっている可能性があります。アプリケーションの現在の状態に対応していない仕様、設計ドキュメント、またはユーザーマニュアルよりも悪いものはありません。個人的には、開発を始める前に、プロジェクトに関連付けることができるすべてを読んで、エンドユーザー、要件、以前の開発者、およびプロジェクトへの指示と影響についての感触をつかみます。古くなったドキュメントは、この取り組みを本当に妨げています。
複雑なドキュメンテーションシステムに心を込める必要がないという事実に同意します。 Algerは、渡す必要がある情報について答えました。また、あなただけが知っているかもしれない多くのパスワードに注意することを忘れないでください。
私は TiddlyWiki を個人的に使用しています。これは、HTMLファイルに保存されているミニWikiです。これは、さまざまな情報を保存し、HTMLファイルを新しい人に渡すだけでよい情報を渡すための本当に素晴らしいツールです。メンバーにはそれぞれ独自のwikiがあり、「newcomer」ミニwikiも用意しています。新しいwikiは継続的に更新され、新しい開発者が到着するたびに提供されます。これには、ソフトウェア、コードソースリポジトリの場所、特定のJavaプロジェクトなどの責任者)などのさまざまな情報が含まれています。