Buscar en Gazafatonario IT

domingo, enero 29, 2023

Historias de usuario basadas en hipótesis

Foto de Kaleidico en Unsplash

En general, las historias de usuario son hipótesis hasta tanto el producto resultante de aquellas se encuentre en manos de los usuarios quienes finalmente “emitirán” un veredicto al respecto. Es por ello por lo que hacemos entregas iterativas e incrementales, para poder adaptarnos a medida que esas sentencias emergen. Es posible que unas veces acertemos, pero es posible que otras veces no.

Ahora bien, el desarrollo basado en hipótesis (HDD por sus siglas de inglés de Hypothesis-Driven Development) es un método de prototipo que permite a los diseñadores de productos desarrollar, probar y elaborar un producto hasta que sea aceptable para los usuarios. Es una medida iterativa que explora los supuestos definidos durante la iniciativa e intenta validarlos con la retroalimentación de los usuarios. Y este es el principal beneficio de HDD.

También posibilita que se reduzca el tiempo y los recursos asociados con los procesos de desarrollo tradicionales. Además, la naturaleza iterativa del proceso permite una mejor comprensión de las necesidades y preferencias del usuario, lo que puede ayudar a garantizar que el producto satisfaga las necesidades del cliente.

El proceso de desarrollo basado en hipótesis incluye cinco pasos principales:

1.    Definir el problema: identificar el problema que necesita ser resuelto antes de comenzar el proceso de desarrollo.

2.    Formular la hipótesis: enunciar suposiciones e hipótesis que puedan ayudar a resolver el problema.

3.    Desarrollar un prototipo: elaborar un prototipo basado en las hipótesis formuladas.

4.    Probar el prototipo: validar el prototipo con usuarios reales y recopilar su retroalimentación.

5.    Iterar: iterar el prototipo en función de la retroalimentación y volver a probar hasta que satisfaga las necesidades del usuario.

No voy a entrar en detalles de cada uno de estos pasos del método. Lo que sí haré es ilustrarlos con un par de ejemplos antes de ir directamente al tema principal que nos convoca: las historias de usuario basadas en hipótesis.

Ejemplo 1 de HDD:

Problema: un motor de búsqueda no proporciona los resultados más precisos.

Hipótesis: Al mejorar los algoritmos utilizados para buscar, se proporcionarán resultados más precisos.

Prototipo: desarrollar un nuevo algoritmo que pueda buscar mejor a través del texto.

Prueba: hacer pruebas del nuevo algoritmo con usuarios que hayan buscado en el pasado y recopilar la retroalimentación de estos sobre la precisión de los resultados.

Iterar: tener en cuenta la retroalimentación dada para refinar el algoritmo y volver a probar hasta que los resultados sean lo suficientemente precisos para las necesidades de los usuarios.

Ejemplo 2 de HDD:

Problema: una tienda de ropa no tiene artículos para clientes de tallas grandes.

Hipótesis: al ofrecer ropa elegante y de moda para clientes de tallas grandes, la tienda atraerá a una base más grande de clientes.

Prototipo: desarrollar una línea de ropa elegante y de moda para clientes de tallas grandes.

Prueba: probar la línea de ropa con clientes de tallas grandes para obtener retroalimentación sobre el ajuste, el estilo, la calidad y el precio.

Iterar: usar la retroalimentación dada para refinar la línea de ropa y volver a probar hasta que los productos satisfagan las necesidades de los clientes.

Entran las historias de usuarios con el enfoque HDD

Historia # 1

Veamos un par de historias de usuario en la forma clásica:

Como cliente de tallas grandes,

Quiero poder encontrar ropa elegante y a la moda que me quede bien,

Para sentirme tan seguro y elegante como cualquier otra persona.

Hipótesis: al ofrecer ropa elegante y de moda para clientes de tallas grandes, la tienda de ropa atraerá a una base más grande de clientes.

Historia # 2

Como estudiante,

Quiero poder encontrar fácilmente fuentes confiables de información para fines de investigación,

De modo que pueda encontrar rápidamente respuestas precisas a mis preguntas.

Hipótesis: al mejorar los algoritmos utilizados para la búsqueda, se suministrarán resultados más confiables y precisos.

