Como identificar cuando un reboot puede ser beneficioso en el desarrollo de software

reboot

reboot

En todo momento debe haber una arquitectura conocida por todo el equipo y unos principios que se persiguen con dicha arquitectura.

Algunos ejemplos de principios podrían ser: elementos gráficos autocontenidos capaces de pintarse a sí mismos, pantallas que contienen componentes  que se comunican entre sí mediante un único mecanismo acordado, etcétera.

Estos principios pueden violarse a veces sin que signifique que la arquitectura ha dejado de servir. Pero si el equipo no respeta estos principios a menudo, quizás hacen falta nuevos principios. Un buen indicador de que este momento ha llegado es la vergüenza del desarrollador: si dejamos de sentirnos culpables por violar estas normas, aunque las consecuencias negativas sean patentes, es que estas normas ya no sirven.

Cuando se llegue a este punto, el equipo técnico debería celebrar una reunión para revisar la arquitectura. Cualquier miembro del equipo debería poder proponer esta reunión si piensa que se dan las condiciones para ello. El tema, sin duda, surgirá en mil conversaciones informales entre los programadores. Pero si hay que establecer un momento oficial para proponer la reunión, una Retrospectiva al final del Sprint puede ser un buen momento. Todo el equipo técnico estará presente, y en ese mismo momento puede decir si tiene sentido o no.

No se debe discutir en ese momento si el reboot se debe realizar o no, sólo si merece la pena revisar y discutir la cuestión.

Si la propuesta recibe suficiente apoyo (repetimos, no el reboot, sino la reunión para revisar la arquitectura), se programará una reunión de unas dos horas a tal efecto a la que asistirá únicamente el equipo técnico.

En esta reunión debería decidirse únicamente desde el punto de vista técnico si el código necesita el reboot. Deberían responderse preguntas como las siguientes:

Si el software sigue teniendo una arquitectura reconocible y seguida por todos.

Si los módulos están adecuadamente desacoplados, según criterios compartidos por el equipo.

Si es posible dividir el trabajo en el equipo sin que sus miembros se estorben unos a otros.

Si, en general, es cómodo y agradable trabajar en el código.

Si las respuestas son negativas, hay que decidir si puede solucionarse el problema con refactorizaciones sucesivas o por el contrario el código no tiene salvación. También debe analizarse si el problema se encuentra en la totalidad o sólo en parte del software.

Al finalizar la reunión, debería haber una propuesta para solucionar los problemas detectados. Habiendo llegado a este punto, el resultado de esta reunión nunca debería ser que no hay que hacer nada.

Hay que recalcar que sólo se deben discutir cuestiones técnicas, sin tener en cuenta cuestiones como la duración del proyecto, los plazos para tal o cual entrega, o si en un futuro entrarán más o menos características nuevas.

Estas son cuestiones más relacionadas con la gestión del proyecto, y deben discutirse posteriormente junto con el jefe de proyecto.