メトリクスのフィードバックループ

ぼくとしては、この中で一番大事だと思っているのは「収集」です。

測定とか対応の方が頭を使うし、高度なことをしているように思えますが、収集の地道な作業が大変です。

この収集のためにメンバーにこの項目をきちんと設定してください、といった手間が増えてしまうと、本業の負担になります。

みんなの作業増やして、データ分析だけして、ためにならない理屈を展開する上司がいましたが、そりゃ、違うでしょ、と。

芳しくなければ不要な収集に関する業務をなくすことを考えるのも対応だと。

本書では測定は低コストで出来るべき、大事なものだけ測るとしています。

また測定の尺度も難しいのですが、動くソフトウェアこそが動く進捗の最も重要な尺度、であるとしています。

悪い副作用を示唆するメトリクス

では、何を分析するか、本書では悪い副作用を示唆するメトリクスとして一例を挙げています

多すぎるコメント数 - プルリクエストに6個以上コメントがある場合、多くのことに翻弄されている状態
プルリクエストが開かれている期間 - 妥当であれば、その日のうちにマージされるはず。何日間も開かれたままのPRは、何らかの問題を抱えている
プルリクエストごとのコミット数 - プルリクエストは数回のコミットから始まる。対応すべきコメントがあったり、PRが却下されたりした場合は、対応するためにコミットしていく。多ければ多いほど元のPRが悪いものであったこと意味する