Vamos a darle un giro a estas historias de usuario con el enfoque HDD, es decir, representar la historia como una hipótesis. Para ello, usaré la forma:

Creemos que <esta capacidad>

Dará como resultado <este resultado>

Tendremos confianza para proceder cuando <veamos esta señal medible>

Historia # 1

Creemos que ofrecer ropa elegante y de moda para clientes de tallas grandes dará como resultado una base más grande de clientes para la tienda de ropa. Tendremos confianza para proceder cuando observemos un aumento de clientes en un 15 % y de ventas en un 25 %.

Criterios de aceptación:

·       La tienda debe ofrecer una gama de ropa elegante y de moda para clientes de talla grande.

·       La ropa debe quedarles bien a las clientes de talla grande.

·       La ropa debe ser de calidad superior.

·       El precio de la ropa debe ser razonable.

Historia # 2

Creemos que mejorar los algoritmos utilizados para buscar

Dará como resultado resultados más confiables y precisos.

Tendremos confianza para proceder cuando observemos una mejora en los resultados de búsqueda.

Ahora, escribe algunos Criterios de Aceptación de estas historias de usuario

Criterios de aceptación:

·       El motor de búsqueda debe ser capaz de buscar con precisión a través del texto.

·       Los resultados deben ser lo más precisos posible.

·       La búsqueda debe ser rápida y eficaz.

·       La búsqueda debe proporcionar una gama de resultados que sean relevantes para la consulta.

Ahora, veamos algunas historias de usuario con este enfoque HDD de una aplicación tipo “Netflix”:

Creemos que ofrecer recomendaciones de contenido personalizado

Dará como resultado usuarios más comprometidos.

Tendremos confianza para proceder cuando veamos un aumento del 17 % en la participación de los usuarios.

Criterios de aceptación:

·       La aplicación debe proporcionar recomendaciones de contenido personalizadas basadas en los hábitos de visualización del usuario.

·       Las recomendaciones deben ser pertinentes y precisas.

·       El usuario debe poder ver fácilmente el contenido recomendado.

 

Creemos que brindar una experiencia de visualización optimizada

Resultará en una mejor experiencia para el usuario.

Tendremos confianza para proceder cuando observemos un aumento en la satisfacción del usuario.

Criterios de aceptación:

·       La aplicación debe proporcionar una experiencia de visualización optimizada.

·       El usuario debe poder encontrar y ver contenido fácilmente.

·       El tiempo de carga debe ser rápido.

·       La interfaz de usuario debe ser intuitiva y fácil de usar.

Una breve explicación de este enfoque

HDD es una forma específica de describir historias de usuario que incluye tres elementos clave:

1.    Creemos en <esta capacidad>: este elemento describe la capacidad o función en la que se centra la historia de usuario. Define lo que la historia de usuario está tratando de lograr desde un punto de vista funcional o técnico.

2.    Dará como resultado <este resultado>: este elemento describe el resultado esperado o el beneficio de la capacidad o característica descrita en el primer elemento. Define qué problema está tratando de resolver la historia de usuario y qué valor aportará al usuario.

3.    Tendremos confianza para proceder cuando <veamos esta señal medible>: este elemento define una señal medible que indicará que se ha logrado el resultado esperado. Este es un aspecto clave de la forma HDD de representar historias de usuario, ya que garantiza que el éxito de esta se pueda medir y rastrear.

El formato HDD es una forma efectiva de escribir historias de usuario porque garantiza que cada historia de usuario está claramente definida y tiene un propósito específico. Este modelo ayuda a garantizar que todos los interesados comprendan claramente el problema que la historia de usuario intenta resolver, el resultado esperado de la solución y la señal medible que indicará el éxito. Esto puede ayudar a garantizar que el producto se entregue a tiempo, dentro del presupuesto y a satisfacción de todos los interesados y consumidores.

Algunos beneficios que he comprobado al usar este modelo incluyen:

1.    Claridad: este modelo ayuda a definir claramente el problema que la historia de usuario está tratando de resolver y el resultado esperado de la solución. Esto puede facilitar que todos los interesados y comprometidos entiendan el propósito de la historia de usuario y cómo encaja en el producto general.

