Erase una vez un proyecto… ¡ágil!
Como en la mayoría de los proyectos nuestros compañeros comerciales nos solicitaron una propuesta para cubrir las necesidades de software de un cliente. Creemos que para tener éxito en un desarrollo, hay que tener historias de usuario lo más pequeñas posibles, estar todo el equipo comprometido con el proyecto y colaborar con el cliente.
Para no tener historias épicas hicimos un inception con el equipo comercial para que todos tuviéramos la misma visión. Todo el equipo colaboró en la creación de las historias de usuario para posteriormente estimarlas. La participación de todo el equipo en este punto del proyecto no solo sirvió para conocer más y mejor el trabajo a realizar, también ayudó a que todos estuviésemos comprometidos con el proyecto y con la estimación realizada. Alcanzar el objetivo de cada iteración con una tecnología en la que no teníamos toda la experiencia deseable era todo un reto.
Para evitar desviaciones durante el desarrollo realizamos al inicio varias pruebas de concepto (spikes, conocidos cariñosamente en el equipo como bobby’s). Esta decisión resultó ser clave para no tener desviaciones en el proyecto permitiéndonos iniciar el desarrollo con varios problemas técnicos detectados y solucionados.
Para estrechar la colaboración con el cliente antes de iniciar el desarrollo del proyecto todo el equipo visitó sus instalaciones. Sirvió para que nos conociéramos personalmente, escuchar su visión del negocio y saber lo que esperaba recibir. Por nuestra parte le explicamos nuestra forma de trabajar con entregas continuas y la flexibilidad del agilismo para ir adaptándonos a las necesidades reales.
Durante todo el proyecto hemos hecho especial hincapié en el cumplimiento de las planificaciones de los sprints, terminando las funcionalidades a las que nos habíamos comprometido en cada iteración. Las planificaciones de cada sprint se han basado siempre en estimaciones realistas, incluyendo tanto como realmente creíamos que podíamos terminar.
Desde el primer día apostamos por la calidad y aunque al principio podía parecer que el desarrollo tardaba más de lo esperado, las iteraciones se iban completando tal como las habíamos planificado. Optamos tanto por técnicas de extreme programming (integración continua, TDD y pair programming -solo en las historias iniciales y aquellas que tenían cierta dificultad-) como por técnicas de rendimiento personal como pomodoros. Al inicio de cada historia nos juntábamos todo el equipo en una pequeña reunión técnica para que la solución fuese conocida, consensuada e integrada. El definition of done (definición de producto terminado) no solo fue estricto en la parte funcional. Técnicamente tendría que cumplir con 0% de errores de checkStyle y PMD, una cobertura del 95% del código y manual técnico siempre que fuese necesario. Nuestra apuesta firme por la calidad ha dado como resultado la reducción de deuda técnica en cada entrega, evitando así el lastre inicial de una iteración y consiguiendo a la larga mayor velocidad gracias a la consolidación técnica del proyecto.
Casi al final del proyecto se incorporó un miembro nuevo al equipo, reconvertido a java desde otra tecnología. Gracias a las medidas adoptadas fue productivo desde el inicio.
El ir afinando las buenas prácticas nos ha ayudado a conseguir un proyecto rentable aplicando técnicas y metodologías ágiles. Las decisiones adoptadas han sido fruto de retrospectivas donde evaluábamos los resultados conseguidos en cada sprint.
Y como siempre se dice, una imagen vale más que mil palabras:
Velocidad absoluta
- La barra azul representa los puntos de producto terminado
- La barra roja las horas de kanban positivo
- La barra amarilla las horas de kanban negativo (en los sprints iniciales teníamos incidencias de otro proyecto)
Relación entre los puntos planificados y puntos finalizados al final de cada sprint
Porcentaje de puntos pendientes de finalizar al final de cada sprint
Nunca cedimos en calidad, negociamos alcance para un marco de tiempo determinado.
