La latencia de revisión es cuánto espera un pull request antes de que otra persona se involucre. En el producto la vas a encontrar como Avg Member Review Time en la tabla de Team Activity. Suele ser uno de los mayores aportantes al Lead Time for Changes.
Qué mide
Para cada persona, el tiempo promedio entre que se abre un pull request y su primera acción sobre él, considerando los pull requests que esa persona no escribió.
Cómo la calcula Leanmote
avg_member_review_time = suma(primera_accion - creacion_del_pr) / prs_revisados
Es un promedio, no una mediana, y el resultado se redondea a horas enteras. Un
0significa menos de media hora, no instantáneo.El reloj arranca en la fecha de creación del pull request. Leanmote no registra cuándo se pidió la revisión, así que pedirla tarde no corre el arranque.
El reloj se detiene en la primera acción de cualquier tipo de quien revisa: su primer comentario, su primera aprobación, o un commit que haya pusheado. Pushear un commit a la rama de otra persona cuenta como revisarla.
Los pull requests propios se saltean por completo, así que esto nunca mide a nadie contra su propio trabajo.
Las acciones registradas antes de la creación del pull request se descartan en vez de contarse como negativas.
Dos cosas que esta métrica no hace, aunque sea fácil suponerlas:
No juzga si la revisión fue sustantiva. Una aprobación vacía y una crítica detallada detienen el reloj igual.
No ajusta por horario laboral. Un pull request abierto un viernes a la noche acumula todo el fin de semana.
Cómo interpretarla
Son reglas de oro, no umbrales que el producto haga cumplir. Recuerda que el valor viene en horas enteras.
Menos de 4 horas es excelente, pero sobre reloj corrido, así que un equipo en una sola zona horaria va a verse mejor que uno distribuido con la misma conducta.
Entre 4 y 24 horas es lo típico en equipos sanos.
Más de 24 horas significa que el cycle time se está yendo en esperar que alguien tome la revisión. Se ataca con un SLA o rotando asignaciones.
Qué hacer al respecto
Define un SLA de revisión explícito para el equipo (por ejemplo, "primera revisión dentro de 4 horas laborales").
Reparte las revisiones: asignación automática en vez de que quien escribe salga a buscar revisores.
Pon un tope a la cola de revisión por persona antes de que cada quien tome trabajo nuevo.
Mira el tamaño de los pull requests: los grandes se revisan tarde. Achicarlos es lo que más rápido mueve esta métrica.
Métricas relacionadas
Lead Time for Changes
Tiempo hasta la primera aprobación
Participación en revisiones
Cycle Time
Waiting Time