開発アプローチ文書には何を含めるべきですか？
私は、オフショアリソースが私たちのプロジェクトに着手するときに、オフショアリソースの「開発アプローチ」ドキュメントを共同制作している最中です。
当社が使用した最新の（類似した）ドキュメントは80ページを超えており、これにはコーディング標準/規約のドキュメントは含まれていません。
私の懸念は、このドキュメントは消費できず、したがって失敗することです。
開発アプローチ文書にはすべきは何ですか？このトピックに関して適切なガイドラインはありますか？
編集：開発アプローチ文書には、ソフトウェアの設計、構築、およびテスト中にソフトウェア開発者が使用するプラクティスとテクニックの詳細を記載する必要があります。
私が働いていた会社の1つでは、多くのドキュメントを使用して、この全プロセス指向のアプローチがありました（そのほとんどは、プロジェクトマネージャーからの入力を求められました）。しかし、長さと説明にもかかわらず、私はそれが人々をサポートするためにほとんど使用されていないことに気づきました-本当の開発者。
それで、私は「開発者を助ける」という特定の目的で自分を引き受けることに決めました。私が始めた最も重要なことは、最も基本的な質問-real FAQを収集することです。
私が学んだことは、特定のプロセスを採用したい場合、ほとんどの人にとって以下のことが重要であること、そして彼らが事前のアイデアを持っていないかもしれないが、ロジックを理解すればすぐに感謝する多くのことです。
このようなドキュメントが役立つはずの主要なトピックは次のとおりです。
開発から展開へのプロセス-コードをどのように編成、コンパイル、公開する必要がありますか（DLL、ライブラリ、実行可能ファイル、インストーラー、Webページの形式で、どのように展開およびテストするのですか）。
どのようにバージョン管理を行うべきですか？ （そして初心者がいる場合はなぜか）。リポジトリの構造、行動規範-チェックインが受け入れられる場合と受け入れられない場合、バージョン/タグが発表されたとき、パッチ、マージがどのように適用されるか、パッチまたはリリースが宣言された完了
方法論の実行-俊敏性はありますか。どの方法論を使用するか、事前設計を行いますか？これを考えると、特定の会社の修正になる可能性があります。さて、ほとんどの人にとって、彼らは知りたいどのようにそれを実装するのか与えられたプロジェクトについて。これは、人々がさまざまなマイルストーンを視覚化できるようにするプロジェクトと、潜在的に重要なことについて非常に具体的です。研究指向のプロジェクトでは、「重要なアルゴリズムを上に構築する前に常に検証する」ことをシュリンクラップで示し、機能の正確さと重要性に焦点を当てます。
コミュニケーションの責任-正式なコミュニケーションをどのように行うかを定義する-これは、特定の人々が互いに話し合うことができるかどうかでは行われません-しかし、人々は何であるかについての感覚を持っている必要があります十分重要（問題、設計決定、機能フリーズ）実装に進む前にアナウンスまたはディベートすることもできます。
最後に、すべての人がコード品質、コーディング標準、および一般的に大丈夫か衛生レベル以下であると私たちが考えるものについて共通の理解を持っている必要があります。
すべてのプロジェクトをそのようなドキュメントから始めたいと思いますが、それは簡単ではありません。しかし、重要なことは、日々の行動と開発者の選択に関連するすべての問題に対処することです。これは、市場への複数のリリースを配信する必要がある場合に長くかかります。
最後に、可能な限り非公式にすることをお勧めします。通常、プロセス指向の人は、文脈の外で誤解される可能性のある非公式のドキュメントはあまり好きではありません。ただし、開発者をつなぐ方法で行う必要があります。
「開発アプローチドキュメント」と呼ばれるものは、通常ソフトウェアプロジェクト管理計画と呼ばれます。 （ソフトウェアプロジェクト計画またはソフトウェア開発計画。）これらの条件があれば、そこにあるいくつかのサンプルについてGoogleにアクセスできるはずです。 Victor HurdugaciとDonal Fellowsが述べたように、作成するソフトウェアプロジェクト管理計画は、（1）ニーズに合わせて調整され、（2）状況の変化に応じて最新のドキュメントとして更新されます。とはいえ、これまで一度も書いたことがなく、他に何を入れればよいかわからない場合は、ゼロから作成するのは難しい場合があります。
IEEE標準1058（ソフトウェアプロジェクト管理計画のIEEE標準、1998年）によるガイダンスがいくつかあります。投稿された標準のコピー here があります。この計画はかなり重いと思いますが、アイデアを得るにはまともな場所です。オフショアのチームのためにすべて書面で書く場合は、追加の重みが必要になる場合があります。また、かなり良い概要があり、ソフトウェアプロジェクトを計画する方法についてのいくつかの優れた説明があります。本の中で、従来の（非アジャイル）ソフトウェアプロジェクトについてかなり頻繁に取り上げています。品質のソフトウェアプロジェクトFutrell、Shafer、およびShaferによる管理。
アプローチ文書は 「ここにもそこにもない」 資料。これは、ソフトウェアアプリケーション開発組織のプロジェクトマネージャー（ソフトウェア開発マネージャー）からビジネス組織のプロジェクトマネージャー（ベンダーマネージャー）が一般に尋ねたドキュメントです。
このドキュメントの目的は、Business Org PMのニーズによって異なります。
ハードウェアアーキテクチャ、システム機能、通信計画、構成計画、リソース読み込み計画、テクノロジスタック、アプリケーションアーキテクチャなどを含めることができます。
繰り返しますが、上記のリストはニーズに基づいて可変です.. :)
そのような文書に関する正式な文献はまだ見ていません。標準的な著者によるものがある場合は、プレスマンなどが共有します。
または私は何かが欠けていますか？.
要件の変化や、使用する言語、ライブラリ、フレームワークのセットの変化に伴い、開発慣行は時間とともに変化します。この変更は必然的であり、紙に置いたものはすべて（ほとんど）すぐに古くなることを意味します。これに対処する方法は？すべてをwikiに保存し、チームのすべてのメンバー（社内外を問わず）を更新して関連性を維持できるようにしてください。
死んだ文書から生きた文書に一歩踏み込んだら、何を入れるべきかという議論の緊急性は低くなります。今考えられることだけを入れて、後で戻ってくるだけです。 （良い点は、最初にドキュメントを書くためにすべてを理解する必要がないことです。）また、古い80ページのドキュメントの古いコンテンツをすべてシードすることもできます。それはあなたに他に何もないにせよ多くのアウトライン素材を与えるでしょう、退屈なものの巨大なscadsを書くことを考える必要からあなたを救います。
ドキュメントは短くしてください。新聞スタイルの構造化を使用してください-高レベルの詳細から始めて、詳細に従ってください。標準プラクティスを含める代わりに、それらを参照し、標準からの逸脱を詳しく説明します。
1：社内ですでにプロジェクトを行っている場合は、そのプロセスに参加します。多分彼らにあなたのプロジェクト開発の管理を下請けにすることさえします。車輪を再発明しないでください。
2：社内で開発をまだ行っていない場合は、使用している請負業者がプロジェクトに使用する適切な方法論を持っていることを主張します。次に、その方法論を使用します。
信頼するが検証する。あなたは長期的にゴミを取り除こうとしています。したがって、彼らに何もさせないでください。最後に成果物のみを使用して、任意のプロセスに従ってください。先に進む前に、成果物を完成させて確認するように要求します。
それを超えて、私は基本的に@Dipanに同上します
当社が使用した最新の（類似した）ドキュメントは80ページを超えており、これにはコーディング標準/規約のドキュメントは含まれていません。
すでにいくつかのドキュメントを持っているので、それが出発点です。自問してみてください：
- このドキュメントで何が役に立ちますか？
- 何が欠けている？
- なぜ私はこのドキュメントを使用するのでしょうか（しません）？
答えが出たら、不要なものを切り取り、足りない部分を追加します。
ドキュメントの実際の内容は利用可能なリソースによって異なり、提供された情報を使用して推測するのは難しいと思います。
ヒント：このドキュメントは時間をかけて調整したいので、書きすぎないでください;）