作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
頻度: 反復ごとに 1 回 | |
役割: プロジェクト管理者 | |
ツール メンター: |
ワークフローの詳細: |
ウォータフォール アプローチと比較した場合の、反復アプローチの主な利点の 1 つとして、反復では進捗状況の評価とリスクの管理に対し自然なマイルストーンが提供されることが挙げられます。反復では、進捗状況とリスクを継続して評価し (非公式の場合)、問題によってプロジェクトが計画から逸脱しないようにします。
目的 | ステータスと改良を確認するために、プロジェクトの品質と進捗状況に関する情報を収集すること |
このステップでは、プロジェクトの測定計画に基づき、次の作業を行います。
反復の評価中にメトリクスを検討し、必要なアクションを決定します。これには、測定計画の再検討に加え、再計画、ツールの再選択や再作成、トレーニング、再整理などが含まれることがあります。サイクルの最後と同様に、「プロジェクト終了後のレビュー」により、収集したメトリクスの一部をプロセスの改善や見積もりの目的で利用できます。
数週間または数か月にわたる反復の場合、成果物: ステータス評価で定期的に中間結果を得ながら、メトリクス収集とレポートを継続的に行います。
目的 | 反復の予想結果と、実際の結果を比較すること |
各反復の終盤では、中心となるプロジェクト チームが会合を開き、次の点に焦点を当てて反復を評価します。
反復計画書に確立されている評価基準と比較して、反復の結果を評価します。機能、性能、容量、品質などの測定を使用します。評価の基礎としては、可能な限りテストの作業やメトリクスの収集ステップの結果として作成されたメトリクスを使用して、評価を数量化します。質的な測定は、方向づけフェーズや反復の初期では十分ですが、後の推敲フェーズ、作成フェーズ、移行フェーズでは、特定のテスト測定に基づいて品質、性能、容量などを評価する必要があります。反復中に実行されたステータス評価書に記載されたその他の未解決の問題や、プロジェクト管理者の問題リストのほかの問題にも対処します。
すべてのリスクが容認可能なレベルまで低減され、すべての機能が実装され、すべての品質目標が満たされたら、製品は完成します。移行フェーズの最後でこの状態を達成するためには、十分な計画と確実な実行が重要です。
目的 | プロジェクトが「外部の世界」と接触を保っていることを確実にすること |
プロジェクト チームは内にこもって作業に集中しがちなため、外部の変化に気付かないことがよくあります。ビジネスでは、主要な要求が変更、追加、削除されることがあります。また、競争会社が市場に同様の製品を導入し、マーケティングのタイミングや、機能、目標にする製品のコストが変わることもあります。
現在の外部環境の状況と照らし合わせて、プロジェクトの計画 (マイルストーンも含む) が今でも有効なことを確認します。また、リスクが変わったために反復計画書を見直す必要がないか、作成しているのが適切な製品であり開発構想がまだ有効であるか、プロジェクト チームが製品を納品するために予定どおりに作業しているかなどについても確認します。また、外部状況の変化により、プロセスの変更が必要であるかどうかを確認してください。
これらの検討結果を使用して、開発構想書、リスク リスト、プロジェクト計画書、反復計画書、開発個別定義書の変更依頼を作成します。
目的 | 評価基準が現実的なものであることを確認すること |
場合によっては、目標が高すぎるために反復が当初の目標を達成できないことがあります。目標を高く持つことは大切ですが、積極性と非現実性が紙一重になることもあります。プロジェクト チームは目標によってやる気を起こし、能力を伸ばすことができますが、目標が常に手の届かない範囲にある場合、士気に影響する場合があります。プロジェクト チームにあまりストレスを与えず、同時にプロジェクトをやりがいのあるものにするような目標を設定するには、チームの共同体制を確立し、限界を知るために、数回の反復を経験しなければならない場合もあります。
評価基準が現実的であるかどうかを検討します。反復の利点は、当初重要視していた要求がそれほど重要でないことが判明することにもあります。最新のテクノロジーに魅了された過度に熱狂的なユーザーによる、複雑でありながら重要度は低い要求によってプロジェクトが暗礁に乗り上げてしまうことも多くあります。反復を 1 回または 2 回行うことによって、これらのユーザーの要求を再設定し、真の価値を持つ機能に焦点を絞らせることができます。
特定の機能を実装するのにコストが非常に高くかかったり、保守が不可能なアーキテクチャが作成されてしまったりすることが明らかになることもあります。その場合は、機能の開発企画書を見直し、開発範囲内に留めるか、要求を低コストで達成できるように変更するかを検討します。
目的 | プロジェクト計画の成果物を更新すること |
評価の結果に基づき、開発構想書、リスク リスト、プロジェクト計画書、反復計画書、開発個別定義書、要求に対する変更の提案を作成します。
Rational Unified Process
|