Historias de Usuario

Programacin Orientada a Objetos

1
Historias de Usuario

Uno de los puntos que ms interrogantes provocan en la gente que se
acerca a las metodologas giles es cmo dividir el desarrollo de un
proyecto en historias de usuario, es decir en tareas lo ms pequeas
posibles que aporten valor funcional al cliente.

En este documento se explicara el enfoque recomendado cuando se
trata de describir un requisito funcional cmo historia de usuario.
Obviamente no es la nica opcin, ni la mejor, se aceptan
sugerencias y/o mejoras, pero creemos que puede ser til cmo
primera aproximacin para aquellas personas que no tengan del todo
claro un procedimiento a seguir.

Vamos a tomar como ejemplo la especificacin para un sistema de
bibliotecas:

Se quiere desarrollar un sistema sencillo de control de prstamos en una
biblioteca. El sistema debe admitir el alta y la baja de socios y de libros. Los socios
pueden pedir libros en prstamo, pero no se pueden tener ms de tres libros en
prstamo en un momento determinado. Los libros se han de devolver antes de un
mes de la fecha del prstamo. Cada vez que un socio devuelve un libro despus de
la fecha de la devolucin, se penaliza reduciendo en una unidad el nmero de libros
que puede tener simultneamente. Cuando llega a cero el socio se de de baja
automticamente.

Ahora supongamos que este problema nos lo ha planteado nuestro
cliente, que quiere que le construyamos exactamente el sistema
descrito en el enunciado Cmo llegamos desde el mismo, a la lista
de tareas a desarrollar del producto? Por el momento vamos a obviar
aquellas tareas que a simple vista no aportan valor al cliente pero
que son del todo necesarias para el proyecto (definir e implementar
la arquitectura del sistema por ejemplo) y vamos a centrarnos
nicamente en los objetivos funcionales.

Lo que vamos a hacer va a ser un clsico anlisis de
requerimientos, intentando extraer del texto (lo que nos dice el
cliente) las diferentes funcionalidades que debe tener el sistema. Para
ello analizamos los prrafos del texto. A simple vista podemos extraer
las siguientes funcionalidades:


De la siguiente frase: El sistema debe admitir el alta y la baja de socios y de
libros extraemos las siguientes posibles historias de usuario:



Historias de Usuario
Programacin Orientada a Objetos


2
Alta Libro
Baja Libro
Alta Socio
Baja Socio

Del prrafo siguiente: Los socios pueden pedir libros en prstamo, pero no se
pueden tener mas de tres libros en prstamo en un momento determinado
obtenemos una nica funcionalidad o historia
Prstamo libro

En este prrafo: Los libros se han de devolver antes de un mes de la fecha del
prstamo. Cada vez que un socio devuelve un libro despus de la fecha de la
devolucin, se penaliza reduciendo en una unidad el nmero de libros que puede
tener simultneamente creo que podran identificarse dos historias (es mi
opinin, quizs otra gente opine que slo hay una posible historia)
Devolver libro
Penalizar socio

En el ltimo prrafo obtenemos otra posible historia: Cuando llega a cero
el socio se de de baja automticamente. Aunque pueda parecer que es una
historia repetida, yo considero que a nivel de valor al cliente es una
funcionalidad diferente.

Baja automtica de socio




Historias de Usuario
Programacin Orientada a Objetos


3
Aparte de las historias que aparecen ms o menos explcitas en el
cdigo, quizs podran deducirse otras historias cmo:


Iniciar sesin en el sistema
Cerrar sesin
Alta usuario
Baja usuario

La lista completa de historias que tendramos sera la siguiente:
Alta libro
Baja libro
Alta socio
Baja socio
Prstamo de libro
Devolver libro
Penalizar socio
Baja automtica de socio
Iniciar sesin en el sistema
Cerrar sesin
Alta usuario
Baja usuario

Si estuviramos en una metodologa clsica de desarrollo, en este
punto deberamos hacer los casos de uso para los
requerimientos identificados, sus diagramas de secuencia, etc.
En una metodologa gil, por definicin, no es necesaria esta
documentacin (queda a eleccin de cada uno decidir que



Historias de Usuario
Programacin Orientada a Objetos


4
documentacin necesita su proyecto) y lo que nos quedara por hacer
es definir e introducir las historias en la lista de tareas a desarrollar
del producto. Y cmo se define una funcionalidad en forma de
historia de usuario? Pues la idea es expresarla desde el punto de vista
del cliente, o del usuario que va a usar el sistema, con un lenguaje
que pueda ser entendido perfectamente por ellos (nada de UML, OCL
o dems lenguajes de especificacin) y que no cree ambigedades.
Por ejemplo:

Historia: Prstamo de libro
ID: 5
Descripcin: Cmo cliente quiero que los socios puedan pedir
prestado un libro, indicando su nmero de socio y la referencia del
libro, siempre y cuando no tengan ya tres libros en prstamo en ese
momento.
Importancia: 300
Cmo probarlo:
Introducir un nmero de socio incorrecto y comprobar que se
indica error
Introducir un socio que ya tiene 3 libros en prstamo y
comprobar que se indica error
Introducir un libro del que no hay ejemplares y comprobar que
se indica un error
Introducir todos los datos correctos y comprobar que el nmero
de ejemplares disponibles del libro disminuye y el nmero de
prstamos del socio aumenta en uno.
Cmo vemos, en las metodologas giles se detalla de manera poco
explcita la funcionalidad, nicamente se explica a nivel de cliente. La
ventaja es que no se fijan los detalles de la implementacin hasta el
momento en que se va a realizar (en la descomposicin en tareas)
con lo que se puede reaccionar ms gilmente ante los cambios de
los requisitos o de las necesidades del cliente.



