要件に基づいた製品計画
顧客要件を十分に分析して、製品に何が求められているのかを把握できたら、製品を実装するための計画を立てる必要があります。 既存の製品の場合は、足りない機能を特定して、変更のための計画を立てます。 ただし、要件から自動的に計画が決まるわけではありません。
ここでは、一連の要件から計画を作成する方法の概要を説明します。 ここで説明する方法は、Visual Studio で使用できるさまざまな方法の一例にすぎません。また、この方法を使用する際には、個々のニーズに合わせて調整する必要があります。
要件と機能を定義して対応付けるには、バックログおよびポートフォリオ バックログを使用できます。
要件と機能
この方法には、顧客要件と機能という 2 種類の要件があります。 顧客要件は、顧客が製品に何を求めているのかを分析することによって特定される要件です。 機能は、製品計画の項目で、顧客要件の小さなサブセットに相当します。 そのサブセットに、複数のユーザー エクスペリエンス領域や複数の機能領域に対応する部分が含まれる場合もあります。
顧客要件
顧客要件は、対象ユーザーなどの利害関係者との話し合いによって特定されます。
顧客要件を分析する際には、ストーリーボードとモデルを作成して、ツリーを構成する小さなステップへとシナリオを分解するのが一般的です。 ユース ケースやアクティビティなどのモデリング要素をシナリオ作業項目にリンクできます。
顧客要件には次の 2 つの種類があります。
シナリオ (ユース ケース)。特定のゴールを目指して行われるユーザーと製品の一連のやり取りを表します。 たとえば、"ユーザーが本を購入する" というタイトルのシナリオなどが考えられます。
サービス品質要求。パフォーマンス、セキュリティ、使用性などの基準が含まれます。
これらの要件は、種類が要件の作業項目として表すことができます。"必要条件の種類" フィールドを "シナリオ" または "サービス品質" に設定します。 詳細については、「要件の開発」を参照してください。
これらの要件作業項目は、システム テストにリンクされている必要があります。これにより、すべての要件がテストされることが保証されます。 「Team Web Access での手動テストの計画」を参照してください。
これらの要件作業項目の一覧を表示するには、バックログを表示するか、[顧客要求] クエリを開きます。
どの要件が満たされているかを監視するには、必要条件の進行状況レポート (CMMI)レポートを使用します。
機能
機能とは、タスクのグループを表す製品計画の項目です。 製品計画では、開発チームと利害関係者のそれぞれの代表者が機能をイテレーションに割り当てます。 詳細については、「プロジェクト計画 (CMMI)」を参照してください。
機能は、要件作業項目として入力します。"必要条件の種類" フィールドを "機能" に設定します。
機能のタイトルでは、それまでのイテレーションではできなかったどのようなことができるようになるのかをユーザーの言葉で説明します。 新しいユーザー価値を提供しない項目は計画に (ほとんど) 含まれません。
たとえば、次の一連の機能から実装計画を作成できます。
"購入者は、一覧から本を選択して購入予定商品の一覧に追加できる。"
"本の一覧には価格が表示される。 購入予定商品の一覧には合計金額が表示される。"
"販売店は本にタグを添付できる。 購入者は本の一覧をタグでフィルター処理できる。"
これらの機能はいずれも、ユーザー エクスペリエンスの 1 つのステップでのみ使用される機能でも、製品アーキテクチャの 1 つの部分にのみ関係する機能でもありません。 したがって、これらの機能を実装する際には、複数の機能が見直され、それらに新しいユーザー価値が追加されます。
機能は、製品計画でイテレーションに割り当てられます。 1 つの機能のタスクはすべて同じイテレーションに割り当てる必要があります
機能は、顧客要件の部分的な実現を記述します。 顧客要件のサブセットに相当し、各顧客要件を限られた範囲で実装できます。
すべての機能を、その機能によって表される部分の要件をテストする 1 つ以上のテスト ケースにリンクできます。 それらのテスト ケースは、顧客要件にリンクされたシステム テストのサブセットです。
機能のテストが完全に定義されて、すべてのテストに合格するまでは、機能の状態を完了にすることはできません。
すべての機能は、開発タスクとテスト タスクのグループであり、 タスク ツリーのルートです。 開発タスクは、機能によって記述される部分の要件を実装します。 テスト タスクは、適切なテスト ケースを設計および実行します。
機能の一覧を表示するには、[製品要求] クエリを使用します。
機能の特定
要件をインクリメンタルな機能に分類する作業は、開発者、アナリスト、および利害関係者が参加する必要があるクリエイティブな作業です。 機能は、周囲から切り離して実装しても問題がない製品の機能の一部を定義します。 したがって、一連の機能を定義して計画を作成する作業は、システムのアーキテクチャにある程度依存します。
そのため、製品の計画と初期設計は並行して行う必要があります。計画の概要を決定するイテレーション 0 では特にそうする必要があります。
シナリオの分解
要件を機能に割り当てる際には、シナリオを小さなステップに分解すると便利です。
この作業には、多くの場合、ストーリーボードが役に立ちます。 ストーリーボードとは、シナリオを一連の絵で表現したものです。 代替パスを示すには UML アクティビティ図が、複数のアクターの相互作用について話し合うには UML シーケンス図が便利です。 これらのツールを使用してシナリオを分析したら、分解されたシナリオをチーム エクスプローラーに入力します。 これにより、シナリオにテスト ケースをリンクして、要件が満たされているかどうかを確認できるようになります。 詳細については、「UML アクティビティ図: ガイドライン」および「UML シーケンス図: ガイドライン」を参照してください。
機能 - 各イテレーションで満たされる要件
機能とは、各イテレーションの完了時にユーザーが行えるようになることをまとめた要件です。 各イテレーションに対して複数の機能を作成できます。 機能は要件作業項目として入力し、[必要条件の種類] を [機能] に設定します。
機能は、シナリオの作業項目への割り当てを使用して定義できます。 次の機能計画は、前のセクションで行ったシナリオのイテレーションへの割り当てに基づいています。
イテレーション 1
- 顧客がメニューから品目を選択し、それらを注文に追加して、配達先の住所を追加する。
イテレーション 2
顧客は、最初にレストランの一覧を表示してレストランを選択する。
顧客が注文を完了すると、選択したレストランの画面に注文が表示される。
各品目の価格と合計金額が注文に表示される。
イテレーション 3
レストランは、作った料理が配達されると注文を "完了" としてマークする。 料理がレストランに対して記録される。
各レストランはメニューを入力したり更新したりできる。
顧客はレストランを選択する前にすべてのレストランのメニューを閲覧できる。
イテレーション 4
顧客は注文の完了時に支払いの詳細を入力する。 レストランが注文を "完了" としてマークすると顧客のカードに料金が請求される。
"完了" としてマークされた注文の料金がレストランに支払われる。
イテレーション 5
- レストランは配達エリアを設定できる。 顧客はセッションの開始時に郵便番号を入力する。 Web サイトは、そのエリアに配達できるレストランのみを表示する。
部分的に実装されたシナリオ
シナリオを小さなステップに分解すると、早い段階で実装できるステップを、後回しにできるステップから分離できます。
しかし、シナリオのその他の側面を分離できる場合もあります。 たとえば現在の例では、基本的なバージョンのユーザー エクスペリエンスを初期のイテレーションで実装し、後から改良を加えていくことも考えられます。 その場合、たとえば次のような機能を追加できます。
- イテレーション 6 - レストランは、メニューの配色とフォントを選択したり、レストランのロゴと料理の写真をアップロードしたりできる。
この種の機能は、シナリオをステップに分解することによって直接明らかになるのではなく、通常は、ストーリーボードについての話し合いの中で特定されます。 ユーザー エクスペリエンスの機能は後期のイテレーションに割り当てられるのが一般的です。
機能の入力および検査
種類が要件である作業項目を作成し、"必要条件の種類" フィールドを "機能" に設定します。 タイトルには、機能の短い説明を使用します。
機能から要件へのトレース
機能を要件にリンクするには次の方法があります。
機能作業項目を、そのイテレーションのリーフ シナリオ要件にリンクします。 リーフ シナリオには既に親があるため、[関連項目] リンクを使用する必要があります。
テスト ケース作業項目を、対象となるシナリオおよびサービス品質要求にリンクし、 機能を、開発が完了したときに合格する必要があるテスト ケースのサブセットにリンクします。 これにより、テスト ケースが機能と顧客要件の間のリンクとして機能するようになります。
サービス品質機能
サービス品質要求は、一般に、ソフトウェア設計のあらゆる側面に関係します。 たとえば、セキュリティの要件は、通常は特定の開発タスクに関連付けられることはありません。
それでも、各サービス品質要求に対して、サービス品質基準が満たされているかどうかを確認するテスト タスクを主な子とする機能作業項目を作成する必要があります。 これらの作業項目をサービス品質機能と呼びます。
一部のサービス品質機能には開発タスクを含めることもできます。 これにより、たとえば、少数のユーザーのみを処理できるバージョンのシステムを概念実証として初期のイテレーションで実装し、 顧客要件に示されている目標キャパシティを指定する機能を後のイテレーションで追加することができます。
製品計画
各イテレーションを開始する前に、会議を開いて製品計画のレビューを行います。 最初の製品計画会議で計画を作成し、その後の会議で、その計画をそれまでのイテレーションに基づいて見直します。 詳細については、「プロジェクト計画 (CMMI)」を参照してください。
製品計画レビューでは、ビジネス上の利害関係者と機能について話し合います。機能の優先順位を変更したり、機能を別のイテレーションに割り当てたりできるようにしておく必要があります。 この会議には、ビジネス上の利害関係者と、開発チームの代表者が参加します。
会議では、機能の開発順序について話し合います。 これは、[製品要求] クエリの Office Excel ビューを表示して (プロジェクターまたは画面共有を使用します)、機能をイテレーションで並べ替えることによって行うことができます。
そのほかに、機能を特定の順序で並べて、各イテレーションでどこまで開発できるかを検討するという方法もあります。 この方法を使用すると、たとえば、"顧客は価格を表示できる" という機能をイテレーション 2 からイテレーション 3 に移動するかどうかを話し合う際に、その機能をいちいち移動する必要がなくなります。 項目を順序で並べ替えるには、"順位" という名前の列をスプレッドシートに追加して、順序を表す整数を挿入し、 その列でスプレッドシートを並べ替えます。 順位は Team Foundation Server に保存されませんが、そのスプレッドシートを保存することができます。 保存したスプレッドシートを再び開くときには、作業項目テーブルの任意のセルをクリックし、[チーム] タブの [最新の情報に更新] をクリックします。
製品計画では、機能の優先順位と開発コストについて検討します。 優先順位は、ビジネス上の利害関係者が提出します。リスクに関する開発者のアドバイスも考慮されます。 コストの見積もりは開発者が提出します。 開発チームがコストを正確に把握するためには、製品のアーキテクチャの作業がある程度完了している必要があるほか、場合によっては、それまでのイテレーションから得た知識も必要になります。 そのため、コストの見積もりは製品計画レビューのたびに調整する必要があります。
イテレーション計画
製品計画レビューが終わったら、イテレーションの計画を立てます。 製品計画によって、イテレーションの終わりまでに実現される機能が決まります。 イテレーション計画では、それらの機能を実装およびテストするためにチームが行う作業を決定します。
イテレーション計画には、次のアクティビティが含まれます。
開発およびテストのタスクを作成し、それらを子として機能要件にリンクします。
各機能で開発される顧客要件の側面のテスト ケースを作成します。 作成したテスト ケースは、要件がどの程度完了したかを監視できるように顧客要件にリンクする必要があります。
また、テスト ケースを機能にリンクして、機能と要件の対応関係を追跡できるようにすることもできます。 リンクされているテスト ケースに合格するまでは、機能を完了としてマークすることはできません。
詳細については、「イテレーションの計画 (CMMI)」を参照してください。