Alberto Gutierrez lleva varios años trabajando con Ágil, y llegó a la conclusión que hay varios principios dando vueltas que son sólo palabrerío que apuntan a convencer a la gerencia, y que en realidad no ayudan al desarrollo de la aplicación.
A continuación repasamos una lista de los mitos más frecuencias en el mundo Ágil.
1. Las historias son mejores cuando usan tal o cual convención para crearlas
¿Alguna vez tuvieron una discusión sobre la mejor convención para usar al momento de nombrar una historia? ¿O pasaron horas y horas tratando de dividir al backlog en historias que sigan tal o cual criterio? ¿O quizás pasaron semanas decidiendo cuál sería la mejor aplicación para almacenarlas?
Lo curioso sobre las historias es que, cuando hay un problema de comunicación en el equipo, las historias se llevan la culpa: no son lo suficientemente claras, el criterio de aceptación no era bueno, el color de las tarjetas no ayudaba...
Las historias son invitaciones para generar discusiones entre el equipo de desarrollo, la gerencia, QA y el cliente. Son para eso. Lo que se necesita es asegurarnos que todos los involucrados las entiendan y mantengan una discusión abierta.
Cuando la comunicación no funciona el problema es del equipo, y la solución en general no pasa por mejorar las historias, sino por mejorar la comunicación.
2. La planificación ágil es divertida y precisa
Verdad: la planificación en el desarrollo de software no es precisa. Podemos usar días, horas, puntos, jugar al poker o al blackjack, no va a funcionar, y si funciona es coincidencia. Entonces, ¿deberíamos dejar de planificar?... mmm... no creo que los gerentes se sientan muy contentos con eso.
La planificación agrega valor, nos dice el alcance de la tarea: ¿estamos hablando de horas, de días o de semanas? Y nos ayuda a determinar el porcentaje de terminado de la aplicación. También sirve para establecer las expectativas de la gerencia.
Ágil hace un buen trabajo en establecer las expectativas correctas. Con Ágil el cliente tiene legitimidad para esperar recibir la mejor solución posible en una fecha dada, pero Ágil no nos dice cuándo vamos a terminar, aunque probablemente sea más preciso que Cascada.
3. Reunión de parado diaria, la panacea de la comunicación
Aunque algunos equipos ágiles parezcan pensarlo, las reuniones de parado no sustituyen la comunicación en el equipo; el enfoque "lo tratamos en la reunión de parado de mañana" no sirve.
Las reuniones de parado están bien, sirven para brindar una vistazo general del día anterior y del día actual, y eso es todo lo que hacen. La comunicación es muy importante en el desarrollo de software y no puede limitarse a una discusión matutina de 10 minutos.
4. Ágil es el proceso que sirve para todo
Ágil no es la bala de plata. Seguramente sea una de las oraciones más repetidas en los entornos ágiles de trabajo; y sin embargo muchas de estas personas se compartan como si lo fuera.
Aplicar los principios ágiles a ciegas no sólo está mal, sino que lleva a situaciones ridículas, como nunca documentar el código, nunca crear documentación o nunca crear aunque sea el más mínimo diseño inicial.
El desarrollo de software es un tema complejo que necesita distintos enfoques que dependen de las circunstancias; a veces puede que funcione mejor un enfoque en cascada o vice versa, y la mayor parte del tiempo lo que mejor se adapte sea una mezcla de enfoques.
5. Las retrospectivas arreglan todo
Esperar hasta la retrospectiva para tratar un tema es una mala práctica, además de ser bastante inocente creer que solucionaremos el problema por el sólo hecho de hacerlo visible. Los problemas que se levantan en las retrospectivas suelen ser impedimentos serios, y se los dejamos a la gerencia para que los resuelva más tarde... lo cual suele ser nunca.
En estos años llegué a la conclusión que eliminar impedimentos o mejorar el proceso suele ser el trabajo de individuos. Los "desarrolladores héroes" hacen mucha diferencia en el desarrollo de software.
Estos desarrolladores son quienes se cansan de no usar bien un SCM o no tener una suite automatizada de pruebas... deciden ser héroes y arreglar las cosas en sus propios términos.
6. Las pruebas unitarias en todo lo que necesitamos
Hay una tendencia a pensar que lo único que necesitamos son las pruebas unitarias. Pero el tema es que los problemas más grandes siempre están en los puntos de integración de la aplicación, y eso es algo que las pruebas unitarias no señalarán. Las pruebas unitarias son muy importantes, tienen mucho valor para hacer refactors y para ayudarnos a diseñar el código, pero recordemos que igualmente necesitaremos integrar el software, de punta a punta, por lo que necesitamos usar otros tipos de pruebas para garantizar la calidad del producto.
7. Ágil es un proceso apto para desarrolladores junior
Respuesta corta: No, Ágil no es un proceso apto para desarrolladores junior. Ágil cambia la responsabilidad principal del desarrollo de unos pocos a todos en el equipo.
Todos son responsables por mantener la calidad de la aplicación, y si le pedimos esto a alguien sin experiencia vamos a comprarnos problemas.
