プロジェクト管理
MSF for CMMI Process Improvement ガイダンスのプロジェクト管理セクションを使用すると、ソフトウェア製品の開発と保守に対する管理、計画、および調整を行う方法をより的確に把握できます。 CMMI の詳細については、「CMMI の背景」を参照してください。
CMMI のプロセス領域のプロジェクト管理グループには、プロジェクト計画、プロジェクトの監視と管理、サプライヤー契約管理、統合プロジェクト管理、リスク管理、および定量的プロジェクト管理が含まれます。 定量的プロジェクト管理以外はすべてモデル レベル 2 または 3 の一部です。 定量的プロジェクト管理はモデル レベル 4 のアクティビティで、成熟度の高い組織が定量的で統計的に守勢の客観データを使用して、管理に関する意思決定を行ったりプロジェクトを正常で予測可能な結果に導いたりする方法が反映されます。
プロジェクト管理アクティビティは、付加価値エンジニアリング アクティビティの経済的コストを表します。 このようなアクティビティは、リスクの管理、正常なエンジニアリング工数の調整、および顧客の要求の適切な設定に必要かつ重要です。 ただし、このようなアクティビティに費やす工数は最小限に抑える必要があります。 " 少しずつ頻繁に" という方針をお勧めします。 バッチを小さくすると、複雑さと調整コストが軽減されます。 プロセス定義を定義および調整する際には、プロジェクト管理アクティビティを最小限に抑えながらプロジェクトのリスク プロファイルを満たさなければならないということを念頭に置く必要があります。
反復開発
Team Foundation と MSF for CMMI プロセス テンプレートを組み合わせると、反復作業がサポートされます。 反復開発では、プロジェクト全体にわたって設定された間隔でデモンストレーションできるテスト済みのソフトウェアを納品することでリスクを管理します。
.png "連続したイテレーション")
プロジェクト スケジュールは、通常、4 ～ 6 週間の一連のイテレーションに編成されます。 各イテレーションの最後に、使用できるテスト済みのソフトウェアのデモンストレーションを行います。 詳細については、「区分およびイテレーションの作成および修正」を参照してください。
プロジェクト計画は、各イテレーションで開発される機能の要件を示します。 プロジェクト計画はイテレーション 0 で策定され、各イテレーションの開始時に確認されます。 プロジェクト計画は、プロジェクト ダッシュボードなどのいくつかの方法で表示できます。 詳細については、「要件 (CMMI)」および「プロジェクト ダッシュボード (CMMI)」を参照してください。
各イテレーション計画は、そのイテレーション中に実行されるタスクを示します。 ほとんどのタスクは、そのイテレーション用にスケジュールされている機能の要件を満たすために必要な開発作業とテスト作業です。 イテレーション計画は、進行状況ダッシュボードから表示できます。 詳細については、「タスク (CMMI)」および「進行状況のダッシュボード (CMMI)」を参照してください。
反復作業では、リスク管理は自動的に行われません。 リスクを最小限に抑えるには、プロジェクト計画をインクリメント方式で調整する必要があります。 初期のイテレーションでは、"全体的な薄切り"、つまり製品の最も重要な動作の最小バージョンを提供する必要があります。 後期のイテレーションでは、機能を追加します。
一方、プロジェクトの最初の 3 分の 1 でショッピング Web サイトの販売部分をすべてスケジュールし、次の 3 分の 1 でウェアハウス システムをすべてスケジュールし、最後の 3 分の 1 で支払いシステムをスケジュールすることはそれほど役立ちません。 このスケジュールには、企業が顧客から支払いを受け取る手段のない魅力的で多機能な販売 Web サイトを生成してしまうリスクがあります。 ここでは、インクリメント方式を使用せずに反復作業を行っています。
インクリメンタル開発には、次のような利点があります。
実際の要件を満たすことができます。 関係者が製品を試用できるので、提示された要件を常に改善できます。
アーキテクチャを調整できます。 開発チームは、プラットフォームで発生する問題または設計の改善の可能性を見つけて対処することができます。
結果を確保できます。 関係者は、プロジェクト リソースがある程度進んだ段階で削減された場合でも、これまでのコストが無駄になっていないことを把握できます。 これは、開発の見積もりが楽観的であったことが判明し、重要度の低い機能を削除しなければならなくなった場合にも当てはまります。
インクリメンタル開発の適切なフォームで要件を指定する方法の詳細については、「開発要件」を参照してください。
大規模なサイクルと小規模なサイクル
ソフトウェア開発の循環的な側面となるのは、プロジェクトとイテレーションだけではありません。 たとえば、イテレーションでは、チーム メンバーがタスクを開始および完了し、コードをチェックインします。 ビルド システムでは、製品が継続的にまたは毎日夜間にビルドされます。 チームは、イテレーション タスクの進捗状況を毎日簡単に確認します。
.png "チェックイン、デイリー ビルド、イテレーション、プロジェクト、プログラム")
大規模なプロジェクト
チームが一連のイテレーション作業を順次行うプロジェクトは、大規模なプロジェクトまたはプログラムの一部である場合があります。 大規模なプロジェクトには、並行して作業するいくつかのチームが存在します。 各チームには、通常、4 ～ 16 人が所属します。
チームごとに個別のバージョン コントロールの分岐を開きます。 各チームは、イテレーションが終了するたびにメイン分岐と統合する必要があります。 詳細については、「分岐とマージ」を参照してください。
メイン分岐は、統合およびテストのために予約します。 ビルド コンピューターで、統合の後に完全なテスト セットを実行します。
各チームに領域を割り当てて、その作業項目とその他の作業項目を簡単に分けることができるようにします。 詳細については、「区分およびイテレーションの作成および修正」を参照してください。
チーム間で一連の統合を共有できますが、必ずしも共有する必要はありません。 チーム間で統合を同期しない場合は、各チームがイテレーション名にそれぞれ独自のプレフィックスを付ける必要があります。
このセクションの内容
プロジェクト サイクル: プロジェクトの開始、要件の収集、プロジェクト計画の作成、そのイテレーションへの分割、およびリリースの納品を行います。 リスクを管理し、計画の変更を管理します。 |
|
イテレーション サイクル: 要件の確認および更新、要件を実装するためのタスクの計画、および問題の発生時の管理を行います。 |