ソフトウェア開発プロジェクトの成果物
プロジェクト管理の標準フレームワークに従って、ソフトウェア開発プロジェクトの場合、毎月末に成果物（ドキュメントとソフトウェア）を提供します。
私の質問は：
5月から6月にかけて、ソフトウェアの開発中、毎月の成果物はどのようになりますか？
各ドキュメントはバージョン1.0から始まります。 1か2か月後にバージョン2.0と同じドキュメントを配信することは可能ですか？途中で変更が発生する可能性があるためです。
ユーザーやクライアントは、毎月の成果物として何かを見たいと私に尋ねます。そのため、彼らはプロジェクトが方向性なしに進んでいるとは感じません。
途中で変更が発生する可能性があるとおっしゃったように、サイクルタイムを1〜2週間に短縮し、毎月の終わりまで待たないようにすることは可能でしょうか。これにより、ユーザーがソフトウェアを開発しているときに何かを見ることができます。また、ユーザーはいくつかのフィードバックをより迅速に行うことができます。これは、彼らが何かが変わったのを視覚的に見て、毎月の終わりに神経質に待っているのを見ないように彼らに感じさせます。そのため、短い会議を開いて、毎週または2週間の成果物を彼らに知らせることができます。これは、小さな機能が完成するのに1か月丸ごとである必要はないと思うからです。タスクが大きすぎる場合は、スライスして小さなタスクに分割できます。そうすれば、ユーザーは予想以上に多くのことを見たと思うでしょう。
そして、バージョン番号は、ユーザーに同意するために必要なものだと思います。小さな変更は1.1.1と呼び、毎週1.1.2に上がり、毎月末に確実に1.2または1.3に上げることができます。
上記に基づいて、あなたは仕事のスケジュールを持っています。その作業には、仕様、技術要件、およびプロトタイプが含まれます。
これに基づいて、5月から8月の成果物はアプリケーション/プロジェクトの段階的なリリースであり、各リリースはプロトタイプに基づいて構築されるため、5月にはアプリケーション/プロジェクトが25％完了し、6月は50％完了します。 。
もちろん、5月にその25％以内に完了するモジュールもあれば、100％完了するものもあれば、0％完了するものもあります。
5月から8月の成果物を承認する前に、毎月アプリケーション/プロジェクトのどの側面/モジュールを完了するかを指定する必要があります。
はい、提供されたモジュール/変更要件に基づいて、バージョンを1.0から2.0に移動できる可能性がありますが、マイナーな変更を1.0から1.1または1.2などにするのがより一般的です。
プロジェクトの途中でメジャーバージョンの変更が発生している場合は、必要な機能を使用してプロジェクトを予定どおりに完了できない可能性があります。