La comunicación

El proyecto software que un equipo de desarrollo va a realizar en la mayoría de los casos no responde a una idea suya sino más bien a las necesidades que alguien (los usuarios) tienen. Los usuarios deben indicar lo que quieren resolver a otra persona (en el modelo tradicional un analista), éste a su vez captura lo que él ha entendido como requisitos del usuario y describe en forma de análisis de requisitos o funcional u algún modelo similar, lo que él ha entendido. Ese trabajo acabará finalmente en unas indicaciones más o menos concretas para que el equipo de desarrollo finalmente implemente el proyecto.

Una de las mayores preocupaciones es que el analista que capta las peticiones del usuario, suele terminar transmitiéndolas en un documento de difícil compresión para éste. Así en general los completos documentos de análisis de una aplicación rara vez suelen ser entendidos por los usuarios, que en general suelen basarse en lo que ellos aseguran que dijeron más allá de lo que especifique el documento de análisis.

Además, otro de los problemas del modelo en cascada es que requiere de un análisis completo de los requerimientos para generar un documento completo antes de iniciar las posteriores fases de diseño y desarrollo.

Una alternativa a estos modelos es utilizar las Historias de Usuario, como mecanismo para ser mucho más ágil a la hora de captar los requisitos, así como acercar la definición final de los mismos al último momento que se pueda, para conseguir captar cualquier cambio en las ideas iniciales.

Según Mike Cohn, las Historias de Usuario describen la funcionalidad de algo que es valioso para un usuario de un sistema o software.

Las Historias de Usuario se componen de tres elementos:

• Una descripción escrita de la historia usada para la planificación y como un recordatorio.
• Conversaciones sobre la necesidad de la historia que sirven para profundizar en los detalles de la misma
• Elementos de prueba que permiten determinar cuando las tareas que va a cubrir la historia está completa.

Así una historia debe permitir conocer la base de las necesidades del usuario, así como los detalles que después permitan fijar la batería de pruebas  para poder determinar si un desarrollo es correcto o no.

Inicialmente se fijaba que esas historias de usuario se escribieran en unas tarjetas en vez de en una libreta, lo que hizo que Ron Jeffries lo llamara CCC Card, Conversation, Confirmation (Tarjeta, Conversación y Confirmación). Así la tarjeta almacenaba la historia del usuario, y a través de la Conversación y la confirmación. Hay autores que afirman que las tarjetas son la mejor forma de almacenar las Historias de Usuario.

Otro de los aspectos fundamentales es que la historia de usuario debe estar expresada en un lenguaje  que el usuario pueda entender y que refleja una descripción sintetizada de lo que el usuario desea.

La descripción puede ser libre, aunque es generalmente el modelo propuesto por Mike Cohn es el aceptado.  En él que se indican tres cosas, ¿Qué tipo de usuario es el que solicita? ¿Qué se quiere? ¿Por qué se quiere?

Un ejemplo de Historia de Usuario podría ser:

“Como responsable de almacén quiero conocer cuando se alcanza el stock mínimo para poder realizar más órdenes de compra.”

 

Atributos de las historias de usuario

Las Historias de Usuario son peticiones muy sencillas y claras que definen cuales van a ser los requisitos del proyecto. Es preferible tener un número mayor de historias simples que uno menor de historias más complejas.

Pero hay una serie de atributos mucho más concretos que las Historias de Usuario deberían cumplir.  Bill Wake en su libro Programming Explored and Refactoring las denomina con el acrónimo INVEST que se basa en las iniciales de los seis atributos recomendables para las Historias de Usuario.

• Independent
• Negotiable
• Valuable to users or customers
• Estimatable
• Small
• Testable

 

A.        Independendientes (Independent)

 

Es razonable evitar la existencia entre dependencias entre las historias, es decir historias que para estar finalizadas dependen de la finalización de otras. Esto añade un punto más de complejidad a la planificación de realización de tareas, obligando a estar muy pendiente de estar interrelaciones y definir una priorización en la realización de las mismas.

Imaginemos las Historias de Usuario a definir para que un cliente pueda realizar el pago con diferentes tarjetas de crédito:

 

• Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
• Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard
• Como Jefe de ventas quiero que mis clientes puedan pagar con American Express

 

