Por qué siempre digo que la gestión de versiones es imprescindible. Una experiencia real ilustrativa

No suena tan “cool”, ni tal ágil, ni tan data, ni tan cloud, ni tan lean. Pero siempre lo repetiré: no existe un proyecto software sobre que funcione mínimamente bien (en lo que refiere a calidad, productividad y tranquilidad) sin una buena gestión de la configuración y control de versiones.
Es decir, y sin perdernos en definiciones, que si no controlas correctamente los cambios que se realizan en los productos del ciclo de vida, el cómo varias personas trabajan a la vez sobre, por ejemplo, los mismos fuentes, como gestionar diferentes versiones del mismo producto en producción en diferentes clientes, cómo una vez solucionado un cambio en una versión se replica el parche en el resto versiones para no arrastrar errores, etc. Si no tienes una estrategia para lo anterior, acabaras, como poco, duplicando el número de personas del equipo (euros) o perderás el control del software (euros).
Experiencias reales terroríficas te podría contar decenas (perdida de fuentes, bugs reparados que vuelven a aparecer, programadores que no pueden trabajar mientras los tester prueban, etc.) porque me he encontrado casi de todo, y supongo que aún me queda por ver. Pero por no entristecerte mucho la mañana, te voy a dejar sólo una…
Recuerdo que hace ya muchos años “me invitaron” a revisar la calidad del desarrollo de un proyecto. El responsable del departamento quería que le diera mi opinión, ya que a él le parecía que el equipo era poco productivo, vamos que había demasiada gente para el trabajo que se hacía, y que se le estaban disparando los costes de mantenimiento del producto software que desarrollaban.
Como en “toda casa de vecino”

, había muchas cosas que se podían mejorar, pero lo que más me llamó la atención era un grupo de gente llamado el “equipo de replicación”. Y siempre que aparecen equipos transversales con nombres poco claros… algo raro pasa.
Resulta que el famoso equipo de replicación hacía lo siguiente: llegaba un bug, desarrollo lo solucionaba en una versión del software que había igual a la que tenía en producción el cliente que reporto el error… y una vez solucionado el bug el equipo de replicación se encargaba de buscar «a mano» y corregir ese mismo bug en más de veinte versiones software, que supuestamente eran igual a la anterior, pero que estaban en repositorios separados, había un repositorio separado por cliente, pero teniendo todos el mismo producto software.
En vez de una rama principal, y ramas para versiones, estabilización, “merges”, etc., había realmente más de 20 versiones en más de 20 repositorios diferentes.
Así claro que se necesitaba un equipo de repicación. Porque no se desarrollaba un producto con varias versiones… se mantenían más de 20.
Por si te interesa saber cómo terminó la historia, al final, con tanto lío, realmente las múltiples versiones ya no eran muy iguales, porque la mitad de bugs no se replicaban por tiempo, y tampoco se conocían las diferencias entre ellas, lo que se juntó con que era inviable el coste de «replicación».
La empresa se quedó sin dinero, se prescindió de las personas del equipo de replicación, se dejó de “replicar”, y se asumió que de por vida habría que mantener muchos productos (euros), ahora diferentes, pero a la vez similares.
Por esto, y por muchas otras historias que cuando tenga tiempo escribiré a modo “mis memorias” en post, siempre digo que la gestión de la configuración y el control de versiones son imprescindibles. Si yo pudiera, metería en cada una de las Universidades, en cada escuela de informática, una asignatura obligatoria sólo de gestión de la configuración.
No hay excusa, hay expertos en el tema, hay decenas de libros (te recomiendo encarecidamente leer el que para mí es el mejor libro sobre el tema, el Configuration Patterns de Berczuk y Appleton) que cuentan cómo gestionar como Dios manda las versiones, hay patrones, el área es madura, hay herramientas, las hay de software libre, y hasta una de las mejores herramientas es española (Plastic SCM, la de los amigos de Codice).

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023