martes, noviembre 19, 2013

Cómo luce (se ve) una historia de usuario - un pequeño ejemplo

Cuando se explican las historias de usuario, las personas no creen que son tan simples de escribir y creen que hay quedan cabos sueltos. La verdad es que si son simples (es solo cumplir el criterio INVEST [2] ) y no quedan cabos sueltos debido a dos elementos:
  • Criterios de Aceptación
  • Conversación


Las historias de usuario tienen dentro de sus objetivos:
  • sincronizar las espectativas del PO (Product Owner) con el Equipo respecto a una funcionalidad
  • servir como elemento que dirigirá construcción del software
A continuación quiero compartir un ejemplo de como luce (o se vé) una historia de usuario:

Nota : todo lo referente al ejemplo de la historia de usuario, lo registraré en color azul.


TEMPLATE
Yo como  <usuario>
necesito / deseo / quiero  <funcionalidad>
para <beneficio de negocio>



USANDO EL TEMPLATE PARA UN SISTEMA DE PRESTAMOS CREDITICIOS

 SOLICITUD DE INFORMACIÓN LABORAL DEL CLIENTE
(Nota : El título no sobra, algunas veces también se le adiciona codificación a la historia)


Yo como  CLIENTE DEL BANCO
Deseo INGRESAR MI INFORMACIÓN LABORAL ACTUAL
Para QUE EL BANCO DETERMINE SI ME PUEDE PRESTAR O NO


Criterios de aceptación 
(se pueden manejar dos opciones)


Criterios de Aceptación
 en Prosa
Criterios de Aceptación
en Formato BDD

GIVEN – DADO
WHEN – CUANDO
THEN – ENTONCES

(La verdad, prefiero este formato, ayuda a que no queden cabos sueltos)
Que pida lo datos de la empresa
Escenario 1: Solicitar Datos de la empresa

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO se soliciten los datos de la empresa
ENTONCES se pedirá el nombre de la empresa.
Que pida el nit (identificador único nacional para las empresas) y lo valide
Escenario 2: Solicitud de Nit

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO solicite la información de nit
ENTONCES se verificará el número del nit que su estructura sea correcta.
Que pida salario actual
Escenario 3: Solicitud de Salario

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando el salario
ENTONCES verifique que el valor sea entero y positivo
Y menor a $100.000.000
Que pida fecha de ingreso a la empresa
Escenario 4: Solicitud de fecha de ingreso

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando la fecha de ingreso a la empresa
ENTONCES la fecha sea superior a 50 años antes a partir de hoy
Y la fecha sea inferior a hoy
Que pida tres comprobantes de pago
Escenario 5:  Solicitud de 3

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando los comprobantes de pago
ENTONCES solicite tres comprobantes de pago en formato imagen.




---------

Conversación
 (la conversación son aclaraciones realizadas por el PO durante el refinamiento o el planning, y muchas de esas aclaraciones son solicitadas por los miembros del equipo al entender las historias de usuario y comprender el negocio)
  • Los datos de la empresa son nombre, teléfono y dirección
  • Que la validación del nit sea contra el web service de la Direccion de Impuestos (DIAN)
  • El minimo valor de salario actual debe ser el salario minimo, el que debe ser leído de la tabla de parámetros
  • La fecha de ingreso a la empresa debe ser superior a 6 meses
  • Los comprobantes de pago deben ser en formato jpg, gif y máximo de 2 megas cada uno.
(Como fruto de una conversación puede resultar que se actualicen los criterios de aceptación o solo que se deje el registro aclaratorio.


-----
Durante el sprint no se cambiarán los criterios de aceptación y en caso de que se observen mas criterios de aceptación, estos harán parte de otra historia de usuario que se construirá en otro sprint)



Donde seguir

Ver más acerca de las historias de usuario en:





Importante:

La historia de usuario debe ser de un tamaño tal que a lo sumo tome 3 días una persona construirla, probarla  (quedando con cero errores) y desplegarla en el ambiente de pruebas (o el ambiente indicado), de majera que el equipo de trabajo pueda decir tranquilamente y sin ningún temor "¡ESTA LISTA PARA PRODUCCIÓN!"



Referencias:

[1] WHAT’S IN A STORY?  http://dannorth.net/whats-in-a-story/
[2] Características de una buena historia de usuario - http://lecciones-aprendidas.blogspot.com/2013/07/caracteristicas-de-una-buena-historia.html

-------- Ver más ejemplos


