Hace unos años, cuando trabajaba en otro país, en desarrollo software para telecomunicaciones, ocurrió algo que nuca olvidaré, y para ello además el destino me ayuda recordándomelo frecuentemente, haciendo que la situación se haya seguido repitiendo en mi vida, en varias ocasiones.
Sin perderme en detalles, la historia comienza por un clásico, un macro desarrollo software, con un montón de gente, con una fecha tope para salir a producción (navidad para más detalles) y que, dicho de manera fina, “no era estable”, dicho para que todos lo entendamos… tenía tantas incidencias y bugs que no había manera de salir a producción.
Como en tantas ocasiones, la “gestión de proyectos dirigida por fuerza bruta” se impuso a la maña, al pararse a pensar y al conocer bien la especial y particular condición de la gestión software. Y alguien pensó que la solución era otro clásico: el equipo en paralelo.
El equipo en paralelo es una estrategia utilizada desde que el mundo tiene memoria para proponer una solución que suena bien a situaciones desesperadas. Suele verse en macro desarrollos cargados de problemas y con presupuesto. La aparentemente solución, con aparente “mucho sentido”, es montar un grupo de personas dedicadas exclusivamente a resolver el principal problema: las incidencias que impiden salir a producción sin que los clientes nos fusilen a críticas.
Así sucedió en aquella ocasión, se creó el equipo en paralelo.
Ese grupo de hombres y mueres, los elegidos, a lo peli de Armageddon, aquellos que van a liberar a la humanidad del siniestro asteroide del bugs que se aproxima para aniquilarnos a todos.
En general, siempre os digo que el añadir gente a un equipo, en sus diferentes formas y expresiones (añadir gente a desarrollo, añadir testers a mansalva, añadir un equipo en paralelo, añadir comerciales porque no vendemos, etc.), suele ser el síntoma más evidente de que algo va acabar mal. No siempre añadir gente es un error, pero hacerlo sin estructura previa (que se dice rápido pero es donde está la clave, no quiero alargar el post pero montar un equipo en paralelo sin un 8 en el Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software, es un suicidio), que es lo usual, suele terminar mal.
Y en este caso así fue. Mientras el equipo de desarrollo de siempre trabajaba a destajo añadiendo funcionalidad, el de corrección de bugs trabajaba con una lista de bugs que daba sentido a su vida, obviamente, lista que había sido priorizada por diversos medios casi esotéricos para determinar qué era bloqueante y qué no.
Normalmente, casi todo era bloqueante, porque con tantos gerentes metidos en el desarrollo, en una situación los más opuesta a las prácticas bajo lo que llamamos Product Owner (aquí te dejo algunas de esas prácticas), todos pidiendo a la vez, nadie quería que lo suyo fuese menos que lo de el de al lado.
Pero lo peor no era eso, no. Cuando se dan este tipo de circunstancias, grandes retrasos, grandes equipos y jerarquías, pocas estimaciones fiables, muchos bugs, es lógico que otros, menos obvios para quien toma las decisiones, también brillen por su ausencia y me refiero a, entre otros: buena estrategia de control de versiones, correcta política de integración, de pruebas, de entornos, de ciclos de vida, de calidad en los fuentes, diseños, etc.
No me quiero extender mucho el post, pero si quieres más detalle, situación de un cero en el Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software.
Así, lo que le pasó al pobre equipo Armageddon era que mientras solucionaban un bug aquí… resulta que ese código fuente en que hacían la corrección, ese fichero, había quedado obsoleto y ese trozo de código no se usaba o era totalmente diferente.
Lo que le pasó al pobre equipo Armageddon era que cuando iba con sus modificaciones, a integrarlas en el nuevo desarrollo… aquello era un infierno, no había tiempo, era difícil saber qué añadir y donde, por lo que la integración se dejaba para el final, para no quitar tiempo a desarrollo y luego, cuando llegaba, medio trabajo del equipo Armageddon había que tirarlo.
Lo que le pasó al pobre equipo Armageddon era que no tenía donde hacer testing, o donde testear una versión fiable con funcionalidad actualizada y que se pareciera más o menos a la que se suponía iba a pasar a producción… por lo por cada bug que solucionaban se generaban 10 nuevos. Era una situación similar a aquello que te contaba de pruebas en cascada, pero peor porque no había iteraciones.
Así, resumidamente y por no extenderme. Un cero en el Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software
Conclusión, meter caos en el caos es igual a caos por 3. Al estilo de déjate de probar (o de diseñar, refactorizar, etc.) y ponte a programar, que no tenemos tiempo
En esto del desarrollo software buscarse atajos obvios para quien decide, pero que se saltan las bases de cómo se gestiona un desarrollo software… nunca ha funcionado. Aunque se venda bien en los powerpoint.
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
No habían leído el mito del hombre mes? 🙂 ya estaría publicado, no?
En ocaciones el equipo queda permanente y se genera el área de incidencias. Fabuloso no?