AgileとCMMIの融合:SEPG Conferenceより

masayang2010-04-01

CMMIAgileの思想とプラクティスを取り込む動きは2006年あたりから始まっていたが、今回開催されたSEPG Conferenceにおいて以下のような議論が進行した。

  • 従来のウォーターフォール思想を基盤としたCMMIは今後メンテされない。つまり進化しない。(お猿さん向けに残るには残る。)
  • AgileCMMIに正式に取り込まれる。
  • ただし、CMMIが重視する「成熟度」「再現性」などはAgileであっても尊重されなければならない。
  • 成熟度や再現性が問われる以上、プロジェクトは一定以上の「見通し」が確保されるべきである。
  • すなわち、イタレーションやスプリントという言葉に代表される「やってみて、できるところまで作業する」という姿勢は正されるべきである。
  • このような考えのもと、Agile+CMMIはRUP(Rational Unified Process)を踏襲した工程名を採用することになった。Agileでいうイタレーションは9回までと規定される。(RUPの4 Phaseよりは細かくなった)
工程名 概要 成果物
Pre-Inception Process 開発対象の要件を漏れが無いように分析し、大雑把な工数と予算を把握する。これをもとに大計画を立てる。 要件定義書、概要計画書、仮契約書
Inception Process 要件定義をもとに、開発対象の仕様を漏れが無いように分析。詳細な工数と予算を把握する。これをもとに、詳細な計画を立てる。 概要設計書、詳細計画書、契約書
Pre-Elaboration Process 概要設計を元に、必要な画面や帳票およびファイルレイアウトなどをもれなく記述する。 外部設計書
Elaboration Process 外部設計書を元に、Construction Processで仕事をする人が頑張れるようなフローチャートとかほとんどコーディングと変わらない程度の粒度で内部仕様を書く 詳細設計書
Construction Process 詳細設計書をコードやデータベースに落とす コード、DD文
Post-Construction Process 詳細設計書を元に単体テスト項目を洗い出し、一通り試す 単体テスト計画書、単体テスト項目書、テスト結果
Pre-Struggling Process ビルドをし、全体を結合させる。結合できない場合はできるまで頑張る。その後、外部設計書を元に結合テスト計画を策定し、一通り試す。通らなかったら頑張って通るようにコードを直す。 結合テスト計画書、結合テスト項目書、テスト結果
Struggling Process 概要設計を元に総合テスト計画をたて、テスト項目をとにかく洗い出す。で、一通り試す。通らない項目は通るようになるまでコード修正、単体テスト結合テスト、ビルドを繰り返す。 総合テスト計画書、総合テスト項目書、テスト結果
Exodus Process 要件定義を元に受け入れテスト計画を立て、受け入れテスト項目をとにかく洗い出す。受け入れ担当はユーザになるので、ユーザがわかるようなテスト手順書も作る。テストを確認したら、それが検収受け入れになるような書式にしておくと手戻りが減る。ここまで持ち込めば、客は受け入れざるを得ない。 受け入れテスト計画書、受け入れテスト手順書兼確認書兼検収受け入れ書