Una Guía Rápida para Implementar ATDD

Este artículo proporciona una guía rápida para cualquier persona interesada en implementar ATDD en sus equipos y proyectos. Describe los beneficios de seguir este enfoque ágil basándome en mi experiencia de primera mano en un equipo de desarrollo de software corporativo.

La colaboración es uno de los valores fundamentales de la metodología ágil. Una vez, mientras trabajaba en un gran proyecto, me di cuenta de la falta de colaboración entre los desarrolladores, los probadores y las personas con mentalidad empresarial; la falta de claridad en los requisitos; la frecuente ampliación del alcance de los requisitos; la falta de visibilidad con respecto a las pruebas realizadas; y los defectos que se identificaban tarde en el ciclo de vida del proyecto. Sin embargo, lo más importante para mí era que nadie tenía ni idea de nuestro marco de trabajo de automatización, por lo que todas las pruebas de automatización se escribían después de que las características estuvieran desarrolladas y listas para ser probadas. Debido a estas observaciones, empecé a investigar cómo la gente aborda este tipo de problemas. Como resultado, encontré el Desarrollo Dirigido por Pruebas de Aceptación (ATDD) como uno de los enfoques utilizados para mitigar muchos de estos problemas. A menudo se utiliza como sinónimo de Desarrollo Dirigido por el Comportamiento (BDD), Desarrollo Dirigido por Pruebas de Historias (SDD) y Especificación por Ejemplo (SBE). La principal distinción de ATDD, a diferencia de otros enfoques ágiles, es su enfoque en hacer que los desarrolladores, los probadores, la gente de negocios, los propietarios del producto y otras partes interesadas colaboren como una unidad y creen una comprensión clara de lo que necesita ser implementado.

Basado en mi propia experiencia, voy a compartir mis ideas sobre cómo los equipos pueden implementar ATDD en sus propios proyectos.

El Contexto

Trabajé en una gran empresa que tenía una mentalidad de startup, por lo que cualquier idea innovadora y los comentarios fueron alentados por el equipo. Construimos rápidamente prototipos para ver si una idea mejoraría nuestro producto o ayudaría en los objetivos generales de la empresa. Yo era el probador principal de un equipo de 25 miembros, formado por un maestro de scrum, un jefe técnico y varios analistas de negocio, diseñadores, desarrolladores y probadores. Como resultado de la cultura de la innovación, a menudo había caos dentro del equipo, incluyendo cambios frecuentes en los requisitos de las características, los individuos que trabajan en entornos de silos, y la moral del equipo que está en su punto más bajo. Esto me preocupaba, así que me ofrecí para ayudar a encontrar una solución a estos puntos de dolor, lo que me llevó a ATDD.

Todos mis aprendizajes y experiencias con ATDD se pueden clasificar en los siguientes 3 pasos.

El ciclo de implementación de ATDD

Creado por Raj Subramanian

Paso 1 – Formación y experimentación

Hay muchas maneras de abordar las tareas, especialmente cuando se consideran las experiencias de los individuos que trabajan en diferentes equipos ágiles dentro y fuera de sus organizaciones actuales. Con el fin de aportar una comprensión compartida y común de los objetivos del equipo y de la organización, es importante proporcionar la formación adecuada. En lo que respecta a ATDD específicamente, debe incluir las metas, los objetivos, las expectativas y la información sobre los resultados que se obtendrán al utilizar este enfoque. Después de la formación, es importante comenzar con una implementación a pequeña escala para probar diferentes cosas y recibir una retroalimentación iterativa.

Por ejemplo, después de investigar el ATDD, expliqué a las diferentes partes interesadas por qué necesitábamos explorar este enfoque y qué beneficios recibiríamos de él. Destaqué algunos de los posibles aspectos positivos, como el aumento de la colaboración del equipo, una mejor clarificación de los requisitos, una identificación más temprana de los defectos dentro del ciclo de vida del desarrollo de software (SDLC), una mayor visibilidad y un uso más temprano de la automatización en el SDLC, así como la participación de todo el equipo en la elaboración de criterios de aceptación claros.

Durante mi discusión con las partes interesadas, hice hincapié en que esto requeriría cierta experimentación, pero sin probarlo, nunca podríamos conocer sus beneficios. Tras unas largas discusiones, decidimos dividir el equipo original de 25 personas en dos equipos más pequeños: El equipo A estaba formado por 12 personas, y aplicaría el ATDD. El equipo B tenía las 13 personas restantes, y seguiría haciendo lo que ya estaba haciendo.

