Buscar en Gazafatonario IT

domingo, julio 21, 2013

Historias de Usuario: un nuevo orden en los requisitos del software

Papiro - Historias de Usuario: un nuevo orden en los requisitos del software
Las Historias de Usuario no requieren almacenarse en
documentos pesados o especiales
VademeScrum, Sección 2: Las Historias de Usuario 1
Estoy escribiendo un artículo sobre Scrum sin Historias de Usuario, pero entonces noté que quizás muchos de mis lectores no sabrían que es una historia de usuario y por qué se usan en Scrum. Así es que tomé la decisión de cambiar el curso del destino y escribir primero sobre este asunto. En el desarrollo ágil, la historia de usuario es un sustituto más ligero para lo que han sido nuestros medios tradicionales de especificar requisitos de software: documentos de especificaciones de requisitos de software, especificaciones de casos de uso y similares.
Ejemplo 1: La historia de usuario “Leer un libro”
Pensemos en una historia de usuario como una manera de dejar un legado, algo que trascienda más allá del tiempo, por ejemplo, de un proyecto y que permita que las culturas sobrevivan. Para ello, las historias tienen que ser simples, cortas, fáciles de entender y de aceptar y de franca recordación sin que tengan que escribirse todos sus detalles. Ese es el gran poder de las historias de usuario. Veamos, por ejemplo, la siguiente historia de un caso no software pero que ilustra perfectamente la estructura y comportamiento de una historia de usuario:
Como: crítico literario
Quiero: leer un libro
Para: escribir una reseña sobre el libro
Estos tres elementos conforman el núcleo de toda historia de usuario. En el primero (Como) se establece quién es el usuario o grupo de usuarios que “intervienen” en la historia, típicamente es un rol de usuario, en el desarrollo de software este elemento responde a la pregunta “quién usará la funcionalidad” descrita por esta historia. El segundo elemento (Qué) es la actividad, el eje de la historia, qué hace el usuario en la historia. Y el tercer elemento (Para) es el propósito de la historia, la meta que quiere alcanzar el usuario al ejecutar la historia. Todos, en conjunto, describen una finalidad, más que un requisito.
Definición
En resumen, una Historia de Usuario es una corta declaración de intención que describe algo que el sistema necesita hacer para el usuario. Se describe desde el punto de vista de quien usará la funcionalidad, es decir, su usuario. Pero ya que definimos qué es una historia de usuario, dejemos claro también qué no es: no es una especificación detallada de requisitos de software, algo que el sistema debe hacer, es más bien, un contrato negociable de intención que indica que el sistema necesita hacer algo más o menos así.
Algunas características de las historias de usuario son:
  • Son cortas y fáciles de leer, entendibles por los desarrolladores, interesados y usuarios
  • Representan incrementos pequeños de funcionalidad valorada, que puede ser desarrollada en un período de días o semanas
  • Son relativamente fáciles de estimar porque el esfuerzo de implementar la funcionalidad puede determinarse rápidamente
  • No se llevan en documentos grandes o pesados, sino más bien en listas organizadas que pueden ordenarse más fácilmente y reordenarse a medida que se descubre nueva información
  • No se detallan al principio del proyecto, sino que se elaboran sobre una base JIT – evitando así especificidad demasiado pronto, retardos en el desarrollo, inventario de requisitos y una declaración sobre-restringida de la solución.
  • Necesitan poco o ningún mantenimiento y se pueden desechar con seguridad después de la implementación
  • Las historias de usuario, y el código que se crea rápidamente a continuación, sirven como insumo para la documentación, la cual también es elaborada de manera incremental.