2.    Alineación: al establecer claramente el problema y el resultado esperado, esta forma puede ayudar a garantizar que todos estén alineados con el objetivo de la historia de usuario. Esto puede ayudar a reducir la confusión y garantizar que todos trabajen hacia el mismo objetivo final.

3.    Medición: el modelo permite definir una señal medible que indique el éxito de la historia de usuario. Esto puede ayudar a determinar si la solución final es exitosa, es decir, la hipótesis era cierta y si se ha logrado el resultado esperado.

4.    Priorización: el modelo facilita la priorización de historias de usuarios al tener una comprensión precisa del problema y del resultado que todos quieren. Esto puede ayudar a garantizar que las historias de usuarios más importantes e impactantes se aborden primero.

5.    Comunicación: esta forma de historia de usuario proporciona una forma clara y concisa de comunicar la historia del usuario a todos los interesados, los miembros del equipo y otras personas involucradas en el desarrollo del producto. Después de todo, lo más importante siguen siendo las conversaciones que se tengan alrededor de la historia de usuario. Esta es una manera más de iniciar y mantener esas conversaciones.

Algunos ejemplos adicionales

En la forma clásica:

Como cliente,

Quiero poder pagar mis compras con mi tarjeta de crédito

Para poder tener más flexibilidad en mis pagos.

En forma de hipótesis:

Creemos que proporcionar a los clientes la capacidad de pagar sus compras con su tarjeta de crédito

Dará como resultado que los clientes tengan más flexibilidad en sus pagos.

Tendremos confianza para proceder cuando al menos el 70 % de los clientes opten por pagar con su tarjeta de crédito.

 

En la forma clásica:

Como empleado de una empresa de logística,

Quiero poder rastrear la ubicación de nuestra flota en tiempo real

Para poder tomar decisiones más informadas.

En forma de hipótesis:

Creemos que proporcionar a los empleados de la empresa de logística la capacidad de rastrear la ubicación de la flota en tiempo real

Dará como resultado que los empleados puedan tomar decisiones más informadas.

Tendremos confianza para proceder cuando al menos el 75 % de la ubicación de la flota se actualiza en tiempo real.

 

En la forma clásica:

Como empleado de recursos humanos,

Quiero gestionar las solicitudes de vacaciones de los empleados de forma automatizada

Para poder ahorrar tiempo y reducir los errores.

En forma de hipótesis:

Creemos que proporcionar la capacidad para que los empleados de RR. HH. gestionen las solicitudes de vacaciones de los empleados de manera automatizada

Dará como resultado que los empleados de RR. HH. brinden un mejor servicio a los empleados de la compañía.

Tendremos confianza para proceder cuando las solicitudes de vacaciones se gestionen en menos de 24 horas.

 

Como puedes ver, el formato clásico proporciona una descripción general de la historia del usuario. Sin embargo, en forma de hipótesis, se proporciona una vista más detallada y estructurada de la historia, con un claro énfasis en el problema, la solución y la medida de éxito.

 

martes, enero 24, 2023

El poder de los equipos pequeños y por qué deberías usarlos para el trabajo complejo

 

Foto de Annie Spratt en Unsplash

Para lograr equipos de alto rendimiento, la comunicación es clave. Esto significa que el equipo debe poder comunicarse de manera efectiva entre sí, así como con su entorno y otros grupos dentro de la empresa. Los equipos Scrum son una excelente manera de lograr esta comunicación, ya que son pequeños y serializados. Esto permite una mejor colaboración y elimina la necesidad de paralelismo, que a menudo puede generar problemas de comunicación.

Los equipos Scrum generalmente se componen hasta de 10 personas, pero bien sabemos que equipos más pequeños se comunican mejor y son más productivos. Es decir, de unos 4 a 6 miembros por equipo es un volumen adecuado para una microentidad de este tipo. Este tamaño permite un entorno de trabajo más íntimo y centrado, lo que ayuda a crear un sentido de propiedad entre el equipo, ya que cada individuo es responsable de sus tareas particulares y puede expresar sus ideas o inquietudes durante los eventos de Scrum. Todo esto, sin llegar al extremo de que cada persona tenga metas individuales o intereses apartados de los demás.

