第83号：CMMI V1.3とアジャイル

CMMI V1.3の特徴の１つに、アジャイル手法を採用する場合のガイドが追加されたというのがあります。どんな内容なのか気になっている方もいらっしゃるかと思いますので、簡単に概要をご紹介します。

モデルのパートIの部分の"Interpreting CMMI When Using Agile Approaches"に全体的な説明があります。以下のようなことが解説されています。
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
・CMMIはいろいろな組織で使用できるように一般的な言葉で述べられており、アジャイルを含む特定のアプローチに言及していないが、アジャイルを使う人々が自分達の環境でCMMIのプラクティスを解釈することを手助けするための"注釈"が追加された。

・すべての注釈は、"In Agile environments,"の書き出しで始まり、見つけやすいように枠で囲んである。

・注釈は、以下の各プロセス領域の導入部にある。
プロジェクト管理：プロジェクト計画策定(PP)、リスク管理(RSKM)、
　　　　　　　　　プロジェクトの監視と制御(PMC)、要件管理(REQM)
エンジニアリング：要件開発(RD)、技術解(TS)、成果物統合(PI)、検証(VER)
支援　　　　　　：構成管理(CM)、プロセスと成果物の品質保証(PPQA)
プロセス管理　　：なし
　
・これらの注釈は、アジャイルを採用した際にプラクティスをどのように解釈するかの例であって、プロセス領域を満たすのに必要十分ではないことに注意すること。

・V1.3でアジャイルに関する解説が追加された背景となったSEIのレポート：
　CMMI or Agile: Why Not Embrace Both!
　http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥

それではプロセス領域ごとに見ていきましょう。
※全部見ていくと長くなるので、個人的に気になったプロセス領域のみピックアップします。

‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
●プロジェクト計画策定(PP)
・アジャイル環境では、インクリメンタルに開発を行い、伝統的な開発方法よりも頻繁に計画、監視、制御、および再計画を行います。
・見積は、イテレーションを遂行するための期間や工数やリソース、リスクなどを反映して行います。
・チームは、各イテレーション(反復型プロセスにおける1回の開発サイクル)の間に計画、監視、計画の調整を頻繁に(例えば日次で）行います。
・計画へのコミットメントは、タスクが割り当てられているときに明らかにされ、イテレーション計画の間に受け入れられます。
・ユーザーストーリー(備えるべき機能をユーザが理解できる言葉で記述したもの)は精緻化し、見積もられます。
・イテレーションは作業のバックログ(管理対象となる要求やタスクの固まり)からのタスクで設定されます。

●プロジェクトの監視と制御(PMC)
・アジャイル環境では、プロジェクトの活動において、顧客と潜在的なエンドユーザーの持続的な関与が、プロジェクト成功に不可欠です。したがって、顧客やエンドユーザーの関与を監視する必要があります。

●要件管理(REQM)
・要件は、製品バックログ、ストーリーカード、画面のモックアップなどのメカニズムを通して追跡されます。
・要件のコミットメントは、チームまたは権限を与えられたリーダーによって集約的に作られます。
・作業の割り当ては、要件や解が明らかになる時に、日次や週次の進捗状況などに基づいて定期的に調整します。
・要件と作業成果物の追跡可能性と一貫性は、イテレーションの開始と終了時におけるレトロスペクティブ(振り返り)やデモといった活動だけではなく、上記のメカニズムを通して取り上げられます。

●要件開発(RD)
・アジャイル環境では、顧客のニーズやアイデアの引き出し、精緻化、分析および妥当性が繰り返し行われます。
・要件は、ユーザーストーリー、シナリオ、ユースケース、製品バックログ、イテレーションの結果(ソフトウェアの場合は作業コード)などのフォームに文書化されます。
・どの要件がそのイテレーションで取り上げられるかは、製品バックログに残っているものの優先順位とリスク評価結果によって決まります。
・要件をどの程度詳細に文書化するかは、チーム、後続のイテレーションとの調整のニーズや、文書化しないことによるリスクによって決まります。
・導出要件についての責任は、適切なチームに割り当てられます。

●構成管理(CM)
・アジャイル環境では、構成管理は重要です。頻繁に発生する変更やビルド、複数存在するベースライン、複数の作業空間（個人やチーム単位での作業、ペアプログラミングでの作業等）を支援するために必要だからです。
・チームは、以下のような仕組みにより動きやすくなるかもしれません。
　1) ビルド用スクリプトや整合性チェックなどで構成管理を自動化
　2) 構成管理を標準作業の１つのセットとして実装
・開始時に、構成管理担当者を識別する必要があります。
・各イテレーションの開始時に、構成管理の支援ニーズが再確認されます。
・構成管理は、作業の邪魔にならないように、チームのリズムの中に慎重に組み込まれます。

●プロセスと成果物の品質保証(PPQA)
・チームはイテレーションの当面のニーズではなく、より長期的で広範な組織のニーズに集中する傾向があります。
・価値があり、効率的であると認識されるPPQAを行うには、早期に次のようなことを議論すること：
　（1）客観的な評価をどのように行うか、
　（2）どのプロセスと作業成果物が評価されるか、
　（3）どのように評価の結果がチームのリズムの中に組み込まれるか
　（例：日々のミーティング、チェックリスト、ピアレビュー、ツール、継続的な統合、レトロスペクティブなどの一部として）
‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥

いかがでしたか？
正直、これだけ読んでもCMMIベースでプロセス改善を進めている中にアジャイルを導入するのは難しい、というのが大方の感想ではないでしょうか。

パートIの全体説明のところでもあったように、これらは解釈の例示であってすべてではないので、プラクティスをアジャイルでどのように実装していくかは、もう少し具体化が必要そうです。

個人的にも興味のある分野ですので、新たな情報が分かりましたらまたメルマガ等でお伝えしたいと思います。