Las tres historias están muy relacionadas, además el coste en horas de implementación de cada una de ellas es dependiente de las otras. Es decir el tiempo para construir  la primera puede ser 4 horas y una vez realizada la primera, implementar las otras dos, tendrían un coste considerablemente menor. Existen dependencias entre las tres historias. La forma de evitarlas podría ser construir una historia que las englobe:

• Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjetas Visa, Mastercard y American Express

 

Si las historias todavía tienen un tamaño elevado, se puede hacer una subdivisión, más equivalente cuanto a coste

• Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
• Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard y AmericanExpress

 

Otra alternativa es que en la estimación de tiempo de cada historia se especifique el coste si se realiza antes o si se realiza después que otra (Aunque es un mecanismo algo complicado ya que añade un elemento más a los cálculos de costes).

 

B.        Negotiable (Negociables)

Es una de las bases de la programación ágil, las Historias de Usuario no son unos requisitos cerrados que permiten cerrar un contrato que no se puedan cambiar. Una Historia de Usuario es una breve descripción de la funcionalidad que muchas veces se puede utilizar como un recordatorio. Los detalles de la historia se suelen retrasar hasta los últimos momentos para precisamente evitar cambios de última hora.  Eso no impide que si en el momento de redactar la base de la historia, se conoce algún detalle se pueda anotar en la misma tarjeta toda la información que se conozca (aunque suele ser sensato contrastarla en el momento que sea necesario).

En este caso el cliente (el jefe de ventas) puede considerar en el momento de la entrevista que solo se admitan dos tarjetas aunque es razonable contemplar en la implementación que es posible que se incorporen  más.

Si se dispone de más información del requisito es bueno tomar nota de él. El reverso de la tarjeta es un lugar ideal para acompañar detalles útiles en la implementación.

La tarjeta es un recordatorio, personalmente yo recomiendo apuntar detalles que generan duda o incertidumbres a contrastar directamente, hay que olvidar el famoso dicho de “no hace falta apuntarlo ya que ya lo recordaré”. Es bueno tomar nota, e incluso subrayar si es necesario realizar una consulta a otras personas.  Estas pequeñas notas en el reverso pueden ayudar en la segunda entrevista al usuario.

 

 

 

C.        Valuable (Con valor para el usuario)

Es uno de los aspectos más controvertidos sobre las Historias de Usuario. Hay quién indica que las historias deben aportar valor al usuario y por eso es razonable que el usuario las pida directamente. Yo considero que todas las historias que se implementen deben tener valor para el usuario aunque éste inicialmente no lo sepa.

El usuario debería estar seguro que todas las historias le aportan valor. En general, temas de seguridad a muchos niveles no les preocupan (no porque no lo consideren importante, sino porque a veces lo dan por hecho). Las Historias de Usuario deben aportar valor, en general se definen en base a peticiones del usuario, no obstante cabe la posibilidad de definir historias de usuario a partir de criterios técnicos por parte del equipo. Es estos casos es necesario que se explique correctamente al usuario los motivos de necesidad de estas.

 

D.       Estimatable (Estimable)

El equipo de desarrollo debe poder estimar el coste (al menos aproximado) de desarrollar cada una de las Historias de Usuario. Es un requisito fundamental para poder planificar de manera razonable las historias que se pueden desarrollar dentro de un Sprint. La forma de medir el coste puede ser las horas de desarrollador  o los puntos de historia (tratados en capítulos anteriores)

Es posible que el coste de una historia no pueda ser calculada con un nivel de precisión razonable, los motivos habituales por los que esto pueda ocurrir son

1. El equipo de desarrollo no conoce el dominio. Ya se comentará en el tema de la entrevista. Obviamente el equipo de desarrollo no puede pretender tener el mismo conocimiento que tiene el cliente del entorno de trabajo de éste. Aun así, es conveniente adquirir unas bases que permitan, en primer lugar dar confianza al cliente, y en segundo lugar abordar con el suficiente conocimiento los desarrollos a realizar.
2. El equipo de desarrollo no tiene conocimientos técnicos del entorno. También puede ocurrir que el equipo de desarrollo deba trabajar en un entorno de programación o base de datos novedoso (al menos para ellos) que puede hacer que estimen sin un nivel de confianza lo suficientemente alto. Es este caso se agradece la aportación de expertos en el entorno que pueden hacer ver las comparaciones de costes con entornos mejor conocidos por el equipo de desarrollo. Si no se dispone de ningún experto, es razonable que algunos miembros del equipo profundicen de manera rápida en el tema. Esta profundización debe contar como una historia más, ya que tiene su coste en horas.
3. La historia es demasiado compleja o tiene un tamaño muy grande. Este caso es el más sencillo de resolver, se debe dividir la historia en dos o más historias de menor tamaño que puedas ser estimadas con mejor precisión.

