Estructura de las Historias de Usuarios

2/11
Recursos
Transcripción

¿Cómo se estructura una historia de usuario?

Crear una historia de usuario es fundamental en el desarrollo de software, ya que clarifica quién va a utilizar una funcionalidad, qué se espera implementar y, sobre todo, qué ventajas se persiguen. A continuación, te detallo los componentes de una historia de usuario que debes tener en cuenta para asegurar su efectividad.

¿Quién es el usuario?

Es esencial definir quién utilizará la funcionalidad que estamos creando. No se trata de quién solicita o propone la funcionalidad, sino del usuario final que realmente interactuará con ella.

  • Enfoque humano: Recuerda que el software debe ser pensado de personas para personas. Tener presente al usuario es vital para que el producto final cumpla con las expectativas.
  • Investigación: Empatiza y entiende las necesidades del usuario final para definir correctamente este componente.

¿Qué funcionalidad se quiere implementar?

La funcionalidad define el “qué” de la historia de usuario. Especifica detalladamente la acción que se desea llevar a cabo.

  • Claridad y precisión: Evita ambigüedades y sé preciso. Por ejemplo, si la funcionalidad es permitir que los usuarios publiquen un estado en una red social, detalla las características específicas de esta acción.
  • Compatibilidad: Asegúrate de que la funcionalidad propuesta es compatible con las herramientas y la plataforma usada.

¿Cuál es el beneficio buscado?

Entender el “para qué” de la funcionalidad es crucial. Saber el propósito o beneficio genera un consenso en el equipo y asegura que todos tienen un objetivo común al que dirigirse.

  • Reducción de retrabajo: Conocer el beneficio ayuda a prevenir correcciones más tarde derivadas de malentendidos o expectativas no cumplidas.
  • Satisfacción del cliente: Un objetivo claro alineado con las expectativas de los stakeholders asegura clientes satisfechos.

¿Qué criterios de aceptación deben establecerse?

Los criterios de aceptación son estándares de calidad que la funcionalidad debe cumplir.

  • Definición de condiciones claras: Establecen qué es aceptable y qué no. Por ejemplo, para una red social, limitar el texto de un estado a mil caracteres como máximo.
  • Calidad del producto: Garantizan que el producto final cumple con las expectativas desde una perspectiva de calidad.

¿Cómo aplicar los componentes en un ejemplo práctico?

Para darle vida a estos conceptos, observemos un ejemplo aplicado:

Ejemplo de una aplicación de red social

Considera una aplicación que tiene la funcionalidad de "publicar mi estado":

  • Usuario: Los miembros de la red social que desean mantener contacto y actualidad en su red.
  • Funcionalidad: Permitir publicaciones de estado.
  • Beneficio: Facilita la conexión y la percepción de vigencia entre usuarios.
  • Criterios de aceptación:
    • Textos: Limitar las publicaciones a mil caracteres.
    • Imágenes: Permitir imágenes de hasta cinco megas y automáticamente ajustar la resolución si es necesario.

Este ejemplo ilustra cómo emplear una estructura coherente para construir historias de usuario efectivas que cumplan las expectativas. Continúa aprendiendo y profundizando en esta técnica para mejorar tus proyectos de software. ¡El camino del conocimiento es vasto y lleno de oportunidades!

Aportes 32

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>

Una Historia de usuario puede ser (basada en una pequeña caracteristica del sistema):
En la práctica es más sencillo armar todo en un solo enunciado, es más fácil para la comprensión de equipo. E igual, es importante mencionar, que si una historia de usuario, tiene muchos criterios de aceptación, es mejor buscar partirla en 2 HU. O igual, otro criterio podría ser, si la estimación del equipo la ve muy compleja, pero eso se ve en otra clase.
Como (quien va a utilizar la funcionalidad) Quiero que (comportamiento del sistema a desarrollar) para (el para que es importante, da contexto al desarrollador, así se enfoca en resolver el problema innovando y no solo seguir indicaciones) Criterios de aceptación (condiciones de calidad, como guías de lo que verdaderamente se está esperando) Add: Una buena práctica es entender el verdadero dolor del usuario, involúcrate en ese dolor y no solo dejes que el usuario te dé la solución disfrazada de dolor. Recuerda que el software está creado de personas, para personas. Aún más importante, elimina el pensamiento de: El usuario no sabe lo que quiere, si el usuario supiera no estarías contratado. No subestimemos el pensamiento de nuestros usuarios.
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