Cómo planificar el calendario de un lanzamiento de software en Gantt
Planifica el tramo desde la última funcionalidad hasta producción: la congelación del código como hito, pruebas en paralelo, su unión antes de la aprobación y la ruta crítica para ver qué fija la fecha del lanzamiento.
Las fechas de lanzamiento suelen anunciarse antes de que exista el plan de pruebas. Esta guía muestra cómo convertir el tramo entre la congelación y producción en un cronograma que puedes comparar con la fecha que te han dado.
En resumen
- Convierte la congelación del código en un hito de duración cero que todas las tareas de desarrollo deben alcanzar.
- Inicia desde la congelación las líneas de pruebas, las notas de la versión y el manual de operaciones, para que corran en paralelo.
- Une todas las líneas en una tarea antes de la aprobación, y condiciona el despliegue a la aprobación y a los documentos.
- Planifica como tareas los días posteriores al despliegue: una prueba de humo, un anuncio y una ventana de seguimiento.
- Activa la ruta crítica para ver qué línea fija la fecha y compara la fecha de fin con la que necesitas.
Planificar el tramo posterior a la última funcionalidad
Un plan de lanzamiento es corto pero denso. Diecisiete tareas caben en un mes aproximadamente, y la mayoría dependen de otras dos o tres. Por eso una lista plana falla aquí: dice lo que tiene que ocurrir, pero no que las pruebas de aceptación pueden empezar dos días después de la congelación mientras las de regresión no pueden acabar antes de ella, ni que el manual de operaciones debe estar listo el día en que empieza el despliegue y no el día en que terminan las pruebas.
El método consiste en planificar en cuatro movimientos. Primero, convierte la congelación en un hito que todo lo anterior debe alcanzar. Segundo, inicia las líneas de pruebas desde la congelación y deja que la documentación empiece también ahí. Tercero, une las líneas en una sola tarea antes de la aprobación, para que esta no pueda aparecer antes de tiempo. Cuarto, da al despliegue sus puertas y planifica los días posteriores como tareas reales. Las fechas se calculan entonces a partir de las duraciones y los vínculos, y comparas la fecha de fin con la que necesitas en lugar de escribirla de antemano.
Un cronograma no hace seguro un lanzamiento. Muestra cuándo debería terminar el trabajo si cada estimación se cumple, y no detectará una prueba que falte ni una marcha atrás sin probar. Guarda los resultados de las pruebas, las aprobaciones y la lista de defectos en los sistemas que los contienen. El diagrama planifica el orden y el tiempo, y no se conecta a un repositorio, a un gestor de incidencias ni a una herramienta de despliegue.
El ejemplo es la plantilla de lanzamiento de software, en /es/templates/plantilla-diagrama-de-gantt-de-lanzamiento-de-software. Si necesitas el proceso y sus decisiones en lugar del cronograma, consulta los diagramas de flujo en /es/templates/proceso-de-release-de-software y /es/templates/proceso-de-despliegue-de-software. Para un desarrollo completo, de los requisitos al lanzamiento, usa /es/templates/plantilla-diagrama-de-gantt-de-proyecto-de-software.
Un calendario de lanzamiento, construido por etapas
Diecisiete tareas en cuatro grupos. Las duraciones son días laborables orientativos; fija las tuyas. Abre el panel de la hoja de cálculo para ver las filas de cada etapa.
El desarrollo termina con un hito
«Terminar las funcionalidades pendientes» dura 10 días laborables. «Corregir defectos conocidos» (6 días) empieza 5 días laborables después de que empiece aquella, un vínculo de inicio a inicio con desfase, así que la corrección de defectos se solapa con el final del desarrollo. «Funcionalidad completa» es un hito de duración 0.
La congelación y tres líneas de pruebas
La «Congelación del código» es un hito. Las «Pruebas de regresión» (5 días), los «Controles de rendimiento y seguridad» (4) y las «Pruebas de aceptación de usuario» (6) la siguen, y las pruebas de aceptación empiezan 2 días laborables después de la congelación. «Corregir bloqueos de la versión» (3 días) espera a las tres.
Preparación y puertas del despliegue
«Redactar las notas de la versión» y «Actualizar el manual de operaciones y el plan de marcha atrás» (3 días cada una) empiezan en la congelación, no después de las pruebas. «Desplegar en producción» (1 día) espera a la «Aprobación de la versión», a las notas y al manual. La «Prueba de humo en producción» lo sigue.
Los días posteriores al despliegue
«Anunciar la versión» (1 día) y «Seguimiento y gestión de incidencias iniciales» (5 días) esperan ambas a la prueba de humo, así que van en paralelo. La «Retrospectiva de la versión» es la última tarea, un día para decidir qué debe cambiar el próximo plan.
Cómo funciona
Enumera las tareas entre la última funcionalidad y la primera persona usuaria
Escribe todas las tareas que deben terminar antes y después de producción, incluidos los documentos y el plan de marcha atrás. Da a cada una una duración en días laborables. Solo días enteros, así que redondea hacia arriba una tarea de medio día.
Fija la congelación como un hito
Añade una tarea de duración 0 para la congelación. Haz que dependa de las tareas de desarrollo, y que las líneas de pruebas, las notas de la versión y el manual dependan de ella.
Solapa lo que pueda solaparse
Usa un vínculo de inicio a inicio con desfase donde el trabajo empiece a mitad de otra tarea, por ejemplo 4SS+2 en Depende de. Úsalo para corregir defectos durante el desarrollo y para unas pruebas de aceptación que empiezan unos días después de la congelación.
Une las líneas antes de la aprobación
Da a la tarea posterior a las pruebas una dependencia de cada línea, escrita como lista separada por comas. La aprobación no puede entonces ser anterior a la línea más lenta.
Condiciona el despliegue y planifica los días posteriores
Haz que el despliegue dependa de la aprobación y de los documentos. Añade como tareas una prueba de humo, el anuncio y una ventana de seguimiento, para que el tiempo de soporte forme parte del plan.
Comprueba la ruta crítica frente a tu fecha
Abre el menú Ver y activa la ruta crítica. Compara la fecha de fin con la que necesitas. Si la fecha es fija, cambia la cadena que la determina, porque acortar otras tareas no la moverá.
Errores que debes evitar
Escribir los documentos después de las pruebas
Unas notas de la versión y un plan de marcha atrás redactados tras las pruebas suman su duración al final del plan. Empiézalos en la congelación y haz que el despliegue los espere para que no se omitan bajo presión.
Una aprobación sin unión
Si la aprobación depende de una sola línea de pruebas, el diagrama muestra una fecha que las demás líneas quizá no cumplan. Vincúlala, directamente o mediante una tarea de corrección, a todas las líneas.
Olvidar los días posteriores al despliegue
Un plan que acaba en el despliegue oculta el seguimiento y las correcciones que vienen después. Mantén una ventana de seguimiento en el diagrama, aunque su duración sea una suposición.
Fijar la fecha de lanzamiento como un inicio
Un Inicio fijo en la tarea de despliegue no hace que el trabajo anterior encaje. Si la fecha calculada es posterior a la fijada, el diagrama marca el conflicto. Interprétalo como el mensaje de que la fecha no puede cumplirse con estas estimaciones.
Abre el diagrama de Gantt de lanzamiento de software
Abre la plantilla de lanzamiento, cambia las duraciones por las tuyas y comprueba qué línea de pruebas fija la fecha.
Guías relacionadas
Preguntas frecuentes
¿Cuánto debe durar un calendario de lanzamiento?
Lo que tarde en tu equipo el trabajo entre la congelación y producción. Las duraciones de la plantilla son orientativas. Sustitúyelas por lo que tardaron tus últimos lanzamientos e incluye los días posteriores al despliegue.
¿La congelación debe ser una tarea o un hito?
Un hito, que es una tarea de duración 0 y se dibuja como un rombo. Marca el punto que todo lo anterior debe alcanzar, y las líneas de pruebas se vinculan a él.
¿Puedo ver qué línea de pruebas fija la fecha del lanzamiento?
Sí. Activa la ruta crítica en el menú Ver. Ilumina la cadena de tareas que fija el final, y al seleccionar una tarea se ilumina de qué depende y qué depende de ella.
¿Sirve para correcciones urgentes?
Una corrección urgente es un diagrama corto: corregir, probar, aprobar, desplegar, prueba de humo. Duplica un diagrama de lanzamiento, quita lo que no necesites y conserva las puertas.
¿Dónde está el proceso de lanzamiento en sí?
En las plantillas de diagrama de flujo, que dibujan las decisiones y aprobaciones: /es/templates/proceso-de-release-de-software y /es/templates/proceso-de-despliegue-de-software. Usa el diagrama de Gantt para saber cuánto tarda, y el diagrama de flujo para saber quién decide qué.
