Esta situación puede provocar múltiples reacciones según quién la escuche. Si no has vivido mínimo un par de ellas, te genera ilusión, el vislumbrar el fin de un trabajo de varios meses probablemente y el momento más ansiado: la entrega del regalo empaquetado al cliente y abrir la botella de cava.
Si eres el jefe de proyecto y ya te han salido algunas canas, más bien te produce temor. Sabes que por mucho que analices, prepares y le eches huevos, el cabrón de Murphy siempre, siempre, está al acecho.
Vamos a intentar sumar para mejorar estas situaciones:
Situación tradicional
Vamos a listar algunas de las habituales cosas que suceden porque, desengañémonos, la primera reacción que provoca una salida a Live es: pánico en la audiencia:
- El cliente habitualmente se dedica las 2 últimas semanas (con especial foco en los 2 últimos días) a modificar y cuestionar todo, porque es cuando realmente lo revisa.
- Los de arquitectura maldicen en arameo cualquier intento de tocar las máquinas para cualquier despliegue o cambio de última hora, con lo que les ha costado estabilizarlas.
- Aumenta dramáticamente la necesidad de reportar y comunicar en todas las direcciones (a usuarios, a gestores, a dirección, al equipo…) y tú necesitas la info y por tanto haces lo propio con tu equipo, que ya está suficientemente estresado como para que los agobies.
- “Vosotros dijisteis que…” “Nunca me avisaste de…” Todo el mundo intenta ponerse a la defensiva.
- El “alcance flexible”: son las 2 semanas dónde con tanta revisión y nuevos actores que aparecen habitualmente al final nos llenamos de sugerencias, cambios, evolutivos y “necesidadesimperiosasquenoentiendoquenohayastenidopresente”…
Una salida a Live es sinónimo de noches de pizza en la oficina, de tensa espera en cada acción que realizas (no sea que estropee otra que ya ha pasado por QA) y una fantástica fuente de aparición de nuevas peticiones.
¿Por qué AGILE minimiza estos problemas?
La construcción iterativa y el testing continuado en cada entrega minimizan y anticipan los problemas mencionados antes. ¡NO DESAPARECEN! LOS ANTICIPA.
Además el perseguir que cada entrega o incremento sea probable de forma independiente, en vez de entregar o declarar simplemente un % de avance sobre una tarea, anticipa imprevistos y facilita las pruebas de integración.
Durante las demos que deben hacerse con los usuarios finales (o como mínimo con el Product Owner) ya se va contrastando la funcionalidad y el producto y su alineación con los requerimientos y necesidades planteadas por ellos, con lo que evitas las sorpresas finales.
¿Y si te cambian el alcance? ¡Pues se cambia! porque de eso se trata: de permitir y adaptarnos al cambio “incluso en etapas tardías del desarrollo” (obviamente si el cambio es justificado y aumenta significativamente el valor que aporta tu solución al negocio). Y diréis: ¿y esto es una ventaja? Pues es una condición indispensable que debemos aceptar y entender, pero Agile y sus metodologías como Scrum por ejemplo, disponen de todos los mecanismos necesarios para anticipar estas situaciones al máximo.
Y no os olvidéis que probablemente si usáis Agile no habrá solamente una salida a Live sino varias con lo que diluyes los riesgos en el tiempo y los acometes paso a paso.
¿Si apuestas hoy por Agile, echas a perder tu experiencia previa?
Indudablemente NO. Puedes aplicar los mismos principios pero en cada uno de los sprints. Agile no hace magia, sino que facilita tu labor y maximiza las probabilidades de acierto. En Scrum, por ejemplo, en cada sprint pasas por las mismas etapas que en un proyecto completo waterfall pero compactado en cada sprint. Por tanto, las lecciones aprendidas años atrás en un modelo más clásico o secuencial SÍ TE SERVIRÁN. Y con facilidad las extenderás.
Como decía al principio: “si ya tienes algunas canas” coincidirás conmigo en los siguientes consejos en términos generales. Te propongo que las leas y constates que son plenamente aplicables en cada uno de los sprints:
- Realiza pruebas de integración (no sólo unitarias) y de regresión
- Prepara con antelación una lista de tareas previas a los despliegues y conviértelas en historias de usuario técnicas para poder planificarlas en los sprints.
- Estabiliza cuanto antes la arquitectura (la piedra en el zapato de cualquier salida a Live)
- Realiza pruebas de rendimiento e interpreta bien los resultados. No escondas las conclusiones a nadie y prioriza tareas relativas a corregir datos insuficientes, no los dejes para el final.
- Automatiza todo lo posible tanto en pruebas como en despliegues (con una buena política de rollbacks)
- Deja muy claras las condiciones de aceptación de cada historia (requerimiento) para facilitar no solamente su validación sino para que los equipos se orienten a ello (buena práctica XP: Test-Driven-Development o desarrollo orientado a pruebas)
Todo esto sumado a la experiencia que te hace prever algunos problemas habituales, (o al menos mitigarlos) te garantiza que la salida a live será exitosa probablemente puesto que ya la has preparado y simulado con suficiente antelación.
¡Os invito a añadir tantos tips o consejos como consideréis!
Not Wasted Time 