開発生産性可視化に使われるメトリクスを見かける度メモる

実際に生産性指標として使われているメトリクスは開発者のアクティビティによるものからシステムレベルも含め多々存在しているが、どのようなメトリクスが用いられているか調べて && 見つける度にひたすらメモしていく

Four Keys

言わずと知れた、LeanとDevOpsの科学で紹介されたState of DevOps ReportやDevOps Research and Assessment（DORA）チームの研究・調査から導き出されたソフトウェア開発チームのパフォーマンスを示す4つの指標
Four keysについてと開発組織の生産性・パフォーマンス測定にFour keysの何が良いのか？

r.kagaya

Git/GitHubベースのアクティビティメトリクス

コード、Gitベースのメトリクス
Four Keysを計測するために or ブレイクダウンしたメトリクスとして使われる例が多いが、Four Keysの文脈に関係なく、コミット数やスプリント毎のストーリポイント数で生産性を測っている例はいくつか見受けられたので、一旦独立したカテゴリにした
いわゆるアクティビティにあたり、単体では生産性を適切に表す指標とは言いづらいものが多いが、測定が比較的容易でもあるため利用実績は多く、Four Keysを追っている場合でもコミット数なども別途追加で可視化している例はそれなりに確認できた
比較的測定が容易であり、特にボトルネックなどの改善につながる示唆を得ることも可能なため、あくまでコミット数やコード行数だけで開発者、開発組織の生産性を測ることが難しいというだけで、可視化して追跡する意味はあると考えている

指標(WIP: まだ追加出来ていない指標が沢山ある)

コミット数
平均コミットサイズ
PR作成数、マージ数
J- IRAチケットのクローズ数
コード行数
平均PRクローズ時間
PR作成~closeまでの時間
- 多くの場合、Four Keysの変更のリードタイムにはfirst commit~masterマージまでの時間を含むため、変更のリードタイムの一部を表す指標になる
コードレビューにかかる時間
- 基本は平均PRクローズ時間に含まれ、Four Keysとしては変更のリードタイムに関連する
- 実際にボトルネックを特定して改善進めていくとなれば、細かく可視化されている必要が出てくる
CIに関する数値(成功,Flaky率、時間、etc)
- CIにかかる時間などは平均PRクローズ時間、そして変更のリードタイムに繋がる。また後述のフィードバックループにも関連する
- PR Closeまでのボトルネックになっているのは、コードレビューとCIが体感多いので、コードレビューにかかる時間と合わせて可視化しておくと改善時には便利

参考

r.kagaya

マイクロフィードバックループ

日々開発者が実行/直面する作業の一つ一つは小さくとも、それらも塵も積もれば山となる、という話
自動テストの実行など開発者が日々行なっている基本的な事に要する時間が長ければ、一つ一つは数十秒であっても、その分が積み重なると開発スピード、体験の低下、またFour Keysのスコア低下にも繋がってしまう
CI回すのに数十分かかる時の影響を考えるとイメージしやすいが、CBTD(code-build-test-debug) loopに限らず、ドキュメント探しにかかる時間やローカル環境や開発環境に反映されるまでの時間なども含まれる

指標

Validate a local code change works
Find root cause for defect
Validate component integrates with other components
Validate a change meets non-functional requirements
Become productive on new team
Get answers to an internal technical query
Launch a new service in production
Validate a change was useful to the customer

参考

Maximizing Developer Effectiveness

r.kagaya

SPACE

開発者の生産性を測るためのフレームワークSPACEについてでまとめている

r.kagaya

Developer Velocity

ちゃんと見れていない

参考

r.kagaya

スピードのメトリクス

ソフトウェアデリバリーパイプラインのスピードと効率性を評価
ex)
- スループット
- 変更リードタイム
- スプリントのスピード
  - イシューとストーリーポイントの数
  - 完了できたイシューの数と予定していたイシューの数の比較
  - イシューの種類ごとの分布割合