Ejemplo 2: La historia de usuario “Ingresar a la red social”
Un aspecto que viene con la simplicidad y el tamaño relativamente pequeño de las historias de usuario es que, por lo general, representan funcionalidades parciales, es decir, no indican funciones o procedimientos complejos y grandes que el sistema debe hacer. Por ejemplo, podríamos tener una historia llamada “Ingreso Básico a la Red” para especificar la entrada a una red social en Internet. El usuario es un “miembro de la red” y lo que hace más habitualmente este miembro es compartir enlaces con sus contactos. La historia luciría más o menos así:
Como: miembro de la red social
Quiero: ingresar a la red
Para: compartir un enlace
La “Narración” de las Historias de Usuario
Pero y ¿dónde están los detalles de la historia de usuario? ¿Cómo sabemos que efectivamente la historia descrita en el ejemplo anterior es simple y representa una funcionalidad parcial? ¿Cómo ingresa el usuario a la red? Estos pormenores se dan durante la Conversación y se especifican en los Criterios de Aceptación de la Historia. La Conversación representa una discusión entre el equipo, el usuario, el propietario del producto y los otros interesados, que es necesaria para determinar el comportamiento más detallado requerido para implementar la intención.
En el ejemplo citado, la conversación puede responder a preguntas como:
  • ¿Qué información necesita el usuario proporcionar al sistema para ingresar?
  • ¿Es obligatoria toda la información o puede ser parcial, esto es, hay datos opcionales?
  • ¿Qué ocurre cuando la información está incorrecta o incompleta?

Encontrar respuestas  a estas y a otras cuestiones relacionadas delimita la funcionalidad de la historia. Por ejemplo, en una primera entrega del software o salida a producción del mismo, podemos acordar con los usuarios tener solo la funcionalidad básica de ingreso, de allí el nombre de la historia establecido en la sección anterior. O sea, solo se solicitará un nombre de usuario y una contraseña con algunas características. A continuación, el sistema validará que el par nombre de usuario + contraseña coincidan y permitirá el ingreso del usuario, nada más. En caso contrario mostrará un mensaje advirtiendo la imposibilidad de ingreso a la red.
Entre tanto, los criterios de aceptación, llamados también Confirmación, representan las condiciones de satisfacción que se aplicarán para determinar si la historia cumple o no la intención así como los requisitos más detallados. Es precisamente la Prueba de Aceptación del usuario, que muestra cómo el usuario confirmará que la historia se ha implementado a su entera satisfacción. Los flujos alternativos en la actividad, los límites de aceptación y otras clarificaciones deberían capturarse junto con la historia. Muchos de estos se pueden convertir en casos de pruebas de aceptación u otros casos de pruebas funcionales, para la historia.
En la historia “Ingreso Básico a la Red”, estos criterios de aceptación podrían incluir:
  • El nombre de usuario es la dirección de correo electrónico del usuario.
  • La contraseña debe contener letras y números.
  • La contraseña debe ser de al menos 8 caracteres y máximo de 32.
  • El usuario ya debe estar registrado en la red social.
  • Si la contraseña no coincide con el nombre de usuario, el sistema mostrará el mensaje “Combinación incorrecta de correo electrónico/contraseña”.
  • Entre otros.

