Desarrollo ágil. ¿Qué necesitamos?

Seguir aprendiendo es la mejor forma de poder seguir enseñando y motivar a otros a aprender. Luego de muchos días sin escribir en el blog, vuelvo renovado después de haber visitado la hermosa ciudad de Bogotá. No, no fue un viaje de placer. Fui a participar de un taller de desarrollo ágil, con lo cual buscaba adquirir nuevos conocimientos y compartir con personas con otra cultura y experiencia laboral. Fue todo un reto, pero puedo decir que fue mucho más enriquecedor de lo que esperaba.

Fueron tres días realmente intensos. Veinticuatro horas en las que los participantes no tuvimos mucho tiempo para conocernos e integrarnos, pero lo logramos finalmente gracias a nuestras habilidades comunicativas y a un excelente trabajo en equipo, con los que conseguimos sacar un producto valioso para nuestro P.O.  El taller consistió en lo siguiente: repasar ciertas prácticas de Extreme Programming (XP) y Test Driven Develpment (TDD), aprender un nuevo lenguaje de programación (aprender a un nivel muy básico), y finalmente construir un sistema (un juego realmente) aplicando todas estas prácticas.

Y esta gran experiencia me ha hecho reflexionar sobre lo que pasa regularmente en los equipos de desarrollo: código deficiente, redundante, difícil de mantener, deuda técnica, en otras atrocidades. Me lo confirmaron mis compañeros de trabajo mientras pasaban las horas. Y a pesar de confesarme sobre estos hallazgos en sus carreras, dieron cuenta de lo difícil que a veces puede ser meterse en el terreno oscuro de modificar código antiguo y ajeno (sobretodo).

Pero más allá de la reflexión lógica sobre los inconvenientes en el desarrollo, quiero exponer cómo es que, frente a ello, las prácticas ágiles están a la espera de ser tomadas en cuenta para facilitar las cosas.

Entonces vale preguntarse ¿Qué es desarrollo ágil?

En términos simples, no es más que aplicar las diversas prácticas ágiles, mayormente aquellas propuestas por XP y TDD, a los cuales se suma ATDD y claro, el marco de trabajo Scrum. De acuerdo, no es tan simple como suena, pero realmente he podido comprobar que conforme pasa el tiempo, es posible adoptar las técnicas a tal punto de no querer despegarte de ellas.

Algunos de los participantes, incluso, ya aplicaban Scrum y XP, sin embargo, se dieron con la grata sorpresa de que había varias prácticas que aún les falta adoptar e incluso se dieron cuenta de que quizás no estaban aplicando la agilidad de una forma adecuada, sobre todo TDD y ATDD.

¿Para qué nos sirve Scrum, XP y TDD juntos? ¿Funciona la relación?

Funciona, sí y muy bien. TDD es una técnica que nos permite construir código a partir de las pruebas unitarios, siempre pensando en hacer el mínimo código posible, y preguntándonos luego y a cada instante “estamos orgullosos de ese código”? Al mismo tiempo, tenemos a nuestra pareja de programación al lado (técnica de pair programming) el cual nos ayuda a ver cosas que no vemos, refactorizar mejor y a no adelantarnos por cosas que aún no aportan valor.

Y si pensaban que pair programming era solo tener una persona al lado que les diga a cada instante lo que está mal, pues se equivocaron. Es una técnica que nos debe ayudar a generar propiedad compartida. Es decir, todo el código debe ser propiedad de todos y, por ende, debe ser conocido por todos.

En el proceso de construcción, lo ideal es rotar continuamente. Recuerden que trabajamos en parejas, pero el código necesita ser tocado por todos para lo cual es necesaria la rotación incluso entre parejas. Obviamente, se debe mantener el estándar (y no hablo de estándar de programación sino del estándar del equipo), lo ideal es que no se note que un código y otro han sido tocado por dos personas distintas.  Para esto el equipo tendrá que pasar por un proceso normal de conocimiento, tanto a nivel de personalidades como de código, un proceso en el que la transparencia hará su trabajo: no habrá código oculto.

Entonces, programamos en parejas, rotamos continuamente (XP), partimos de las pruebas unitarias (TDD), pero ¿qué pasa con las Historias de Usuario y sus criterios de aceptación? Para eso existe ATDD (Acceptance Test Drive Development) con lo cual empezaremos a construir software desde las pruebas de aceptación. Es decir, partiendo desde el diseño de la vista que da la “cara” al cliente.

Cuando partimos de las pruebas de aceptación, desarrollamos pensando en hacer el mínimo código posible para generar el éxito de un criterio de aceptación. A partir de ello, comenzamos a refactorizar y en la mayoría de los casos, ingresamos al terreno de TDD para construir las otras capas internas del software (ya sea capa lógica o controlador)

Bajo ese enfoque, nos aseguramos que estamos construyendo un producto de calidad (porque cumplimos con los criterios de aceptación) y con las técnicas ya mencionadas propias de XP, nos aseguramos de la calidad del software

Y, ¿Scrum?

Scrum enmarca todo el proceso de desarrollo. De inicio a fin. Primero, la planificación del sprint nos permite identificar las historias o ítems que se van a desarrollar. Luego, mediante las reuniones diarias, sincronizamos las tareas realizadas e identificamos inconvenientes. Asimismo, estamos en constante coordinación con el P.O. para asegurarnos que vamos por buen camino. Luego, antes de finalizar el sprint, nos preguntamos si hay algo que refinar en las historias que vienen en el segundo sprint, eso se define en conjunto con el P.O. Finalmente, revisamos las funcionalidades desarrolladas antes de finalizar el tiempo asignado al sprint para recibir la retroalimentación del P.O. y se generen observaciones que impliquen nuevos ítems que atender en el siguiente sprint.

Es posible, que los primeros sprints, incluso los primeros proyectos nos sea difícil lograr la madurez del equipo, sin embargo, se requiere del coraje (muy mentado en XP) para poder insistir en ello y así, trabajar de forma ágil.

Finalmente, no quería terminar el post sin hacer una recomendación: si tienen la oportunidad de salir de la zona en la que se encuentren y conocer personas de otras regiones, háganlo sin duda. Tendrán una experiencia muy valiosa que los motivará y, por que no, los desafiará a llevar lo aprendido a sus centros de trabajo.

Please follow and like us:
0

Leave a comment

Hey, so you decided to leave a comment! That's great. Just fill in the required fields and hit submit. Note that your comment will need to be reviewed before its published.