Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Lean. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Lean. Mostrar todas las entradas

viernes, marzo 24, 2023

[Nuevo Libro] Cultura Ágil: ese oscuro objeto del deseo

 

Prefacio

La cultura ágil es algo que muchas organizaciones quieren pero que les resulta difícil de alcanzar o definir. De allí la metáfora que expresé en el título del libro. He notado que, con frecuencia, las personas ven la cultura ágil como un concepto vago o elusivo que requiere cambios radicales en la estructura, los procesos y la tecnología de sus organizaciones. Pero la cultura ágil es mucho más que eso. Es una mentalidad y una forma de ser que puede transformar la manera en que las empresas operan y brindan valor a sus clientes e interesados.

Hace diez años escribí un artículo para la Scrum Alliance con el nombre del libro. De hecho, es el primer apartado de este. Recuerdo que me inspiré en una película francesa del director español Luis Buñuel, llamada precisamente “Ese oscuro objeto del deseo” de la que escuché hablar a mi padre, cinéfilo empedernido, por allá en 1977 y que yo vi una década después. La película cuenta la historia de un hombre que se obsesiona con una mujer que cambia constantemente su identidad y actitud hacia él. Elegí el título porque creo que capta la naturaleza paradójica de la cultura ágil: es a la vez simple y compleja; es a la vez sólida y dinámica; es a la vez deseable y oscura.

Han pasado muchas cosas en estos diez años desde la aparición del artículo. He recorrido el camino que representa la agilidad y he estado preparando y escribiendo el libro desde entonces en mi blog y en otros sitios. En medio de ello aprendí, como muchos de mis colegas, que no se trata solo de “hacer ágil” sino de “ser ágil”. También asimilé que, en el entorno enérgico e incierto de hoy, la cultura ágil puede ayudar a las organizaciones a responder de una manera más efectiva y quizás más rápida a las crisis, lograr una mayor satisfacción y felicidad de sus clientes y superar a sus competidores.

También en ese caminar ágil, llegué a la conclusión de que no cambiamos la cultura, en cambio, enviamos impulsos al entorno organizacional que, bien conducidos y con tiempo, cambian la cultura. Junto a esa conclusión he condensado los principales atributos de la cultura ágil en una declaración sucinta de tres leyes simples pero poderosas que son parte de mi mantra cultural y sobre las que soporto mi esquema de liderazgo. Estas son, pues, las tres leyes de la cultura ágil:

1.    La ley del cambio: la cultura es la forma como cambiamos las cosas por aquí.

2.    La ley del lenguaje: la cultura necesita un lenguaje que fomente la mejora y la forma de mejorar.

3.    La ley del liderazgo cultural: se requieren líderes para mejorar que dominen el lenguaje de la mejora y de la cultura organizacional.

Estas leyes te ayudarán a entender qué significa ser ágil en la práctica, cómo cimentas una cultura ágil en tu empresa o entorno, y cuáles son los beneficios y desafíos de hacerlo, entre otras cuestiones. Para ello compartiré mi viaje personal de descubrimiento y adopción de la cultura ágil. Contaré historias que presencié o de las que incluso he participado, porque, además, contando historias es como las culturas sobreviven y se vuelven más fuertes, y es una de las formas de inspirar el cambio organizacional.

Los modelos de cambio son artificiosos. Te dan la sensación de que, si los sigues, puedes lograr tus objetivos cuando de transformación cultural y organizacional se trata. Así que el mayor desafío que me he propuesto con el libro es que, apartado tras apartado, capítulo a capítulo, encuentres los fundamentos que te ayuden a entender y buscar la cultura ágil en tu propio contexto. Esta no es más una moda pasajera. Es una forma extensamente probada de trabajar que puede favorecerte y ayudar a tu organización a lograr mejores resultados y a sobrevivir en ambientes con alta incertidumbre y ambigüedad.

A lo largo de todo el libro te daré pistas de cómo promover el cambio organizacional y cómo llegar a la cultura que quisieras tener en tu empresa y en tu entorno. Si apenas vas a iniciar o si ya has trasegado durante algún tiempo, mi gran deseo es que aquí puedas encontrar algunas respuestas que hagan tu viaje ágil tan apasionante y visceral como el mío.

Medellín, Colombia. 20 de marzo de 2023.

Importante:

Puedes encontrar el libro en:

https://www.amazon.com/Cultura-%C3%81gil-oscuro-objeto-Spanish-ebook/dp/B0BZ5CZF8P/

jueves, marzo 16, 2023

El Scrum Máster no es un "Policía del Framework"

Imagen elaborada con ayuda de Dall-E 2

Ni mucho menos un Dictador de Scrum. Ser un Scrum Máster se trata más de crear una cultura de colaboración, productividad e innovación que simplemente seguir un marco de trabajo. Con Jorge Abad escribimos un libro sobre cómo ser un Scrum Máster extraordinario, pero te voy a dejar aquí algunas cualidades y prácticas esenciales de las que un Scrum Máster debe adueñarse para tener éxito en su responsabilidad más allá de Scrum.