- 実行時間
- 平均復旧時間
- 成功率

意欲のメトリクス

ex)
- 個人とチームの意欲
- コード品質に対する自信
  - カバレッジよりも自信を重視する

ビジネスのメトリクス

ex)
- 企業の成長ファネルのメトリクス
- エンドユーザーにとっての価値

r.kagaya

リワーク率

マージされてから21日以内に書き直されたコードの割合
下流の品質問題の予測測定や、要件が見落とされたことを示す

Review to Merge Time (RTMT)

GitLab の開発ハンドブックで提案
PRのレビューを依頼してから PR をマージするまでの時間を計測
RTMTが高いと、フィードバックを待っている間に開発者が作業を進めることができず、異なる課題間でコンテキストを切り替えることを助長してしまう

r.kagaya

VSCodeとJetBrainsのIDE上で、issueとかチケットを扱えるようにするらしいサービス

r.kagaya

Lead Time

摩擦が多いプロセス、オーナーシップのないプロセス、明確な説明がないプロセスは、リードタイムに悪影響を及ぼす
自動化もリードタイムを決定する重要な要素
リードタイムは現実的な機能ロードマップを作成するのに役立ちつ
- 現実的なロードマップは、開発者へのプレッシャーを軽減し、全体の雰囲気と定着率に良い影響を与える

The Percentage of Codebase Issues Resolved

コードベースが改善されているかどうかを示す最も良い指標の1つは、コードベースのissueの解決数

Time to Complete a Code Review

コードレビューは開発プロセスの一部
多くの場合、PRには明確な所有権がなく明確な受け入れ基準がない
- PRがいつapproveされるのか、そうでないのかが不明瞭
多くのチームでは経験豊富な開発者がほとんどのコードレビューを担当
- 複数の開発者に知識を分散させることが重要
誰がコードレビューを行っているか、コードベースへのプルリクエストの受け入れにどれくらいの時間がかかっているかを追跡する

r.kagaya

Circle CIのレポート

r.kagaya

Cycle Time
- 開発チームがエンドユーザーにどれだけ早く価値を提供できるかを追跡
Deploy Frequency
- より小さなコードのかたまりをより頻繁にリリースすること
- デプロイのリリースとテストがより管理しやすくなり、全体的な品質も向上する
Rework Ratio
- チームがエンドユーザーに納品した後に書き直す必要があるコードの量
- コミュニケーションが不十分であったり、レビュープロセスに問題があったりして、将来の品質問題につながる可能性を示唆
High-Risk Branches
- 手戻りの割合が高いコードブランチの数
- より多くの変更を加えなければならない場合、リスクはより大きくなり、手直し率の高いブランチは、低品質につながるリスクも高くなる
Investment Profile
- チームがさまざまな種類の作業に費やした時間
- バグの修正から非機能的なタスクの処理まで
- チームメンバーが労力を費やす作業の種類を表す
- リソースの適宜配分を判断する
Context Switching
- チームメンバーが、様々な障害によって、ある問題から別の問題へ移動しなければならない頻度
- コンテキストの切り替えが多い場合は、チームが非効率的である可能性が高いことを意味
WIP Balance
- WIPバランスメトリクスは、チームメンバーに仕事が均等に配分されているかどうかを判断するためのもの
- 各メンバーがどれだけの仕事を抱えているのかがわかる
  - あるメンバーには負担がかかり、他のメンバーには負担がかからないという状況を回避することができる
Days Worked
- チームがイテレーション中に何日活動したかを測定し、燃え尽き症候群を回避することができる

r.kagaya

Sustained Velocityなるものについて書いてる
ある作業を評価するとき、あるいは技術設計を評価するとき、いかに早く構築できるかだけに注目するのではなく、その作業が現在および将来のチームのベロシティにどのような影響を与えるかにも注目

r.kagaya

アーキテクチャメトリクス