Tiempo de vídeo: 16 minutos, 53 segundos.
Cuando empiezas a rascar un poco en el mundo de los frameworks ágiles, te encuentras con que esto del Agile no es una moda nueva, ni tampoco algo pasajero, si no una forma de ver el desarrollo de software que se aparta de la concepción típica de «proyecto en cascada» donde no pasamos a la siguiente fase hasta no haber completado la anterior… vamos, como si estuviésemos levantando una casa, por poner un ejemplo.
Cuando vamos a construir una casa, lo primero son los cimientos pensarás, pero antes de los cimientos tienes que tener el plano de arquitectura y para ello, tienes que tener antes los requisitos cerrados de cómo va a ser la casa y no cambiarlos… Aquí te pegas de bruces con la primera pega y no es otra que la de que en desarrollo de software, ¿cuándo tienes los requisitos cerrados?
Asumiendo esto, el planteamiento de proyecto debe ser diferente, debe ser un «proyecto ágil» y aquí es donde entra la interpretación errónea de #agilidad. Cuando empiezas a contarle al equipo de desarrollo todo lo que hay que hacer dentro de un sprint, siempre hay quien te dice: «pero es que hacer todo esto… ¡no es ágil!» y lo cierto es que si lo ves así, ¡claro que no es ágil!
Es como si te piden que bajes a la calle desde un cuarto piso y te tiras por la ventana… Esa forma de bajar es ágil si, pero… ¿cómo llegas al suelo?
El concepto de agilidad se enfoca en hacer entregas de funcionalidad operativas (importante el detalle de que sean operativas) en un tiempo más o menos breve.
Tenemos que dejar a un lado la concepción de «proyecto en cascada» en el que vamos a necesitar varios meses para poder entregar una primera versión de la aplicación. ¿Cuántas cosas pueden cambiar en esos meses? Las necesidades del usuario pueden ser diferentes y probablemente lo serán.
Situaciones así acaban degenerando en lo que, en el vídeo que os dejo al final de este post, llaman «proyecto zombi». Proyectos que no se mueren nunca y que se comen todo lo que se cruza en su camino (equipos, presupuestos, paciencias…).
Hacer una entrega funcional en poco tiempo implica eso, que tiene que funcionar. No tiene por qué tener toda la funcionalidad que nos han pedido, pero si entregar algo con lo que nuestro cliente pueda empezar a trabajar, a ver, a trastear, a usar…
Ya sabemos lo que cuesta tener una idea clara de cómo queremos que sea nuestra aplicación hasta que no la tenemos delante y no empezamos a trabajar con ella, no es fácil que aquellas personas que van a darle uso tengan claro lo que verdaderamente necesitan, pues vamos a darles algo con lo que puedan empezar a trabajar y sobre lo que nos vayan diciendo cómo evolucionarlo.
Una entrega que funcione tiene que haber sido probada, obviamente. Hacer pruebas no te garantiza al 100% que la funcionalidad sea perfecta, pero si que estamos poniendo una red bajo el alambre de funambulista al que nos hemos subido, así que si las dejamos para el final, es bastante probable que nos hayamos comido el tiempo con otras tareas y al final, las pruebas, las haremos deprisa y mal (en el mejor de los casos).
Tener un equipo al margen del de desarrollo, encargado de hacer las pruebas no es la mejor forma de incorporar esta funcionalidad en el ciclo ágil, ya que debemos conseguir integrarlas dentro de la operativa del equipo, como una tarea más dentro de las propias de la evolución de nuestro proyecto.
Si intentamos sacar las tareas de testing de las habituales dentro del sprint, va a suponer una inversión mayor de tiempo, ya que si los que prueban no están inmersos en el desarrollo, ¿cómo obtienen el conocimiento de negocio necesario para poder probar lo que otro equipo está desarrollando? Requeriría definir más los requisitos, elaborar documentación más detallada, definir mejor los criterios de aceptación… esas cosas que tanto cuestan hacer en un proyecto en cascada, sobre todo tiempo que al final no tienes.
Bueno, ya está bien de reflexiones, por este post al menos. Te dejo con el vídeo, no tiene desperdicio…