Notamos de inmediato que en esta historia “Ingreso Básico a la Red” no se estableció nada acerca de olvido de la contraseña o del nombre de usuario, o qué ocurre luego de mostrar el mensaje sobre datos incorrectos, o de cambio de contraseña o de otras funcionalidades adicionales al ingreso como “No cerrar sesión”, restablecer la contraseña, usar el número de teléfono móvil en vez del correo electrónico para ingresar o si la cuenta se bloquea al hacer varios intentos de ingreso fallidos y qué se debe hacer para restablecer el acceso, entre muchas otras cosas que giran alrededor del ingreso a la red. Estos detalles pueden hacer parte de otras historias a construirse más adelante para la versión actual del producto o para otras versiones sucesivas del producto.
Lo que hicimos con este ejemplo fue encontrar la historia de mayor valor para el negocio, es decir, esa funcionalidad o parte de la funcionalidad que será usada la mayor parte del tiempo por los usuarios y que, por consiguiente, permite obtener el máximo valor de negocio o el retorno de inversión más rápidamente posible. Recordemos que cuando se trata de desarrollo de software, las prácticas ágiles lo son porque permiten entrega rápida de valor. Hablaremos de este asunto en otra oportunidad porque me parece vital a la hora de acoger los principios o pilares ágiles.
Ejemplo 3: La historia de usuario “Quiero publicar una entrada básica de blog”
Veamos un ejemplo completo de una historia de usuario relacionada con la creación de blogs y la publicación de entradas al blog.
Carta:
Como Bloguero (<rol de usuario>) quiero ser capaz de publicar entradas en un blog (<lo que hago con el sistema>) para aumentar mi credibilidad y posicionarme como experto en el área de mi interés (<valor del negocio que recibo>).
Conversación:
P1. ¿Cuál es su área de interés? (El equipo al Bloguero)
R1. El área de mi interés es la literatura contemporánea hispanoamericana
P2. ¿Cuál es el público esperado?
R2. El público esperado es el compuesto por jóvenes y adultos
P3. ¿Cuál es la frecuencia de publicación?
R3. El objetivo es publicar una entrada quincenal
(Sigue…)
En el caso de Scrum, esta conversación se da típicamente durante la planeación del sprint, al principio del mismo, y durante el sprint.
Confirmación (criterios de aceptación): 
El contenido de las entradas debe ser texto principalmente
El sistema debe permitir entradas de hasta tres mil palabras
Cada entrada debe llevar un título de hasta 256 caracteres
Cada entrada debe publicarse en una página separada
(Sigue…)
Este esquema estructural de la historia de usuario es lo que se conoce como la “Aliteración Carta, Conversación, Confirmación”, propuesta por Ron Jeffries, uno de los co-creadores de eXtreme Programming o XP.
¿Cuándo se usan las historias de usuario?
Dado su carácter de simplicidad y tamaño (pequeño), la poca información explícita que contienen, las historias de usuario se usan o son beneficiosas cuando hay requisitos cambiantes, lo que ocurre la mayor parte del tiempo, pero y más importante, cuando los usuarios o representantes de estos están disponibles sin protocolo para que el equipo de desarrollo resuelva todas las inquietudes que se le presenten mientras convierten la historia en funcionalidad. En Scrum, por ejemplo, ese representante de los usuarios e interesados en el producto es precisamente el Dueño del Producto.
En otros artículos proporcionaré más ejemplos, buenas prácticas para identificar y documentar historias de usuario y hablaré de los principales atributos de toda historia de usuario, agrupados bajo las siglas INVEST.

Otros artículos de esta serie:

Sobre los atributos INVEST de las historias de usuario:

Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_19.html