Historias de Usuario
Programacin Orientada a Objetos


5

Haciendo lo mismo con las dems funcionalidades, nos quedara un
una lista de requerimientos del producto similar a lo siguiente (se ha
obviado la parte de test de las historias):

Historia Importancia Descripcin
Alta libros 600 Dar de alta un libro en el sistema
Baja libros 250 Dar de baja un libro del sistema
Alta socio 500 Dar de alta un socio en el sistema
Baja socio 300 Dar de baja un socio del sistema
Pedir libro 350 Pedir prestado un libro
Devolver libro 340 Devolver un libro
Penalizacin socio 330 Penalizar al socio por retrasarse en la devolucin
Baja automtica 320 Dar de baja automticamente de socio
Iniciar sesin en el
sistema
550 Iniciar una sesin de usuario en el sistema
Cerrar sesin 500 Terminar sesin con el sistema
Alta usuario 450 Dar de alta un nuevo usuario en el sistema
Baja usuario 400 Dar de baja un usuario del sistema
En este punto tenemos identificadas todas las tareas funcionales del
proyecto, y se ha descrito cada una de ellas cmo una historia de
usuario.

Aunque ya tenemos completa la lista de funcionalidades, es obvio que
el listado de historias del producto tal y como est no es suficiente
para poder avanzar en el proyecto, ya que no aparecen todas
aquellas tareas que no son funcionales (historias tcnicas,
requisitos no funcionales o como se le quieran llamar) pero que son
necesarias para el desarrollo del proyecto. Pero la mayora de estas
tareas no aportan valor al cliente, entonces Se deben incluir estas
tareas en la lista de tareas del producto? Y de que manera? Pues, se
podra gestionar de la siguiente forma:
En proyectos que se estn iniciando, es fcilmente justificable
introducir tareas tcnicas o no funcionales, ya que sin ellas el
proyecto no existe. As bajo la forma de Epics (o sper historias de
usuario) se podran englobar tareas tales cmo Implementar la capa



Historias de Usuario
Programacin Orientada a Objetos


6
de datos, implementar la capa de comunicaciones, etc. Estas tareas
se llevaran a cabo en las primeras iteraciones, o incluso en una
primera iteracin mayor que las otras.
En fases ms avanzadas del proyecto, es difcil justificar tareas no
funcionales, cmo la refactorizacin de mdulos, instalacin de
servidores de pruebas, etc. Ya que el cliente querr priorizar aquellas
historias que le aporten valor. En este caso lo ideal es intentar que el
cliente comprenda la importancia de las tareas a realizar, o si eso no
es posible utilizar otras tcnicas, cmo introducirlas dentro de alguna
de las historias de usuario, o mantener una lista separada de
historias tcnicas con un porcentaje de tiempo no negociable con el
dueo de producto.
Cmo hemos visto el proceso de definir historias de usuario es tan
simple (o tan complicado) cmo realizar un anlisis de
requerimientos, proceso para el cual no hay ningn truco infalible y
depender en gran medida de la experiencia y pericia del analista o
analistas que se encarguen de l, y expresar las funcionalidades
resultantes del anlisis en un lenguaje que pueda ser fcilmente
entendido por el cliente de nuestro proyecto.

Grficamente:



Historias de Usuario
Programacin Orientada a Objetos


7

ID: Identificador de la historia de usuario
TTULO: Ttulo descriptivo de la historia de usuario
DESCRIPCIN: Descripcin sintetizada de la historia de usuario
ESTIMACIN: Estimacin del coste de implementacin en unidades de
desarrollo (estas unidades representarn el tiempo terico de
desarrollo/hombre que se estipule al comienzo del proyecto)
PRIORIDAD: Prioridad en la implementacin de la historia de usuario
respecto al resto de las historias de usuario. A mayor nmero, mayor
prioridad. Otra aproximacin a la priorizacin de tareas se hace a travs del
mtodo 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 debera completar este requerimiento si su
implementacin no afecta a la consecucin 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 debera ser dependiente de
otra historia, pero a veces es inevitable. En este apartado se indicaran 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 ingls (Card, Conversation, Confirmation):



Historias de Usuario
Programacin Orientada a Objetos


8
TARJETA (Card), la creacin de la tarjeta en s, con la estructura definida
anteriormente y que sirve para determinar QU se debe hacer y cmo
planificarlo.
CONVERSACION (Conversation), representado por pequeos documentos y
anotaciones que sirven para aportar detalles y refinar los datos sobre las
caractersticas del requerimiento.
CONFIRMACIN (Confirmation), o pruebas de aceptacin. Pruebas
consensuadas entre el cliente y el desarrollador y que el cdigo debe
superar para dar como finalizada la implementacin del requerimiento.

REFERENCIAS
1.- http://www.userstories.com/
2.- http://en.wikipedia.org/wiki/User_story