Planifiqué un taller de formación de 2 días para el equipo A aprendiendo sobre ATDD, determinando qué conceptos tenían sentido en el contexto de nuestro proyecto, y cómo podíamos aprovechar la automatización en todo este proceso. Incluí una mezcla de ejercicios teóricos y prácticos en la formación. Algunos de los ejercicios son los siguientes:

• Cómo escribir declaraciones Gherkin – Given/When/Then (GWT)
• ¿Cuáles son los atributos clave de una buena historia de usuario?
• Una demostración de nuestro marco de automatización, incluyendo tanto cómo funcionaba como cómo estaba estructurado. También hubo ejercicios sobre cómo escribir en equipo un código de prueba de automatización sencillo. Antes del taller, un miembro del equipo y yo modificamos nuestro marco de automatización para que estuviera en sintonía con el enfoque ATDD. Utilizamos el plugin Cucumber con Java y Appium para nuestro marco de automatización.

Fuente

Paso 2 – Aumentar la visibilidad

Cuando un proyecto vive varios sprints, es fácil perder la pista de los diferentes procesos que hay que seguir. Así que la clave es hacer que las metas, los objetivos y las expectativas sean visibles para todo el equipo.

Cuando empezamos a utilizar ATDD, empecé simplemente escribiendo cada uno de los procesos diarios que habría que seguir en una pizarra, que coloqué donde nuestro equipo tenía sus reuniones diarias. En cada historia de usuario añadí una lista de comprobación de los elementos que debían realizarse antes de que la historia se considerara completa. De esta manera, no había ninguna ambigüedad sobre los procesos de ATDD que debían seguirse. Uno de estos elementos de la lista de comprobación era una reunión inicial, durante la cual el desarrollador, el probador y la gente de negocios discutían los requisitos como equipo, identificaban qué requisitos podían ser automatizados y esbozaban los criterios de aceptación de la historia en formato GWT. Otro elemento de la lista de comprobación era el traspaso QA-Dev, en el que el desarrollador mostraba al probador, mediante una demostración rápida o un debate, cómo se habían completado los requisitos y qué pruebas unitarias se habían escrito como parte de la historia. A través de este traspaso, el evaluador aprendió qué áreas no estaban cubiertas por las pruebas unitarias y desarrolló una mejor comprensión de la característica implementada, lo que condujo a una mejor cobertura de las pruebas. Los elementos de la lista de comprobación son a veces obvios, pero es bueno tenerlos claros. Incluimos uno para asegurar que todos los defectos asociados a la historia se cerraban; otro era la aprobación final por parte de una persona del negocio al ver una demostración, asegurando que la característica se construía de acuerdo con los requisitos y expectativas previamente establecidos.

También empezamos a tener un «Halcón de Procesos». Se trataba de un miembro individual del equipo; podía ser un maestro de scrum, un director de proyecto o cualquiera que se asegurara de que el equipo siguiera el proceso. En mi caso, era otro tester senior dentro del equipo; él y yo recordábamos regularmente a todos que siguieran el proceso ATDD en todas las reuniones, incluyendo el standup, la planificación, la retrospectiva y otras reuniones del equipo.

Paso 3- Aprendizaje iterativo y retroalimentación

Tener un bucle de retroalimentación constante es crucial en la implementación de cualquier enfoque ágil, incluyendo ATDD. Tener reuniones retrospectivas semanales o quincenales con todo el equipo es una forma importante de saber qué partes del proceso están realmente beneficiando al equipo, y cuáles pueden necesitar ser modificadas. Como ya sabemos, algo que no ayuda al equipo hace que se pierda tiempo y esfuerzo. Como afirma Brian Tracy, autor de Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time, «Uno de los peores usos del tiempo es hacer muy bien algo que no es necesario hacer en absoluto»

En la era actual de la tecnología de la información, las organizaciones no pueden permitirse el lujo de perder tiempo y energía en enfoques ineficaces; más bien, necesitamos que se apliquen procesos ajustados y eficaces. Esto se relaciona con el principio de aprendizaje validado de las lean startups: el ciclo Construir, Medir, Aprender.

Con esto en mente, empecé a tener reuniones de 30 minutos todos los jueves con el equipo A para comprobar cómo le iba al equipo con el nuevo proceso. Esta era una buena manera de medir los cambios que había que hacer en función de las reacciones del equipo. Esta reunión se celebraba por separado de la reunión retrospectiva que tenía lugar al final de los sprints de dos semanas. Este enfoque aportó una retroalimentación continua del equipo, lo que nos permitió hacer cambios inmediatos y efectivos. La retroalimentación no provenía únicamente de las revisiones semanales del proceso; las reuniones diarias de puesta en marcha también resultaron ser una valiosa fuente de información. Las actualizaciones y discusiones individuales de los miembros del equipo descubrieron banderas rojas relacionadas con el proceso, y pudimos abordarlas inmediatamente antes de que afectaran al resto del equipo.

