Estructura de las Historias de Usuarios

2/11
Recursos
Transcripci贸n

Aportes 26

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:

Ccmparto una de mis HU

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.

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.

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>

![](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鈥檚:

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.

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.

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