1

Agile Metrics 入門

株式会社 SHIFT太田健一郎

2

• アジャイル開発の QCD+S• アジャイル開発におけるメトリクス取得の目的• メトリクスのやってはいけない• メトリクスの入力元• アジャイルメトリクス• メトリクス組合せ例• 他社案件事例• メトリクスツール• 参考情報

アジェンダ

3

アジャイル開発の QCD+S

4

• Quality– 品質→価値

• Cost– ポイント毎の実時間 x 総ストーリーポイント

• Delivery– Agile では通常固定

• Scope– スプリント毎に提供するストーリーの総量– Agile では開発するストーリーは交渉できる要素

QCD + S

5

アジャイル開発におけるメトリクス取得の目的

6

• Measure– チームとプロダクトの健康状態を確認する

• React– 健康でなかった場合のアクションを発見する– アクションを実施する

• Repeat– Measure, React を繰り返して、パフォーマンスを

上げていく

Measure, React, Repeat

メトリクス取得！＝管理

7

メトリクスのやってはいけない

8

• 結果– そのメトリクス以外の要素を犠牲にしてもそのメト

リクスを向上させようとする• 例– 納期 (D)

• 品質 (Q) 、コスト (C) が犠牲になる

– ベロシティー (Q)• 実稼働時間が上昇する• メンバーの健康が阻害される• 従来の意味の品質が低下する

一つのメトリクスだけを用いる

9

• 結果– 収集されたメトリクスが React に活かされない– 収集されたメトリクスを誰も意識しない

• 例– LOC (C)

• LOC だけでは生産性を意味しない

– コードインスペクションの違反の数 (Q)• 重み付け、修正条件、修正する目的などを定義しないと違

反の数だけでは修正する理由付けにはならない

– ユーザー別コミットの回数 (C?)• 評価に使おうとしている？？

目的の不明確なメトリクスを取得する

10

• 結果– 本質的でないメトリクス収集の工数が取られる– メトリクス収集職人が必要になる

• 例– ユニットテストの障害数、障害率 (Q)

• 取得することは可能だが、取る工数の割に得られるものが少ない

• TDD 的な開発だと伝統的な開発からの統計とは異なった値が出がち

– テストコードの実装工数 (C, D)• 共通部品 (PageObject やユーティリティークラス ) が充実

するまでは変動が大きい• コミット時間等で自動的に取得するのは難しい

取得に複雑な手作業が必要なメトリクスを取得する

11

• 結果– 正しい情報を入力しなくなる– 情報を捏造するようになる

• 例– LOC をメンバーの生産性と評価に使う (C, D)

• コメントやブロックを水増したり、コピペしたりするようになる

– 作り込んだ障害数を評価に使う (Q->C)• 障害でないと否定したり、開き直ったりする

– 起票した障害数を評価に使う (Q->C)• 障害票の内容がおざなりになる• 改善案であり障害か怪しいものを障害として起票する

メトリクスを人の評価に使う

12

• 結果– 現場が疲弊している状態を見逃す– 内部品質が悪い状態を見逃す

• 例– EVM (Q, C, D)

• EVM だけ見ていてもスケジュールやコストの差異が分かるだけで、現場の疲弊感や実際の品質などは分からない

– テストの合格不合格率 (Q)• 合格不合格率のみを見ていると，実際にはテストコードや

テスト設計の品質が低い可能性がある– 不具合収束曲線 (Q, D)

• 曲線との乖離の理由は複数のメトリクスと現場の成果物、メンバーを分析する必要がある

メトリクスだけを見て現場を見ない

13

メトリクスの入力元

14

メトリクスの入力元と集約

チケット管理ツール

バージョン管理ツール

CIツール

デプロイツール

本番監視管理ツール

Agile Metrics統合

リポジトリ

15

アジャイルメトリクス

16

• 基本– ベロシティー (Q)

• 消化ストーリーポイント / スプリント• チームがスプリントで提供できる価値を表す• チームの能力が上がると一般に向上する

– ストーリーバーンダウン (Q, S)• 予定残ストーリーポイント /日• 実績残ストーリーポイント /日• ストーリー消化の予定と実績を表す• チームの能力が上がると一般に予定残に近づく

アジャイルメトリクス

17

• 基本– ベロシティーとストーリーバーンダウンのみを使っ

た場合の問題• 相対ポイントであるため、実稼働時間が上がっていても，問題に気づきにくい

• 欠陥の作り込み、障害の発生を測定していないので、硬化スプリント (洗練及びテスト専用スプリント ) や本番環境で障害が増加するリスクがある

– 補完するメトリクス• CI でのテストの合格失敗率、テストの増加率• ニコニコカレンダーによるチームメンバーの健康状態可視化

• ストリーポイントの実時間の比 ( 実時間 / 見積もり )

アジャイルメトリクス

18

• 応用– プロジェクト単位

• ポイント単位のバーンダウン /日 (Q, S)• テストの合格不合格 /日 (Q)

– スプリントではなく、長期間の傾向分析をする

– スプリント単位• ポイント単位のストーリーのオープンとクローズ /日 (Q)• テストの合格不合格 /日 (Q)• メンバーの実時間ワークロード /日 (C)

– スプリント内の効率や品質、健全性を分析する

アジャイルメトリクス

19

メトリクス組合せ例

20

• ポイント単位のバーンダウン /日 (Q, S)• テストの合格不合格 /日 (Q)– 良い傾向

• テストの合格率が一定でバーンダウンが予定通り– 悪い傾向

• バーンダウンの進行と共にテストの不合格率が増加

スピードと品質の両立

21

• 日単位のベロシティー (Q)• メンバーの実時間ワークロード (C)– 良い傾向

• ベロシティーが一定もしくは向上しているが、メンバーの実時間ワークロードが一定もしくは下がっている

– 悪い傾向• メンバーの実時間ワークロードが上がっている

スプリント内のスピードとメンバーの健康

22

• スプリントのベロシティー (Q)• 1 ストーリーポイントの実時間 ( 見積もり / 実測 )

(C)– 良い傾向

• ベロシティーが一定もしくは向上しているが、メンバーの 1 ストーリーポイントの実時間の実測が一定もしくは下がっている

– 悪い傾向• メンバーの 1 ストーリーポイントの実時間の実測が上がってい

る

スプリント間のスピードとメンバーの健康

23

メトリクスツール

24

• 商用の統合 Agile プロジェクト管理ツール– 自身以外にも JIRA や Jenkins など各種ツールをメト

リクスの入力元として利用できる

VersionOne

25

• OSS– 主要ツールからメトリクスを収集して可視化– https://github.com/cwhd/measurementor/tree/

development• 現在、書籍 "Agile Metrics in Action" の発売に備えて開発中

measurementor

26

参考情報

27

• Agile Metrics in Action– http://www.manning.com/davis2/

• Metrics in Scaled Agile Framework– http://www.scaledagileframework.com/metrics/

• VersionOne– http://www.versionone.com/

• measurementor– https://github.com/cwhd/measurementor

参考情報