Product Backlog Item 9:TR: Updater de Tiempo Real

Yo como OPERADORA
deseo TENER LA ULTIMA VERSIÓN DE TIEMPO REAL
para CONTAR SIEMPRE CON LA VERSIÓN MÁS ACTUALZADA DEL SISTEMA DE TRACKING

Escenario 1: Verificando versión

DADO que hago clic en el ícono de tiempo real
CUANDO el sistema verifica que tengo la última versión
ENTONCES el sistema sacará un mensaje que diga "Verificando versión. Espere un momento..."

Nota:La verificacion se realizara de la siguiente forma

al ejecutar el updater verificara la version que esta en la base de datos contra la version que leera el updater del ejecutable local, si la version es igual solo abrira la version existente de tiempo real ubicada en la maquina local, en caso contrario descargara la ultima version del repositorio y posteriormente abrirá tiempo real con la version actualizada en la maquina local

Escenario 2: Tengo la última versión
DADO que estoy verificando versión
CUANDO se comprueba que tengo la última versión
ENTONCES El sistema llama a la aplicación de TIEMPO REAL permitiendo el ingreso de usuario y contraseña.


Escenario 3: No tengo en mi máquina la última versión
DADO que estoy verificando versión
CUANDO se comprueba que no tengo la última versión
ENTONCES El sistema descargará la última versión del repositorio oficial en la máquina local
Y eliminará la versión anterior
Y realizará la invocación de TIEMPO REAL permitiendo el ingreso de usuario y contraseña
Y Presentará la información de la versión de tiempo real en la parte superior derecha de la pantalla ejemplo: "Versión 1.0.1"
Product Backlog Item 161:Registrar REUNIONES para TR --Validaciones

Yo como INGENIERO DE PRODUCCIÓN
deseo REGISTRAR LAS REUNIONES 
para QUE LOS IMPRODUCTIVOS QUEDEN CORRECTAMENTE BIEN AFECTADOS

Criterios de Aceptación

Que la pantalla tenga validaciones.

Nombre : 
máximo 20 caracteres: Sino se cumple poner mensaje de validación
mínimo 5 caracteres: Sino se cumple poner mensaje de validación

Descripción
mínimo 5 caracteres: Sino se cumple poner mensaje de validación
máximo 50 caracteres: Sino se cumple poner mensaje de validación
que el campo quede como un text area de 2 rengolones

Tiempo
mínimo 5 mín : Sino se cumple poner mensaje de validación
máximo 480 min: Sino se cumple poner mensaje de validación

Fecha 
igual o superior a hoy : Sino se cumple poner mensaje de validación
máximo, un mes mas : : Sino se cumple poner mensaje de validación
que los tiempos se ingresen.
que los tiempos en minutos.
que aparezca un mensaje de éxito o de fracaso.
que en el grid de reuniones aparezca la columna fecha
que se puedan quitar personas de la reunión
que la invitación de usuarios que permita filtrar por usuarios (que yo ingrese a y traiga todos los de a)
que la invitación sea organizable por nombre
que el listado de los invitados sea organizado por nombre




Tomado de: 


Como dueño de una cuenta
Yo quiero retirar efectivo de un cajero automático
De manera que pueda tener dinero cuando el banco esté cerrado.

Escenario 1: La cuenta tiene suficientes fondos
Dado que el balance de la cuenta es $100
Y la tarjeta es válida
Y el cajero tiene suficiente dinero
Cuando el dueño de la cuenta solicita $20
Entonces el cajero debe dispensar $20
Y el balance de la cuenta debe ser $80
Y la tarjeta debe ser retornada

Escenario 2: La cuenta no tiene suficientes fondos
Dado que el balance de la cuenta es $10
Y la tarjeta es válida
Y el cajero tiene suficiente dinero
Cuando el dueño de la cuenta solicita $20
Entonces el cajero no debe dispensar dinero
Y el cajero debe decir que no hay suficientes fondos
Y el balance de la cuenta debe ser $10
Y la tarjeta debe ser retornada

Escenario 3: La tarjeta ha sido bloqueada
Dado que la tarjeta esta bloqueada
Cuando el dueño de la cuenta solicita $20
Entonces el cajero debe retener la tarjeta
Y el cajero debe decir que la tarjeta ha sido retenida

Escenario 4: El cajero tiene fondos insuficientes

a la/s
Etiquetas: , , , , , ,

No hay comentarios.:

Publicar un comentario

Suscribirse a: Comentarios de la entrada (Atom)