Cuando se habla de metodologías ágiles y quizás porque en el fondo somos programadores y no gestores, siempre se habla de cosas como la reunión diaria, las entregas frecuentes, los tableros Scrum, los test automáticos, etc, etc. Sin embargo, hay otro punto realmente importante y del que no se suele hablar, la intervención directa del cliente a lo largo de todo el proceso.
Afortunadamente, he tenido oportunidad de practicar con este último punto y ahí va la experiencia. Pongámonos primero en contexto
El proyecto es un proyecto pequeño para lo que estamos acostumbrados, un solo desarrollador, yo mismo, durante algo más de seis meses y con la suerte de poder dedicarme al 100% al proyecto (cosas de la crisis, no hay demasiado trabajo). Hay también un jefe de proyecto, pero su única gestión es básicamente el tema económico y alguna reunión o charla esporádica con los "jefes" del cliente. El proyecto es un proyecto Web, en el que sólo hay software implicado, el servidor está desde el principio en las instalaciones del cliente, con su dominio público en internet y al que tengo acceso de administración con una VPN (red privada virtual)
En este contexto, tengo contacto diario y directo, por teléfono y email, con los usuarios finales del proyecto, los que van a estar usando esa web día a día, así que pensé que es una situación ideal para metodologías ágiles. Al ser yo el único desarrollador y estar el cliente en otra ciudad a más de 400 km de distancia, todo eso de las "demos" y reuniones al estilo Scrum no me parecía adecuado, así que opté por una opción más al estilo Kanban. Me di de alta en https://kanbanflow.com , hice un tablero con cuatro columnas : to-do, in-progress, verification y done, copié los requisitos iniciales en la columna to-do y le mostré el tablero a los clientes, así como una explicación del funcionamiento general de Kanban y metodologías ágiles, en lo que a ellos les afecta. Les pareció una idea estupenda y es lo que estamos usando.
Ellos ordenaron y matienen ordenada la columna de "to-do", además de añadir más tareas cuando les viene en gana, en el orden en que quieren que se desarrolle. Yo siempre saco la primera tarea de arriba del todo y la muevo a la columna "in-progress", teniendo como máximo 3 tareas simultáneas en desarrollo. Cuando termino de probarla en mi entorno de pruebas y la subo al servidor, la muevo a "en verficacion" y ellos, tras probarla, la mueven a "done" o la devuelven a la primera columna con más cosas que quieren o bugs que han encontrado. En fin, nada que no sepamos ya del funcionamiento de un tablero Kanban.
¿Y cuales son las consecuencias de todo esto?. Pues bien, como nada es blanco ni negro, hay cosas buenas y otras no tan buenas. Empecemos con las primeras.
Lo mejor de todo es que el cliente está encantado. No es solo que me lo digan cuando les pregunto, es también el "feedback" que me da nuestro jefe de proyecto cuando habla con ellos o lo que yo mismo oigo a los clientes hablar entre ellos cuando nos hemos reunido cara a cara.
Lo primero que les gusta, por supuesto, es que el producto, aparte de no tener grandes fallos, cumple exactamente lo que necesitan, como no puede ser de otra forma, puesto que los mismos usuarios finales lo ven evolucionar día a día y deciden sobre lo que se debe hacer y cómo. Y lo segundo que les encanta es la excelente gestión de sus peticiones (mérito de un mecanismo como Kanban), ellos tienen total control sobre lo que piden y cuándo se aborda, así como total visibilidad de lo que se está haciendo y lo que tarda en hacerse. Ninguna de sus tareas lleva un tiempo estimado de más de 3 ó 4 días, pero la mayoría son de 1 ó 2 días, por lo que ven progresos de forma continua. Si alguna tarea lleva mucho más, hablo con ellos y tratamos de partirla, creando una tarea más pequeña con lo que realmente es importante para ellos y otras con lo menos importante y que puedan poner más abajo en la lista.
Y ahora viene la parte no tan buena. Aunque se deja claro al principio que pueden añadir, modificar y ordenar tareas a su gusto, también se deja claro que el proyecto tiene una fecha de terminación y que toda modificación que hagan o tarea que añadan, no debería afectar a esa fecha, sino simplemente hacer más probable, si no seguro, que las tareas al final de la columna to-do se queden sin hacer. Esto, por supuesto es algo que no les gusta oir. Pero eso no es lo peor, porque la ventaja de controlar el desarrollo día a día les convence frente a la posibilidad de que alguna tarea poco importante para ellos se quede sin hacer y de alguna forma, lo aceptan. Lo peor es que en el día a día se "emocionan" con las tareas que se van realizando y tienden a no acabarse nunca. Cuando terminas una tarea y ellos la prueban, se les ocurren mejoras que inmediamente hacen que la tarea vuelva a la columna "to-do", con añadidos para hacer y, normalmente, al principio para que se aborde inmediatamente. Hay que estar continuamente pidiéndoles verificación, como sutil indirecta de que nos estamos eternizando en los detalles, de si están seguros que ese nuevo añadido es más prioritario que las siguientes tareas en la lista.
Hay otro detalle, no sé si bueno o malo, y es el "pequeño estrés" que causa este método al desarrollador (yo). Al ver ellos el progreso día a día y ser tareas de tan poco tiempo estimado (1, 2, 3 días), "canta" mucho si un día me distraigo con cualquier cosa. Si tengo alguna reunión ajena al proyecto, si acabo de volver de vacaciones y tengo el típico día perezoso que te pasas "güeveando" en internet o con el email … Se ve agravado por el hecho de que para tener mejor visibilidad de cómo va el proyecto, llevamos un pequeño excel compartido que se actualiza todos los Viernes, en él aparecen las tareas, el tiempo que yo estimo para cada una de ellas en días y sumando esos días, la fecha prevista de terminación de cada una de ellas … y por tanto la fecha prevista de terminación del proyecto si se hacen todas las tareas. Si una tarea se complica más de lo previsto, ya me causa un pequeño "estrés" actualizar el excel y ver cómo la fecha de finalización se va alargando a la vista de todos. Pero me causa mucho más "estrés" si encima ese retraso va causado por la típica pereza que todos tenemos algún día que otro.
Puedo asegurar que nunca he trabajado tanto y tan seguido como en este proyecto, en parte por el "estrés" que me causa perder el tiempo, en parte por tener en todo momento perfectamente claro qué es lo que tengo que hacer y cómo. Ojo, no he echado ni una sola hora de más, es simplemente que apenas pierdo el tiempo a lo largo del horario laboral tratando de que el flujo de tareas de "to-do" a "done" sea lo más fluído posible.
Ahora nos estamos acercando a la fecha prevista de finalización, por supuesto, con requisitos iniciales que el cliente no ha considerado importantes al final de la lista to-do y totalmente fuera de plazo, pero con otros requisitos que han añadido sobre la marcha y que han considerado más importantes hechos a su gusto, con el cliente bastante contento en general. Veremos qué tal va el cierre final ….