7つのアジャイルメトリクス

感想おまちしてます!

Stopwatch

アジャイルコーチとか名乗っていると、開発生産性の定量的なデータを聞かれることがしばしば。今日は日頃計測しているデータの紹介です。元ネタはSWプロジェクトにおけるツールの活用を考える会 第五回勉強会のボーナスステージとして発表させていただいた内容です。

開発の安定度を確認するベロシティ

Screen Shot 2013-04-28 at 2.19.48 PM

アジャイル開発で有名なベロシティです。ベロシティ=速度と訳せるのですが、開発チームの速度メーターとして計測しています。

上の図の数値は、イテレーション(私の場合、1週間)での実績日の合計です。作業にどれだけ時間を使ったかで計測しているので、ストーリーポイントではなく実績日を使っています。

Redmineでアジャイルチームのスピードやパワーを見える化する」でも書かせて頂きましたが、どこまでベロシティを高めるかではなく、安定しているかどうかを意識しています。作業ごとのばらつきもあるでしょうが、上の図をみると、じわじわ上がってきているのが成果かなと。

下がったら原因を探して、上がったら無理してないか心配する・・・の繰り返しです。上下に大きく振れたときが大抵怪しいので、そういう場合は、なぜそうなったかを考えています。

タスクの状態を考える状態別タスク数

Screen Shot 2013-04-28 at 2.27.25 PM

単純にTODO、Doing、Doneにあるチケットや付箋の数を数えたものです。

TODOが減るとそろそろ計画の時期になり、Doingが増えると無駄な作業が溜まっていたり、マルチタスクで困っている人がいないかを確認。Doneが減ったら、同じくDoingの状態を確認して「終わらせる」ために作戦を考えます。

Screen Shot 2013-04-28 at 2.31.47 PM

これらの数を積み上げると、上の図のようなバーンアップチャートになります。個人的には、バーンダウンよりも、バーンアップのほうがテンションも上がるので好きです。

TODOの積み上げが途中で増えているのは、計画が遅すぎて見積り待ちになった経験を得て、改善した結果となります。Doingの角度とDoneの角度をよく意識しています。

終わりを意識するためのDONE率

Screen Shot 2013-04-28 at 2.35.14 PM

予想していた作業がどれぐらいの割合で実現できたのかを、終わった作業(ストーリー)の数で数えています。経験上、80%ぐらいのDONE率になることが多いので、約80%で安定させるために計画を調整します。

Screen Shot 2013-04-28 at 2.37.58 PM

DONEの数を積み上げるとこんなグラフになりました。面白いのは、過去2回3か月ぐらいの規模の開発を行った時は、リリース直前にぐーんとDONEが増えて、リリース後に落ち込みます。

経験上、最後にがんばる作戦は疲れるし、終わったあとにホッとして開発スピードが落ち込むことがわかったので、2週間に1回ぐらいのリリースでイテレーティブに開発をするようになっていきました。

その結果、最近では安定してDONEが増え、無理せずに成果を出せるようになってきました。

リリースのコスト確認としてリリース時間

Screen Shot 2013-04-28 at 2.43.15 PM

トラブルが多い現場だったので、改善のための現状把握として計測し始めたのが、リリース時間です。

リリースにかける時間を少なく・・・はもちろんなのですが、どちらかというと、サービスの新機能や改善のリリースと、トラブル対応や技術的負債対応のリリースの割合を気にしています。

ユーザに価値を届けなければサービスは成り立ちません。でも、一方で、システムリファクタリングを続けないと、開発やリリースが複雑になってサービスに影響が出ます。これは本当にバランスをとるのが難しいのですが、向きあわなければならない問題です。

機能ができるまでのサイクルタイム

Screen Shot 2013-04-28 at 2.43.27 PM

リードタイムとも呼ばれる数値です。機能を作り始めて(今週の作業に貼った時)から、リリースできる状態(システムテストが終わる)までの時間を計測しています。

今の開発プロセスでは、大きく分けて開発、単体テスト、システムテストを行なっています。一体どれぐらいの時間でリリース可能な状態に持っていけるのか?これを知りたくて最近始めた計測です。

調べて間もないですが、面白い傾向が出ています。

上の図で言うと、左側はシステムテストを最後にまとめてやったときのサイクルタイムです。右側は逆にそれぞれの機能ごとにシステムテストを小さく行った結果になります。

まとめてやる場合と、ちょっとずつやる場合で、どちらが楽なのかを知るために、実験的にやりかたを変えて調べているところです。

まとめ

計測は継続的に行なっていますが、「開発を支援するツールを使うと思いやりが減る」でも書かせていただいたように、取ってみては止めて・・・を繰り返しています。

計測する側として気にしておきたいのは、計測をがんばりすぎないこと。計測のためにエンジニアに負担を強いていいことありませんでした。

よく「ツールを使えば自動で・・・」って言われますが、週1回15分ほどの作業なので、私自身が使っている「かんばん」やツールを確認しながら、Excelに入力してグラフ化しています。