AgileMetrics入門がとても分かりやすい

太田健一郎さんの資料「Agile Metrics入門」がとても素晴らしいのでメモ。
以下は、資料を読んで自分の理解をラフなメモ書き。

Agile Metrics入門 from 健一郎 太田

【1】「アジャイル開発におけるメトリクス取得の目的」として、「チームとプロダクトの健康状態を確認する」点が挙げられているのは同意。

【2】「メトリクスのやってはいけない」点の列挙も同意。いわゆる、メトリクスの罠。
特に、マネージャはEVMや信頼度成長曲線が大好きなのだが、それだけではプロジェクトの詳細は分からない。
あくまでも、健康診断や人間ドックの診察結果にすぎない。

【3】アジャイルメトリクスの入力元として、チケット管理、バージョン管理、CIツール、デプロイツール、本番監視管理ツールが挙げられている。
これだけのデータがあれば、システムの品質や開発チームの開発速度のメトリクスも精度が高くなるだろう。

【4】興味を惹くのは、アジャイルメトリクスとして、どんなメトリクスを採用しているか、という点だ。
基本は、Velocityとストーリーバーンダウンを選択しているようだ。
他に、CIでのテスト通過率、テスト増加率、ストーリーポイントの実時間比などが挙げられていた。

個人的には、Velocityとサイクルタイム(ステータス間の更新時間間隔)、またはリードタイム(要望受付からリリースまでの期間)が基本的なメトリクスと考えていた。
上記に絞られた意図がもっと知りたい所。
たぶん、データの収集のしやすさ、メトリクスの有意性から、そのような決定がなされたのだろうと推測する。

【5】アジャイルメトリクスの評価の観点も面白い。

たとえば、ポイント単位のバーンダウン/日、テスト通過件数/日から、悪い傾向は、テスト不合格が増加するケース。
Velocity/日とメンバーの実作業時間/日から、悪い傾向は、Velocityは一定又は低下して、メンバーの作業時間が増えているケース。
スプリントのVelocity、実作業時間/ストーリーポイントから、悪い傾向は、Velocityは一定又は低下して、メンバーの1ストーリーポイントの実作業時間が増えているケース。

悪いケースのいずれの場合でも、そういう結果が出てきたら、開発者がどんな心境で、どんな作業をしているのか、経験者なら想像がつくに違いない。
そういう傾向をメトリクスでいち早く検知できるのも面白い。

【6】気になるのは、「OSS 主要ツールからメトリクスを収集して可視化 」というページで、measurementorというツールが紹介されていた点。
「現在、書籍"Agile Metrics in Action"の発売に備えて開発中」と書かれているが、アジャイルメトリクスの収集・集計ツールなのだろうか。

GitHub - cwhd/measurementor at development: The code from Agile Metrics In Action; A system to collect data & display metrics for application lifecycle intelligence.

下記の本なのだろうか？

Agile Metrics in Action: Measuring and Enhancing the Performance of Agile Teams: Christopher W. H. Davis: 9781617292484: Amazon.com: Books

情報がないか探してみる。