Otra ventaja de los equipos Scrum es que permiten el trabajo serializado. Esto significa que en lugar de tratar de hacer varias cosas a la vez, el equipo puede concentrarse en una tarea a la vez para avanzar de manera eficiente. Esto puede generar menos errores y mejorar la productividad, al tiempo que brinda la oportunidad de aprender nuevas habilidades en el camino.

Además, los equipos Scrum permiten una mejor comunicación entre todos los interesados. Los eventos de Scrum son una excelente manera de garantizar que todos estén en la misma página y que cualquier problema o pregunta se aborde de manera rápida y eficiente. Esto puede ayudar a evitar confusiones, desacuerdos y conflictos dentro del equipo y garantizar que todos trabajen hacia el mismo objetivo.

Así que si eres un Scrum Master extraordinario o quieres llegar a serlo debes asegurarte de que tu pequeño equipo Scrum tenga éxito. Es tu razón de ser. Tu única razón de estar. El resto de tu trabajo es derivativo. Te voy a contar cómo hacerlo:

Primero, cerciórate de que todos los miembros del equipo estén comprometidos con Scrum. Esto significa que están dispuestos a trabajar juntos en colaboración y comunicarse abiertamente entre sí. Aquí es donde entran en juego los valores Scrum de Compromiso y Respeto, entre otros. Pero también es soporte vital que haya un espíritu del juego Scrum, es decir, al usar Scrum, la comunidad de productos de tu organización debe enfocarse en crear explícitamente una cultura donde las personas conozcan y sigan el espíritu de Scrum: empirismo y pensamiento Lean, valores y pilares. todos los que trabajan en o con un Equipo Scrum deben ayudar a desarrollar esa cultura predicando con el ejemplo.

En segundo lugar, es importante tener un objetivo claro y compartido de lo que se quiere lograr como equipo. Esto ayudará a todos a mantenerse enfocados y motivados. Tener una identidad de equipo sirve en estos casos. Y el Team Canvas es una herramienta que te puede asistir para ello. Luego vendrán el Objetivo de Producto y las metas intermedias: el objetivo de cada sprint. Como Scrum Master tienes que lograr que estos elementos sean los motivadores universales de cada miembro del equipo. Trabaja con quien sea necesario (por ejemplo, Talento Humano) para que esta identidad y estos objetivos compartidos se conviertan en el motor de ensueño para cada persona del equipo: no es lo mismo “pegar ladrillos” que estar “construyendo la catedral de Notre Dame”.

También, es importante que les brindes todo el apoyo necesario a los miembros de tu equipo. Esto puede incluir capacitación, recursos físicos y materiales o simplemente tener a alguien disponible para responder preguntas.

Ahora bien, una cosa es el tamaño del equipo y otra el alcance del proyecto o el trabajo que van a realizar. Un equipo más pequeño puede moverse más rápido y ser más ágil, pero también puede tener menos capacidad para tareas complejas. Además, a los equipos más pequeños les puede resultar más difícil establecer funciones y responsabilidades claras. Como resultado, es importante considerar cuidadosamente los desafíos que podría enfrentar un equipo pequeño de Scrum antes de emprender una iniciativa.

Para superar estos desafíos, asegúrate de que todos los miembros del equipo entiendan su función y sean conscientes de las habilidades y destrezas de los demás miembros. Esto se puede hacer a través de comunicaciones y reuniones periódicas. También, establece con ellos expectativas claras para cada miembro del equipo. Y recuérdales constantemente que un equipo pequeño aún puede tener éxito si todos trabajan juntos hacia un objetivo común. Dale a cada persona la oportunidad de contribuir y expresar su opinión. Sé flexible con el proceso del equipo y “pon el empirismo a trabajar”, es decir, abre espacio a la prueba y el error a medida que el equipo encuentra lo que funciona mejor para ellos. Finalmente, mantén una comunicación abierta con el equipo e inspíralos a que este tipo de comunicación sea el modus vivendi y su pasión entre ellos mismos y con su entorno.

¿Te suenan algunas de estas ideas? ¿Algunas otras? Por favor, déjamelo saber en el foro.

lunes, enero 16, 2023

Historias de usuario basadas en el comportamiento

 

 Foto de Icons8 Team en Unsplash

