エンジニアリングの生産性の測定は複雑なプロセスであり、開発者がどのように時間を費やしているかを全体像を把握するのは困難です。生産性を測定する一般的な方法は、DORA や SPACE などのシステム メトリクスを分析することです。これらは、業界標準と比較してチームの生産性を理解するのに非常に役立つ指標となります。これらの各指標を詳しく調べると、チームの速度を遅らせている原因についての洞察も得られます。 しかし、場合によっては、開発者が 1 日を通して、生産性に影響を与えているとは認識されない「隠れた時間」が存在することもあります。しかし、これらを合計し始めると、驚くべき数字になる可能性があります。 たとえば、開発者が変更のせいでテストが失敗したかどうかを判断するために、不安定なテストのデバッグに費やす時間を考えてみましょう。または、メインラインのビルドの失敗を解決しようとする開発者が費やした時間。 その観点を提供するために、私たちはエンジニアリングの効率を評価するための計算機を構築しました。これは、エンジニアリング チームの効率を完全に分析できるものではありません。 それが提供するのは、一般的な生産性指標には通常現れない、無駄な時間の「隠れたポケット」を垣間見ることです。 この計算ツールは、開発者のワークフローにおけるビルドとテストの失敗によって、あなたとあなたのチームがどれだけの時間を失っているかに焦点を当てています。 これを DORA メトリクスと比較すると、変更のリードタイムはビルドとテストの不安定性によって大きく影響されます。 その影響は、この計算ツールを使用して評価できます。 使い方 GitHub アクティビティと GitHub ブランチの使用方法に基づいてデータを入力するように求められます。以下の実際の計算を説明するために、それぞれに変数を割り当ててみましょう。 M – 1 日にマージされる PR 数 X – 1 週間以内にメインラインに障害が発生する T – 平均 CI 時間 F – 剥離係数 % これらの入力に基づいて、エンジニアリング チームがビルドの失敗の管理と不安定なテストの処理に週にどれだけの時間を浪費しているかを推定します。結果を一つずつ見ていきましょう。 修正に何時間も無駄にした これにより、メインライン ビルドの失敗が検出されたときに、特定、優先順位付け、修正、およびビルドの再合格にかかる時間の無駄が計算されます。通常、大規模なチームでは、誰かが壊れたメインライン ビルドに気づき、報告します。 メインラインのビルドの失敗には、平均 1 ～ 3 人の開発者がデバッグと修正を行う必要があると想定しています。問題が報告され、修正が適用されるまでにかかる時間を平均 1 時間と考えると、問題の追跡、調査、解決に 費やしていることになります。 (2*T + 1) 時間を つまり、週に X 件の障害が発生した場合、メインラインのビルド障害と戦うために (( 開発者の時間に費やしていることになります。 2 開発者 * X/5 * (2*T + 1)) 時間を マージ競合の解決に何時間も無駄になった ロールバックとマージの競合により、さらに問題が発生する可能性があります。壊れたビルド時間 の間にマージ競合が発生する PR が約 2% あり、1 時間ごとに PR が入ってくると仮定すると、 これらの競合を解決するために無駄になります。 ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0.02 * M/8 は、 ビルドの破損による毎週の CI 障害 チームが機能ブランチのベースとしてゴールデン ブランチを使用していない場合は、失敗したメインライン ブランチの上に機能ブランチを作成する可能性があります。任意の時点で作成される PR の数は、メインラインからの機能ブランチの平均数と同程度であるため、毎日 個の CI エラーが発生することになります。 。 (2*T + 1 時間) * X/5 * M/8 CI を解決する時間 ビルドが失敗するたびにハンドルを切り替える約 15 分間のコンテキストを考慮すると、 時間の開発時間が毎日 CI の失敗で無駄になります。 (2*T + 1 時間) * X/5 * M/8 * 0.25 不安定なテストの再実行に費やされた時間。 同様に、不安定なテストでは、テストが不安定か本物かを調査するためにコンテキストの切り替えに時間がかかり、テスト自体の再実行には 1 回の実行につき平均 15 分かかります。薄片性係数によっては、開発者は毎日 時間を無駄にすることになります。 (0.25 * M * F / 100) 効率の向上 これらのほとんどは、 エンジニアリング チームのワークフローの非効率性の測定という点では、まだ表面をなぞっただけです。ビルドとテストの失敗の影響は、リリースの遅延にもつながり システム内での不安定なテストの持続性など、他の DORA メトリクスに影響を与え、失敗率の増加につながる可能性があります。 。 変更のリードタイムに関連する DORA メトリクスに影響を与えますが、 、展開頻度、サービスの復元時間、 DORA メトリクスの詳細については、こちらをご覧ください または、その欠点について詳しく学びましょう。 私たちは、大規模なエンジニアリング チームの隠れた課題のいくつかを解決するために 構築しました。現在、多くのエンジニアリング組織は、Aviator MergeQueue を使用して、ビルドを中断することなくマージ ワークフローを拡張できます。これを のような不安定なテスト抑制システムと組み合わせることで、チームは毎週何百ものエンジニアリング時間を節約できます。 Aviator を TestDeck でも公開されています。 ここ
