¿Cómo hacer una revisión eficiente del código durante la fiebre de liberación?

La fecha límite para un lanzamiento es mañana, su colega finalmente terminó su tarea que es crucial para este lanzamiento, el gerente de proyecto está parado sobre su hombro y lo presiona para que finalmente realice una compilación y nota una falla en el código de su colega durante la revisión. No es crítico, pero es algo que no dejarías pasar si no fuera por el lanzamiento de mañana. Y para empeorar las cosas, tiene su propio trabajo que necesita para terminar lo antes posible. ¿Entonces, Qué haces? ¿Planteas tu objeción a pesar de la presión o simplemente dejas pasar esta?

Una forma que encontré es fusionar temporalmente este commit en una rama diferente y dejar una revisión para más adelante. Funciona si el problema es solo cosmético y si es el único que todavía está esperando la revisión del código. Sin embargo, ¿hay una manera más eficiente de manejar esto? Por ejemplo, ¿recomendaría comprometer a una persona para que solo revise y realice pruebas de código?

La respuesta aquí es comunicarse.

1. Informe al líder técnico / del equipo sobre el problema.
2. Hable con QA sobre el impacto potencial
3. Dígale a la gerencia del proyecto (quién está detrás de usted) que puede haber un problema que retrase el lanzamiento, y volverá con ellos lo antes posible (en cuestión de minutos u horas)
4. Evaluar si este problema es un obstáculo para el lanzamiento

Si el problema no es un show stopper, continúe con el lanzamiento. Informe a QA y a sus usuarios sobre el problema y comprométase a una fecha de seguimiento en la que se reparará el problema. Esto simplemente se convierte en otro riesgo para la producción.

Si esto es un obstáculo para el espectáculo (lo que significa que tendrá un impacto negativo en el resultado final o en la salud de alguien), comunique esto en la cadena que su recomendación es retrasar el lanzamiento y explique por qué. Luego regrese con el desarrollador y calcule cuánto tiempo tomará solucionar el problema, y ​​dígale a la gerencia que necesita X cantidad de minutos / horas / días.

Lo más probable es que la gerencia no esté contenta con un show stopper a estas alturas del juego, pero no querrá que se lance a producción.

Comuníquese y deje que la gerencia haga la llamada.

No solo comunique el problema, documente

Mi gran preocupación con las otras respuestas hasta el momento: cualquier cosa que diga en este sentido al gerente de proyecto típico que enfrenta un plazo inminente probablemente se ignorará u olvidará. Entonces, aún puede terminar enganchado por comunicar insuficientemente el riesgo, si algo sale mal.

Informe al gerente del proyecto sobre el problema que ha encontrado y hágale saber que lo documentará . Debe poder señalar su diligencia debida.

Dónde documentar y a quién contar depende de su entorno de trabajo, pero definitivamente incluya a su jefe.

Identificar riesgo e impacto

Usted menciona que el problema no es crítico, pero realmente no define lo que eso significa. Desarrollar eso es tu próximo paso.

Haga un análisis rápido de riesgo e impacto para identificar el problema, la probabilidad de que cause un problema (riesgo) y la gravedad de las consecuencias si el riesgo se materializa (impacto). Use términos bien definidos (que su gerente de proyecto debe saber) como los que se encuentran en el enlace anterior, pero también proporcione una descripción que respalde su análisis.

Su documentación también debe incluir su curso de acción recomendado. Sí , está bien plantear una inquietud y aún así recomendar continuar con el lanzamiento. Es correcto identificar el riesgo .

¿Cuándo es tu próximo lanzamiento?

Si, después de completar su análisis de riesgo / impacto, aún no sabe qué recomendar, tenga en cuenta su calendario de lanzamientos. Se puede lanzar algún código imperfecto si puede esperar incluir la solución en dos semanas.

Si existe la posibilidad de que la solución de su inquietud se “despriorice” (es decir, se descuide a favor de la próxima mejora brillante), entonces esa es una razón más para documentar el problema lo antes posible después de descubrirlo: si efectivamente comienza el reloj "sobre el tema.

En este caso, solo informe a todos y déjelos decidir. Probablemente no sea el primer error que se libera.

La fecha límite es mañana, pero te encuentras en esta situación:

el gerente de proyecto está parado sobre tu hombro y te presiona para que finalmente construyas

Esta puede ser la excepción, por lo tanto, no realice cambios drásticos en su proceso solo porque un error se deslizó. Lo que debe hacer es poner algunas medidas en su lugar, para que no esté haciendo compilaciones en el último minuto. Con suerte, estás haciendo compilaciones con una frecuencia lo suficientemente regular como para darte la confianza de que tendrá éxito. Eso todavía no es una razón suficiente para ejecutarlos en el último minuto. Tener las cosas bien probadas es otra pieza para aumentar la confianza.

Presente este escenario a quien lidere esta cosa.

• Determine qué tipos de problemas deben presentarse.
• Identifica las opciones.
• ¿Quién toma la decisión?
• ¿Cuándo debería decidirse todo esto? Probablemente va a ser relativo a la fecha de lanzamiento.

Aunque esto no responde qué hacer con este problema de último minuto, sí ofrece una manera de asegurarse de que pueda lidiar con ellos en el futuro. Especialmente cuando hay presión para liberar, desea tener una manera de manejar las cosas de una manera pensada y no impulsada por las emociones.

Si hay una fecha límite, y su gerente está justo detrás de usted, mirando por encima del hombro, le dice que se vaya. Él se va o tú te vas. Explíquele que al verse obligado a revisar bajo presión, es muy posible que no revise el código.

En una situación como esta, puede estar seguro de que pasará algún error crítico.

Es posible que se encuentre en una situación afortunada, como enviarlo a la App Store de Apple, donde tiene unos días para retractarse de una nueva versión. Pero si su código se envía a los clientes, esa es una receta para el desastre. La próxima vez espero que tu gerente planifique mejor.

Otras respuestas se centran en el problema de que su gerente intente doblegar su proceso de calidad.

Sin embargo, lo que creo que está preguntando es cómo lidiar con el hecho de que la revisión del código requiere al menos 2 personas y, por lo tanto, presenta retrasos significativos. Por ejemplo, si una tarea tarda 2 horas en implementarse y 2 horas en revisarse, a menudo hay una larga pausa entre las dos actividades. En tiempo real, la tarea puede tardar 2 o 3 días en completarse.

Este es un problema clásico de rendimiento vs latencia. En las máquinas productoras de software (seres humanos), los cambios de contexto son caros, por lo que evitar el trabajo de alguien para hacer una revisión inmediata no debería ser una práctica común.

Aquí hay algunos consejos para mitigar el problema:

• Mientras trabaja en una tarea, envíe código en partes pequeñas, de modo que el revisor no tenga que reservar largos períodos de tiempo continuos.
• Promueva una cultura de alta prioridad para las revisiones de código. No dejes tu unidad de trabajo actual cuando recibas una solicitud, pero cuando te preguntes qué hacer a continuación, elige siempre una reseña de tu lista.
• Aproveche la diferencia de zona horaria en sus equipos, si hay una.
• No comprometa a una sola persona a revisar solo el código. Es contrproductivo. No podrá manejar la carga, si va a tomar en serio su tarea. Su gerente no aceptará la idea de que alguien esté inactivo, solo para potencialmente ahorrar un día.