Ya sabemos que el así llamado Desarrollo Conducido por Comportamiento (BDD por las siglas en inglés de Behavior-driven development) es un proceso de desarrollo de software que se enfoca en el comportamiento de una aplicación. BDD acentúa la comunicación y la colaboración entre los desarrolladores, y aquí estoy usando “desarrolladores” en el sentido amplio de Scrum, es decir, las personas que elaboran software, sean especialistas en áreas como desarrollo o aseguramiento de la calidad, o en el sentido preferido de los practicantes ágiles, personal más especialista-generalista o simplemente más multifuncionales. Pero BDD no solo resalta la comunicación entre ellos, sino también entre estos desarrolladores y las personas no técnicas dentro y fuera de los equipos, como un Product Owner, usuarios o interesados.

En general, BDD implica la creación de casos de prueba que describen el comportamiento del sistema desde la perspectiva del usuario final. Estos casos de prueba, llamados "características" (“features”), se escriben en una sintaxis de lenguaje natural llamada "Gherkin", lo que posibilita que todos los miembros del equipo puedan leer y, mejor aún, entender las funciones de la aplicación, independientemente de su experiencia técnica.

Por ejemplo, si el sistema que se está desarrollando es un sitio web o una aplicación para un servicio de emisión o transmisión en directo por suscripción que les permita a usuarios ver series y películas en un dispositivo con conexión a internet, puedo tener la posibilidad de adicionar películas a una lista de películas favoritas:

Característica: Lista de Favoritas

Como usuario, Quiero agregar películas a mi lista de favoritas y conservarlas allí para poder verlas posteriormente

Luego, puedo agregar uno o más bloques de "escenario" que describen comportamientos o acciones específicas que el sistema debería poder realizar.

Escenario: Agregar película a la lista de favoritas

Dado que estoy en la página principal

Cuando busque por “películas de Ciencia Ficción”

Y haga clic en el botón “Adicionar a la lista” del primer resultado

Entonces la película debe ser adicionada a mi lista de favoritas

Y se repite la adición de escenarios para cada comportamiento que se quiera probar de la aplicación. Como siempre, es importante tener en cuenta que el comportamiento y sus escenarios solo deben se definen desde la perspectiva del usuario final. No debe contener detalles de implementación ni jerga técnica.

Ejemplos de historias de usuario tipo Gherkin

Y es aquí donde entran las historias de usuario. Podemos usar este “lenguaje natural” tipo “Gherkin” para representarlas. Sigamos con el ejemplo de la aplicación de transmisión que llamaremos RedTV.

Dado: un usuario tiene una cuenta con la plataforma RedTV

Cuando: el usuario intenta iniciar sesión

Entonces: El usuario se autentica y puede acceder al servicio de streaming

 

Dado: un usuario está buscando una película o una serie

Cuando: el usuario ingresa el título que quiere

Entonces: al usuario se le presentan las opciones de transmisión disponibles

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario detiene la transmisión

Entonces: el contenido se detiene y se puede reanudar más tarde

 

A estas historias de usuario podemos agregar algunos criterios de aceptación:

1.    El usuario puede iniciar y cerrar sesión en la plataforma de transmisión con las credenciales de su cuenta.

2.    El usuario puede buscar cualquier título, ya sea una película o serie, y ver las opciones de transmisión disponibles.

3.    El usuario puede poner en pausa el contenido de transmisión y reanudarlo más tarde.

4.    El contenido no debe interrumpirse ni detenerse mientras el usuario está transmitiendo.

5.    La calidad de la transmisión debe ser constante durante toda la duración de la transmisión.

6.    La plataforma de transmisión debe ser accesible tanto en dispositivos móviles como en computadoras de escritorio.

Advertencia: no todos estos criterios son para todas las historias de usuario anteriormente descritas. Dejo al lector para que use su habilidad de discernir sobre cuáles criterios serían de qué historias.

Ahora sí, veamos algunos ejemplos de historias de usuario con sus respectivos criterios de aceptación:

Dado: un usuario está navegando por el servicio de transmisión

Cuando: al usuario se le presentan recomendaciones basadas en su historial de visualización

Entonces: El usuario recibe recomendaciones de contenido personalizadas.

Criterios de aceptación:

