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.