[Update de este post, pues no, mi primer proyecto ágil no fue este, labores de arqueología en discos duros descubrieron que fue en 2001 trabajando con en una consultora que empieza por A]
Desde hace ya un tiempo, de vez en cuando, me pasaba por la cabeza la siguiente pregunta: “¿cuándo fue la primera vez que utilicé en un proyecto la gestión ágil (iterativa)?” (frente a la predictiva o cascada).
En lo “teórico” tenía más claro mi primer contacto con los ciclos iterativos y ágiles, ya que entre mis libros favoritos está una de las primeras ediciones del genial “Análisis y diseño de aplicaciones informáticas de gestión”, donde por primera vez leí (y estudié en la universidad) los ciclos en espiral, iterativos y similares (que todos ellos son la base de los ciclos ágiles). Y porque en mi estantería de libros técnicos está una primera edición del “eXtreme Programming” comprada en el año 2000.
Pero en lo profesional no lo tenía tan claro. Hasta que buscando no sé que, allá en la profundidad del disco duro, apareció. Apareció aquel Excel con el que recordaba que habíamos montado nuestra primera gestión iterativa (aunque iterativo no siempre es Ágil). Y todo volvió a mi memoria.
Aquel fue un proyecto bastante grande, que arrancó en el 2005, con una duración estimada de dos años. Su lanzamiento coincidió con que en la empresa en que trabajábamos eran bastante fans de las gigantescas planificaciones en cascada. Y con que ya estábamos cansados de ver decenas diagramas Gantt, en esta y otras empresas, que planificaban años de proyecto, que nunca se cumplían y siempre se retrasaban.
Así que aprovechamos el lanzamiento de aquel nuevo proyecto para arrancar una gestión iterativa.
En aquellos años no había tanto conocimiento, experiencias, webs, libros, y demás, sobre la gestión ágil, por lo que tomando las bases principales de la gestión iterativa fuimos creando la gestión del proyecto, e inventándonos herramientas de gestión, que con el tiempo, y sin saberlo en aquel momento, coinciden bastante con muchas de las que hoy se utilizan y cuentan en los libros.
Por ejemplo, creamos, porque nos pareció de lo más lógico, y sin haberlo leído en ningún lado, lo que hoy se conoce como “burn chart”. En la figura de abajo he dejado una de las versiones de aquel “burn chart”. Podéis ver que es un mecanismo para seguir el avance del proyecto cruzando tiempo de proyecto con el trabajo completado.
El trabajo completado del diagrama anterior lo calculábamos en función del número de casos de uso implementados al final de cada iteración. Otra cosa curiosa, ya que en ese proyecto en vez de historias de usuario (te dejo un post sobre historias de usuario) usamos casos de uso. Los casos de uso no son historias de usuario, pero, en aquellos tiempos, para nuestro caso eran más útiles los primeros, ya que nos facilitaban mucho las pruebas, la arquitectura, las interfaces gráficas, y demás. Y a efectos de gestión la cosa no varía mucho.
Otra cosa interesante es que las iteraciones, inicialmente, las planificamos de una semana, donde para cada iteración se fijaba un número de casos de uso a completar y manteníamos un “sub-objetivo” de número de casos de uso a completar por semana.
En la siguiente imagen podéis ver un momento de dicho seguimiento, correspondientes a las semanas de la 5 a la 8, donde la media de casos de uso a completar por semana en todo el proyecto era de unos 5, aunque en cada iteración podía variar el objetivo de casos de uso a completar.
En la imagen podéis ver otros cálculos como el acumulado de casos de uso completados (el Excel es un poco “cutrecillo” en lo que a formato se refiere, pero he querido dejar el original, y tanto UC como CU significa caso de uso)
De aquella experiencia aprendimos:
- Que hay que tratar con especial cuidado el introducir el ciclo de vida iterativo en organizaciones acostumbradas al cascada.
- Que cada proyecto necesita adaptar el concepto de iteración, y la agilidad (si te funcionan los casos de uso, adelante con ellos)
- Que igualmente hay que ser cuidadoso a la hora de fijar tiempo de duración de una iteración.
- La importancia de soportar todo con una robusta infraestructura técnica (pruebas unitarias, integración continua, etc.)
- Que una gestión así es altamente potente y no es comparable con la gestión en cascada, reduce riesgos y entrega un producto más cercano a las necesidades del usuario.
No me extiendo más, deseando leer experiencia similares, queda abierta la sección de comentarios…
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
Pingback: Bitacoras.com
Pingback: Una selección de post escritos en 2012 que tienes que leer antes de empezar el 2013 - Javier Garzás, sobre calidad software y otros temas relacionados
Muy interesante, Javier. Una consulta: por lo que he supuesto, lo que hicisteis fue gestión de proyectos pero con prácticas que hoy consideramos bajo el paraguas de metodologías ágiles. ¿Cómo manejasteis el tema de la calidad del software? Al fin y al cabo el jefe de proyecto tiene una fecha límite que se debe cumplir y eso significa que en muchas ocasiones se acaba penalizando la calidad del código que se entrega.
Hola José,
Medíamos calidad del producto con PMD, Checkstyle y dedicábamos x horas por iteración a refactorizar.
Saludos