검토자를 서두르지 않고 풀 요청 검토 시간을 줄이는 방법
더 빠른 첫 번째 검토를 위한 시스템 접근 방식: 대기열을 올바르게 측정하고, 실제 제약 조건을 찾고, 검토 품질을 저하시키지 않고 작업 균형을 재조정합니다.
리뷰어 속도가 아닌 대기 시간을 측정하세요.
첫 번째 검토 대기 시간은 변경 사항이 검토 준비가 된 시점부터 첫 번째 의미 있는 인적 검토 이벤트까지의 시간입니다. 이는 개인의 성과등급이 아닌 전달체계의 속성이다. 작성자가 검토를 요청하기 전에 발생한 초안, 자동화된 봇 댓글, 이벤트를 제외하세요. 분포 및 적용 범위와 함께 중앙값을 보고합니다. 변경 사항의 10%를 기반으로 한 중앙값은 전체 검토 이벤트를 기반으로 한 것과 동일한 신뢰도를 가져서는 안 됩니다. 변경 사항을 적극적으로 논의하거나 수정하는 데 소요되는 시간과 기다리는 데 소요되는 별도의 시간입니다.
숫자 뒤의 대기열 찾기
저장소, 팀, 변경 크기, 소유권 영역, 요청된 검토자 및 요일별로 대기 시간을 분할하세요. 그런 다음 기록을 엽니다. 긴 대기 시간은 소규모 리뷰어 그룹, 소유권이 불분명한 구성 요소, 과도한 변경 사항, 시간대 전달 또는 릴리스 경계 근처에 제출된 작업을 중심으로 클러스터되는 경우가 많습니다. 전역 중앙값은 이러한 패턴을 숨깁니다. 검토자가 수용할 수 있는 것보다 더 빨리 도착하는 수요와 팀 간에 전달되는 변경 사항을 찾으세요. 올바른 개입은 대기열에 따라 다릅니다. 4시간 이내에 모든 것을 검토하는 것과 같은 일반적인 목표는 제약 사항을 거의 해결하지 못합니다.
압력을 가하기 전에 지식의 균형을 재조정하세요
소수의 사람이 대부분의 요청을 받으면 더 빨리 작업하도록 요청하기보다는 의존성을 줄이십시오. 정의된 소유권 영역에 대한 백업 검토자를 추가하고, 숙련된 검토자를 학습자와 짝을 이루고, 검토 의무 기간을 순환하고, 반복적으로 승인을 차단하는 결정을 문서화합니다. 더 많은 사람들이 안전하게 이해할 수 있도록 변경 사항을 작게 유지하세요. 전문가의 검토가 정말로 필요한 경우 계획 중에 해당 종속성을 표시하십시오. 목표는 동일한 전문가에게 전달되는 더 큰 알림 스트림이 아니라 보호된 집중 시간을 갖춘 더 넓고 안정적인 검토 네트워크입니다.
경량 서비스 계약 생성
팀은 변경이 준비되는 시기, 검토 요청이 전달되는 방법, 차단 댓글의 구성 요소, 긴급 변경이 에스컬레이션되는 방법에 동의할 수 있습니다. 유용한 계약은 하루에 두 번의 검토 창을 예약하고 작성자에게 주의를 요청하기 전에 컨텍스트, 테스트, 위험 및 롤아웃 메모를 제공하도록 요청할 수 있습니다. 엄격한 개별 응답 목표를 피하십시오. 그들은 피상적인 댓글과 지속적인 방해를 장려합니다. 몇 주 후에 실제 대기열 증거를 사용하여 계약을 검토한 다음 동일한 대기가 계속되면 저장소 규칙, 팀 경계 또는 계획 가정을 조정합니다.
품질과 흐름을 함께 확인하세요
빠른 검토는 변경 사항이 이해 가능하고 안전하게 유지되는 경우에만 개선됩니다. 대기 시간과 함께 후속 수정 사항을 추적하고, 신호를 되돌리고, 반복 검토 라운드 및 사고 링크를 추적합니다. 새로운 워크플로가 심층 작업을 보호하는지, 작성자가 유용한 피드백을 받는지 검토자에게 물어보세요. 하루 하락을 축하하는 대신 비슷한 기간을 비교하십시오. 최상의 결과는 가능한 가장 작은 숫자가 아닙니다. 중요한 변경 사항이 올바른 전문 지식을 신속하게 받고 정상적인 작업이 영웅적 가용성에 좌우되지 않는 예측 가능한 검토 시스템입니다.