1.    El usuario debe recibir recomendaciones personalizadas basadas en su historial de visualización y preferencias.

2.    El algoritmo de recomendación de contenidos debe ser eficaz y preciso.

3.    El usuario debe poder filtrar las recomendaciones por género, clasificación por edad y otros parámetros.

4.    El usuario debe recibir las recomendaciones más actualizadas.

 

Dado: un usuario está navegando por el servicio de transmisión

Cuando: el usuario intenta ver una película o un programa de televisión

Entonces: al usuario se le presentan todas las opciones de transmisión disponibles

Criterios de aceptación:

1.    Al usuario se le deben presentar todas las opciones de transmisión disponibles para una película o programa de televisión.

2.    Las opciones de transmisión deben incluir opciones premium y opciones gratuitas.

3.    El usuario debe poder filtrar las opciones de transmisión por precio, calidad y otros parámetros.

4.    El usuario debe tener la información más actualizada sobre las opciones de transmisión.

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario intenta cambiar la calidad de la transmisión

Entonces: Al usuario se le presenta una gama de opciones de calidad.

Criterios de aceptación:

1.    Al usuario se le debe presentar una variedad de opciones de calidad para elegir.

2.    La calidad de transmisión no debe degradarse al cambiar la configuración de calidad.

3.    El usuario debe poder cambiar entre configuraciones de calidad con una interrupción mínima.

4.    La configuración de calidad debe ser uniforme en todos los dispositivos.

 

Dado: un usuario está navegando por el servicio de transmisión

Cuando: el usuario intenta comprar una película o una serie

Entonces: Al usuario se le presentan opciones de pago

Criterios de aceptación:

1.    Al usuario se le debe presentar una variedad de opciones de pago.

2.    El proceso de pago debe ser seguro y fácil de usar.

3.    El usuario debe tener la opción de comprar contenido por tiempo limitado o de forma permanente.

4.    El proceso de pago debe explicarse claramente al usuario.

Ahora sí, una brevísima explicación de esta forma BDD "dado-cuando-entonces" de historias de usuario

El formato Gherkin-BDD "dado-cuándo-entonces" es una forma de representar historias de usuario que se centra en el punto de vista del usuario. La forma se divide en tres partes: Dado, Cuándo y Entonces. La parte "Dado" de la historia de usuario establece el contexto y describe la situación actual. La parte "Cuando" describe la acción que está realizando el usuario. La parte "Entonces" describe el resultado esperado de la acción. Esta forma permite que las historias de usuario se expresen desde la perspectiva del usuario, asegurando que se consideren las necesidades y expectativas del usuario.

Podemos usar diferentes estilos para relatar o representar historias de usuario. Veamos un ejemplo de una historia de usuario primero en el estilo clásico "Como - Quiero - Para " y luego, la misma historia en la forma “Dado - Cuando - Entonces”.

Como usuario,

Quiero modificar la información de mi perfil

Para poder mantenerla actualizada.

Ahora en “Gherkin”:

Dado: Un usuario tiene una cuenta

Cuando: el usuario intenta modificar la información de su perfil

Entonces: el usuario puede actualizar correctamente la información de su perfil

Y algunos criterios de aceptación:

1.    El usuario puede ver la información de su perfil.

2.    El usuario puede modificar la información de su perfil.

3.    El usuario puede guardar los cambios que realiza en la información de su perfil.

4.    El usuario puede eliminar la información de su perfil si así lo decide.

5.    Las modificaciones a la información del perfil deben ser seguras y privadas.

Algunas recomendaciones para narrar mejores historias de usuario con la forma BDD

Usa mi modelo de las 5 C:

1.    Céntrate en la perspectiva del usuario: representar historias de usuario desde el punto de vista del usuario es clave para asegurarse de que se cumplan sus necesidades y expectativas. Esto no es exclusivo para esta forma de representación, pero siempre es bueno recordarlo, las historias son “de usuario”, no de desarrollador, de interesado ni de gerencia.

2.    Concretiza: Sé específico. Asegúrate de incluir tantos detalles como sea posible, ya que esto facilitará que quienes implementen las características del producto comprendan el resultado deseado. Esto no tienes que hacerlo solo “escribiendo” historias de usuario. Recuerda que la parte más importante de estas es la conversación que tengas alrededor de la misma. Esto no cambia con una modificación en la forma de representarlas.

