Blog

スクラムにおけるメトリクスの扱い

 2012/08/04
このエントリーをはてなブックマークに追加

みなさんこんにちは。@ryuzeeです。

最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。

スクラムでよく登場する数値データ

スクラムでよく登場する数値データとしては、プロダクトバックログ項目のビジネス価値や見積もり、スプリントバックログ項目の理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積もりポイント(相対見積もりの場合)の合計がベロシティ、全プロダクトバックログ項目の未完了分の合計見積もり値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。

最新のスクラムガイドでは見積もりを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかについては定義されていませんが、これらのデータはとっておけばチーム状況の可視化や改善の役にたつので、必要に応じて各スプリント毎に更新しておくとよいでしょう。

完成の定義とメトリクス

一方スクラムプロセス自体ではなく、作っている製品に目を向けると、「完成の定義」をステークホルダー、プロダクトオーナー、チーム等の間で合意して、その定義に合致するものを「出荷可能な製品」とよび、各スプリントの成果物ではその基準を満たしている必要があります。 この「完成の定義」をもとに、内部品質に関するメトリクスを考えると分かりやすいと言えます。 一般的には、完成の定義に含まれるのは

  • ユニットテストが書かれている
  • カバレージN%
  • 結合テストが書かれている
  • コードレビュー済
  • セキュリティや性能
  • 自動化できない箇所は手動でテスト済
  • コーディング規約準拠
  • 複雑度がN以上のものがない
  • CPDによる検査で重複コードがないこと
  • 必要なドキュメントが更新されたり作成されている

といったあたりになることが多いと思います。(もちろんプロジェクトによって当然違います) これらのうち自動で取得できるデータについては、常時確認可能にしておくと良いでしょう。 手動でデータを作成するのは継続性に問題があり、毎回作業のムダが発生するので、継続的インテグレーションサーバに組み込んだり、夜間バッチ処理をする等の工夫が必須です。

メトリクスの間違った活用方法

スプリントの中ではチームは自己組織的に仕事をしているべきであり、外部から監視目的でメトリクスを取ることはありません(そういう用途で使ってはダメです)。 あくまでもチームが自分達自身がうまく製品を届けるため、そして改善のためにメトリクスを使うことになります。

例えばスクラムチーム外から監視や人事評価やプロジェクト評価のために、チームのためのデータを使うと、必ず以下のようなことが発生します。

ベロシティの数値そのものの大小が評価される

スプリントプランニングで、見積りが上振れする(インフレを起こす)ことにつながります。

あくまでベロシティは、このプロジェクトがこのペースでいくついつ終わるのか、もしくはスプリント数が限られている場合は上からどのくらいまでのプロダクトバックログ項目ができそうか、という予測のツールでしかない点に注意してください。

スプリントのタスクで残り時間だけでなく、見積もり時間と実時間の乖離が測定され評価される

バッファを積んだ安全な見積もりを行い、早くタスクが完了しても、予実の差を発生させないように、時間が来るまで完了にさせないようになったりします。

そもそも知りたいのはそのスプリントプランニングで選択したプロダクトバックログ項目を完了にできるかどうかであって、かかった時間を追跡しても仕方ありません。 今後同じ作業をする場合に参考になるから、という話を聞くこともよくありますが、スプリントの回数をこなせば見積もりの精度は徐々にあがりますし、ふりかえり等で改善活動も行えます。 かかった時間を測定する時間はムダではないのか?をよく考えてください。 もしかしたら使うかも!の作業は本当にやるべきでしょうか?

スプリントのタスクをこなした数で評価を行う

開発チームのメンバーが自分ができる簡単なタスクだけを取りたがり、他のメンバーを助けないようになります(助けてもインセンティブがないと感じてしまうからです。本当は開発チーム全体の責任にも関わらず…)

バグの発生件数の多寡で評価される

バグを隠します。 連続無障害N日間とかの張り紙があるような現場では、確実にバレない程度の障害は隠蔽されています。

さらに身も蓋もない話をすれば、プロジェクトの評価は、その製品をマーケットに投入することで、どれくらいビジネス価値が生まれたのか、それは投資したコストに見合ったものなのか、で評価されるべきであって、その評価抜きに開発チームを評価しても仕方ないわけです。

それでは。

 2012/08/04
このエントリーをはてなブックマークに追加