6 comentarios:

  1. He revisado el tema de historias de usuario y metodología Agile y aún no encuentro la manera como estas historias de usuario contengan el suficiente detalle para implementar una funcionalidad, viendolo desde la perspectiva RUP, las historias de usuario serían sólo Características del sistema, pero no encuentro aún como un desarrollador puede iniciar partiendo de algo con tan pocos detalles.

    ResponderBorrar
    Respuestas
    1. Importante asunto, interesante por demás. En efecto, las Historias de Usuario tienen cabida en un contexto ágil, tal cual se deriva de los valores y principios ágiles, personas y sus interacciones, colaboración con el cliente, respuesta al cambio, etc. Es decir, en un entorno de trabajo colaborativo, donde el conocimiento tácito tiene tanta validez que el explícito, donde la mejor forma de comunicación es la reunión cara a cara.

      En la definición digo, en breve, que la Historia de Usuario, es una “carta de intención”, un recordatorio de una conversación que va a ocurrir más adelante, justo cuando se va a iniciar el proceso de su transformación en software. En Scrum, por ejemplo, eso ocurre típicamente en una sesión de planificación o en sendas reuniones de refinamiento. Con esto en mente, una historia de usuario no es un requisito de software, al menos no como lo conocemos a la mejor de usanza de RUP, por ejemplo, con los casos de uso. Bien dices que se trata de características. Los detalles se obtienen durante sucesivas conversaciones con los usuarios (con el Dueño del Producto en un equipo Scrum, por ejemplo).

      Ahora bien, no debemos ver este mecanismo desde la perspectiva RUP, en este sentido te invito a considerar Casos de Uso 2.0, cuyo eje cardinal son las porciones de casos de uso. Casos de Uso 2.0 son tan livianos como las historias de usuario y tienen además el poder del modelado de los casos de uso. Sobre casos de uso 2.0 puedes leer mi serie de artículos en este mismo Gazafatonario:

      http://www.gazafatonarioit.com/2012/04/casos-de-uso-20.html
      http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html
      http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html
      http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-aplicable-todos-los.html
      http://www.gazafatonarioit.com/2012/11/casos-de-uso-20-cosas-con-las-cuales.html
      http://www.gazafatonarioit.com/2013/02/todavia-otra-leccion-mas-sobre.html

      El libro, en su edición en español, lo puedes descargar gratuitamente de:
      http://www.ivarjacobson.com/resource.aspx?id=2018

      Salud@s,

      Borrar
    2. Uno de los principios basicos de las metodologias ágiles es un software funcional ante una extensa documentación. El porque las metodologias agiles son tan efectivas al entregar productos software que satisfacen las necesidades del cliente, es sencillamente porque la comunicación sobre el proyecto fluye libremente por todo el equipo de desarrollo.

      Borrar
    3. El problema que veo es dentro de una empresa cuando al finalizar, despues de 20 meses y 2000 reuniones donde el cliente ya vio en cada paso lo que se estaba haciendo y como se hacia... Dice: "Ahhh, pero esto no es lo que esperabamos". Entonces ahi no hay evidencia de nada de que el cliente quiso las cosas asi. Suele pasar mucho en las empresas que piden "A" y despues salen diciendo que en realidad querian "B", independientemente de que se les fue mostrando todo paso a paso cuando se estaba construyendo.
      Con los requisitos bien especificados (Algo muy tedioso), sirven como evidencia de lo que se fue pidiendo.
      En cambio lo que veo con las HU, es que es mas bien una expresion deseo para un llegar a un fin, sin importar mucho como se haya implementado, si se llega a ese fin, listo.

      El pro de las HU, es que agilizan las cosas.
      La desventaja es que no sirven para evitar que al final el cliente se haga el dolobu y desconosca lo que pidio.

      El pro de los requisitos tediosos de siempre, es que no puede decir nada el cliente porque todo quedo por escrito, y si lo aceptó, es su problema.
      La desventaja es que es un dolor de huevos hacerlos y modificarlos.

      Borrar
    4. Hola:

      Muchas gracias por tu comentario. Resulta que los equipos ágiles no esperamos 20 meses y 2000 reuniones para que el usuario nos cuente si eso es lo que quiere o no. En cada Sprint (de menos de un mes --por ejemplo, de 2 semanas), mostramos al usuario software probado y funcionando, o sea, las historias de usuario construidas, y obtenemos la retroalimentación de manera inmediata. Esto es más efectivo, ya que si nos equivocamos, en conjunto, el usuario y el equipo, tienen tiempo de reaccionar y adaptarse para actuar en consecuencia.

      Las cosas así, el usuario puede introducir cambios cada vez que lo requiera, asunto muy natural en los proyectos de software, sin que haya que montar una estrategia compleja para manejar esos cambios. Los equipos ágiles aprovechamos los cambios para brindar ventaja competitiva al cliente.

      Saludos,

      Borrar
  2. muy buena la traducción de los casos de uso mi estimado Lucho. Saludos!

    ResponderBorrar