Cuándo hacer la Revisión de Código

Depende de la naturaleza de las historias de usuario.

Puede ser efectivo crear una rama para cada historia de usuario, el progreso en diferentes historias es visible, se puede transmitir si es necesario, si las historias no se completan en el sprint, entonces el progreso puede permanecer en la rama durante el siguiente sprint. Las revisiones finales se pueden realizar al final de una historia de usuario en la rama de uso de la historia y combinarlas si el código es estándar.

Para trabajar de la manera en que las historias deben estar finamente integradas para evitar tareas de fusión inmanejables al final de un sprint. Las historias pequeñas permitirán una actualización constante de la rama de desarrollo a través del sprint que los desarrolladores que trabajan en otras historias de usuario necesitan extraer constantemente (VCM básico).

Esto crea sobrecargas de procesos al tener que crear y fusionar sucursales constantemente, lo que en algunos casos se puede resolver con scripts de automatización, pero el equipo aún necesita sentirse muy cómodo con el VCS.

Al final de un sprint, fusionas tu rama de desarrollo en integración / producción, etc.

También he trabajado en equipos en los que todos trabajan en una rama de desarrollo, al completar una historia de usuario, el código se envía a esa rama para su revisión y prueba, y si alguien empuja algo que rompe la versión de desarrollo, tiene que obtener el equipo. cervezas en.

La forma más efectiva de revisar el código es levantarse, encontrar a alguien y pedirle que venga y discuta el código que acaba de desarrollar.

No use una herramienta a menos que no pueda encontrar a alguien que revise su código localmente.

Puedes evitar las revisiones de código por completo.

¿Todos en el equipo son locales? Si es así, solo pídale a alguien que venga y eche un vistazo antes de verificar el código. ¿No es local? Encienda su programa favorito de pantalla compartida y llame a alguien. Yo personalmente hago esto a menudo. A veces lo hago solo para decir "¡Eh, mira lo que hice!"

Prefiero este estilo de revisiones de código ad-hoc al estilo donde alguien está de pie y presentando su código al equipo. Las revisiones ad-hoc pueden proporcionarle muchos (¿todos?) Los beneficios del emparejamiento sin la incomodidad. Además, es más probable que su "revisor" haga preguntas y sugiera mejoras en un entorno informal y personal.

Creo que la revisión de código no es una parte formal de SCRUM, pero las revisiones son una táctica independiente para lograr calidad y mejorar sus proyectos / equipo.

Por lo tanto, usaría SCRUM (u otra metodología de desarrollo ágil) para garantizar / mejorar la calidad del PROYECTO y mantener el calendario. Además, una buena táctica es hacer la revisión del producto (no el código) de forma independiente de sus tareas de control de calidad / pruebas normales. Si esta actividad se puede hacer frente a su equipo / socios / clientes / audiencia, será mejor.

Debe usar revisiones de código (u otras) específicas principalmente para mejorar su EQUIPO, esperando resultados a medio / largo plazo. Esto afectará sus PROYECTOS, pero a largo plazo como producto de la mejora de su EQUIPO.

Entonces, para responder a tu pregunta, creo que estás tratando de presionar demasiado de SCRUM, y deberías considerar las revisiones solo como están.

¿No es obvio hacer revisiones de código antes de registrar su código?

TFS no funciona como GIT, por lo que cada vez que marque el código en una rama o troncal, estará disponible para todos.

Esto significa que la revisión debe realizarse en el momento del registro, para que los cambios erróneos no se propaguen a la copia de trabajo de todos.