·       Empatía: un Scrum Máster debe poder comprender y relacionarse con las perspectivas, desafíos y aspiraciones de las personas del equipo. La empatía ayuda a generar confianza, respeto y un entorno seguro para que los miembros del equipo hablen y sean escuchados.

·       Liderazgo de servicio: el Scrum Máster debe priorizar las necesidades y los objetivos del equipo sobre los suyos propios y facilitar la autogestión y la toma de decisiones del equipo. Debe actuar como un líder servidor, guiando y apoyando al equipo, en lugar de microgestionar o imponer sus puntos de vista.

·       Mejora continua: una Scrum Máster debe fomentar una cultura de aprendizaje y mejora continua, no solo para el equipo, sino también para él mismo y la organización. Debe fomentar la experimentación, la retroalimentación y la reflexión, y buscar oportunidades para mejorar el desempeño y los resultados del equipo.

·       Comunicación y facilitación: la Scrum Máster debe ser una comunicadora eficaz, capaz de facilitar reuniones, debates y colaboraciones entre los miembros del equipo y los interesados. Debe promover la transparencia, la claridad y la apertura en la comunicación, y eliminar cualquier barrera o conflicto que obstaculice el progreso.

·       Adaptabilidad y agilidad: el Scrum Máster debe poder adaptarse a circunstancias, desafíos y prioridades cambiantes, y ser ágil en su enfoque para la resolución de problemas y la toma de decisiones. Debe tener disposición para experimentar con diferentes métodos, herramientas y técnicas para encontrar la mejor opción para el equipo y la iniciativa.

·       Pensamiento estratégico: el Scrum Máster debe tener una mentalidad estratégica, capaz de alinear las metas y prácticas del equipo con la visión y misión de la organización. Debe tener habilidad para identificar oportunidades de innovación y crecimiento, y tomar decisiones informadas basadas en datos, perspectivas y en la retroalimentación recibida.

Cómo reconocer un policía o dictador de Scrum

Cuando un Scrum Máster se comporta como un policía de Scrum o como un dictador, puede tener un impacto negativo en la moral, la productividad y el éxito del equipo. Sin importar tu responsabilidad en el equipo, o si eres un interesado, un usuario, incluso un cliente, aquí te enumero algunos comportamientos de un Scrum Máster que se comporta como un policía o autócrata del marco de trabajo:

·       Microgestión: el Scrum Máster se involucra demasiado en las actividades del día a día del equipo, dejando poco espacio para la autonomía y la creatividad.

·       Cumplimiento estricto de las reglas: hace cumplir las reglas y prácticas de Scrum sin considerar las necesidades y circunstancias únicas del equipo.

·       Negativa a adaptarse: sigue rígidamente Scrum sin considerar la retroalimentación del equipo o las necesidades cambiantes del negocio.

·       Falta de empatía: el Scrum Máster no tiene en cuenta los sentimientos, las preocupaciones o el equilibrio entre el trabajo y la vida de las personas en el equipo, lo que genera falta de motivación y agotamiento.

·       Insistencia en los informes de estado: exige informes de estado y de progreso frecuentes, lo que puede ralentizar la productividad y causar estrés innecesario.

·       Cultura de culpa: culpa a las personas o al equipo por los fracasos o contratiempos de la iniciativa, lo que lleva a una cultura de miedo y desconfianza.

·       Falta de comunicación: no se comunica de manera efectiva con el equipo o los interesados, lo que genera malentendidos y confusión.

·       Desestimación del feedback: ignora la retroalimentación o las ideas del equipo, lo que lleva a una falta de compromiso y motivación.

·       Control excesivo: intenta controlar todos los aspectos de la iniciativa, lo que lleva a una falta de autonomía y creatividad.

·       Falta de transparencia: no comparte información ni actualizaciones de progreso, lo que genera falta de confianza y transparencia.

Si un Scrum Máster exhibe tres o menos de estos comportamientos está bien. Solo necesita acompañamiento, quizás un mentor o un coach que lo guíe y lo ayude a encontrar el camino. Si en cambio hace gala de entre cuatro y siete de estas conductas, necesita una intervención fuerte, un programa de mejoramiento intenso que puede tomar un tiempo considerable para que se encamine por la senda apropiada y en el que trabaje en un cambio de mentalidad y de valores. No hay nada de malo en empezar así, lo verdaderamente inquietante es que varios meses después lo siga haciendo.

Pero si tiene ocho o más de estos hábitos, quizás no haya nada que hacer. Un Scrum Máster de este nivel de pensamiento no ayuda a, más bien entorpece, la incorporación, práctica e inspiración de comportamientos que a la postre den como resultado la cultura que necesita una organización para lograr sus objetivos en un entorno exigente y VUCA como los que nos cobijan en la actualidad.

Eso sí, hay que intentar ayudarlo. Mientras lo haces, déjame saber en la sección de comentarios qué otros comportamientos has visto en un policía o autócrata de Scrum.

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