特定のプロジェクトごとに必要な量の技術文書を推測することは非常に難しく、重要です。 プロセスの速度、品質、コストはそれに依存するため、 重要です。 プロセス自体は時間の経過とともに変化する可能性があり、エグゼキュータは変化する可能性があるため、プロセスの特定の状態に対して適切なセットとドキュメントの量を選択することはそれほど容易ではありません。
ここで、小さなプロジェクトの作業を文書化する私のアプローチについてお話したいと思います。 小さなプロジェクトとは、アナリストリーダー、1〜3人の開発者、テスターです。 またはいくつかの同様の構成。 文書化により、ディスカッション、要件管理、変更管理、バージョン管理のプロセスをサポートするために作成された成果物を理解しています。 私は他のプロセスを文書化しません。
ツールキット
私はエンタープライズアーキテクト、AxureRP、Github、Skypeを使用しています。 以上です。
議論
すべての交渉の結果を修正します。 少し時間がかかりますが、次のような質問に答えることができます。「なぜこれが必要なのですか？」、「なぜ今必要ないのですか？」 質問の最初のグループは、分析部分の妨害またはいくつかの古い機能への復帰により発生する場合があります。 質問の2番目のグループでは、転換点でより自信を持って意思決定を行うことができます。
githubで、Wikiに会議議事録ページを作成し、そこでディスカッション結果を時系列で記録しました。 タイトルに議論の日付と主題を示します。 すぐにgithubに書き込みます。 したがって、すべてのディスカッションの結果を含む1ページがあります 。 ディスカッションがSkypeのテキストであった場合、Skypeで編集中のメッセージを1つ書いて確認を求めています。 確認とともにgithubにコピーします。 1つのディスカッションの平均録音ボリュームは5〜10行です。
必要条件
これは少し複雑です。 コミット：ユーザーインターフェイス、サブジェクトエリア、各反復の要件テキスト。
ユーザーインターフェイス -AxureRPを使用。 私は詳細に文書化しています-ボタンまで、ページ遷移のダイナミクスを追加し、ページの一部を更新します。 適切なユーザーシナリオ向けのソリューションを設計する際の開発者自身の間違いを特定するために、開発者へのタスクの配信を高速化するのに役立ちます。 共有用のインターフェイスを公開し、要件とディスカッションの必要なページへのリンクを使用します。 とても快適です。 各変更の直後にインターフェイスを更新します。
これは私の最も一般的なインターフェイスプロトタイプのようです：
サブジェクトエリア -私はEnterprise ArchitectをER図の描画としてのみ使用しています。 この段階は私にとって非常に重要です。なぜなら、その上で、提案された実装を変更するための多くの提案をキャッチし、将来的に特定の利点を得ることができるようになるためです。 非常に小さなプロジェクトでは、このコンポーネントをしばしば省略します。 結果の図の写真をaxshareプロトタイプと一緒に公開し、反復割り当てまたはSkypeのディスカッションでそれらへのリンクを提供します。これにより、開発者はタスクをよりよく理解できるようになります。 また、プロトタイプユーザーインターフェイスから直接ダイアグラムへのリンクを提供して、開発者が要件を読むときにコンテキストを失わないようにすることも非常に便利です。
要件 -私はすぐにgithubで書いています。 wikiのgithubで、 すべての変更（それぞれ、すべての反復）が時系列で含まれる別のページを作成しました。 プロトタイプとドメイン図へのリンクを使用します。 ロジックのみを説明します。 より詳細に記述すると、ドキュメントの維持コストが急激に増加します。 1〜10行の4〜5段落の平均ボリューム。 反復は通常3〜10日です。
このアプローチにより、 1つのページで反復および分析の年表全体と開発者を確認できます。 また、これは非常に重要です。同じページを使用して、次の反復の計画を記録します。 現在の反復を色または太字のテキストで強調表示します。 時々、反復の開始日と終了日の事実/計画日を示します。 現在から計画された反復が遠いほど、プレゼンテーションが抽象的であるほど、より詳細になります。 私は、開発者やプロセスの他の参加者との議論のために、将来の反復の説明を使用します。
反復要件の典型的な例：
反復の要件を文書化するのに平均して週に1〜2時間かかることを計算しました：サブジェクト領域に1時間、インターフェースの設計に1時間、要件のテキスト記述に最大1時間。
変更点
この変更により、バグと強化の2つのタイプが特定されました。 トラッカーとして、私は同じgithubを使用します。 時間が経つにつれて、次の一連のタスクラベルにたどり着きました。
そして、ステータスを貼り付けるための次のルール：
作成。 アナリストはタスク（バグまたは機能強化）を実行し、オプションでエラーが戦場にあり、テストにない場合-as（prod）を示し、オプションで修正が緊急に必要かどうかを示します（A）。
作業開発者は、タグ（A）を持つタスクがないかどうかを確認します。 ある場合はそれを取り、そうでない場合は次に取ります。 読み取り、修正（アップロードが必要）、または複製できない（複製できない）、または追加情報が必要（情報が必要）と表示されます。
情報反応が必要な場合、アナリティクスはコメントで回答し、タスクを削除（情報を複製できない/情報を必要としない）するか閉じます。
作業タスクが削除されず設定されている場合（アップロードが必要）、開発者は修正します。
テストの記入開発者は、テストサーバーにアップロードされた内容を修正し、必要な更新を削除します。 バグが戦闘のものから指定されている場合、開発者は戦闘のものに変更があるまで修正済みに設定しません。
テストの検証テスターは、タスクを探して閉じるか、タスクを開いたままにして修正を削除します。
バトルを埋める開発者はバトルに注ぎます：-すべてクローズ、修正済み（同時に固定を削除）-（prod）および（アップロードが必要）がすべて開いています。
戦いを確認するテスターは、（prod）と（fixed）のバグをテストし、すべてが正常であればタスクを閉じます。
* wikiには開発者や他のプロセス参加者の本名があります。 役立ちます。
コードバージョン
ここではすべてが非常に普通です。 githubを使用しています。
おわりに
私はこの形式の仕事に、アナリスト/プロジェクトマネージャーとして数年間働き、小規模企業の自動化プロジェクトと従来のインターネットサービスの両方に取り組んできました。 上記はささいなことかもしれませんが、それは本当に時間を節約し、チーム全体がイベントに遅れずについていくことを可能にし、余分なドキュメントをサポートする時間を失いません。
ありがとう