Resumen

Como resultado de seguir el ciclo de implementación de ATDD, el equipo A comenzó a ver diferencias considerables en la moral del equipo, la colaboración y los requisitos.

Moral del equipo

Todos comenzaron a trabajar como un equipo y se sintieron capacitados. Cada persona era dueña de una historia de principio a fin. Se aseguraba de que la historia tuviera toda la información necesaria para iniciar el trabajo de desarrollo y pruebas. El miembro del equipo también se aseguraba de que se hicieran todos los seguimientos relacionados con la historia. Por último, la persona se encargaba de mostrar la historia a todos los interesados al final del sprint. Este sentimiento de propiedad aumentó significativamente la moral del equipo.

Colaboración

Las reuniones de inicio reunieron a la persona de negocios, el desarrollador y el probador, con el fin de desarrollar una comprensión común de la historia de usuario. El traspaso QA-Dev, que tuvo lugar antes de enviar la compilación a los servidores QA, ayudó al desarrollador y al probador a saber qué pruebas se completarían como parte de la historia, y aportó una mejor comprensión de la función implementada. Hubo una mayor visibilidad en la automatización, ya que todo el equipo se hizo cargo, en lugar de sólo los probadores. Por último, en las reuniones de planificación, todo el equipo discutió la historia conjuntamente, generando así más ideas, preguntas y debates. El aumento de la colaboración también condujo a un mayor aprendizaje: el equipo decidió celebrar sesiones de coaching entre pares para aprender unos de otros, los probadores empezaron a realizar pruebas exploratorias por parejas y diferentes miembros del equipo organizaron sesiones de almuerzo-aprendizaje para debatir diversos temas relacionados con la tecnología. Todas estas cosas llevaron a mejorar la colaboración general del equipo.

Requisitos

Uno de los principales problemas de nuestros procesos anteriores eran los frecuentes cambios en los requisitos y el aumento del alcance. Con el enfoque ATDD, era imperativo que una vez que el desarrollador comenzara a trabajar en una historia, los requisitos quedaran bloqueados. Cualquier cambio debía priorizarse junto a las demás historias próximas y añadirse a los siguientes sprints. Esto redujo la carga de trabajo tanto de los desarrolladores como de los probadores, y evitó que las partes interesadas tuvieran expectativas poco realistas de las características completadas.

Después de ver todas las mejoras anteriores, el equipo B comenzó a implementar ATDD también. Como resultado, todo el equipo original utilizó este enfoque después de la experimentación regular y la retroalimentación.

Conclusión

Recomiendo el enfoque de ATDD, y se alinea con el «Paradigma del Cambio a la Izquierda» que establece que el desarrollo y las pruebas deben comenzar tan pronto como sea posible en el SDLC. Aportó más visibilidad a la automatización, ya que empezamos a escribir pruebas automatizadas al principio del SDLC, lo que a su vez aumentó la colaboración dentro del equipo.

Fuente

Recuerda, ATDD no es una solución de «talla única». Era el enfoque ágil que tenía más sentido en el contexto de mi proyecto, pero hay varias otras formas de mejorar los procesos en los equipos. Utilicé este enfoque porque se centra en mejores pruebas de aceptación, pero sobre todo por su énfasis en la colaboración. La pieza de colaboración es una parte integral de este enfoque, y creo que es la más valiosa.

Acerca del autor

Raj Subrameyer es un estratega de carreras tecnológicas que se centra en ayudar a las personas a conseguir el trabajo de sus sueños y a convertirse en líderes de éxito. Le apasiona guiar a los profesionales para que maximicen sus oportunidades y descubran su zona de genialidad. Utiliza su experiencia en la industria tecnológica para investigar, hablar y escribir sobre cómo podemos adoptar la tecnología y convertirnos en ciudadanos digitales de pleno derecho. Es un ponente muy solicitado en varias conferencias y ha aparecido en numerosos podcasts y publicaciones, como CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success y The Good Men Project. También es el autor del nuevo libro «Skyrocket Your Career». Sus áreas de especialización incluyen la promoción profesional, el liderazgo, la motivación, la productividad y el espíritu empresarial. En su tiempo libre, le gusta viajar y disfrutar de la cerveza artesanal. Puedes encontrar más información sobre cómo sirve a la gente a través de su página web.