Aplicando Agil en el Desarrollo de la Aplicación

El mes pasado publiqué:

El Armado Agil de una Aplicación

describiendo algo del proyecto que está desarrollando mi equipo, usando iteraciones semanales, y un Scrum-like, con iteration backlog, reuniones diarias con compromisos y avances, revisión de iteración, etc.. Como es un proyecto privado, no puedo comentar detalles de la aplicación. Pero puedo seguir escribiendo sobre algunos avances y descubrimientos de las últimas semanas.

Primero, el núcleo de lo que estamos desarrollando, lo podemos llamar X. Es un sistema a consumir, no directamente, sino por otros sistemas. En vez de desarrollarlo completamente, lo que estamos haciendo es encarar los casos de uso. Por ejemplo, en la penúltima semana construimos una aplicación A, símil de otra existente en la empresa contratante. Es una aplicación con interfaz web para usuarios, que consume los servicios básicos de X:

A –> X

Luego, en esta última semana, pusimos a prueba algunos conceptos de seguridad de X, que fueron aplicados exitosamente en la aplicación A. Además, hicimos una variante nueva de A, digamos A1, que tiene algunas características adicionales que no existen en la aplicación real en uso. Eso sirvió para que el “product owner” vea que X es lo suficientemente poderoso y flexible para lo que queremos hacer, AUN SIN ESTAR totalmente definido e implementado. Todo esto gracias a algo que comenté en el post anterior: NOS CONCENTRAMOS EN LOS CASOS DE USO, en vez de ir pensando e implementando en detalle TODO X. De hecho, el dominio de X, y los de A, siguen estando en memoria, y no hemos tenido que definir tablas, bases de datos, blob storage, todos artefactos que todavía no necesitamos (igual tenemos el código preparado para tener ese tipo de persistencia, y ya lo hemos probado en los casos simples).

En la reunión de revisión de iteración de ayer, surgieron dos temas, que me parecen que son hitos en este proyecto.

Uno, ha ido emergiendo qué es la “esencia” de X, los servicios fundamentales de este “engine” a ser consumidor por aplicaciones. Por ejemplo, visitamos aplicaciones reales de otras empresas, y VIMOS que podríamos reimplementar lo que brindan usando el “engine” X por debajo. Para eso poner a prueba eso, ya tenemos los casos A, A1, de aplicaciones reales implementadas parcialmente.

Otro, es también interesante, aunque no tan relacionado tanto con el “engine” X. El “product owner” planteó que lo que más le sumaría valor, para las próximas iteraciones, sería implementar B, una aplicación que refleje un proceso ya existente en la empresa, pero que se maneja semi-informalmente en planillas Excel (jeje… todos tenemos esto en nuestro karma ;-). Esta vez, la idea es llegar más allá de una simple implementación A. Ahora queremos armar un B que se ponga en uso real. El PO eligió este caso, guiado por el valor que gana: implementar totalmente A sobre X, no agrega tanto valor, porque YA HAY una aplicación preexistente, funcionando, del tipo A. En cambio, la aplicación B va a implementar algo que no existe todavía como aplicación en la empresa.

Pero ahí apareció algo nuevo, en la discusión: la necesidad de tener una aplicación C, que facilite el trabajo de los usuarios. Todo nació de una frase tipo “Tim necesita … “. Y ese fue el “key point”: al analizar QUE necesitaba, y POR QUE, pudimos llegar a comprender cuál es el problema a resolver, más allá del tema puntual de planillas Excel y proceso. Y ahí apareció cómo los usuarios podrían usar lo que estamos haciendo, de una forma MAS ORIENTADA a lo que necesitan. Lo que quedó claro ayer, es que podemos usar una metáfora (disculpen de nuevo, no hay mucho detalle a mostrar) que nos va a guiar en las siguientes iteraciones, al implementar la funcionalidad de B y de C. Iremos probando su efectividad, viendo qué funciona y qué no, en el uso de los usuarios.

Y quiero destacar: esto no surgió solamente de un equipo “iluminado” que dice “hay que ir por acá”, o que dijo “hay que usar la tecnología tal y cual, porque tiene las características … “. Tampoco fue “bajada de línea” del cliente. Surgió de la interacción con sinergia del PO, y del centrarse en los casos de uso y problemas a resolver.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 2752, 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *