Mejorando la gestin de historias de usuario en o eXtreme Programming*

Emilio A. Snchez Patricio Letelier Jos H. Cans a e o

Departamento de Sistemas Informticos y Computacin a o Universidad Politcnica de Valencia e Camino de Vera s/n 46022 Valencia - Espaa n {emsanchez|letelier|jhcanos}@dsic.upv.es

Resumen Extreme Programming (XP) es una de las llamadas metodolog agiles que ms inters ha generado en el ambito industrial y acadas a e e mico. Sin embargo, llevada a la prctica surgen inconvenientes no abora dados expl citamente por la documentacin disponible. En este trabajo o se estudia la problemtica de los requisitos, la cual en el contexto mina imalista de XP se reduce a la especicacin y seguimiento de las hiso torias de usuario (User Stories). El planteamiento de XP al respecto es muy sencillo, pero debido a la gran cantidad de historias de usuario que puede tener el proyecto y a la volatilidad de los requisitos, su gestin o puede llegar a ser complicada. En este trabajo damos algunas pautas para abordar las alternativas de evolucin que puede sufrir la historia de o usuario y presentamos el prototipo de una herramienta para gestionar historias de usuario que apoya dichas pautas.

1.

Introduccin o

En la actualidad las metodolog agiles estn acaparando gran atencin en al as a o ambito industrial y acadmico de ingenier del software. Mucho se ha debatido e a respecto a este nuevo estilo de desarrollar software, caracterizado por su minimalismo en cuanto a artefactos generados, roles y actividades. Esto ha generado un cruce de cr ticas entre las comunidades asociadas, metodolog agiles [1] frente as a metodolog tradicionales (o peyorativamente llamadas metodolog peso as as pesado, siendo las agiles sinnimo de peso ligero [16]). Probablemente los ex o ponentes ms populares en ambas categor son RUP (Rational Unied Process) a as [13] y XP (eXtreme Programming) [2], como metodolog tradicionales y agiles as respectivamente. Existen comparaciones entre ambas metodolog [15][11][12] e as incluso propuestas de adaptacin de RUP con prcticas XP[14]. o a XP es la metodolog agil de la cual se dispone mayor informacin, tanto a o en libros como en Internet, sin embargo, an no se cuenta con datos rigurosos u referentes a los resultados en su aplicacin. Esfuerzos como el realizado por la o red europea NAME [8] van dirigidos precisamente en esta direccin. o
*

Este trabajo ha sido nanciado por el proyecto DOLMEN-SIGLO de la Comisin o Interministerial de Ciencia y Tecnolog TIC2000-1673-C06-01. a,

Basndonos en nuestra experiencia en la aplicacin acadmica de XP [5] a o e en los dos ultimos aos y en los resultados obtenidos [6][7], hemos detectado n algunos inconvenientes en la especicacin y seguimiento de requisitos. En XP o la gestin de requisitos es extremadamente simple, el cliente escribe y prioriza o las historias de usuario que expresan requisitos funcionales y no funcionales del sistema. Los programadores estiman el esfuerzo asociado (no ms de la duracin a o de una iteracin) y las dependencias entre ellas. Para planicar el trabajo desde o el punto de vista tcnico las historias de usuario son divididas en tareas para e las cuales tambin se realiza una estimacin (el esfuerzo asociado a estas tareas e o no debe superar los 3 d de programacin). Teniendo en cuenta el esfuerzo as o asociado a las historias de usuario y las prioridades del cliente se dene una release que sea de valor para el cliente y que tenga una duracin de unos (pocos) o meses. La release es dividida en iteraciones de no ms de 3 semanas, asignando a a cada iteracin un conjunto de historias de usuario que sern implementadas. o a Esta sencilla prctica es denominada en XP Juego de la Planicacin. Durante a o el desarrollo de la iteracin y en particular al nal de cada iteracin se realiza o o un seguimiento del plan de la iteracin y de la release. Es de esperar situaciones o relativas a historias de usuario tales como: aparicin de nuevas, postergacin en o o cuanto a la iteracin en la cual se implementa, no nalizacin en la iteracin o o o planicada y modicacin durante la iteracin o una vez completada en una o o iteracin previa. o XP propone chas en papel para registrar las historias de usuario y tareas asociadas, sin dar mayores gu respecto a la informacin que debe ser recolecas o tada ni cmo debe gestionarse dicha informacin. Por otra parte, adems de o o a las restriccin mxima de esfuerzo asociado (3 semanas de programacin) no o a o hay ms pautas respecto a la granularidad de una historia de usuario, con lo a cual, tratndose de requisitos funcionales y no funcionales, el nmero puede ser a u considerable incluso para sistemas pequeos. Aunque existen algunos trabajos n que han mostrado su inters por registrar en soporte informtico las historias e a de usuario [3][10], en ellos no se ha dado solucin al tratamiento de las posibles o situaciones antes mencionadas. El objetivo del presente trabajo es presentar un mtodo para especicar y e gestionar historias de usuario utilizando una herramienta ad hoc desarrollada por los autores y denominada Volt. El resto del art culo est organizado como se indica a continuacin. En la a o seccin 2 se describe el artefacto historia de usuario de XP y se propone una o plantilla esencial representada en XML. La seccin 3 muestra la funcionalidad de o un sistema de control de versiones y en particular se analiza la herramienta Subversion [17] y cmo sta puede servir para el versionado de historias de usuario. o e La seccin 4 presenta nuestra propuesta de mtodo para gestin de historias o e o de usuario y la herramienta que estamos desarrollando, la cual est basada en a Subversion. Finalmente en la seccin 5 se elaboran las conclusiones y el trabajo o futuro.

2.

Historias de usuario

El primer problema que encontramos al intentar trasladar las historias de usuario desde las chas en papel a un sistema informtico radica en la necesidad a de denir qu informacin deben contener las mismas y en qu forma se va a e o e representar dicha informacin. o Respecto al primer punto apenas existen indicaciones que orienten a la hora de crear las historias de usuario. Beck [2] arma que la unica informacin que o se debe recoger es el nombre de la historia y una descripcin de la misma. Aun o as en el mismo libro se incluyen plantillas para las historias de usuarios cuyo uso se ha desaconsejado [9]. Otros, por su parte, mantienen que se deber registrar a la cantidad m nima de informacin que sea util para el proyecto de desarrollo o [18]. Creemos que la sola descripcin de la historia de usuario no es suciente, o pero manteniendo la simplicidad de XP cualquier otra informacin asociada debe o estar justicada con respecto al benecio que aporte. Es ms la informacin de a o una historia de usuario podr variar y ajustarse a las caracter a sticas espec cas del proyecto. Por otro lado, pudimos comprobar en un experimento anterior [7], que el usuario no se siente cmodo ante el trabajo adicional que supone o decidir cules son los datos relevantes para conformar sus historias de usuario, a preriendo que se le ofrezca una plantilla a rellenar. Con el n de no hacer ms a complicado el proceso de desarrollo al usuario, la herramienta que presentaremos en la seccin 4 provee una plantilla congurable para las historias de usuario que o incluye al menos la informacin que consideramos esencial en cualquier proyecto o de desarrollo. Esta plantilla es el resultado de estudiar las historias de usuario dadas como ejemplo en libros [2][18], en informacin en Internet y nuestra propia o experiencia de aplicacin de XP [6][7]. o Una vez conocida la informacin que compondr las historias de usuario o a debemos elegir el medio ms adecuado para representar estos datos. Para tomar a esta decisin hemos de tener en cuenta el tratamiento que la herramienta va a o hacer de esta informacin. Dado que se va a realizar control de versiones sobre las o historias de usuario es recomendable utilizar un formato en el que la informacin o de las historias se almacene de forma textual. Esta representacin permitir al o a sistema de control de versiones mostrar las diferencias entre una versin y otra o de forma inteligible. Partiendo de este requisito decidimos representar nuestras historias de usuario utilizando XML, de forma similar a la representacin de eso cenarios utilizada por Breitman [3], ya que cumple la propiedad deseada adems a de ofrecer cualidades interesantes. La utilizacin de XML como lenguaje de reo presentacin nos permite, adems de facilitar el control de versiones, disponer o a de un formato sencillo de tratar por herramientas informticas. a 2.1. Representacin en XML o

A continuacin se presenta el DTD a partir del cual se pueden instanciar doo cumentos XML para cada una de las historias y que constituye nuestra plantilla esencial.

<?xml version="1.0"?> <!ELEMENT user_story (story_id,name,creation_date,customer, priority,dependence*,estimation, risk, release,iteration,upgrade*,base?, description)> <!ELEMENT story_id (#PCDATA)> <!ELEMENT name (#PCDATA)> <!ELEMENT creation_date (#PCDATA)> <!ELEMENT customer (#PCDATA)> <!ELEMENT priority (#PCDATA)> <!ELEMENT dependence (#PCDATA)> <!ELEMENT estimation (#PCDATA)> <!ELEMENT risk (#PCDATA)> <!ELEMENT release (#PCDATA)> <!ELEMENT iteration (#PCDATA)> <!ELEMENT upgrade (#PCDATA)> <!ELEMENT base (#PCDATA)> <!ELEMENT description (#PCDATA)> Este DTD pone de relieve cules has sido los datos que hemos considerado a relevantes en nuestras historias de usuario. story id, identicador un voco para la historia. name, nombre de la historia de usuario. date, fecha en la que la historia de usuario fue creada. customer, cliente que ha confeccionado la historia de usuario. priority, prioridad asignada por el cliente a la historia de usuario. dependence, dependencia con otras historias de usuario establecida por el personal de desarrollo. estimation, estimacin realizada por el grupo de desarrollo del esfuerzo o necesario para implementar la historia de usuario. risk, riesgo asociado a la implementacin de la historia de usuario de acuerdo o a la experiencia del equipo de desarrollo. release, release que incorporar la funcionalidad especicada por la historia a de usuario. iteration, iteracin en la que el cliente desea que se implemente la historia o de usuario. upgrade, identicador de la historia de usuario que acta como mejora o u correccin de la actual. o base, identicador de la historia de usuario modicada o ampliada por la actual. description, texto explicativo de la historia de usuario. Aunque algunos campos pueden parecer complejos a la vista del cliente, sobre todo los campos upgrade y base, cabe resear que el cliente slo debe rellenar los n o campos name, priority, release, iteration y description. El equipo de desarrollo se encargara de los campos dependence, risk y estimation. El resto de campos

se rellenaran y tratarn de forma automtica por la herramienta. De esta forma a a la utilizacin de la herramienta pretende ser el a la losof XP procurando no o a complicar intilmente el proceso de desarrollo, centrndose en ofrecer un entorno u a sencillo, claro y conciso para cada tipo de usuario.

3.

Control de versiones

Los sistemas de control de versiones se han utilizado a lo largo del tiempo en proyectos de desarrollo de software. Cierto es que, normalmente, tan solo se realiza control de versiones sobre cdigo fuente, siendo este el ambito en el o que los sistemas de control de versiones han demostrado su ecacia y enorme utilidad. Estos sistemas permiten almacenar la historia de los cheros con el n de poder recuperar antiguas versiones de los mismos. Adems, cada vez que se a registra un cambio se almacena un comentario explicativo sobre la razn de ser o del mismo junto con el usuario que lo produce. Para realizar su cometido los sistemas de control de versiones almacenan los cheros en un repositorio. Este repositorio se puede considerar como un servidor de cheros que recuerda cada cambio hecho a los archivos. La utilizacin del repositorio permite que varias personas trabajen simulo tneamente sobre los mismos cheros sin que los cambios de un desarrollador a sobreescriban los realizados por otro. Esto se consigue aislando a los usuarios unos de otros. Cada usuario del sistema de control de versiones trabaja sobre una copia local del repositorio a la que tan solo l tiene acceso. e Un escenario clsico en la utilizacin de estos sistemas es el siguiente. Los a o usuarios A y B obtienen una copia local actualizada del repositorio. Cada uno trabaja sobre su copia local independientemente del otro. Cuando el usuario A naliza su trabajo registra los cambios en el repositorio. Dado que nadie ms a hab registrado cambios desde que A obtuvo su copia local el sistema integra los a cambios de A en el repositorio. Cuando B naliza su trabajo tambin pide actuae lizar el repositorio. Si los cambios de B se han producido en cheros diferentes a los realizados por A el sistema integrar los cambios automticamente. Por a a otra parte, si se han producido cambios en cheros modicados por A el sistema informa de un posible conicto mostrando las diferencias entre los archivos. En este momento es responsabilidad del usuario el descartar alguno de los cambios o mezclar las dos versiones del chero si los cambios se produjeron en l neas distintas y no producen conicto entre ellos. 3.1. Subversion

Subversion [17] es el sistema de control de versiones libre que hemos elegido como base para nuestra herramienta. Subversion naci como sustituto funcional o de CVS [4]. Su principal intencin es la de corregir todos los defectos que CVS o arrastra desde sus comienzos. Al mismo tiempo pretende ser lo ms parecido a posible a CVS para permitir que los usuarios de este sistema puedan comenzar a utilizar Subversion sin necesidad de un esfuerzo adicional.

Muchas son las ventajas que ofrece Subversion sobre CVS. Entre ellas destacan: versionado de directorios, versionado de metadatos, ramicado eciente o actualizaciones atmicas. Dos han sido las caracter o sticas que nos llevado a adoptar este sistema de control de versiones en nuestra herramienta, ellas se describen a continuacin: o Hooks Los hooks son programas que pueden ser ejecutados antes o despus de e realizar ciertas acciones con el repositorio. En nuestro caso esta funcionalidad nos permite validar cada historia de usuario con su DTD antes de registrar cualquier cambio en el repositorio. Interoperabilidad Entendiendo como interoperabilidad la facilidad con la que Subversion es accesible desde otras herramientas. En este caso Subversion se ofrece como un conjunto de librer en C con una API bien denida. Esto as facilita su utilizacin desde otras aplicaciones y lenguajes. o 3.2. Versionando historias de usuario

Al poner a prueba el sistema de versionado utilizando las historias de usuario extra das de nuestros experimentos con alumnos, pudimos comprobar que todav era necesaria exibilidad en cuanto a su composicin. El control de vera o siones mostr el comportamiento esperado almacenando el historial de los arteo factos y mostrando de forma inteligible los cambios que se produc de una an versin a otra mediante formato XML. Pero el principal problema apareci al o o intentar utilizar el sistema para registrar cambios en los requisitos. Cuando el usuario se enfrenta a un nuevo requisito debe registrarlo como una nueva historia de usuario, pero cuando se trata de modicar un requisito existente apenas se encuentra informacin en la bibliograf sobre cmo abordar o a o el problema. Con un sistema de control de versiones lo ms sencillo parece ser a modicar directamente la historia de usuario y registrar el cambio en el repositorio. Pero actuar de esta forma tiene una repercusin negativa en la estimacin o o de esa historia de usuario que debe ser realizada de nuevo. Siguiendo la losof a XP un cambio en los requisitos se podr registrar como una nueva historia de a usuario, si se adopta esta opcin y queremos mantener la trazabilidad entre los o requisitos nos vemos obligados a almacenar referencias entre la antigua historia de usuario y su correspondiente modicacin. o Para enfrentar con xito esta falta de informacin referente al mtodo de e o e desarrollo creamos una pequea gu que sirva de orientacin al usuario cuando n a o se enfrente con este problema. Tras estudiar el conjunto de historias de usuario decidimos no limitarnos a una sola forma de modicar las historias sino seguir las siguientes pautas: Si la modicacin que deseamos realizar no implica cambios en el contenido o de la historia entonces crearemos una nueva tarea de programacin para o cubrir esa funcionalidad. De esta forma registramos las mejoras y modicaciones detectadas por el equipo de desarrollo pero que no afectan a los requisitos iniciales registrados en la historia de usuario.

Si la modicacin implica cambios en la informacin de la historia tomaremos o o la decisin de acuerdo a la granularidad del cambio. o - Si la modicacin es de una granularidad similar a la propia historia de o usuario implica que nos encontramos ante una nueva historia de usuario. En este caso se necesitan mantener referencias entre las dos historias para disponer de trazabilidad. - Por otra parte si el cambio no alcanza el nivel de una nueva historia se modicar la historia de usuario afectada y ser el control de versiones a a el encargado de registrar ese cambio.

4.

Herramienta Volt

Volt es una herramienta que permite gestionar historias de usuario a travs de e un navegador web incluyendo control de versiones. Para ello la herramienta codica cada historia de usuario en XML siguiendo el formato descrito anteriormente y las registra en un repositorio Subversion. Al mismo tiempo la herramienta permite gestin de usuarios ofreciendo una interfaz personalizada a cada tipo o rol o de usuario. A continuacin se detallan las principales caracter o sticas de Volt.

Figura 1. Aviso del control de versiones

4.1.

Control de historias de usuario

Cuando los usuarios graban sus cambios estos se registran en el control de versiones. Si un usuario consulta una historia de usuario que ha sido modicada

en el control de versiones el sistema le informa de los cambios. En la gura 1 podemos ver como el usuario Juan L perteneciente al rol Desarrollo consulta la historia nmero cuatro y el sistema la informa de un cambio realizado desde u su ultima visita. A su vez cada usuario puede adems consultar el historial de cambios sufrido a por los artefactos desde su creacin hasta la versin actual. Como muestra la o o gura 2 el sistema almacena y muestra a peticin del usuario todos los estados o por los que ha pasado una historia de usuario desde su creacin. o Consideramos que es un aspecto muy importante que este tipo de herramientas orienten al usuario respecto del proceso de desarrollo a seguir. Por esta razn o la herramienta consta de una seccin en la cual se explica a travs de una serie de o e hipertextos los pasos a seguir durante la creacin, modicacin y mantenimiento o o de sus historias de usuario.

Figura 2. Historial de una historia de usuario

5.

Conclusiones y Trabajo Futuro

Desde que comenz el inters por las metodolog agiles se ha intentado o e as incorporar en ellas prcticas y mtodos establecidos en las metodolog tradia e as cionales con la idea que stos tambin podr ser necesarios y efectivos. Este e e an trabajo est en esta l a nea pues pretende integrar una gestin de requisitos y un o control de versiones ms elaborado que el planteado por XP. Sin embargo, para a

que este tipo de extensiones sean bienvenidas y valoradas en el contexto de las metodolog agiles deben mantener su esp as ritu en cuanto a sencillez y pragmatismo. En nuestro caso esto lo hemos conseguido mediante una denicin de un o mtodo simple y de una herramienta de apoyo amigable e intuitiva que soporta e dicho mtodo. e Durante las primeras fases del trabajo en las que todav no se hab dado a a forma a la herramienta y realizbamos el control de versiones directamente desde a l nea de comandos ya pudimos observar las bondades de nuestro mtodo. El cone trol de versiones nos permite sin necesidad de esfuerzo extra seguir la evolucin o de las historias de usuario a lo largo de todo su ciclo de vida. Con el desarrollo de Volt la interaccin con el sistema de control de versiones se facilita. Adems o a la incorporacin de la gu en la propia herramienta permite que los usuarios o a puedan aprender el mtodo de desarrollo al mismo tiempo que trabajan. e A pesar de que Volt ofrece valor aadido cuando se utiliza en un proceso n de desarrollo siguiendo XP, pensamos que ser interesante extenderla hasta a conformar un entorno integrado para el apoyo a XP. En la actualidad tan slo se o cubren los aspectos relacionados con las historias de usuario pero en prximas o versiones se ampliar el marco de accin, cubriendo ms actividades, tales como: a o a el juego de la planicacin, seguimiento del proceso, refactorizacin, pruebas, etc. o o Respecto a la validacin del mtodo y la herramienta propuesto, tenemos o e planicado incorporarlos el prximo ao acadmico en las prcticas de nuestras o n e a asignaturas donde hemos estado trabajando con XP y as conseguir una primera evaluacin. o

Referencias
1. Agile Alliance, pgina Web: www.agilealliance.org/ a 2. Beck K.. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999. 3. Breitman, K. y Leite, J.. Managing User Stories. International Workshop on TimeConstrained Requirements Engineering 2002 4. CVS, pgina Web: www.cvshome.org a 5. Laboratorio de Sistemas de Informacin, pgina Web: o a www.dsic.upv.es/asignaturas/facultad/lsi/ 6. Letelier P., Cans, J.H. and Snchez E.A. An Experiment Comparing RUP and XP. o a Fourth International Conference on eXtreme Programming and Agile Processes in Software Engineering, XP2003, Gnova, pp. 41-46, LNCS 2675, Springer-Verlag, e 2003. 7. Letelier P., Cans, J.H. and Snchez E.A. Working with Extreme Programming in o a a Software Development Laboratory. Aceptado en la 15th Conference on Software Engineering and Knowledge Engineering, SEKE 2003, San Francisco, Julio 2003. 8. Red Europea del VI programa marco NAME (Network of Agile Methods Experience), pgina Web: name.case.unibz.it a 9. Robinson, W. Story andTask Cards. 09/01/1999 Pgina a Web: http://www.xprogramming.com/xpmag/story and task cards.htm 10. Pinna, S., Mauri S., Lorrai. P, Marchesi. M y Serra N.. XPSwiki: An Agile Tool Supporting the Planning Game. 4th International Conference, XP 2003.

11. Pollice G. RUP and XP Part I: Finding Common Ground, pgina Web: a therationaledge.com/content/mar 01/f xp gp.html 12. Pollice G., RUP and XP Part II: Valuing Dierences, pgina Web: a therationaledge.com/content/apr 01/f xp2 gp.html 13. Rational Unied Process, pgina Web: a www.rational.com/products/rup/index.jsp 14. Borrador de un cap tulo de libro ilustrando la adaptacin de RUP usando los prino cipios agiles, pgina Web: objectmentor.com/resources/articles/RUPvsXP.pdf a 15. Smith J. A Comparison of RUP and XP. Rational Software White Paper, pgina a Web: www.rational.com/media/whitepapers/TP167.pdf 16. Smith R. Why UML Methodologists Are Throwing Their Weights Around. Art culo on-line en DevX.com, pgina Web: a archive.devx.com/uml/articles/Smith03/Smith03-1.asp 17. Subversion, pgina Web: subversion.tigris.org a 18. Wake W.. Extreme Programming Explored. Addison-Wesley, 2001.