¿Cómo defino los criterios de aceptación para los resultados subjetivos?

Creo que las historias de usuarios subjetivas son una receta para el aumento del alcance. Si desea centrarse en los requisitos de los propietarios de negocios y hacer algo que sea medible, entonces recurriría a un marco como el Modelo de medición y marketing digital para generar KPI discretos que el propietario de negocios entenderá y se pueden lograr desde su punto de vista.

p.ej:

• Objetivo: Mejor documentación
• Objetivo: instrucciones utilizables
• KPI: mejorar la implementación de recomendaciones
• Objetivo: el 90% de las recomendaciones se implementan en una semana
• Segmento: informe de tareas pendientes

Entonces la historia de usuario se convierte en:

Como propietario de una pequeña empresa, quiero instrucciones simples y fáciles de seguir para implementar el 90 % de las recomendaciones en una semana.

Por qué su "historia" no es comprobable

Como propietario de una pequeña empresa,
quiero instrucciones simples y fáciles de seguir para cualquier recomendación a mi sitio web
para que entienda qué es lo que debo hacer y qué recursos se requieren.

Aquí tienes dos problemas:

1. Esta no es una historia de usuario. Esta es una epopeya que necesita ser descompuesta.
2. Esta historia no sigue los criterios de INVEST , por lo que carece de criterios de aceptación obvios. Esto suele estar bien (si no es lo ideal) para las epopeyas, pero debe asegurarse de que las historias de usuarios relacionadas sean comprobables.

Las secciones posteriores discutirán cómo descomponer su epopeya, escribir historias que sigan el mnemotécnico INVEST y cambiar a un modelo de documentación iterativo basado en pruebas.

Soluciones ágiles para hacer que las historias de documentación sean comprobables

Descomponga su epopeya

Lo primero que debe hacer es descomponer su épica en historias de usuarios discretas. Considere el siguiente ejemplo:

• Epic: documentación del usuario del sitio web

  1. Como propietario de un sitio web,
     quiero que el manual del propietario contenga un capítulo sobre la configuración de la configuración de captcha
     para poder aumentar la cantidad de intentos de inicio de sesión de usuario necesarios para iniciar sesión.

  2. Como propietario de un sitio web,
     quiero que el manual del propietario contenga un capítulo sobre la aleatorización de la página de destino
     para que sea difícil para los usuarios marcar mi sitio como favorito.

Estas historias, aunque tontas, son en gran medida procesables. Cada historia contiene un entregable concreto (es decir, un capítulo en el manual del propietario) sobre un tema específico con suficiente contexto para proporcionar objetivos medibles.

Definir pruebas de aceptación

Por supuesto, parte de su definición de hecho debe implicar probar si la información en su manual se transmite correctamente. Eso no es parte de la historia del usuario; en cambio, parte de su planificación de Sprint para esta historia es agregar las pruebas de aceptación de usuario necesarias a su Sprint Backlog.

Por ejemplo, el equipo puede planear que un cliente real lea el capítulo sobre la configuración de captcha y ver si es comprensible y completo. O el equipo puede elegir que un miembro del equipo lea el capítulo, paso a paso, y siga las instrucciones del manual en lugar de hacerlo de otra manera para ver si funciona como está escrito. Esto definitivamente proporcionará comentarios útiles sobre la usabilidad de las instrucciones.

Iterar, iterar e iterar de nuevo

El desarrollo iterativo no se trata de obtener algo perfecto la primera vez. Quizás entregue su capítulo sobre páginas de inicio aleatorias, que era comprensible y útil para el probador en ese momento, pero luego tiene un nuevo cliente que tiene problemas con el paso 15 del mismo capítulo. ¡Desde una perspectiva ágil, esta es simplemente una oportunidad para mejorar gradualmente!

Escribirías una nueva historia de usuario, como:

