Historias de Usuario Las historias de usuario se usan para capturar la esencia del valor de negocio de un sistema, y están escritas en un lenguaje cotidiano. Por ejemplo: Como enfermera necesito cambiar mi ubicación predeterminada, para visualizar mis datos preferidos cuando ingreso en la aplicación de Enfermería.
Y de ahí podemos desprender el formato básico de una historia de usuario: Como [rol] quiero [característica] para [valor de negocio] La enfermera es el usuario que utilizará la aplicación de Enfermería. Ella necesita poder configurar su ubicación predeterminada para no tener que perder tiempo en seleccionar una ubicación cada vez que ingresa a la aplicación. El valor de negocio aquí es que no perderá tiempo en hacer esto y en cambio podrá trabajar más rápido sin odiar al software por no ser amigable :) Dependiendo qué tanto lleven escribiendo historias de usuario, pueden que todavía no hayan descubierto un factor clave: los usuarios se meten en el medio. medio . No saben lo que quieren, e igualmente te lo van a pedir. Y lo vas a odiar. No los ignores. ignores . Sin importar cómo se presenten, debemos abordarlos con la mente abierta para encontrar la necesidad real. Si piden un botón o algún campo para ingresar un número, debemos determinar porqué lo necesitan. Si sólo lo quieren porque "queda bonito" o por algún valor insignificante que a) deberá retocarse r etocarse el resto del sistema, o b) lleva mucho tiempo hacerlo, probablemente debamos ver si realmente lo necesita (a largo plazo van a quejarse por cuánto tiempo llevamos desarrollando el cambio, y ahí vamos a responderle con un "vos querías ese botón", y nadie va a estar muy contento). Debemos averiguar lo que el usuario quiere, que propósito sirve, y si le va a servir para el resto de las personas que usan el software. No escribimos código para los casos frontera, escribimos software que funcione en los casos frontera. El sistema es desarrollado para el cliente, por lo tanto, el usuario es quien decide que tareas realizará la aplicación. Este planteamiento se desarrolla a lo largo del proyecto: el cliente es quien decide que hacer. Como primer paso, se debe proporcionar una idea clara de lo que será el proyecto en sí. Las historias de usuario son utilizadas como herramienta para dar a conocer c onocer los requerimientos del sistema al equipo de desarrollo. Son pequeños textos en los que el cliente describe una actividad que realizará el sistema; la redacción de los mismos se realiza bajo la terminología del cliente, no del desarrollador, de forma que sea clara c lara y sencilla, sin profundizar en detalles. Se puede considerar que las historias de usuario en XP juegan un papel similar a los casos de uso en otras metodologías, pero en realidad son muy diferentes. Las historias de usuario sólo muestran la silueta de una tarea a realizarse. Por esta razón es fundamental que el usuario o un representante del mismo se encuentren disponibles en todo momento para solucionar dudas, estas no proporcionan información detallada acerca de una actividad específica.
Las historias de usuario también son utilizadas para estimar el tiempo que el equipo de desarrollo tomará para realizar las entregas. En una entrega se puede desarrollar una o varias historias de usuario, esto depende del tiempo que demore la implementación de cada una de las mismas. Las historias de usuarios deben poder ser programadas en un tiempo entre una y tres semanas. Si la estimación es superior a tres semanas, debe ser dividida en dos o más historias. Si es menos de una semana, se debe combinar con otra historia.
Estructura de una Historia de Usuario Fuente: sixservix.com
El modelo INVEST El modelo INVEST es la clave para pensar y escribir buenas historias de usuario. Las historias deben ser Independientes, Negociables, Valiosas, Estimables, Pequeñas y Testeables.
Independiente - una historia debería ser independiente de otras (lo más posible). Las dependencias entre las historias hace que sea más dificil planificar, priorizar y estimar. A menudo, se puede reducir las dependencias haciendo una combinación de historias, o partiendo historias de forma diferente. Negociable - una historia de usuario es negociable. La "tarjeta" de la historia es tan sólo una descripción corta que no incluye detalles. Los detalles se trabajan durante la etapa de "Conversación". Una tarjeta con demasiados detalles limita la conversación con el cliente. Valiosa - cada historia tiene que tener valor para el cliente (para el usuario o para el comprador). Una forma muy buena de generar historias valiosas es hacer que el cliente las escriba. Una vez que el cliente se de cuenta que la historia no es un contrato y es negociable, van a sentirse mucho más cómodos para escribir historias. Estimable - los desarrolladores necesitan poder estimar una historia de usuario para permitir que se pueda priorizar y planificar la historia. Los problemas que pueden impedirle a los desarrolladores estimar una historia son: falta de conocimiento del dominio (en cuyo caso se necesita más Negociación / Conversación); o si la historia es muy grande (en cuyo caso se necesita descomponer la historia en historias más pequeñas). Pequeña - una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo. Una historia que es más grande va a tener más errores asociados a la estimación y alcance. Testeable - una historia necesita poder probarse para que ocurra la etapa de "Confirmación". Recordemos que desarrollamos aquello que no podemos probar. Si no podemos probarlo, nunca vamos a saber si lo terminamos. Un ejemplo de historia no testeable sería: "el software tiene que ser facil de usar".
ID: Identificador de la historia de usuario
TÍTULO: Título descriptivo de la historia de usuario
DESCRIPCIÓN: Descripción sintetizada de la historia de usuario
ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo (estas unidades representarán el tiempo teórico de desarrollo/hombre que se estipule al comienzo del proyecto) PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de las historias de usuario. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW: o
M – Must, se debe completar este requerimiento para finalizar el proyecto
o
S – Should, se debe completar este proyecto por todos los medios, pero el éxito
del proyecto no depende de él. o
C – Could, se debería completar este requerimiento si su implementación no
afecta a la consecución de los objetivos principales del proyecto. o
W – Would, se puede completar este requerimiento si sobra tiempo de
desarrollo (o en futuras versiones del mismo)
DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero a veces es inevitable. En este apartado se indicarían los IDs de las tareas de las que depende una tarea
El ciclo de vida de la tarjeta se compone de tres fases, conocidas como “Las 3 C” por sus iniciales en inglés ( Card, Conversation, Confirmation):
TARJETA (Card), la creación de la tarjeta en sí, con la estructura definida anteriormente y que sirve para determinar QUÉ se debe hacer y cómo planificarlo. CONVERSACION (Conversation ), representado por pequeños documentos y anotaciones que sirven para aportar detalles y refinar los datos sobre las características del requerimiento. CONFIRMACIÓN (Confirmation), o pruebas de aceptación. Pruebas consensuadas entre el cliente y el desarrollador y que el código debe superar para dar como finalizada la implementación del requerimiento.
Historias de Usuario vs. Casos de Uso
Historia de Usuario Numero: Usuario: Modificación de Historia N°: Prioridad en Negocio: (Alta,media,baja) Desarrollador encargado: Descripción:
Nombre: Iteración asignada Puntos Estimados:
Observaciones:
Historia de Usuario Numero: Usuario: Modificación de Historia N°: Prioridad en Negocio: (Alta,media,baja) Desarrollador encargado: Descripción:
Observaciones:
Nombre: Iteración asignada Puntos Estimados:
