Hay quien sigue la regla de que si en un proceso de desarrollo algo te “hace daño o te molesta hacerlo”… hazlo con mayor frecuencia. Y el mayor ejemplo de algo que “hace daño o te molesta hacerlo” y que deberías hacer con frecuencia es la integración.
Te aseguro que el tema de las “integraciones pesadilla” es algo que me he encontrado en la mayoría de las empresas que he visto. A nadie le gusta integrar, todo el mundo lo deja para el final y al final la integración es una bomba.
Si no tienes muy claro de qué hablo te lo intentaré resumir en unas líneas: el equipo A (o la persona A) desarrolla software que debe integrarse, o que hace uso, etc., del software que va desarrollando el equipo B (o la persona B), pero A y B no ponen en común lo que van desarrollando hasta el último día, muchos meses después, cuando ya es necesario unirlo para entregarlo, lo que hace que la unión de lo que hizo A con lo que hizo B sea muy compleja (bomba).
Si A y B hubiesen unido, integrado, el trabajo que van haciendo cada día, o cada poco tiempo, los posibles problemas de esa unión, integración, serían mucho menores y de mucho más fácil solución.
No mires para otro lado la integración, si sabes que es un dolor… integra mucho, con mucha frecuencia, te ayudará por muchas razones:
– Detectarás problemas pronto, que siendo pequeños es fácil solucionar y que cuando crecen son una pesadilla.
– Comprobarás en qué estado de verdad está el proyecto, quitándote el susto para la última semana.
– Aumentará la interacción entre los miembros del equipo
Además, muchas veces, al intentar integrar frecuentemente se acaba detectando un problema tan antiguo como el propio software, tan antiguo como poco valorado… problemas en la gestión de las versiones y la gestión de configuración, acuérdate de aquello que te contaba de que por qué siempre digo que la gestión de versiones es imprescindible. Una experiencia real ilustrativa.
Igualmente, este típico y claro caso de lo que “hace daño o te molesta hacerlo” hazlo con mayor frecuencia puedes extrapolarlo a otros, como el testing, limpiar el código, juntarte con el usuario, etc.
Recuerda, integra mucho, lo más frecuentemente posible.
Este, el caso de la integración, junto con las pruebas (recuerda eso de no se puede ser ágil si se prueba en cascada), junto con el por qué siempre digo que la gestión de versiones es imprescindible. Una experiencia real ilustrativa y son ejemplos empíricos de cómo está un equipo de desarrollo, a añadir al El Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software
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.
- 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