Imagine una situación (el probador encuentra un error, comienza a discutirlo con el desarrollador) e insiste en que esto no es un error, porque la especificación no habló sobre esta funcionalidad. ¿Eso es familiar?
O porque los requisitos eran ambiguos y él los malinterpretó. O tal vez por el contrario, tenían tanta información que se perdió el foco y parte de la información se perdió de vista durante el desarrollo.
Y en esta situación, el desarrollador no es una plaga que cometió un error deliberadamente. En la práctica, si le proporciona requisitos simples, comprensibles y, lo más importante, cortos, la cantidad de errores que encontrarán los evaluadores será cero.
Probablemente también esté familiarizado con las disputas sobre el tema "un error o una característica". Los clientes han descubierto fallas y el propietario del producto llega al equipo con comentarios. Y el probador y el desarrollador se defienden, explicando esto por el hecho de que en la configuración original no se habló sobre la implementación de esta característica. Y esos momentos comienzan en la cartera de pedidos.
Creo que todas esas tareas instituidas después del lanzamiento, y que son el resultado de una especificación poco desarrollada, también son errores. Errores que caracterizan la calidad de su producto.
Resulta que los analistas de negocios determinan qué características deben crearse. Los desarrolladores los crean. Los probadores encuentran defectos en el trabajo de ambos. Así es como funciona el enfoque de desarrollo tradicional. Pero puede enseñarles a estos tres a trabajar juntos para hacer su trabajo mejor e inmediatamente, sin alteraciones adicionales. Y esta forma de comunicación se llama 3 Amigo. También se llama Story Kick Off Huddles o Triad.
3 Amigo es ...
3 Amigo es una práctica que proporciona una comprensión universal de lo que se entregará al cliente. Ayuda a transmitir la voz del equipo, no el entrelazamiento de opiniones dispersas.
Este método de comunicación dentro del equipo ayuda a:
- llegar a un acuerdo común sobre las expectativas antes del desarrollo
- formar un acuerdo sobre cómo hacer lo correcto de inmediato
También ayuda a entender:
- que problema resolvemos
- cuales son las soluciones
- ¿Qué debemos hacer para que la tarea esté lista?
La reunión de los tres amigos es una forma de pensar juntos que cierra la brecha en la comprensión de las especificaciones comerciales. Ella ayuda en el desarrollo de historias de usuario interesantes.
El objetivo es hacer el trabajo a tiempo, pero al mismo tiempo no planificar con anticipación para que los detalles tengan tiempo de volverse obsoletos.
¿Por qué 3? ¿Quién está aplicando?
El nombre de la práctica no nos limita a tres contextos, sino que solo crea un marco mínimo. Para asegurarse de que en el desarrollo de los requisitos se tuvieron en cuenta todos los matices técnicos, los casos explícitos e implícitos, que la especificación refleja la necesidad real del cliente: se requieren 3 contextos / pensamiento diferentes: negocio, desarrollador, probador. Además, la reunión no se limita solo a estas personas. Involucra a todos los involucrados en la implementación del requisito. Por ejemplo, si su tarea no solo tiene la web, sino también dispositivos móviles, entonces necesita contexto adicional. Es decir, la persona que realizará la implementación en la aplicación móvil. En nuestros equipos, la mayoría de las veces participan 4 desarrolladores (1 ios, 1 android, 1 back, 1 front), un probador y un analista de negocios.
Analista de negocios o PO
Un representante comercial sabe (casi siempre) lo que quiere obtener al final y qué valor recibirá el cliente y el negocio de esto. Es importante hablar sobre este equipo.
Al participar en la reunión de Amigo 3, el analista de negocios comparte información con los participantes para que todos en el equipo tengan la misma comprensión y expectativas de la historia del usuario. Además, solo él puede limitar el alcance de los criterios de aceptación mediante los cuales tendrá lugar la aceptación.
Desarrolladores
El desarrollador sabe cómo implementar el requisito del negocio, cuáles son las oportunidades para esto. Como regla general, piensa en los detalles que necesita saber para comenzar la implementación. Al hacer preguntas basadas en su experiencia y conocimiento del sistema, el desarrollador ayuda a revelar varios matices incluso en la etapa de discusión de los requisitos.
Probador
El probador, como otros miembros del equipo, ayuda a enriquecer los requisitos con varios casos de prueba. Según su experiencia, cada vez más dudas arroja dudas sobre las declaraciones hechas por el equipo. Por lo tanto, es mejor encontrar casos extremos, escenarios implícitos, se pregunta qué podría salir mal, qué debe tener cuidado.
¿Cuándo se aplica la práctica?
Raramente vi un proceso de desarrollo donde los requisitos se presentaban explícitamente. En la mayoría de los casos, los requisitos comenzaron a estudiarse en la etapa de desarrollo o prueba, y solo entonces se revelaron algunas inconsistencias.
Es probable que una especificación no probada tenga requisitos ambiguos, contradictorios, incompletos, duplicados y, a veces, incluso obsoletos, porque todo el mundo entiende lo que ha leído y escuchado a su manera. Por lo tanto, surgen diferencias en la interpretación.
Y si la documentación es grande y detallada, leerla puede llevar más tiempo que el proceso de prueba o desarrollo en sí.
En nuestra línea de negocios, decidimos aplicar esta práctica cuando las tareas comenzaron a demorarse en las pruebas. Identificamos 3 problemas principales:
- En la etapa de prueba, se produjeron muchos retornos debido a la aclaración de los requisitos. Estas fueron pausas tangibles en las pruebas y el desarrollo, cuando un analista de negocios determinó cómo debería funcionar.
- La prueba de la tarea se retrasó debido a una especificación demasiado detallada. Los casos eran frecuentes, cuando el probador podía pasar de 3 a 6 horas solo estudiando los requisitos y desarrollando casos de prueba, y la prueba en sí misma tomó alrededor de 30 minutos. Y lo más notorio fue el caso cuando la prueba se inició después de 2 semanas de estudiar la especificación, fue tan complicado y detallado
- Bueno, el problema más común fue que durante las pruebas de aceptación hubo muchos errores. Esos errores que podrían haberse evitado si se hubieran pensado antes del desarrollo.
Resulta que a pesar del desarrollo ágil, todavía hay una etapa de trabajo con la especificación técnica. Y si no tuvo en cuenta algunos casos, porque el cliente no dijo sobre ellos, o no hizo lo que realmente tenía en mente, después de ir al producto, un montón de tareas para revisión o incluso alteración se encuentran en la cartera de pedidos.
Y finalmente, vale la pena expresar el problema con la evaluación.
Es difícil evaluar una tarea cuando realmente no comprende la cantidad total de trabajo que le queda por hacer. ¿Cuántas pruebas escribir, cuántas devoluciones se deben a errores o alteraciones debido a imprecisiones en la especificación? Incluso si el desarrollador ofrece una evaluación precisa del tiempo de desarrollo en sí, casi nunca adivinará cuánto tiempo llevará la etapa de prueba impredecible.
Pasos para practicar AC
1. Formulamos requisitos como User Story
Recomiendo aplicar para desarrollar requisitos basados en historias de usuarios. Y como base para tomar una historia y en una reunión de 3 amigos para estudiarla solo.
Aquí, un punto muy importante es que el requisito de la empresa se formula realmente como una historia de usuario. Es decir, contenía en sí mismo 3 partes, a saber:
Yo como <role>, quiero <acción>, de modo que <motivación>
Esta es en realidad la plantilla de narración personalizada más popular llamada Connextra. También hay otras plantillas, pero recomiendo usar esta. Y por qué, ahora lo explicaré.
Tradicionalmente, hay 2 problemas al formar una historia de usuario:
- Al grabar, tampoco indique el papel, dejando acción y motivación.
- O indican el papel y la acción, y arrojan la motivación.
Esto realmente causa problemas, e intentaré explicar qué ejemplos con ejemplos simples.
- Conociendo el "rol", ustedes, como miembros del equipo, comprenderán mejor los límites de los criterios de aceptación que deben formular. Si no conoce completamente a la persona involucrada en esta historia de usuario, puede hacerlo en exceso de lo que necesita o viceversa, hacer algún tipo de funcionalidad.
- Ejemplo : el equipo no entendió el papel en la historia del usuario y, cuando trabajó en el problema, decidió que haría 3 métodos para la API: agregar, editar y eliminar. Y en el frente, agregarán botones que llamarán a estos métodos. Cuando presentaron su decisión al negocio, recibieron una retroalimentación de que su cliente es en realidad un analista de negocios específico que necesita un método para agregar. Y no eliminará ni editará. Sí, y él puede llamar a este método a través del cartero.
- El equipo no comprende la motivación del "rol" para el que hacen una historia de usuario. Debido a malentendidos, los límites de la historia del usuario en sí están mal delineados. Y además de esto, los criterios de aceptación al final pueden no resolver el problema final del cliente, aunque corresponderán a la acción expresada en la historia del usuario.
- Ejemplo : un equipo contrató una historia de usuario donde un analista de negocios no podía articular claramente la motivación. Por un lado, ella debía dejar al cliente leal y hacer una mejora para él. Por otro lado, reducción de costos para el banco. En este caso, los métodos de implementación y los criterios de aceptación fueron radicalmente diferentes. Porque en el primer caso, el equipo se centró en los criterios de aceptación del usuario. En el segundo, el equipo prestó atención a cómo hacer la implementación más simple y rápida posible.
Pero la formulación en el formato anterior no es un requisito previo. Conozco equipos que realizan reuniones en formato Amigo 3 y sin una historia de usuario. Y como base, use TK. En este caso, hay dificultades, pero fue una elección consciente del equipo.
Reunión 3 Amigo comienza con la preparación. En preparación para ello, los requisitos se formulan de manera que sean entendibles para todo el equipo. Estos requisitos están validados para la preparación para el trabajo.
La validación incluye evaluar el historial según los criterios de INVEST. Así como la calidad de la redacción de la historia misma. Aquí, se excluye cualquier ambigüedad, verbosidad, y cuando se evalúa por INVEST, se presta especial atención al tamaño de la historia. Si el equipo comprende que el requisito es épico, se produce la descomposición.
Después de que el requisito haya pasado la etapa de transformación en una historia de usuario y validación por parte del equipo (3 amigos), podemos proceder con la elaboración de los criterios de aceptación.
2. Complementamos los criterios de aceptación de User Story en la reunión de 3 Amigo
Primero debe decidir cuáles son los criterios de aceptación.
Por lo tanto, los criterios de aceptación son requisitos del cliente; especificación por la cual se puede verificar el sistema de historia / usuario.
Tienen un nombre alternativo, condiciones de satisfacción: condiciones para la satisfacción de las expectativas (autor Mike Cohn).
En una reunión de 3 equipos de Amigo ya vienen preparados. Ya tienen una historia de usuario validada, que quizás ya tenga algún conjunto de criterios de aceptación que el representante comercial formuló de forma independiente.
Durante la reunión, las tareas de los participantes son complementar / enriquecer la historia con un número suficiente de criterios de aceptación para su posterior implementación.
Los criterios de aceptación no deben incluir detalles de implementación. De hecho, los criterios de aceptación son reglas comerciales que rigen una historia de usuario en desarrollo. Los detalles de implementación se registran en las pruebas de aceptación, pero después de que se hayan formulado todos los criterios de aceptación.
No vale la pena confundir los detalles de implementación con los criterios de aceptación, aunque solo sea porque con plazos limitados, usted como equipo siempre puede "descartar" algún alcance de criterios que no es tan importante para las empresas en el futuro cercano. Si hay detalles con la implementación técnica en los criterios, corre el riesgo de perder información importante y el tiempo que ya se ha dedicado a discutir los detalles de la implementación. Los detalles de su implementación dependen directamente del alcance de los criterios que necesita hacer.
Además, evite una descripción secuencial del escenario con un conjunto de pasos (sistema clásico de administración de casos de prueba). Cualquiera de sus declaraciones debe ser atómica. Es mejor usar un estilo descriptivo del comportamiento esperado de la función creada.
Por ejemplo:
* , .*>
3. Mantenemos el tiempo
Un Estados Unidos bien descompuesto generalmente no contiene más de 10 criterios de aceptación. Si en el proceso de discusión se encuentra una gran cantidad de criterios de aceptación y todos están sujetos a implementación, entonces esta historia debe descomponerse en varias historias con un conjunto diferente de criterios de aceptación.
Si esto no se hace, la reunión de 3 Amigo se retrasará mucho.
El momento óptimo para celebrar una reunión de 3 Amigo es de 30 minutos a 1 hora.
Aumento aceptable al comienzo del camino, cuando el equipo está aprendiendo a comunicarse y aplicar esta práctica.
Si un equipo toma una gran historia para trabajar, es poco probable que en una sesión puedan resolver todos los criterios y pruebas de aceptación. Porque se pierde el enfoque y la atención. En este caso, debe dividir la sesión en varias reuniones. Pero en este caso, existe el riesgo de perder el contexto, y puede ser necesaria una inmersión adicional en una segunda reunión.
4. Para completar el estudio de los criterios, utilizamos la heurística USR
Cuando enseño a los equipos esta práctica, recomiendo usar la heurística al comienzo de su camino para suavizar la falta de experiencia. Con experiencia, el equipo tiene sus propias heurísticas y listas de verificación sobre qué buscar al desarrollar criterios.
La heurística de USR le permite considerar los criterios en todos los niveles que son necesarios para obtener la mayor información sobre lo que el cliente desea.
Entonces
- USUARIO : ¿Qué quiere hacer el usuario con el sistema?
- SISTEMA - ¿Qué debe hacer el sistema?
- RIESGOS - ¿Qué problemas pueden surgir?
Es importante resolver primero todos los criterios del grupo USUARIO y luego pasar al nivel del sistema. Aquí, los desarrolladores de front-end y backend están incluidos, y a nivel de sus sistemas pueden formular criterios de aceptación de lo que debería suceder para implementar los criterios del grupo USUARIO.
Y finalmente, la banda RISK. Muy a menudo, se olvida de la elaboración de requisitos, aunque no es menos importante. Cubre varios casos complejos que es posible que no pueda implementar. Pero para hablar y aceptar los riesgos como equipo se requiere.
Formas de aplicar la práctica para desarrollar casos de prueba antes del desarrollo
La forma recomendada para formalizar los requisitos son los casos de uso, en TI ruso lo llamamos casos de prueba.
Hay una herramienta conveniente para resolver casos de prueba en una reunión de 3 Amigo, llamada mapeo de ejemplo. En este artículo, lo toqué brevemente. En el próximo artículo, publicaremos información detallada sobre esta herramienta y cómo se utiliza en el marco de la reunión de la tríada.
Los casos de prueba se pueden implementar como pruebas de aceptación automatizadas para el historial. Además, cuando trabaje en casos de prueba, asegúrese de agruparlos. Dividir los casos de prueba en grupos es una forma de dividir la historia en varios más pequeños.
En casos de prueba, la descomposición de una regla de negocio se produce exactamente en el nivel del sistema en el que se implementarán, y no por el usuario.
Todos los detalles de implementación deben estar en sus casos de prueba, para que se centren en los desarrolladores en el proceso de implementación.
Cómo puede verse en el proceso general (cuando necesita celebrar esta reunión)
Se recomienda que resuelva los requisitos para una sola historia de usuario en una sola reunión. Se permite más, siempre que sean historias muy pequeñas o estén interconectadas en significado.
Como en el sprint tomas historias listas para trabajar, entonces se debe realizar una reunión de 3 historias de Amigo antes de planificar. De lo contrario, corre el riesgo de cometer un gran error con la estimación preliminar. En la práctica, la evaluación de la historia después de la reunión de 3 Amigo es muy diferente de la original.
Además, tiene sentido agregar un nuevo elemento al DOD como un indicador de que la historia está lista para trabajar en el sprint.
Por ejemplo, tenemos algunos equipos que han comenzado a aplicar esta práctica, acordaron que no tomarán el sprint durante la planificación si no hay criterios de aceptación y pruebas de aceptación para la tarea.
Y en la revisión del sprint, la aceptación de la historia se presenta de acuerdo con los criterios de aceptación.
Pero al mismo tiempo, cumplir con 3 Amigo también encaja en el proceso, si el equipo está trabajando no scrum, pero por ejemplo usa kanban. En este caso, la tarea se desarrolla solo después de haber pasado por una reunión de 3 Amigo.
¿Cuál es el resultado de la reunión 3 Amigo?
- guiones / ejemplos (respuestas obvias)
- reglas especificadas / criterios de aceptación
- historias nuevas / descompuestas
- comprensión común del área problemática
- empatía (empatía, participación)
El resultado principal de los tres amigos son las pruebas de aceptación escritas en el formato " Dado / Cuándo / Entonces" . De hecho, escribirlos puede llevar más tiempo del que quisiéramos, por lo que no se recomienda formalizar todos los requisitos en una reunión cuando todos están juntos. Por lo general, un desarrollador o probador trabajará en esto de forma inmediata. Y tan pronto como tengan todos los criterios y casos de prueba registrados, 3 Amigos observan brevemente lo que sucedió para asegurarse de que todos estén de acuerdo con lo que se registró.
Beneficio de usar la práctica de 3 Amigo
La estrategia de Amigos 3 puede tener un gran impacto en la efectividad de todo el equipo, así como en la calidad y sostenibilidad de sus proyectos, aumentando la maniobrabilidad y la flexibilidad para cambiar.
Aquí hay algunos bonos más:
- Cuando planificamos, no pasamos mucho tiempo sumergiéndonos en el significado de la historia.
- Detecta confusión y malentendidos en una etapa temprana, lo que permite una entrega más rápida
- Asegura que el equipo debata la cantidad de trabajo necesaria.
- Ayuda a encontrar todos los criterios de aceptación y otros atributos de calidad.
- El desarrollo de casos de prueba es mucho más fácil.
- Hacemos que los desarrolladores cubran el código con pruebas
- Rápidamente llegamos a la conclusión de que esta característica no es necesaria
Nuestros equipos, utilizando la práctica, pudieron reducir los retornos de tareas debido a especificaciones inexactas. Las tareas de back-end que los chicos aprendieron a desarrollar "la primera vez". Es decir, sin errores e inmediatamente en el producto.
Trampas
- No te limites a solo tres personas. Si necesita más, llame.
- No te encuentres con todo el equipo. En esta reunión, debe haber un número mínimo de personas para implementar la función.
- No lo considere como una reunión regular, un ritual. De lo contrario, el equipo tendrá un resultado negativo al aumentar el número de reuniones.
Clase magistral en la conferencia QualityConf
Del 27 al 28 de mayo, como parte del festival RIT ++, en la conferencia QualityConf, conduciré una clase magistral sobre el desarrollo de requisitos utilizando la práctica de 3 Amigo.
Si está interesado en el enfoque y tiene preguntas, también puede contactarme en telegram @Travieso_nastya.
Enfoque de la historia
El autor del enfoque: George Dinwiddy, 2009.
Describió este enfoque en su entrevista y mencionó en varios artículos los enlaces a los que adjunto. Además, como material adicional, adjunté todas las referencias a recursos en inglés, de acuerdo con las cuales estudié y aprendí a aplicar esta práctica.
https://www.agilealliance.org/glossary/three-amigos/
https://www.infoq.com/interviews/george-dinwiddie-three-amigos
https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories
https://www.stickyminds.com/better-software-magazine/three-amigos