アジャイルコーチやコンサルタントは、クライアントにアーンド・バリューや作業時間、コード行数、テストによるコードカバレッジがアジャイルプロジェクトにはあまり適さないとよく警告する。しかし、それではアジャイルにあうよいメトリクスとは何だろうか、という質問がクライアントに残る。どのように良いメトリクスと悪いメトリクスを見分けるとよいだろうか。よいメトリクスには悪いコンテキストがあるのだろうか?
XPやScrumのチームにとって伝統的なメトリクスには、もちろんベロシティや直近のイテレーションでどれだけの仕事が完了できたか、がある。そもそもこれらのメトリクスが作られたのは、チームが次のイテレーションでどれだけの仕事をこなすのか、決めるのを助けるためである。しかしながら、よくある質問に、チームの生産性を測るためにベロシティを使えるのではないか?というものがある。二つのチームを比較するためだろうか?Hiren Doshi氏は、ベロシティのメトリクスは「チームに」とても特化したメトリクスであることを指摘した。加えてアジャイルコンサルタントであるPeter Stevens氏は測定をゲームに使う理由があるか、と尋ねた。「このストーリーは2ポイントですか?3ポイントですか?それはチームの判断によります。チームがもし可能な限り多くのストーリーポイントを提供したいと感じているとき、はっきりと3とするか、5とするかもしれません。」
アジャイルとリーンのコーチであるDave Nicolette氏は、貧弱にデザインされたメトリクスは、貧弱な成果物をもたらすと警告する。例えばバグ修正や火消しに報酬を与えると–人々はバグを書き、火をつけはじめる。
適切でアジャイルな計測として、アジャイルコーチのDeborah Hartmann Preuss氏とアジャイルマネジメントコンサルタントのRobin Dymond氏はよいアジャイルな計測の経験則を提示した。
- リーンとアジャイルの原則への理解を促進すること
- 生産量ではなく、成果を測定すること
- 数値ではなく、傾向を追いかけること
- メトリクスと診断は小さな組み合わせから始めることs
- 集めやすいものからやること
- 隠すよりもむしろ大きな影響を与える変数や文脈を明らかにすること
- 意味のある会話を産むための材料として提供すること
- 価値、もしくは製品か、プロセスを測るようにすること
- 「十分によい」品質から自信をつけること
アジャイルなよい計測とはなんだろうか。
Ron Jeffries氏はテストフィーチャーを実行することを提案している。:
- デザインされたソフトウェアは、デザインされたシステムの一部分として提供するため、名付けられたフィーチャー(要求、ストーリー)に分割されます。
- どの名付けられたフィーチャーも一つ以上の自動化された受け入れテストがあり、チームが仕事をする度、フィーチャーに問題がないか実行されるのを示します。
- テストフィーチャーによるメトリクスは、どのプロジェクトでもどれだけのフィーチャーが全ての受け入れテストに合格しているかを示します。
スクラムコーチであるPeter Hundermark氏は、自動テストの実行を一つの計測方法であると示唆した。:
制限の中で、チームがより多くの(言い換えれば 成功する)自動テストを実行することは適切で肯定的な
品質の計測が行えます。一定の水準を越えるまで、そのポイントには到達していないとして
中断できるでしょう。(私たちもそう望んでいます！)
...
ついでに、これはsalesforce.comがアジャイルへ一気に
移行するときの主要なメトリクスでした。
加えて彼は進行中(WIP)を提案した。
進行中のストーリーの数は、生産性のメトリクスです。チームが協調的に作業できているか、
そうではないか追跡することで助けようとします。アジャイルチームにおける考えとして、
チームを全体のためのもので可能な限り協調して一つの作業項目を‘完了’します。これは
生産率や品質と横断的な学習を促します。スプリントの終わりにおける結果的にムダとなる未完了の項目のリスクを減少します。
シンプルに毎日を追跡すること、どれだけ多くの進行中があるかを見える化することは
彼らをより協調的にします。この図は何日もの間、進行中のストーリーを追跡したものです。
スプリントの境界ははっきりわかりません。時間が経つに連れ、１の方に近づくべきです。2以上の値は
どれもスクラムマスターの行動が原因です。
最後にDeborah氏とRobin氏はメトリクスをデザインする時には使うときの事だけを考えるのではなく、いつ止めるのか、またどうやったらゲームにできるのかを思い出させた。
InfoQの過去の記事には、"アジャイルワールドのメトリクスとアジャイルEVM"があります。