3.    Colabora: invita a los interesados y los desarrolladores a colaborar al describir historias de usuario, ya que esto ayuda a garantizar que estas sean claras y brinden la mayor cantidad de detalles posible. Las historias de usuario son un protocolo de colaboración, es una forma de realizar el trabajo en torno a un objetivo deseado.

4.    Considera casos extremos: asegúrate de incluir cualquier caso extremo al contar historias de usuario, ya que esto ayudará a garantizar que se contemplen todos los resultados posibles. Pero no te estreses con tratar de adjuntar todos los casos: primero los más críticos u obligatorios, luego los importantes y por último, si hay tiempo y presupuesto, los buenos, bonitos y baratos.

5.    Cata: Prueba y perfecciona. Después de crear historias de usuario, evalúalas para asegurarte de que sean claras y precisas, y perfecciona según corresponda. La calidad del producto comienza con la calidad de las conversaciones que tengas sobre cada historia de usuario de este.

Conclusión

Esta apenas es una forma más de representar historias de usuario que puedes incluir en tu caja de herramientas y enseñarla a tus equipos lo más pronto posible. Los beneficios de usar una forma u otra vienen dados por el contexto y por los resultados que quieras obtener. No te voy a decir que una forma es mejor que otra, porque no es cierto.

Anexo # 1: historias de usuario de la aplicación RedTV en la forma BDD, cada una con sus respectivos criterios de aceptación.

 

Dado: un usuario está buscando películas o series para ver

Cuando: al usuario se le presenta una variedad de opciones de género

Entonces: El usuario puede filtrar las recomendaciones por género

Criterios de aceptación:

1.    Al usuario se le debe presentar una lista de opciones de género para elegir.

2.    La lista de opciones de género debe ser completa y estar actualizada.

3.    El usuario puede filtrar el contenido recomendado en función de su selección de géneros.

 

Dado: un usuario ha comenzado a ver una película o serie

Cuando: el usuario desea saltar a una escena o sección específica

Entonces: el usuario puede buscar escenas específicas dentro del contenido

Criterios de aceptación:

1.    El usuario puede buscar escenas específicas dentro del contenido que está viendo.

2.    La búsqueda debe ser efectiva y precisa.

3.    El usuario puede saltar fácilmente a la escena que está buscando.

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario intenta ajustar la configuración de audio

Entonces: el usuario puede ajustar la configuración de audio

Criterios de aceptación:

1.    El usuario puede ajustar la configuración de audio del contenido que está transmitiendo.

2.    El usuario puede ajustar el volumen, el balance y otras configuraciones de audio.

3.    La configuración de audio debe ser uniforme en todos los dispositivos y plataformas.

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario intenta compartir el contenido con amigos

Entonces: el usuario puede compartir el contenido en las redes sociales y otras plataformas

Criterios de aceptación:

1.    El usuario puede compartir el contenido con amigos en las redes sociales y otras plataformas.

2.    El proceso de compartir debe ser fácil y seguro.

3.    Los usuarios deben poder compartir contenido desde su dispositivo, así como desde la plataforma de transmisión.

 

Dado: un usuario está buscando películas y series

Cuando: al usuario se le presentan opciones de control parental

Entonces: el usuario puede restringir el contenido según las clasificaciones de edad

Criterios de aceptación:

1.    Al usuario se le deben presentar opciones de control parental cuando busca películas y programas de televisión.

2.    El usuario debe poder restringir el contenido según las clasificaciones de edad.

3.    Las clasificaciones de edad deben ser consistentes y estar actualizadas.

4.    Las opciones de control parental deben ser seguras y fáciles de usar.

Anexo # 2: historias de usuario de una Billetera Digital en la forma BDD

Como usuario de la Billetera Digital,

Quiero agregar mi tarjeta de crédito a mi billetera digital

para hacer pagos usando mi teléfono.

Dado que estoy conectado a mi cuenta

Cuando hago clic en el botón "Agregar tarjeta"

E ingreso los datos de mi tarjeta de crédito

Entonces mi tarjeta de crédito debe agregarse a mi billetera digital

 

