最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。
一方、それらの指標を考えてみた時、以下のような点について悩んでいた。
- マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい
- コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか
このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやすくなるのではないかと考え、集計ツールを作ってみた。
https://github.com/shibayu36/merged-pr-stat
やりたいこと
- 特定期間にマージされたPullRequestの統計情報を集計したい
- 複数レポジトリ横断で、かつ色んな絞り込み条件をかけて、PullRequestを集計したい
- マイクロサービス対応や、botを取り除く・プロジェクトチームで切り分けるなど柔軟に集計したい
- 集計のやり方を工夫すれば、ユーザーの価値に直結するPullRequestだけ集計できる状態にもしておきたい
統計情報としては、次のものを計測した。5 metrics Engineering Managers can extract from Pull Requests – SourceLevelや50 shades of Lead Time. Measuring each part of the development process – SourceLevelも参考にした。
- PullRequest数
- チーム全体の、PullRequest数/day/developer を生産性や健全性の参考にしてみたい (d/d/d を意識)
- 巨大PullRequestが悪という考え方に基づいてPullRequestを分割した場合、この指標が上がるのも良いと考えた
- PullRequestのリードタイム = PullRequestの初コミット日時〜マージ日時
- 変更のリードタイムは「コミット〜本番稼働」を計測しているが、それよりももう少し計測しやすさに重きをおいた
- PullRequestのTime to Merge = PullRequest作成〜マージまでの時間
- レビュー時間の参考値に使えそうなので計測してみた
ツールの使い方
インストール
npmでインストールできる。
npm install -g shibayu36/merged-pr-stat
集計の仕方
例えばvscodeとTypeScriptの2レポジトリで7月中にマージされたPullRequestを集計したいと思ったら次のコマンドを打つ。するとPullRequest数や、リードタイムの平均・中央値、Time to Mergeの平均・中央値を取得できる。
$ GITHUB_TOKEN=... merged-pr-stat --start=2020-07-01T00:00:00 --end=2020-07-30T23:59:59 --query="repo:microsoft/vscode repo:microsoft/TypeScript" { "count": 258, "authorCount": 77, "additionsAverage": 107.89147286821705, "additionsMedian": 19, "deletionsAverage": 41.97286821705426, "deletionsMedian": 3, "leadTimeSecondsAverage": 578271, "leadTimeSecondsMedian": 58163, "timeToMergeSecondsAverage": 735697, "timeToMergeSecondsMedian": 82453 }
--queryオプションには Issue およびプルリクエストを検索する - GitHub Docs のクエリがすべて利用できる。そのため、例えば label:feature
のようにラベルで絞り込んだり、 -author:app/dependabot
でdependabotだけを取り除いたり、authorを並べてチームの特定プロジェクトに所属している人だけに絞り込むことも可能だ。
特定期間をn日ごとに集計する
上記コマンドだと、直近1年分を1週間ごとで集計したいとなった時にやりづらい。そこでそのようなことをするためのサンプルスクリプトも用意した。
例えばrepo:microsoft/vscodeとrepo:microsoft/TypeScript で、2020-01-01から1週間単位で集計したいなら次のコマンドを打つ。出力された内容をスプレッドシートに貼り付けるとグラフを作れる。
$ git clone https://github.com/shibayu36/merged-pr-stat.git $ cd merged-pr-stat $ npm install $ export GITHUB_TOKEN=...; npx ts-node examples/make-stat-on-interval-days-basis.ts --start=2020-01-01T00:00:00 --end=2020-07-30T23:59:59 --interval-days=7 --query="repo:microsoft/vscode repo:microsoft/TypeScript" startDate,endDate,count,authorCount,additionsAverage,additionsMedian,deletionsAverage,deletionsMedian,leadTimeSecondsAverage,leadTimeSecondsMedian,timeToMergeSecondsAverage,timeToMergeSecondsMedian 2020-01-01 00:00:00,2020-01-07 23:59:59,34,21,438.4117647058824,47.5,93.3529411764706,3.5,2411248,258766,2083335,235491 2020-01-08 00:00:00,2020-01-14 23:59:59,52,33,2142.5,74,1700.3076923076924,10,2264733,313925,2210338,246444 ...
PR数の推移。黄色は1ヶ月の移動平均。開発チームの人数と営業日数が分からないのでPR/d/dは計測できないが、単純にPR数が安定していてすごい。
リードタイム(hour)の中央値の推移。first commitから1日ちょっとくらいでマージされている。
PullRequestの生ログを取得する
もしPullRequestの生ログを使い、spreadsheetなどで別に集計したいとなったら、logコマンドを使うと良い。JSONかCSVで出力できる。
$ GITHUB_TOKEN=... merged-pr-stat log --start=2020-07-01T00:00:00 --end=2020-07-07T23:59:59 --query="repo:microsoft/vscode" --format csv title,author,url,createdAt,mergedAt,additions,deletions,authoredDate,leadTimeSeconds,timeToMergeSeconds Encoding euckr does not exist anymore (fix #101847),bpasero,https://github.com/microsoft/vscode/pull/101853,2020-07-07T12:09:03Z,2020-07-07T12:25:10Z,36,25,2020-07-07T12:03:23Z,1307,967 Fixes quick find symbol finder shows 'no matching results' after backspace,jeanp413,https://github.com/microsoft/vscode/pull/101844,2020-07-07T09:31:01Z,2020-07-07T11:20:42Z,11,7,2020-07-07T09:27:08Z,6814,6581 [Settings Editor] Add extra bottom padding for lists in settings,9at8,https://github.com/microsoft/vscode/pull/101812,2020-07-06T17:16:20Z,2020-07-06T18:45:35Z,4,2,2020-07-03T20:19:08Z,253587,5355 ...
まとめ
今回はPullRequestからチーム開発の生産性・健全性を測るCLIツールを紹介してみた。今回取れる指標の推移をトラッキングすることで、開発チームに問題が起こっているかを、直感ではなくデータとして把握できるようになると良いなと思っている。
参考
- https://github.com/shibayu36/merged-pr-stat
- LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ
- 開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiita
- 5 metrics Engineering Managers can extract from Pull Requests – SourceLevel
- 50 shades of Lead Time. Measuring each part of the development process – SourceLevel
- https://twitter.com/hiroki_daichi/status/1100381137929625600