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

 2012/08/04

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

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

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

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

  • ユニットテストが書かれている
  • カバレージN%
  • 結合テストが書かれている
  • コードレビュー済
  • セキュリティや性能
  • 自動化できない箇所は手動でテスト済
  • コーディング規約準拠
  • 複雑度がN以上のものがない
  • CPDによる検査で重複コードがないこと
  • 必要なドキュメントが更新されたり作成されている
といったあたりになることが多いと思います。(もちろんプロジェクトによって当然違います) これらのうち自動で取得できるデータについては、常時確認可能にしておきます。手動でデータを作成するのは継続性に問題があり、毎回作業のムダが発生するので、継続的インテグレーションサーバに組み込んだり、夜間バッチ処理をする等の工夫が必須です。

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

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

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

→スプリント計画会議で、見積もりが上振れする。あくまでベロシティは、このプロジェクトがこのペースでいくついつ終わるのか、もしくはスプリント数が限られている場合は上からどのくらいまでのストーリーができそうか、という予測のツールでしかない点に注意。

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

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

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

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

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

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

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

 2012/08/04

サイト内検索


著作

寄稿

Latest post: