No se trata de lo que quieres comprar, sino de quién quieres ser. Aprovecha el precio especial.

Antes: $249

Currency
$209

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscríbete

Termina en:

14 Días
7 Hrs
4 Min
47 Seg

Estructura de las Historias de Usuarios

2/11
Recursos
Transcripción

Aportes 29

Preguntas 7

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Historia de Usuarios: (Ejemplo propio)

  • Usuario (Quién): Como usuario admin quiero eliminar comentarios 👎
  • Funcionalidad (Qué): Agregar o eliminar comentarios desde el admin
  • Beneficio (Para qué): Interfaz mas limpia para los usuarios sin comentarios no deseados
  • Criterios de aceptación: votos con menos de -15

Esta es mi historia de usuario:

Como usuario cliente quiero ver los productos más vendidos por categoría.
Funcionalidad: Filtrar los productos más demandados por categoría.
Beneficio: Conocer los productos que son más elegidos por los clientes de la empresa.
Criterios de Aceptación:

  • Listar productos con ventas > 100.
  • Ocultar productos con ventas < 100.
  • Filtrar productos más vendidos por sus diferentes categorías.

Ccmparto una de mis HU

Como <usuario > lo que quiero es<funcionalidad> para <beneficio>

  • Quien
  • Que
  • Para que
  • Condiciones de calidad

El propósito del Daily Scrum es inspeccionar el progreso hacia el Objetivo Sprint y adaptar el Sprint
Backlog según sea necesario, ajustando el próximo trabajo planeado.

Historia de Usuario comprende: Quien, qué, para qué y condiciones de calidad (Guía de lo que estas esperando)

El software es de personas para personas Quien? El Usuario por ejemplo Que: lo que se quiere Para que: un contexto claro Criterios de aceptación: que se va a permitir y que no se va a permitir. Evitar ser ambiguo y repetitivo en los criterios de aceptación.

Estructura de una historia de usuario


  1. Usuario. Quién utilizará la funcionalidad.
  2. Funcionalidad. Acción que se podrá hacer en el producto. La solución a un problema específico.
  3. Beneficio. El valor o solución que obtiene el usuario.
  4. Criterios de aceptación. Condiciones de calidad. Qué es lo que se va a permitir con esa acción. Lo que va a considerar el cliente para aceptar la funcionalidad.

Resumen de la clase:
CLASE #2. Estructura de las Historias de Usuarios
• Se debe tener en cuenta 4 elementos: Usuario, funcionalidad, beneficio y criterios de aceptación.
o Usuario: ¿Quién? Quién va a usar el software, o sea el usuario final.
o Funcionalidad: ¿Qué? Qué va a hacer el software, qué es lo que se espera del software.
o Beneficio: ¿Para qué? El para que se pide un requerimiento, evita retrabajo o en el impacto negativo con el cliente.
o Criterios de aceptación: Calidad. Guías para conseguir el objetivo con el sw. Que se va permitir, que no se va a permitir, funcionalidad Vs Expectativa.

Como usuario estudiante lo que quiero es iniciar una sesión de repaso de flashcards estableciendo un temporizador para que así pueda manejar el tiempo de dedicación al repaso y ser productivo en la sesión.

  • Usuario estudiante.

  • Funcionalidad: Iniciar sesión de repaso de flashcards estableciendo un temporizador.

  • Beneficio: para que así pueda manejar el tiempo de dedicación al repaso y ser productivo en la sesión.

  • Condiciones de aceptación:
    El tiempo de sesión se puede establecer de 5 minutos a 1 hora.

Estructura de las Historias de Usuarios

  • Como <usuario> lo que quiero es <funcionalidad>
    para <beneficio>: Quién, qué y para qué.

  • Criterios de aceptación: Condiciones de calidad para poder crear lo que se está esperando. Funcionalidad técnica (limitación de texto, tamaño de imágenes, adaptación de imágenes)

Ejemplo de historia de usuario:
Yo como usuario de la aplicación de Airbnb quiero poder ver que apartamentos o casas se ajustan según mi presupuesto para poder hacer cuentas de cuanto puedo gastar en mi estadía.
Criterios de aceptación:

  • Se debe tener un filtro de precios a la hora de la búsqueda

Por ejemplo: Como usuario nuevo en el website quiero actualizar mi foto de perfil para actualizar mi avatar,completar mi perfil y con ello sea fácil de identificarme en la red

Recuerdo que para el criterio de aceptacion tambien habia un formato,

Given <contexto>
When <Alguna accion>
Then <consecuencias esperadas>

Como proveedor de pasteles necesito crear un pastel de bodas con 3 pisos en 2 libras de masa de chocolate, relleno con dulce de leche, fondan color blanco, decorado con una foto de los novios. Criterios de Aceptación: - Entregar el día Viernes a las 2:00 pm - El pastel debe estar cancelado en su totalidad para poder realizar la entrega. - No deberá añadirle huevo a la mezcla, la novia es alérgica a esta proteína. - La torta debera hacerla a base de banano. - Sin azúcar añadida. Este sería una historia de usuario si me tocara hacer un pastel de bodas. sencillo de entender. déjenme sus comentarios qué les parece el ejemplo y dejen sus sugerencias de que otros Criterios de Aceptación aregarian para cumplir con las expectativas del cliente. #platzi
Es interesante el framework SCRUM, de cómo aborda todo el proceso como un esqueleto, pero sin sesgar los procesos. Tiene sentido, porque no hay una guía para empatizar con el usuario, no existen los pasos que aseguren aquello, **empatizar** tiene relación con las habilidades blandas. Si escuchas a un usuario ¿qué oyes, qué ves? ¿un problema interesante que resolver o el bono que te falta para endeudarte en tu casa nueva? Por eso no existe ninguna metodología que garantice "**empatizar con el usuario**". Pero si te interesas genuinamente, estarás más cerca de resolver el problema.
estructura de la historia de usuario * QUIEN * QUE QUIERE * PARA QUE LO QUIERE -CODNCIONES DE CALIDAD O ACEPTACION *
![](https://static.platzi.com/media/user_upload/image-3e4a53ce-23cd-4da0-b262-86de3f2c2325.jpg)

Los 4 elementos importantes:

  1. Quien, vas usar lo que creo
  2. Que, es lo que se debe realizar en el proyecto
  3. Para, el objetivo del proyecto
  4. Calidad, de la información

El para Quien, el que y el para que… es en definitiva la estructura base y que se debe tener en cuenta.

estructura de la historia de usuario - QUIEN - QUE QUIERE - PARA QUE LO QUIERE -CODNCIONES DE CALIDAD O ACEPTACION

Como usuario( persona que usa módulo o producto)
Funcionalidad: que quiero de ese modulo
Benificio: que me ayuda a resolver ese requerimiento

Ejemplo de Historia de Usuario:
Como usuario quiero poder autogestionar mi cuenta para poder modificar mis datos a gusto.
Condiciones de aceptación:
- Es posible modificar la dirección indicando país, ciudad y calle
- Es posible modificar la edad entre 18 y 60 años
- Es posible modificar el e-mail a una dirección de correo electrónico válida
- Es posible modificar nombre de usuario a uno inexistente
- Es posible modificar la contraseña mientras cumpla con tener una letra mayúscula, una letra minúscula y un número
- No es posible modificar ningún dato si no introduce su contraseña actual

En las historia de usuarios creamos historias entregamos avances por medio de sprint y socializamos con el equipo frente a los avances pero todo después de construir un producto que sea funcional y traiga beneficios a nuestros usuarios y clientes.

Una historia de usuario es una descripción breve de lo que un usuario quiere hacer dentro de un producto de software para obtener algo que resulte valioso.

Las historias de usuario se pueden partir en 3C’s:

CARD: se realiza bajo 3 partes fundamentales del usuario (no del cliente): YO QUIERO funcionalidad, COMO usuario, PARA con qué finalidad

CONVERSACIÓN: Se hace durante la planeación y después, son discusiones abiertas entre cliente y los que participan en la creación del desarrollo

CONFIRMACIÓN: Pruebas o criterios de aceptación, son los ejemplos de la conversación.

EJEMPLO: Yo como usuario de un cajero electrónico, quiero sacar dinero en cualquier lugar para tener dinero físico y hacer diligencias.
Criterios serían: El usuario debe tener una clave de 4 digitos, debe ingresar la clave en menos de 10 segundos o se le cancela la transacción.

Clase 2: Estructura de las Historias de Usuarios

  • Usuario (Quién): Como usuario admin quiero eliminar comentarios
  • Funcionalidad (Qué): Agregar o eliminar comentarios desde el admin
  • Beneficio (Para qué): Interfaz mas limpia para los usuarios sin comentarios no deseados
  • Criterios de aceptación: condiciones de calidad a la funcionalidad. son las guías para poder crear lo que se esta esperando.
  • El propósito del Daily Scrum es inspeccionar el progreso hacia el Objetivo Sprint y adaptar el Sprint
    Backlog según sea necesario, ajustando el próximo trabajo planeado.

Notas

  • En la practica funciona mejor si condensas todo en una sola frase:
Como admin quiero poder eliminar los comentarios con menos likes para mantener la plataforma con una interfaz limpia y que resalte los comentarios.

Criterio de aceptación: Es posible eliminar los comentarios con menos de 15 de likes.

Como <Usuario> lo que quiero es <funcionalidad> para <Beneficio>

Hola, buenos días .

Mando mis historias para su revisión

https://drive.google.com/file/d/1DsdnSdKolhqnkDolknJ8kLubtFVx_lf5/view?usp=drive_link

Saludos