Como usuario,

Quiero poder realizar pagos con mi monedero digital

para no tener que llevar mi tarjeta física conmigo.

Dado que tengo una tarjeta de crédito agregada a mi billetera digital

Cuando elijo la tarjeta en un punto de venta

E ingreso mi número de teléfono o escaneo un código QR

Luego, el pago debe procesarse utilizando mi billetera digital.

 

Como usuario,

Quiero ver mi historial de transacciones

para hacer un seguimiento efectivo de mis pagos.

Dado que estoy conectado a mi cuenta

Cuando hago clic en la pestaña "Historial de transacciones"

Entonces debería ver una lista de todas mis transacciones anteriores

Criterios de aceptación:

1.    El usuario debe poder ver una lista de todas sus transacciones anteriores

2.    El historial de transacciones debe incluir la fecha, el monto y el comerciante de cada transacción

3.    El usuario debe poder filtrar y ordenar el historial de transacciones por varios criterios (por ejemplo, fecha, monto, comerciante)

 

Como cliente,

Quiero seguir el estado de mis transacciones actuales o en curso

para conocer el momento exacto en que mis transacciones se hagan efectivas

Dado que estoy conectado a mi cuenta

Y estoy en la página "Mis transacciones"

Cuando hago clic en el botón "Rastrear transacción" para una transacción actual

Entonces debería ver el estado actual de la transacción seleccionada (por ejemplo, "Procesando", "Enviada", etcétera.)

 

Como usuario,

Quiero agregar varias tarjetas de crédito a mi billetera digital

para que pueda elegir qué tarjeta usar para cada pago.

Dado que estoy conectado a mi cuenta

Cuando hago clic en el botón "Agregar tarjeta"

E ingreso los datos de mi tarjeta de crédito

Entonces mi tarjeta de crédito debe agregarse a mi billetera digital

 

Como usuario,

Quiero ver y administrar todas mis tarjetas de crédito en mi billetera digital

para seleccionar fácilmente la tarjeta que quiero usar para cada pago.

Dado que tengo varias tarjetas de crédito agregadas a mi billetera digital

Cuando hago clic en la pestaña "Tarjetas"

Entonces debería ver una lista de todas mis tarjetas de crédito.

Y debería poder seleccionar una tarjeta para hacer un pago.

 

Como usuario,

Quiero eliminar tarjetas de crédito de mi monedero digital

para retirar las tarjetas que ya no uso y controlar mejor la seguridad de mis datos financieros

Dado que tengo varias tarjetas de crédito agregadas a mi billetera digital

Cuando hago clic en el botón "Eliminar" para una tarjeta específica

Entonces, la tarjeta seleccionada debe eliminarse de mi billetera digital

 

Como usuario,

Quiero poder realizar pagos con mi monedero digital

para no tener que llevar mi tarjeta física conmigo.

Dado que tengo una tarjeta de crédito agregada a mi billetera digital

Cuando elijo la tarjeta en un punto de venta

E ingreso mi número de teléfono o escaneo un código QR

Entonces, el pago debe procesarse utilizando mi billetera digital.

Criterios de aceptación:

1.    El usuario puede seleccionar una tarjeta de crédito de su billetera digital para realizar un pago

2.    El usuario puede ingresar su número de teléfono o escanear un código QR para completar el pago

3.    El pago debe ser procesado con éxito y el usuario debe recibir una confirmación del pago

 

Como usuario,

Quiero poder realizar pagos con mi billetera digital en cualquier lugar que acepte tarjetas de crédito

para que pueda hacer pagos donde quiera que esté.

Dado que tengo una tarjeta de crédito agregada a mi billetera digital

Cuando elijo la tarjeta en un punto de venta

E ingreso mi número de teléfono o escaneo un código QR

Luego, el pago debe procesarse utilizando mi billetera digital.

Criterios de aceptación:

1.   El usuario debe poder realizar pagos en cualquier lugar que acepte tarjetas de crédito (por ejemplo, en la tienda, en línea)

2.   El usuario debe poder seleccionar una tarjeta de crédito de su billetera digital para realizar un pago

3.   El pago debe ser procesado con éxito y el usuario debe recibir una confirmación del pago