次の方法で共有

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

  • [アーティクル]

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

イテレーションの開始時

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

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

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

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

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

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

イテレーション期間中

タスクの実行

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

作業に支障をきたす、すぐには解決できない問題が発生した場合、チーム メンバーはそれらを懸案事項の作業項目に記録します。

テスト

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

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

ロール ビルドと夜間ビルド

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

スタンドアップ ミーティング

チーム全体で、イテレーションのタスクの進捗状況を毎日簡単に確認します。 チーム メンバーは、タスク ボードを使用するか、進行状況ダッシュボードを壁に映すか、または Office Live Meeting を使用して共有します。両方の方法を使用することもできます。

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

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

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

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

スコープの調整

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

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

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

トリアージ

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

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

イテレーションの終了時

検証

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

振り返り

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

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

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

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

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

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

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

統合

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

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

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

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

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

次のイテレーションの準備

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

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