Arquitectura - Mi experiencia como arquitecto de un proyecto SCRUM

Hace algún tiempo (y continuo haciéndolo), tuve la fortuna de participar como arquitecto de software en  un proyecto SCRUM. Previamente había leído algunos libros y asistido a ciertas capacitaciones. La teoría la tenía absolutamente clara, pero continuaba con un gran interrogante. ¿Cuál es el papel de un arquitecto de software en un proyecto ágil? Cada uno de los trainers con los que discutía me daba respuestas diferentes. Uno me dijo que simplemente en Scrum no existe tal cargo, que los diseños son absolutamente emergentes y parten de la decisión de cada uno de los miembros del equipo, otro me dijo que la labor del rol dentro del equipo era de apoyo y consultoría, otro simplemente me dijo que la arquitectura en ágil se presta como un servicio y no como una imposición.

Hoy después de un par de meses como practicante he llegado a una conclusión. La respuesta a esta pregunta no es importante y todos tienen razón.

Los proyectos de software realizados bajo metodología RUP tienen roles claramente identificados, con responsabilidades muy claras, delimitadas en el sentido más estricto. Esta es la forma como había trabajado hasta el momento y era la zona de confort en la que mejor de desenvolvía. Ahora que conozco Scrum pienso que esta estructura imposibilita el trabajo en equipo y orienta a las personas a la realización de tareas y no al logro de metas. Piensen en lo siguiente. El analista de requerimientos es el encargado de levantar los requisitos con el cliente y hacer casos de uso, el arquitecto es el encargado de realizar un diseño de alto nivel que satisfagas los drivers arquitectónicos, los desarrolladores son los encargados de implementar lo que definen el analista de requerimientos y el arquitecto, el de calidad simplemente prueba, reporta errores y le daña la vida a los desarrolladores. ¿Y dónde queda el objetivo de construir un software de calidad que satisfaga las necesidades del cliente?

Alguien me dijo alguna vez. Lo importante no son los roles, ni los cargos. Lo importante es el logro de la meta, algo similar a lo que pasa en un EQUIPO de futbol. Hasta el arquero cobra tiros libres en caso de ser necesario. 

Cuando inició el proyecto en cuestión el equipo pasó varios días tratando de organizarse. Al inicio como arquitecto me encargaba de hacer pair programming de ciertas historias de usuario muy complejas, acompañar los diseños y visionar lo que venía en conjunto con el producto owner. Luego por la premura del tiempo terminé haciendo parte del equipo de desarrollo, implementando y sacando a producción varias funcionalidades. 

La velocidad del equipo era muy baja tendiente a 0. La motivación de las personas decaía y el producto owner estaba molesto, no teníamos un Scrum master asignado de modo que como equipo debíamos tratar de resolver los impedimentos y avanzar en el logro de las metas de cada sprint.

Solo hasta que todo estuvo muy mal, empezamos a mejorar. El producto owner estaba desesperado e insistió en que el equipo debía recuperarse del atraso que se tenía respecto a las historias de usuarios que se habían comprometido e incumplido en sprints anteriores. Incluso sugirió trabajar tiempo extra (Lo que por supuesto el equipo rechazó).

En una de las retrospectivas descubrimos (Entre otras cosas) que el equipo no podía avanzar en la construcción de las historias comprometidas porque en el planning no se consideraban muchas cosas que finalmente se realizaban en la implementación, esto incrementaba el esfuerzo requerido y hacía que se perdiera el foco.

Después de discutir algunas alternativas decidimos que en el sprint planning se revisaran algunas de las historias que podrían hacer parte del siguiente sprint y hacer una definición de listo (Definition of ready). Se trata de revisar que necesitamos que se encuentre completo antes de incluir una historia de usuario en un sprint. 

Como arquitecto mi labor ahora era completar todas aquellas cosas que el equipo requería para poder estimar y completar una historia de usuario. De esta manera se tenía menor incertidumbre en el planning y no se perdía tiempo en labores de configuración de ambiente, o gestiones con otras áreas de tecnología durante el sprint. También debía conversar constantemente con el owner para aclarar mucho más las historias que venían en orden de prioridad y dejar claros los criterios de aceptación de las mismas. Esto se tradujo en mayor foco y por supuesto en mayor velocidad. Ahora el owner y el sponsor se sienten un poco más tranquilos y como equipo estamos avanzando en el logro de la meta.

Como conclusión puedo decir que el nombre del cargo realmente no importa, simplemente es una persona más dentro del equipo que se preocupa al igual que todos por lograr el objetivo y durante el proceso apoya al equipo en todo lo que sea necesario para llegar a la meta (Esto incluye lo que tradicionalmente se hace en arquitectura de software, solo que con un enfoque mas servil y no como imposición que es la forma como tradicionalmente se ve).