Review Time: сколько код ждёт проверки
Review Time: сколько код ждёт проверки
PR открыт в понедельник утром.
Первый комментарий появляется во вторник вечером. Автор отвечает в среду. Ревьюер возвращается в четверг. В пятницу изменение наконец сливается.
Само ревью заняло минут сорок. Но календарно код ждал почти неделю.
Если смотреть только на среднее время ревью, эту проблему легко не заметить.
Одной цифры недостаточно
Review Time лучше разделять на несколько интервалов.
Time to First Review — время от открытия PR до первого содержательного комментария или одобрения.
Показывает, насколько быстро команда вообще начинает проверку. Комментарий бота, запуск CI или автоматическое назначение ревьюера считать не стоит.
Time to Approval — время от открытия PR до получения необходимых approvals.
Сюда входят ожидание, обсуждение и циклы исправлений. Если PR несколько раз возвращается автору, это будет видно именно здесь.
Time to Merge — время от открытия PR до merge.
Кроме ревью, сюда попадают CI, ручной merge, зависимость от других изменений и ожидание релизного окна.
Разница между этими интервалами помогает понять, где именно лежит код.
Почему среднее обманывает
Представим:
девять PR слились за два часа;
один PR висел десять дней.
Среднее значение сгладит ситуацию. Процесс будет выглядеть терпимо, хотя один тип изменений регулярно попадает в очередь на неделю.
Поэтому я бы смотрел не только среднее, но и:
медиану;
85-й или 90-й перцентиль;
долю PR старше выбранного порога;
распределение по размеру и типу изменений;
время до первого содержательного отзыва.
Например, медиана Time to First Review у команды составляет три часа. На первый взгляд всё хорошо.
Но 15% PR ждут больше двух дней.
Значит, проблема не во всём процессе. Нужно искать конкретные репозитории, типы изменений или узких экспертов, возле которых образуется очередь.
Какие сигналы стоит проверить
PR регулярно ждут первого комментария больше рабочего дня;
большая часть ревью проходит через одного человека;
маленькие изменения обрабатываются так же долго, как крупные;
между ответами автора и ревьюера возникают длинные паузы;
PR проходят несколько одинаковых циклов доработки;
approvals уже собраны, но merge происходит значительно позже.
Высокий Review Time может означать что угодно: большой WIP, отсутствие владельца ревью, нехватку экспертизы, слишком крупные PR или архитектурный спор, который начался уже после написания кода.
Иногда причина ещё проще: за создание нового кода разработчика хвалят, а время на помощь коллегам считается отвлечением от работы.
Как не превратить метрику в дубинку
Review Time не нужен для рейтинга «самых медленных ревьюеров».
Количество комментариев тоже ничего не говорит о качестве проверки. А требование мгновенно отвечать на каждый PR быстро приводит к поверхностным approve.
Полезнее смотреть на командный поток:
где изменения чаще всего останавливаются;
сколько времени занимает ожидание, а сколько обсуждение;
какие размеры и типы PR задерживаются;
изменилась ли картина после новых договорённостей.
Из практических шагов можно начать с простого:
договориться о времени первого отзыва;
выделить окна для ревью;
уменьшать размер изменений;
автоматически назначать ревьюеров;
выносить архитектурные вопросы до написания большого PR;
отмечать блокирующие и необязательные комментарии;
показывать старые PR на ежедневном обзоре;
ограничить количество одновременно открытых PR.
Definition of Ready помогает лучше готовить задачи. Working Agreements задают правила ревью. Review Time показывает, работают ли эти договорённости в реальности.
Эта метрика нужна не для того, чтобы люди быстрее ставили approve. Она показывает время, когда готовое изменение лежит без движения.
Что чаще задерживает ваши PR: ожидание первого ревью, долгие обсуждения, исправления или проверки после approval?
PR открыт в понедельник утром.
Первый комментарий появляется во вторник вечером. Автор отвечает в среду. Ревьюер возвращается в четверг. В пятницу изменение наконец сливается.
Само ревью заняло минут сорок. Но календарно код ждал почти неделю.
Если смотреть только на среднее время ревью, эту проблему легко не заметить.
Одной цифры недостаточно
Review Time лучше разделять на несколько интервалов.
Time to First Review — время от открытия PR до первого содержательного комментария или одобрения.
Показывает, насколько быстро команда вообще начинает проверку. Комментарий бота, запуск CI или автоматическое назначение ревьюера считать не стоит.
Time to Approval — время от открытия PR до получения необходимых approvals.
Сюда входят ожидание, обсуждение и циклы исправлений. Если PR несколько раз возвращается автору, это будет видно именно здесь.
Time to Merge — время от открытия PR до merge.
Кроме ревью, сюда попадают CI, ручной merge, зависимость от других изменений и ожидание релизного окна.
Разница между этими интервалами помогает понять, где именно лежит код.
Почему среднее обманывает
Представим:
девять PR слились за два часа;
один PR висел десять дней.
Среднее значение сгладит ситуацию. Процесс будет выглядеть терпимо, хотя один тип изменений регулярно попадает в очередь на неделю.
Поэтому я бы смотрел не только среднее, но и:
медиану;
85-й или 90-й перцентиль;
долю PR старше выбранного порога;
распределение по размеру и типу изменений;
время до первого содержательного отзыва.
Например, медиана Time to First Review у команды составляет три часа. На первый взгляд всё хорошо.
Но 15% PR ждут больше двух дней.
Значит, проблема не во всём процессе. Нужно искать конкретные репозитории, типы изменений или узких экспертов, возле которых образуется очередь.
Какие сигналы стоит проверить
PR регулярно ждут первого комментария больше рабочего дня;
большая часть ревью проходит через одного человека;
маленькие изменения обрабатываются так же долго, как крупные;
между ответами автора и ревьюера возникают длинные паузы;
PR проходят несколько одинаковых циклов доработки;
approvals уже собраны, но merge происходит значительно позже.
Высокий Review Time может означать что угодно: большой WIP, отсутствие владельца ревью, нехватку экспертизы, слишком крупные PR или архитектурный спор, который начался уже после написания кода.
Иногда причина ещё проще: за создание нового кода разработчика хвалят, а время на помощь коллегам считается отвлечением от работы.
Как не превратить метрику в дубинку
Review Time не нужен для рейтинга «самых медленных ревьюеров».
Количество комментариев тоже ничего не говорит о качестве проверки. А требование мгновенно отвечать на каждый PR быстро приводит к поверхностным approve.
Полезнее смотреть на командный поток:
где изменения чаще всего останавливаются;
сколько времени занимает ожидание, а сколько обсуждение;
какие размеры и типы PR задерживаются;
изменилась ли картина после новых договорённостей.
Из практических шагов можно начать с простого:
договориться о времени первого отзыва;
выделить окна для ревью;
уменьшать размер изменений;
автоматически назначать ревьюеров;
выносить архитектурные вопросы до написания большого PR;
отмечать блокирующие и необязательные комментарии;
показывать старые PR на ежедневном обзоре;
ограничить количество одновременно открытых PR.
Definition of Ready помогает лучше готовить задачи. Working Agreements задают правила ревью. Review Time показывает, работают ли эти договорённости в реальности.
Эта метрика нужна не для того, чтобы люди быстрее ставили approve. Она показывает время, когда готовое изменение лежит без движения.
Что чаще задерживает ваши PR: ожидание первого ревью, долгие обсуждения, исправления или проверки после approval?