E.        Small (Pequeña)

El concepto pequeña es muy relativo, pero entendemos como que la Historia de Usuario debe tener una duración que la haga lo suficiente manejable para el equipo. Pequeña no debe confundirse con microscópica, ya que tener un sinfín de cientos de historias microscópicas puede convertir en un infierno la planificación y la integración de todas en el proyecto final.

Es razonable que el equipo de desarrollo defina un coste razonable para las Historias de Usuario estándar con las que van a trabajar. Algunos hablan de semana/programador como el tiempo máximo, mientras otros equipos prefieren definir como un día/programador como un coste medio razonable.

Una historia que fuera como jefe de ventas quiero una “gestión web de las ventas para incrementarlas” tiene una dificultad considerable para ser estimada.

Debiera poder dividirse inicialmente en gestión de usuarios, de productos y en sí de la venta. Aun así cada una de ellas tiene una complejidad elevada. Es posible que la gestión de usuarios al ser bastante estándar pudiera (quizá no debiera) quedar como una historia.

Es más razonable definir historias del tipo:

• Como jefe de ventas quiero poder dar de alta un producto para venta
• Como jefe de ventas quiero poder modificar características de un producto o eliminarlo
• Como jefe comercial quiero poder añadir campaña comerciales que afecten al precio de venta del producto

Un modelo de historias de este tipo es que permite de manera sencilla estimar el coste de cada historia e incluso permite que el cliente pueda priorizar entre las mismas. Así podemos iniciar una página de venta con productos y más adelante permitir la incorporación de campañas comerciales de diverso tipo.

 

La gestión de usuarios, bastante estandarizada puede ser considerada como una única historia de usuario más allá de historias del tipo:

• Como jefe de ventas quiero poder dar de alta un usuario
• Como jefe de ventas quiero poder modificar un usuario
• Como jefe de ventas quiero poder dar de baja un usuario
• Como jefe de ventas quiero poder consultar un usuario

Pero no hay que olvidar que el concepto de Small (pequeño) es muy dependiente de como el equipo de desarrollo se sienta cómodo. En sí lo que si debe garantizar al cien por cien es que toda historia de usuario debe ser estimable y deba tener un coste mínimo algo más alto que el tiempo que se pierda en hablar de ella.

F.         Testable (Se puede validar)

Otro de los conceptos que hemos visto como un tema fundamental es el de terminado. Una historia debe tener unos objetivos claros, y deben ser tan claros que deba ser posible comprobar que el trabajo ha cumplido las expectativas, es decir que se pueda validar el trabajo realizado.

Otro de los objetivos es que el mayor número de historias se pueda validar de forma automática, por lo que es muy interesante utilizar conjuntos de aplicaciones de prueba que así lo permitan. En ocasiones, esto es complicado, pero hay que definir claramente una batería de pruebas que pueda ser realizada para verificar lo correcto de un programa o módulo. El coste de realizar las pruebas se debe incluir en el coste de la historia de usuario, a menos que haya alguna historia que tenga como objetivo la realización de una serie de pruebas de conjunto.

Sólo los requisitos no funcionales como pueda ser “conseguir un Interfaz amigable o facilidad de uso para usuario novel” pueden evitar la definición de esas baterías de prueba. No obstante se pueden definir tareas más complejas que exceden al equipo de desarrollo y que permitan hacer una estimación del grado de resolución de algunos requisitos no funcionales.

 

Conclusiones

Las Historias de Usuario son una forma de acercar el lenguaje del usuario al desarrollador, de forma que se permita hablar un mismo lenguaje ambos y se eviten ambigüedades que puedan suponer pérdidas de tiempo notables.

Lo importante de las historias es que reflejen de forma sencilla lo que el usuario quiere, “El qué” y no “el cómo”.  Es importante que sean muy claras y  con criterios de validación muy concretos. Durante el proceso, las historias pasarán a ser grandes trabajos a realizar muy generalmente especificados, hasta ser tareas concretamente detalladas, pero es un proceso por fases, que permite detallar la tarea junto con el cliente cuando se van a implementar.