Agile Merics入門

Agile Merics入門

1. 1. 1 Agile Metrics入門 株式会社SHIFT 太田健一郎
2. 2. 2 • アジャイル開発のQCD+S • アジャイル開発におけるメトリクス取得の目的 • メトリクスのやってはいけない • メトリクスの入力元 • アジャイルメトリクス • メトリクス組合せ例 • 他社案件事例 • メトリクスツール • 参考情報 アジェンダ
3. 3. 3 アジャイル開発のQCD+S
4. 4. 4 • Quality – 品質→価値 • Cost – ポイント毎の実時間 x 総ストーリーポイント • Delivery – Agileでは通常固定 • Scope – スプリント毎に提供するストーリーの総量 – Agileでは開発するストーリーは交渉できる要素 QCD + S
5. 5. 5 アジャイル開発におけるメトリクス取得の 目的
6. 6. 6 • Measure – チームとプロダクトの健康状態を確認する • React – 健康でなかった場合のアクションを発見する – アクションを実施する • Repeat – Measure, Reactを繰り返して、パフォーマンスを上 げていく Measure, React, Repeat メトリクス取得！＝管理
7. 7. 7 メトリクスのやってはいけない
8. 8. 8 • 結果 – そのメトリクス以外の要素を犠牲にしてもそのメト リクスを向上させようとする • 例 – 納期 (D) • 品質(Q)、コスト(C)が犠牲になる – ベロシティー (Q) • 実稼働時間が上昇する • メンバーの健康が阻害される • 従来の意味の品質が低下する 一つのメトリクスだけを用いる
9. 9. 9 • 結果 – 収集されたメトリクスがReactに活かされない – 収集されたメトリクスを誰も意識しない • 例 – LOC (C) • LOCだけでは生産性を意味しない – コードインスペクションの違反の数 (Q) • 重み付け、修正条件、修正する目的などを定義しないと違 反の数だけでは修正する理由付けにはならない – ユーザー別コミットの回数 (C?) • 評価に使おうとしている？？ 目的の不明確なメトリクスを取得する
10. 10. 10 • 結果 – 本質的でないメトリクス収集の工数が取られる – メトリクス収集職人が必要になる • 例 – ユニットテストの障害数、障害率 (Q) • 取得することは可能だが、取る工数の割に得られるものが 少ない • TDD的な開発だと伝統的な開発からの統計とは異なった値が 出がち – テストコードの実装工数 (C, D) • 共通部品(PageObjectやユーティリティークラス)が充実する までは変動が大きい • コミット時間等で自動的に取得するのは難しい 取得に複雑な手作業が必要なメトリクスを取得する
11. 11. 11 • 結果 – 正しい情報を入力しなくなる – 情報を捏造するようになる • 例 – LOCをメンバーの生産性と評価に使う (C, D) • コメントやブロックを水増したり、コピペしたりするよう になる – 作り込んだ障害数を評価に使う (Q->C) • 障害でないと否定したり、開き直ったりする – 起票した障害数を評価に使う (Q->C) • 障害票の内容がおざなりになる • 改善案であり障害か怪しいものを障害として起票する メトリクスを人の評価に使う
12. 12. 12 • 結果 – 現場が疲弊している状態を見逃す – 内部品質が悪い状態を見逃す • 例 – EVM (Q, C, D) • EVMだけ見ていてもスケジュールやコストの差異が分かるだ けで、現場の疲弊感や実際の品質などは分からない – テストの合格不合格率 (Q) • 合格不合格率のみを見ていると，実際にはテストコードや テスト設計の品質が低い可能性がある – 不具合収束曲線 (Q, D) • 曲線との乖離の理由は複数のメトリクスと現場の成果物、 メンバーを分析する必要がある メトリクスだけを見て現場を見ない
13. 13. 13 メトリクスの入力元
14. 14. 14 メトリクスの入力元と集約 チケット管理 ツール バージョン管理 ツール CI ツール デプロイ ツール 本番監視管理 ツール Agile Metrics 統合 リポジトリ
15. 15. 15 アジャイルメトリクス
16. 16. 16 • 基本 – ベロシティー (Q) • 消化ストーリーポイント/スプリント • チームがスプリントで提供できる価値を表す • チームの能力が上がると一般に向上する – ストーリーバーンダウン (Q, S) • 予定残ストーリーポイント/日 • 実績残ストーリーポイント/日 • ストーリー消化の予定と実績を表す • チームの能力が上がると一般に予定残に近づく アジャイルメトリクス
17. 17. 17 • 基本 – ベロシティーとストーリーバーンダウンのみを使っ た場合の問題 • 相対ポイントであるため、実稼働時間が上がっていても， 問題に気づきにくい • 欠陥の作り込み、障害の発生を測定していないので、硬化 スプリント(洗練及びテスト専用スプリント)や本番環境で障 害が増加するリスクがある – 補完するメトリクス • CIでのテストの合格失敗率、テストの増加率 • ニコニコカレンダーによるチームメンバーの健康状態可視 化 • ストリーポイントの実時間の比 (実時間/見積もり) アジャイルメトリクス
18. 18. 18 • 応用 – プロジェクト単位 • ポイント単位のバーンダウン/日 (Q, S) • テストの合格不合格/日 (Q) – スプリントではなく、長期間の傾向分析をする – スプリント単位 • ポイント単位のストーリーのオープンとクローズ/日 (Q) • テストの合格不合格/日 (Q) • メンバーの実時間ワークロード/日 (C) – スプリント内の効率や品質、健全性を分析する アジャイルメトリクス
19. 19. 19 メトリクス組合せ例
20. 20. 20 • ポイント単位のバーンダウン/日 (Q, S) • テストの合格不合格/日 (Q) – 良い傾向 • テストの合格率が一定でバーンダウンが予定通り – 悪い傾向 • バーンダウンの進行と共にテストの不合格率が増加 スピードと品質の両立
21. 21. 21 • 日単位のベロシティー (Q) • メンバーの実時間ワークロード (C) – 良い傾向 • ベロシティーが一定もしくは向上しているが、メンバーの 実時間ワークロードが一定もしくは下がっている – 悪い傾向 • メンバーの実時間ワークロードが上がっている スプリント内のスピードとメンバーの健康
22. 22. 22 • スプリントのベロシティー (Q) • 1ストーリーポイントの実時間 (見積もり/実測) (C) – 良い傾向 • ベロシティーが一定もしくは向上しているが、メンバーの1スト ーリーポイントの実時間の実測が一定もしくは下がっている – 悪い傾向 • メンバーの1ストーリーポイントの実時間の実測が上がっている スプリント間のスピードとメンバーの健康
23. 23. 23 メトリクスツール
24. 24. 24 • 商用の統合Agileプロジェクト管理ツール – 自身以外にもJIRAやJenkinsなど各種ツールをメトリ クスの入力元として利用できる VersionOne
25. 25. 25 • OSS – 主要ツールからメトリクスを収集して可視化 – https://github.com/cwhd/measurementor/tree/dev elopment • 現在、書籍"Agile Metrics in Action"の発売に備えて開発中 measurementor
26. 26. 26 参考情報
27. 27. 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 参考情報