プロセスのメトリクスの例

これはなに？

ある現場でのプロセスメトリクスの例

他の現場でもこれをたたき台に使えるとは思う

注意点

何を確認したいんだっけ？は見据えておくように

これそのものを”評価”対象にしないように(透明性が低くなりがち)

プロセスメトリクスの例

ベロシティ

理由：チームがどれほど安定してリリース可能なPBIを届けているかを見る

定義：1スプリントにおけるAcceptされたPBIのストーリーポイントの合計

1回のリリース時間

理由：頻繁にリリースできることはそれだけ素早い方向転換や小さな実験ができるため

定義：1回のリリース作業にかかる時間(開始からユーザーが操作できるようになるまで)

プロダクトバックログのタイプの割合

理由：事業やプロダクトの変化の方向性と開発が合致しているかを見る

定義：プロダクトバックログのタイプを機能追加/機能改善/バグ対応に分ける

補足：プロダクトバックログとDoneしたプロダクトバックログそれぞれの割合で見てもいい

トラブル数

理由：プロダクトの信頼性、機会損失を見る

定義：ユーザーの想定として違う動作の数を計測する(1週間毎など)

テストコードのカバレッジ　(※静的チェックの結果も見るのも推奨)

理由：コードの品質が最低限担保されているか、変更容易性を見る

定義：コードに対しユニットテストを実行した際のカバレッジ率

デプロイメントパイプラインが異常から正常に戻る時間

理由：リリースが常にできる状態かを見る

定義：CIの赤→青に戻る時間

追加コードと削除コードの割合

理由：プロダクトのコードの複雑性を見るため

定義：スプリント毎でGItHubを見る

手戻りの数

理由：プロダクトチームとしてどこにプロセス上のボトルネックがあるかを見るため

定義：進んだものが戻った回数をスプリント毎で計測する

例：ストーリーなら開発Readyでスプリントに入れたのに開始できない/タスクならプログラミング完了したものがQAのテストで戻るなど

稼働時間

理由：チームが健康的であるかを見る

定義：チームの稼働時間をスプリント毎に計測する

toil(労苦)の時間や数

理由：ムダのカイゼン

定義：手動の範囲や「辛い」と思える範囲

スキルマップのアップデート度合い

理由：チームの能力、できることが増えているかを見る

定義：トラックナンバーの変化やできることの変化

参考：LeanとDevOpsの科学

1. コードのデプロイ回数

2. 変更のリードタイム

3. MTTR

4. 変更失敗率