How to reduce pull request review time without rushing reviewers
最初のレビューを迅速化するためのシステム アプローチ: キューを正確に測定し、実際の制約を見つけて、レビューの品質を低下させることなく作業のバランスを再調整します。
レビュー担当者の速度ではなく、待ち時間を測定する
最初のレビューの待ち時間は、変更がレビューの準備ができるようになってから、人間による最初の意味のあるレビュー イベントが発生するまでの時間です。これは配信システムの特性であり、個人のパフォーマンス グレードではありません。下書き、自動化されたボットのコメント、作成者がレビューを要求する前に発生したイベントを除外します。分布と範囲とともに中央値を報告します。変更の 10% に基づく中央値は、完全なレビュー イベントに基づく中央値と同じ信頼度を持ってはいけません。待機に費やす時間と、変更について積極的に議論したり修正するのに費やす時間は分けてください。
番号の後ろの列を見つけます
リポジトリ、チーム、変更サイズ、所有権領域、要求されたレビュー担当者、曜日ごとに待機をスライスします。次に、レコードを開きます。長い待ち時間は、小規模なレビュー担当者グループ、所有権が不明瞭なコンポーネント、大規模な変更、タイムゾーンの引き継ぎ、またはリリース境界付近で提出された作業に集中することがよくあります。グローバル中央値はこれらのパターンを隠します。レビュー担当者が吸収できるよりも早く到着する需要や、チーム間で反映される変更を探します。正しい介入はキューによって異なります。 4 時間以内にすべてをレビューするなどの一般的な目標では、制約が解決されることはほとんどありません。
プレッシャーを加える前に知識のバランスを再調整する
ほとんどのリクエストを少数の人が受け取る場合は、より速く作業するよう求めるのではなく、依存度を減らします。定義された所有権領域にバックアップのレビュー担当者を追加し、経験豊富なレビュー担当者と学習者をペアにして、レビュー担当期間をローテーションし、繰り返し承認を妨げる決定事項を文書化します。より多くの人が安全に理解できるように、変更を小さくしてください。専門家のレビューが本当に必要な場合は、計画中にその依存関係を可視化してください。目標は、同じ専門家に向けた大規模な通知ストリームではなく、集中時間が保護された、より広範で信頼性の高いレビュー ネットワークを拡大することです。
軽量のサービス契約を作成する
チームは、変更の準備がいつできるか、レビュー要求がどのようにルーティングされるか、ブロックするコメントの構成要素、および緊急の変更がどのようにエスカレーションされるかについて合意することができます。有用な契約では、1 日に 2 つのレビュー期間を確保し、注意を求める前に作成者にコンテキスト、テスト、リスク、ロールアウトに関するメモの提供を求めることができます。厳格な個別の対応目標は避けてください。彼らは表面的なコメントや絶え間ない中断を奨励します。数週間後に実際のキューの証拠を使用して契約を確認し、同じ待機が続く場合はリポジトリ ルール、チームの境界、または計画の前提条件を調整します。
品質と流れを一緒に確認する
レビューの迅速化は、変更が理解可能で安全なままである場合にのみ改善されます。フォローアップの修正、信号の取り消し、繰り返しのレビューラウンド、およびインシデントのリンクを遅延とともに追跡します。新しいワークフローが深い作業を保護するかどうか、また作成者が有益なフィードバックを受け取るかどうかをレビュー担当者に尋ねます。 1 日の低下を祝うのではなく、同様の期間を比較します。最良の結果は、可能な限り小さい数値ではありません。これは予測可能なレビュー システムであり、重要な変更には適切な専門知識が迅速に提供され、通常の作業は英雄的な可用性に依存しません。