次の方法で共有

イテレーション アクティビティ

  • [アーティクル]

CMMI Process Improvement v6.0 の MSF で、一連の繰り返しとしてプロジェクトが計画されます。各イテレーションは通常は 4 ～ 6 週間で、その期間中に開発チームは指定された一連の要件を実装します。

イテレーションの開始時

イテレーション計画は、各イテレーションの開始時または開始前に行います。これには次のタスクが含まれます。

  • イテレーションに割り当てられた要件を見直し、より詳細に定義する。

  • 各要件を実装およびテストするために実行する必要がある作業のタスク作業項目を作成する。親リンクの種類を使用して、タスクを要件の作業項目にリンクします。

  • 各タスクの "最初の見積もり" フィールドを設定する。数日では終わらないと予測されるタスクは分割します。

  • 見積もりをイテレーションで利用可能な時間と比較する。見積もりの合計が長すぎる場合は、要件の一部を簡略化するか、後のイテレーションに延期します。

詳細については、「イテレーションの計画 (CMMI)」を参照してください。

イテレーション期間中

Ee946845.collapse_all(ja-jp,VS.110).gifタスクの実行

チーム メンバーは、タスクを開始および完了し、それらのイベントを作業項目に記録します。タスクの完了には、プログラム コードおよびその他の成果物のチェックインなどが含まれます。各タスクは数日以内に完了するようにします。数日では完了しないタスクは、イテレーション計画の段階で分割しておきます。詳細については、「作業項目の作成、コピー、および更新」および「Completing Development Tasks」を参照してください。

作業に支障をきたす、すぐには解決できない問題が発生した場合、チーム メンバーはそれらを懸案事項の作業項目に記録します。詳細については、「懸案事項 (CMMI)」を参照してください。

Ee946845.collapse_all(ja-jp,VS.110).gifテスト

手動テストまたは自動テストを開発し、テスト ケースを製品要件にリンクします。成功したテスト ケースおよび機能することを示すテスト ケースに作業項目がリンクされるまでは、製品要件を完了したと見なすことはできません。

テストの開発作業は、製品要件にリンクされたタスクに含めます。

Ee946845.collapse_all(ja-jp,VS.110).gifロール ビルドと夜間ビルド

ビルド システムでは、最近チェックインされた更新から製品をビルドし、自動テストを実行します。主要なテストは継続して実行されるように設定し、スイート全体は毎日夜間に実行されるように設定することができます。これにより、複数のインクリメントでバグが蓄積されるのを防ぐことができます。詳細については、「ビルド システムの構成および管理」を参照してください。

Ee946845.collapse_all(ja-jp,VS.110).gifスタンドアップ ミーティング

チーム全体で、イテレーションのタスクの進捗状況を毎日簡単に確認します。チーム メンバーは、進行状況ダッシュボードを壁に映すか、Office Live Meeting を使用して共有します。その両方を使用する場合もあります。詳細については、「進行状況のダッシュボード (CMMI)」を参照してください。

  • 各チーム メンバーが、最近の進捗状況、その日に取り掛かる作業、および作業を妨げている懸案事項について簡単に報告する。

  • プロジェクト マネージャーまたはチーム リーダーが、懸案事項の解決に関する進捗状況について報告する。詳細については、「懸案事項の管理 (CMMI)」を参照してください。

  • バグの数を確認する。バグは新規の開発よりも優先する必要があります。プロジェクト期間を通じてバグの数が少なくなるようにしてください。バグの数が増えてきたら、その原因と開発作業に対する考えられる影響について話し合います。

  • バーンダウン レートを確認する。

Ee946845.collapse_all(ja-jp,VS.110).gifスコープの調整

バーンダウン グラフを確認することによって、イテレーションの終了までにタスクが完了しないことがわかる場合があります。その場合は、プロジェクト マネージャーまたはチーム リーダーが話し合いを開き、要件をどのように簡略化すればタスクを省略できるかについて検討します。詳細については、「バーンダウンと書き込みレート レポート (CMMI)」を参照してください。

要件とそれに対応するテストを調整します。不足している機能のプロジェクト計画に、新しい要件の機能を配置します。イテレーションの終盤に実施されるプロジェクト計画レビューで、機能を後続のイテレーションに割り当てたり省略したりすることができます。

変更要求とリスクについては、イテレーション期間中には検討しません。

Ee946845.collapse_all(ja-jp,VS.110).gifトリアージ

定期的に (通常はチーム全体ではなく) 一部のチーム メンバーで会議を行い、バグを確認します。各チーム メンバーは、欠陥が見つかったらバグを記録する必要があります。バグは記録された時点では提案済みの状態になります。トリアージ会議の目的は、そのバグを修正するか、後のイテレーションに延期するか、または却下するかを決定することです。

詳細については、「バグの操作」を参照してください。

イテレーションの終了時

Ee946845.collapse_all(ja-jp,VS.110).gif検証

要件は、関連付けられているテストに成功した場合にのみ完了したと見なされます。詳細については、「要件の検証」を参照してください。

Ee946845.collapse_all(ja-jp,VS.110).gif振り返り

プロセスの改善は重要な CMMI ゴールです。

イテレーションの振り返りでは、イテレーションで何がうまくいき何がうまくいかなかったかを踏まえ、チームで使用するプロセスとツールの改善について検討します。振り返りに関しては、さまざまな資料を Web で入手できます。

チーム メンバーに責任を押し付けないでください。個人のミスが影響しにくくなるようにプロセスを改善するようにしてください。

プロセスに変更を加えるときは、チームが次の決定に合意していることを確認してください。

  • 改善されたかどうかをどのようにして判断するか。

  • その評価をいつ行うか。

  • 結果として何を行うか。

Ee946845.collapse_all(ja-jp,VS.110).gif統合

このプロジェクトを超えるプログラムの一部である場合は、各チームは、バージョン管理システムの分岐で作業を実行します。Main 分岐は、チームの作業を統合するために予約されています。チームはイテレーションの終了時に、メイン分岐との統合を実行できます。詳細については、「分岐を使用したリスクの分離」を参照してください。

統合は 2 つの手順で構成されます。

  • 順方向の統合。メイン分岐からプロジェクトのローカル分岐に新しいコードをマージします。マージの実行後に、自動テストと手動テストが実行されます。これによっていくつかの欠陥が検出されますが、これらの欠陥は優先して修正されます。

  • 逆方向の統合。ローカル分岐のコードがメイン分岐にマージされ、メイン分岐でビルドとテスト スイート全体が実行されます。エラーが発生した場合は変更が元に戻されます。メイン分岐でエラーが発生するのは好ましくありません。エラーが発生しなかった場合は、統合の完了が宣言されます。

統合はイテレーションが終了するたびに実行することをお勧めします。統合を先送りすると、順方向の統合の後に修正する必要があるバグが多くなります。バグの修正に時間がかかれば、その間にメイン分岐に新しいマテリアルが追加され、順方向の統合をもう一度実行しなければならなくなります。

Ee946845.collapse_all(ja-jp,VS.110).gif次のイテレーションの準備

イテレーションの終盤または終了時に、プロジェクト管理のアクティビティをいくつか実行します。これには、変更要求および変更された開発の見積もりに関するリスクの確認や計画の見直しなどが含まれます。

詳細については、「プロジェクト アクティビティ」を参照してください。