Como usuario de un sitio web,
quiero que se reescriba el Paso 15 del Capítulo 23 para mayor claridad , de
modo que pueda seguir el procedimiento para aleatorizar mi página de inicio.

Una vez más, el objetivo y el alcance están bien definidos, pero las pruebas de aceptación están ajustadas. Debe agregar pruebas que incluyan pruebas de aceptación por parte de su nuevo cliente (o un representante), mientras que las pruebas de regresión con sus pruebas de aceptación existentes para asegurarse de que no empeoran las cosas para sus clientes existentes.

Siga los criterios INVEST

Cada historia de usuario que escriba debe ser:

• Autónomo, sin dependencias de otras historias.
• Estimables, para que el alcance y el nivel de esfuerzo sean entendidos por el equipo.
• Lo suficientemente pequeño como para planificar, desarrollar y probar en un solo sprint.
• Comprobable, con métricas definidas. Las pruebas objetivas son las mejores, pero "¡Pregúntale a Mikey si le gusta!" aún cumple con los requisitos de comprobabilidad siempre que el equipo haya acordado que es una forma útil de decidir si una historia está "terminada".

Si escribe sus historias de usuario de esta manera, encontrará que al equipo le resultará mucho más fácil identificar tanto el objetivo de la historia como los criterios de éxito para la misma. Esto hace que los detalles de implementación (por ejemplo, qué escribir para cada sección de la documentación) sean mucho más obvios para los desarrolladores y escritores técnicos sin tener que inventar especificaciones detalladas.

Al trabajar con los probadores de aceptación o los usuarios finales dentro del sprint, tanto para definir los criterios de aceptación como para probarlos, también se asegura de no terminar con algo incorrecto al final del sprint. Este cambio a la documentación basada en pruebas puede ser un desafío, pero en realidad no es diferente del código basado en pruebas desde el punto de vista del proceso.

Existen dos enfoques para las mediciones subjetivas en las historias de usuarios que pueden funcionar, según sus circunstancias:

1) No los use: en algunos casos, puede elaborar medidas más concretas con las partes interesadas para reemplazar las medidas subjetivas. Pueden ser específicos, como reemplazar "Quiero que la página se cargue rápidamente" por "Quiero que la página se cargue en 3 segundos" o relativos como "Quiero mejorar el algoritmo para procesar lotes un 25 % más rápido".

2) Concéntrese en la conversación: supongamos que desea un proceso de informe de reclamos intuitivo en su aplicación. "Intuitivo" es mucho más difícil de traducir a términos concretos, por lo que es posible que deba acordar algunos métodos que el equipo usará, como la creación de prototipos en papel con un conjunto de usuarios reales para averiguar cuál de un conjunto de opciones es la mejor. Este enfoque tiene el riesgo de alargarse durante mucho tiempo, por lo que probablemente desee establecer un cuadro de tiempo. Estrictamente hablando, esto es más un Spike que una historia de usuario, pero no obstante debería ayudar a resolver su problema.

Un Criterio de Aceptación, identifique claramente el propósito y el alcance. En general, trato de definir qué escenarios están dentro del alcance y qué escenarios no están dentro del alcance. En este caso y siguiendo los comentarios de los clientes, intentaré enumerar algunos casos de uso para definir algunos de los caminos posibles.

Como regla general, un criterio de aceptación efectivo es detallado/específico e inequívoco y no debemos usar un lenguaje subjetivo.

¡ Usa un pico !

Una tarea destinada a responder una pregunta o recopilar información, en lugar de producir un producto que se pueda enviar. A veces se genera una historia de usuario que no se puede estimar bien hasta que el equipo de desarrollo realiza un trabajo real para resolver una cuestión técnica o un problema de diseño. La solución es crear un “spike”, que es un trabajo cuyo propósito es dar la respuesta o solución. - http://agiledictionary.com/209/spike/

Una vez que se complete el pico, ahora debería tener suficiente definición para crear sus historias de usuario.