反復的なドキュメント開発は可能ですか？それは効果的なドキュメントを提供しますか？
私はすぐには始められない大学のためのプロジェクトを持っていますが、かなり長い間考えていました。大学のプロジェクト開発は業界とは違う（私は現在私はインターンです）ので、現時点で指摘している状況は、実際のソフトウェア開発者にはおそらくばかげているように思えます。 ^^ '
プロジェクト自体には、多くの作業を文書化する必要があります。したがって、マークの数にカウントされるコードの配信に加えて、以下を含むドキュメントを配信する必要があります。
- 要件分析ドキュメント
- プロジェクト計画
- ユースケース、オブジェクトモデル、動的モデル、受け入れテストの計画リスト
- テストプロセスのドキュメントとテストの成功度
- 他のいくつかの議論と時間の使い方などの分析.
これらの成果物は、次の方法で提供されます。
- 最初にRAD
- プロジェクト計画、ユースケース、モデル、テストが続きます（約3週間後）
- 最後に、実際のプログラム、テストプロセスなどのドキュメント+実際のプログラミング自体（約5週間後）
したがって、私が理解していることから、これはプロジェクトへのウォーターフォールスタイルのアプローチに向けられています。 （私の意見では）唯一の問題は、これが大学のプロジェクトであり、プロジェクトの週の学期の終わりにプロジェクトを開発しようとするときと同じように、学生にはすでに十分なプレッシャーがあります。私が学期の終わりにすべてをコーディング/開発/テストすることは本当にしたくないのですが、私が対処しなければならない他の多くの評価にパニックになるでしょう。
少なくとも試行錯誤を繰り返して、コーディング/プロトタイピングを早期に開始でき、最後の分にすべてを行うことに焦点を合わせておらず、それほどプレッシャーがない、継続的な開発サイクルを持っていることを意味しますこのプロジェクトを完了するための学期の終わり。そして今、私の実際の質問が来ます：
- すべてのドキュメントを高速な反復/プロトタイピング開発サイクルで提供する必要があることをどうにかして調整できますか？
- 反復的な方法でドキュメントを生成するための戦略はありますか？
- 私はこれを完全に無理に尋ねて、大学でそれができると期待していますか？
また、この質問は非常にローカライズされていることを理解しているので、業界に関して上記と同じ質問をしたいと思います。また、アジャイルプロセスが直面するこの種の問題の多くがチームごとに異なるかどうかまたは会社。
とにかく、これがどれだけ長いのかすみません、そしてあなたが最後まで読み終わったなら、ありがとう！お時間を割いて頂ければ幸いです！ありがとうございました！
主な関心事（私は私の仕事にも同様の問題があります）は、「プロセス」が特定の時間に特定のアーティファクトを提供することを要求し、誰もが「プロセス」に挑戦することを許可されていない場合、緩みます！それは、それがより良い方法であるという単純な問題ではありません（どの反復型ドキュメント開発がそうであるか）。
したがって、必要なのはプロセス内での作業ですが、希望どおりに作業する方法も見つけます。たとえば、プロセスでは、一度送信されたドキュメントの変更を許可していますか？そうでない場合、反復的な開発は不可能です。もしそうなら、あなたは配達の費用（あなたの時間、あなたの信頼性などに関して）を考え、その費用を管理する必要があります。たとえば、ファイルのコピーだけで何も起こらない場合は、それを試してください。 （私のように）それがピアレビュー、改訂リリースであり、数十人に影響を与え、数千ドルの費用がかかる場合は、慎重に検討し、新しいドキュメントが本当に価値をもたらすことを確認してください。
作業の一般的な方法は、最低限必要な最低限のドキュメントであり、最初に「プロセス」のニーズを満たし、その後、現実を反映するだけでなく、必要に応じて詳細を含む最終的な「構築時」の更新が続きます。コードがそれ自体を語る簡単な説明。