3 amigo principle agile
Introduction to 3 Amigo Principle:
técnicas de prueba de caja blanca con ejemplos
Anteriormente en Scrum Series, le presentamos el concepto de traer autosuficiencia dentro de los miembros del equipo Scrum para inducir la cultura que produce valor empresarial sin necesidad de ayuda del mundo exterior.
Últimamente estuve alineado con un Proyecto de Cliente donde trabajé como Scrum Master. Habiendo trabajado en múltiples proyectos basados en Scrum, pude combinar con éxito la metodología dentro de las formas de trabajo del cliente.
Sin embargo, después de un período de tiempo particular, se encontró mucha vaguedad en torno al requisito de comprensión.
¡Cada miembro del equipo Scrum tiene su propia versión del entendimiento de los requisitos!
Lo que vas a aprender:
- Visión general
- Primera prueba de desarrollo (TFD)
- The Three Amigo Principle
- Three Amigo Process
- Conclusión
- Lectura recomendada
Visión general
¿Qué pasaría si los desarrolladores y los QA tuvieran dos perspectivas diferentes del mismo requisito?
El curso de acción obvio, en este caso, será que los Desarrolladores desarrollarían el Incremento teniendo en cuenta su perspectiva, mientras que los probadores lo probarían teniendo en cuenta su propia perspectiva.
Las dos perspectivas tienden a crear una brecha y los problemas se abordan solo hacia el final del Sprint. Un caso aún peor sería si no queda tiempo para abordar estos problemas dentro del Sprint, lo que nos lleva a una situación para agregar elementos adicionales en un Product Backlog.
Para resolver el planteamiento del problema anterior, se nos ocurrió una solución para tener más sesiones de discusión de requisitos entre los miembros del equipo para analizar y hacer una lluvia de ideas sobre los requisitos en su conjunto. Y de ahí salió a la luz la idea del Principio de los Tres Amigo.
Antes de pasar al principio de los tres amigos, analicemos primero una de las prácticas de prueba ágiles, el desarrollo de la prueba primero (TFD) y cómo se asocia con los tres amigos.
Primera prueba de desarrollo (TFD)
Como sugiere su propio nombre, Test First Development es una práctica en la que los ingenieros de pruebas escriben los casos de prueba antes de cualquier actividad de desarrollo.
Luego, estos casos de prueba se discuten y comparten con todo el equipo. Los miembros del equipo ahora entran en una reunión para discutir, mejorar y revisar los casos de prueba (también conocidos como 'Los Tres Amigos'). Los casos extremos también se agregan a la lista de casos de prueba durante esta reunión.
También podemos incluir al Propietario del producto para agregar y revisar los casos de prueba, lo que generaría la confianza de que los casos de prueba cumplen con los Criterios de aceptación.
Ahora que se han desarrollado los casos de prueba, todo el desarrollo se basaría en estos casos de prueba. Este fenómeno también se conoce como ciclo de prueba y construcción. Dentro de un ciclo de compilación de prueba, compile hasta que se pasen todos los casos de prueba, sin dejar espacio para que existan errores en el sistema.
El desarrollo de prueba primero permite a los desarrolladores crear un incremento que cumpla con los criterios de aceptación y tenga la aceptación del propietario del producto (voz del cliente).
Hoy en día, los equipos han comenzado a adoptar el enfoque y el marco de desarrollo basado en pruebas (TDD), que es el siguiente paso para el desarrollo de pruebas primero. Herramientas como Cucumber, Gauge, Specflow, etc. se encuentran entre las más populares.
The Three Amigo Principle
¿Quiénes son los tres amigos?
El principio de los tres amigos dice que los tres amigos; Los analistas de negocios, desarrolladores y analistas de calidad deben reunirse en una reunión en la que:
- El analista de negocios detalla cada uno de los requisitos comerciales con el equipo.
- Los miembros del equipo de control de calidad discuten los casos de prueba ya creados para estos requisitos comerciales.
- Los miembros del equipo de desarrollo discuten la arquitectura y el diseño de bajo nivel con el equipo.
El objetivo de la reunión de los tres amigos es cerrar las brechas en la comprensión de las especificaciones comerciales por parte de tres amigos.
El analista de negocios se asegura de que todos los miembros del equipo tengan la misma comprensión y expectativa de la historia / requisito del usuario comercial. El analista de negocios recopila los comentarios y revisa los comentarios de los miembros del equipo. También agrega la información que falta y elimina la información ambigua de la historia de usuario, si la hubiera.
Dado que la salud del software siempre se mide por sus estándares de alta calidad, el equipo de control de calidad elabora los aspectos funcionales y no funcionales del incremento del software y detalla los casos de prueba identificados para probar el Incremento. También se aseguran de que los casos de prueba cumplan con todos los Criterios de aceptación.
Los otros miembros del equipo ayudan a enriquecer los casos de prueba al encontrar casos extremos y escenarios faltantes. Los miembros del equipo de desarrollo compartirán sus conocimientos sobre las restricciones técnicas que podrían generar restricciones en las pruebas.
cuántos tipos de archivos hay python
Los desarrolladores discuten su comprensión de los requisitos y lo que se necesita para construir el Increment. También discutirían el diseño de la arquitectura y el diseño de bajo nivel con el equipo para formar un entendimiento común de lo que se va a construir.
El resultado general de la sesión de Three Amigo es que todo el equipo tiene un entendimiento común de lo que van a construir como parte del próximo sprint.
Three Amigo Process
El Proceso de los Tres Amigos constituye lo siguiente:
# 1) Participantes
Un representante del Equipo de Desarrollo y del Equipo de Garantía de Calidad cada uno y el Analista de Negocios. Se sugiere tener estos representantes, las personas que realmente van a trabajar en ese requisito para aprovechar el máximo beneficio del concepto. Otros, como arquitectos, etc., siempre son bienvenidos a unirse a la reunión y brindar su orientación.
# 2) Líneas de tiempo
La sesión de Three Amigo generalmente se lleva a cabo en N-1 Sprint. También es un evento cronometrado, es decir, no se pueden extender. El recuadro de tiempo recomendado para la sesión es de 1 hora, que también es su duración máxima.
Si la función se va a desarrollar en Sprint N. Entonces es muy recomendable realizar la sesión de Three Amigo en N-1 o N-2 Sprint.
# 3) Formato
# 1) La reunión comienza con el Analista de Negocios presentando el requisito a los asistentes junto con los documentos de diseño o wireframes. Se espera que el requisito empresarial esté bien preparado y documentado. Se espera que el equipo haya cumplido con el requisito antes de la reunión.
# 2) Como siguiente paso, los asistentes revisarán el requisito y proporcionarán comentarios que luego serán incorporados por el Analista de Negocios. Los asistentes también señalarán las ambigüedades y lagunas, si las hubiera. También se espera que el Analista de Negocios elimine las ambigüedades y llene los vacíos en el requisito.
En ocasiones, puede haber situaciones en las que el analista de negocios deba confirmar las consultas publicadas por los otros asistentes y no incorporar directamente esa revisión allí.
# 3) Una vez que el requisito está lo suficientemente preparado y los asistentes no tienen más comentarios ni preguntas abiertas, el requisito se marca como 'Listo'.
# 4) A continuación, los casos de prueba se presentan a los asistentes al igual que los requisitos. Se espera que los casos de prueba ya estén bien formados y preparados.
# 5) Los asistentes ahora revisarán los casos de prueba y proporcionarán comentarios. El miembro de QA incorporará todas las sugerencias proporcionadas. Los asistentes también señalarían los casos de prueba perdidos y los escenarios de casos extremos. El objetivo principal aquí sigue siendo que los casos de prueba deben cumplir con todos los Criterios de aceptación y tener una buena cobertura de prueba.
# 6) El siguiente paso es mirar las dependencias y los requisitos previos que podrían haber surgido durante la sesión.
preguntas de la entrevista de servicios web de descanso y jabón
# 7) Se determinan las dependencias y los elementos de acción se crean y asignan al miembro del equipo relevante. Del mismo modo, las tareas para los requisitos previos se crean y asignan.
# 8) Todos los artefactos (requisitos, casos de prueba, tareas, dependencias) mencionados anteriormente deben mantenerse en una herramienta de gestión de proyectos como JIRA para que todos puedan acceder a ellos fácilmente.
# 9) Si hay demasiados comentarios de revisión, el analista de negocios y el ingeniero de aseguramiento de la calidad pueden optar por incorporarlos después de la sesión.
Conclusión
En este tutorial, le presentamos el concepto de The Three Amigo Principle lo que ha demostrado ser muy beneficioso para ofrecer la solución adecuada a un ritmo más rápido con fuertes ciclos de retroalimentación.
Las tres sesiones de Amigo no dejan espacio para tener una comprensión diferente del mismo requisito. El objetivo de la reunión es que todos estén en sintonía y luego dejar que acepten el requisito antes de pasar a la fase de desarrollo.
Si ya está trabajando en Agile Framework, le recomiendo encarecidamente que intente tener un par de The Three Amigo Session y observe el cambio por sí mismo.
¡Nuestro próximo tutorial explicará más sobre el marco ágil escalado!
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- 4 pasos hacia el desarrollo de la mentalidad de pruebas ágiles para una transición exitosa a un proceso ágil
- Tutorial ágil de JIRA: cómo utilizar JIRA de forma eficaz para gestionar proyectos ágiles
- Manifiesto ágil: comprensión de los valores y principios ágiles
- El cambio de mentalidad de un probador ágil: alinearse con el manifiesto ágil
- Tutorial SAFe Agile: Qué es Scaled Agile Framework
- Cuestionario en línea de Agile Scrum: Pon a prueba tu conocimiento de Agile Scrum
- Pruebas de regresión automatizadas: desafíos, procesos y pasos
- Pruebas ágiles en aumento: ¿bendición o perdición?