プロジェクト計画 (CMMI)
プロジェクトの計画の目標は、スコープ、スケジュール、割り当て、リスク管理計画、およびすべての利害関係者からのコミットメントと承認を含む計画を作成することです。 プロジェクト計画の合意が得られたら、その計画を使用して、分析、設計、開発、テスト、そして最終的な納品に至るプロセスを進めることができます。
リスクを軽減するために反復開発の手法を使用します。 反復開発を使用すると、イテレーションが終了するたびに製品の一部の動作をデモンストレーションできるため、そのデモンストレーションからのフィードバックを作業に反映させることができます。 したがって、各イテレーションの開始前には、計画で全体の概要を確認すると共に、計画のレビューおよび調整を行います。
要件の収集とモデリング
このアクティビティでは、ビジネス上の利害関係者、対象ユーザー、および内容の担当者との話し合いを通じて、システムに何が求められているのかを突き止めます。 そこで重要となるのが、ビジネス上のコンテキストの理解です。 たとえば、警察官のためのアプリケーションの開発を依頼された場合は、警察官の専門用語、手順、規則などを理解していると役に立ちます。
複雑な関係を表現したり分析したりするには UML モデルが便利です。 Visual Studio で UML モデルを作成して、他のドキュメントや Team Foundation の作業項目にリンクすることができます。 詳細については、「ユーザー要件のモデリング」を参照してください。
要求モデルは、プロジェクト期間を通じて更新および調整していく必要があります。 イテレーションが近づくたびに、そのイテレーションに関連する詳細をモデルの各側面に追加します。 モデルから検証テストを作成することもできます。
詳細については、「要件の開発」および「モデルからテストを開発する」を参照してください。
インクリメンタルな製品要件の作成
顧客から収集した要件をそのままインクリメンタル開発のスケジューリングに使用することはできません。 たとえば、ユーザーが Web サイトで商品を購入するときの手順を明らかにするために一連の詳細なステップを記述した場合 (顧客がカタログを閲覧する、カートに商品を追加する、カートをチェックアウトする、住所を入力する、支払いを行う、倉庫で配送がスケジュールされるなど)、 それらのステップや、それに対応するアクティビティ図は、インクリメンタルな要件ではありません。
インクリメンタル開発では、たとえば、システムの最初のインクリメントでは商品と配送先を 1 つに限定して支払いサービスでテスト トランザクションのみを実行し、 次のインクリメントでは単純な一覧から成るカタログを提供し、 その後のインクリメントでギフト包装のオプションや他のベンダーのカタログを要求するオプションを追加したり、 サービスの品質に対処して 1 人だけでなく 1,000 人の顧客を処理できるようにしたりすることができます。
要するに、初期のインクリメントでは主要なユース ケースをエンド ツー エンドで実行し、その後、全体を通じて徐々に機能を追加していきます。
既存の製品が対象となる場合もこの原則は変わりませんが、その場合は既存の機能から開始することになります。 その製品の内部設計がよくわかっていない場合は、更新のコストの見積もりが困難になります。 初期の変更に備えてコストは多めに見積もるようにしてください。
詳細については、「要件の開発」を参照してください。
製品要件の入力と編集
Team Foundation で、インクリメンタルな製品要件を要件作業項目として記録し、[必要条件の種類] を [機能] に設定します。 要件のバックログは、TWA または チーム エクスプローラー を使用して作成できます。 複数の作業項目を同時に作成する必要がある場合は、Excel を使用します。
製品要件の見積もり
開発チームは、各製品要件の開発に必要な作業を見積もる必要があります。 見積もりは、作業項目の "最初の見積もり" フィールドに時間単位で入力します。
プロジェクトの初期の段階では大まかな見積もりで十分です。
大きな製品要件は分割します。 各製品要件の開発時間が数日程度に収まるのが理想的です。
製品要件のイテレーションへの割り当て
ビジネス上の利害関係者と開発チームのそれぞれの代表者が協力して、製品要件をイテレーションに割り当てます。 これは、[製品要求] クエリの Office Excel ビューを見ながら会議で行うのが一般的です。
割り当てには次の情報が使用されます。
要件の優先順位。 次のサブセクションを参照してください。
コストの見積もり。 チーム メンバーの数とイテレーションの長さは決まっているため、各イテレーションで開発に使用できる時間は限られています。 さらに、その時間の多くは、イテレーションの計画など、開発に直接関係しない作業に使用されます。
製品要件の間の依存関係。 インクリメンタルな要件では、まず単純な要件を片付けてから、同じ領域を強化する作業に取りかかります。
次の図に示されているように、さまざまな情報を指定して作業項目の要件を定義することができます。
.png "要件の作業項目フォーム")
優先順位付けのガイドライン
優先順位付けには詳細な方法が数多く存在します。 イテレーション計画を作成する際には、それらのいくつかを検討することになります。 ここでは、リスクの管理や追加された価値の最適化に役立つプロジェクト レベルでのガイドラインをいくつか紹介します。
最小限のエンド ツー エンドのシナリオを優先します。
プロジェクトのできるだけ早い段階で単純なエンド ツー エンドのシナリオを実現することを目指します。 その後、そのシナリオのさまざまな部分に機能を追加していきます。 これにより、プラットフォームの主要な機能と要件の主要な要素を早い段階で試すことができます。
反対に、スケジュールをアーキテクチャに従って配分することは避けてください。 最初にデータベース、次にビジネス ロジック、その後にユーザー インターフェイスというように順番に完成させていくスケジュールでは、多くの場合、最後に各部分を統合する際に大量の修正が必要になります。 同様に、{販売コンポーネント; 倉庫コンポーネント; 支払いコンポーネント} などの水平方向の分割も推奨されません。 Web 販売のためのすばらしいシステムができても、支払いコンポーネントの開発が間に合わなくなって顧客から料金を回収できないのでは意味がありません。 完全なコンポーネントの開発を後回しにできるのは、本当に省略可能な追加機能である場合だけです。
技術的なリスクを優先します。
技術的なリスクの高い要素がシナリオに含まれている場合は、早い段階で開発するようにします。 つまり、リスクに対して "早めに失敗する" アプローチをとります。 実現できない機能がある場合、プロジェクトの早い段階でそれがわかれば、その機能の開発を中止したり、別の機能に置き換えたりすることができます。 したがって、技術的なリスクの高い要件は初期のイテレーションに回します。
不確実性の低減を優先します。
ビジネス上の利害関係者は、すべての要件に確信を持っているわけではありません。 ビジネス上のコンテキストで最も有効となる製品の動作を予測するのは困難だからです。 したがって、こうした不確実性を低減するような作業を優先します。 具体的には、ユーザーが試験に使用できる単純なバージョンのシナリオを開発し、 完全なシナリオの開発は後回しにして、試験の結果を反映できるようにします。
価値の高い要件を優先します。
可能であれば、遅延のオポチュニティ コストの関数を各シナリオについて定義し、 それらを使用して、顧客により多くの価値をより早くもたらす可能性が高い要件を特定します。 それらの要件を初期のイテレーションに回します。 これにより、製品の一部を早期にリリースできる場合もあります。
複数のペルソナに共通のシナリオをグループ化します。
複数のペルソナにとって有用なシナリオがある場合は、それらをグループ化して、 そのシナリオを必要とするペルソナの数が多い順に並べます。 多数のペルソナに当てはまるシナリオを初期のイテレーションに回します。
ペルソナに順位を付けます。
ペルソナは、市場セグメントやユーザー グループを表します。 マーケティング担当者や経営者は、製品の効用やセグメントの価値に基づいてそれらのセグメントやグループの優先順位を決定できます。 セグメントやユーザー グループに優先順位を付けられる場合は、それに基づいて各セグメントのペルソナに順位を付けます。 最も順位が高いペルソナのシナリオを特定して、それらをスケジュールの初期のイテレーションに回します。
通常は、失敗の可能性を考えてリスクの低減を優先します。 共通の機能は必要とされる可能性が高く、変更される可能性が低いため、それらも優先します。 さらに、より価値の高い要件を優先します。 また、特定のペルソナのニーズを満たすために必要なすべてのシナリオを優先すると、一部のペルソナに対して製品を早期にリリースできるようになります。
テストの計画
各要件の作業見積もりには、その要件のテストに必要な工数 (手動テストの実施と自動テストの作成の両方) を含める必要があります。
各製品要件は、その要件が満たされているかどうかを示す一連のテスト ケース作業項目にリンクされて、それらのテストに合格するまで完了と見なされません。
製品要件を作成したり改訂したりした場合は、対応するテスト計画を更新する必要があります。
製品要件の改訂
各イテレーションの前に毎回このアクティビティを実施して、改訂された要件、新しい要件、改訂された優先順位、および改訂された見積もりについて検討します。 最初の数回のイテレーションでは比較的多くの改訂が発生します。
最初の数回のイテレーションを過ぎると、見積もりに確信を持てるようになります。 そこで、次の 1 ～ 2 回のイテレーションの見積もりを見直して、それらのイテレーションに割り当てられた要件の "最初の見積もり" フィールドを改訂します。