martes, 10 de marzo de 2009

Definiendo historias de usuario en Scrum

Uno de los puntos que más interrogantes provocan en la gente que se acerca a Scrum es cómo dividir el desarrollo de un proyecto en historias de usuario, es decir en tareas lo más pequeñas posibles que aporten valor funcional al cliente.

En este artículo voy a tratar de explicar el enfoque que yo adopto cuando trato de describir un requisito funcional cómo historia de usuario. Obviamente no es la única opción, ni la mejor, de echo es probable que esté pasando un montón de cosas por alto y que muchos se lleven las manos a la cabeza, pero creo que puede ser útil cómo primera aproximación para aquellas personas que no tengan del todo claro un procedimiento a seguir.

Vamos a tomar cómo ejemplo un problema de la asignatura de Especificación de Software de la Facultad de Informática de Barcelona (Enginyeria del Software: Especificació. Especificació de sistemes orientats a objectes amb la notació UML. EDICIONS UPC), que presenta el siguiente enunciado:

Se quiere desarrollar un sistema sencillo de control de préstamos en un a biblioteca. El sistema debe admitir el alta y la baja de socios y de libros. Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. Cuando llega a cero el socio se de de baja automáticamente.


Ahora supongamos que este problema nos lo ha planteado nuestro cliente, que quiere que le construyamos exactamente el sistema descrito en el enunciado ¿Cómo llegamos desde el mismo, a la lista de tareas del backlog? 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 “clásico” análisis de requerimientos, intentando extraer del texto (lo que nos dice el cliente) las diferentes funcionalidades que debe tener el sistema. Para ello analizamos los párrafos 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:
  • Alta Libro
  • Baja Libro
  • Alta Socio
  • Baja Socio
Del párrafo siguiente: Los socios pueden pedir libros en préstamo, pero no se pueden tener mas de tres libros en préstamo en un momento determinado obtenemos una única funcionalidad o historia
  • Préstamo libro
En este párrafo: Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente creo que podrían identificarse dos historias (es mi opinión, quizás otra gente opine que sólo hay una posible historia)
  • Devolver libro
  • Penalizar socio
En el último párrafo obtenemos otra posible historia: Cuando llega a cero el socio se de de baja automáticamente. Aunque pueda parecer que es una historia repetida, yo considero que a nivel de valor al cliente es una funcionalidad diferente.
  • Baja automática de socio
Aparte de las historias que aparecen más o menos explícitas en el código, quizás podrían deducirse otras historias cómo:
  • Iniciar sesión en el sistema
  • Cerrar sesión
  • Alta usuario
  • Baja usuario
La lista completa de historias que tendríamos sería la siguiente:
  • Alta libro
  • Baja libro
  • Alta socio
  • Baja socio
  • Préstamo de libro
  • Devolver libro
  • Penalizar socio
  • Baja automática de socio
  • Iniciar sesión en el sistema
  • Cerrar sesión
  • Alta usuario
  • Baja usuario

Si estuviéramos en una metodología clásica de desarrollo, en este punto deberíamos hacer los casos de uso para los requerimientos identificados, sus diagramas de secuencia, etc. En una metodología cómo Scrum, por definición, no es necesaria esta documentación (queda a elección de cada uno decidir que documentación necesita su proyecto) y lo que nos quedaría por hacer es definir e introducir las historias en el backlog. ¿Y cómo 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 demás lenguajes de especificación) y que no cree ambigüedades. Por ejemplo:

Historia: Préstamo de libro
ID: 5
Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento.
Importancia: 300
Cómo probarlo:
  • Introducir un número de socio incorrecto y comprobar que se indica error
  • Introducir un socio que ya tiene 3 libros en préstamo 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 número de ejemplares disponibles del libro disminuye y el número de préstamos del socio aumenta en uno.
Cómo vemos, en Scrum se detalla de manera poco explícita la funcionalidad, únicamente se explica a nivel de cliente. La ventaja es que no se fijan los detalles de la implementación hasta el momento en que se va a realizar (en la descomposición en tareas) con lo que se puede reaccionar más ágilmente ante los cambios de los requisitos o de las necesidades del cliente.

Haciendo lo mismo con las demás funcionalidades, nos quedaría un product backlog similar al siguiente (se ha obviado la parte de test de las historias):


Historia

Importancia

Descripción

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

Penalización socio

330

Penalizar al socio por retrasarse en la devolución

Baja automática

320

Dar de baja automáticamente de socio

Iniciar sesión en el sistema

550

Iniciar una sesión de usuario en el sistema

Cerrar sesión

500

Terminar sesión 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 cómo una historia de usuario.

Aunque ya tenemos completa la lista de funcionalidades, es obvio que el product backlog 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 técnicas, requisitos no funcionales o como se le quieran llamar) pero que son necesarias para el desarrollo del proyecto. Pero la mayoría de estas tareas no aportan valor al cliente, entonces ¿Se deben incluir estas tareas en el backlog? ¿Y de que manera? No vamos a discutir en este artículo el tema, ya que daría para muchos posts, pero a modo de apunte se podría gestionar de la siguiente forma:

En proyectos que se están iniciando, es fácilmente justificable introducir tareas técnicas o no funcionales, ya que sin ellas el proyecto no existe. Así bajo la forma de Epics (o super historias de usuario) se podrían englobar tareas tales cómo Implementar la capa de datos, implementar la capa de comunicaciones, etc. Estas tareas se llevarían a cabo en las primeras iteraciones, o incluso en una primera iteración mayor que las otras.

En fases más avanzadas del proyecto, es difícil justificar tareas no funcionales, cómo la refactorización de módulos, instalación 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 técnicas, cómo introducirlas dentro de alguna de las historias de usuario, o mantener una lista separada de historias técnicas con un porcentaje de tiempo no negociable con el dueño de producto.

Cómo hemos visto el proceso de definir historias de usuario es tan simple (o tan complicado) cómo realizar un análisis de requerimientos, proceso para el cual no hay ningún 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 análisis en un lenguaje que pueda ser fácilmente entendido por el cliente de nuestro proyecto.

Por si queréis ampliar información os dejo algunos links interesantes sobre Historias de Usuario i Scrum (o Agile en general). Esperamos vuestros comentarios!

http://en.wikipedia.org/wiki/User_story
http://www.userstories.com/
http://www.joelonsoftware.com/articles/fog0000000036.html
http://ezinearticles.com/?Scrum-User-Stories&id=1605892
http://scrummethodology.com/scrum-user-stories/
http://kanemar.com/2006/09/09/writing-user-stories/

14 comentarios:

Anónimo dijo...

Amigo, tus temas me estan sirviendo como muy buena teoria para entender Scrum y aplicarlo en mi trabajo.

Muchas gracias!

vgaltes dijo...

Gracias a ti por leernos!! Estamos encantados de que esto sirva a alguien.

Un saludo!

Anónimo dijo...

Me parece un post muy practico. De los que mas se agradecen cuando se estan buscando respuestas a como se hace..

Gracias y a seguir asi!

Anónimo dijo...

Excelente el ejemplo y muy didáctico, me sirve mucho para el proyecto que voy a empezar

Gracias

JASOSA dijo...

Muchas gracias a ti! Intentaremos aportar mas ejemplos prácticos por si le pueden servir a alguien de ayuda!!

Anónimo dijo...

Gracias por tu explicación. Me ha ayudado mucho para tener una idea práctica.

Sigue así!

Judavi dijo...

Excelente post.
Te felicito!
Quedo bastante claro el tema :)

Judavi
http://www.judavi.com

Anónimo dijo...

me exita tu post esta bien hecho, una paja en tu honor

breikerAQP dijo...

muy bueno el post !!!

Andrés Quijada dijo...

No me gusto el post, con todo respeto parece que todo lo dices por tu experiencia..dentro del desarrollo ágil, no se debe tratar de convencer al cliente de hacer algo. Otra cosa, las historias deben terminar con un PORQUE.."quiero se capaz de hacer esto, de esta forma PORQUE así se facilitara.." eso determina el valor de la historia.

Pero bueno, lo dijiste al comienzo del post, tal vez a algunos nos parezca descabellado.

JASOSA dijo...

Hola Andrés,

gracias por tu comentario.

En efecto el post está basado en mi experiencia (la que tenía en el momento de escribir el post). Si te fijas en uno de los primeros párrafos digo que "voy a tratar de explicar el enfoque que yo adopto"

Además, es un post escrito hace más de 3 años, justo cuando empezaba con todo el tema de agile. Seguramente ahora el post sería muy diferente... entre otras cosas aprecería el PARA en las historias.

Gracias de nuevo.

JACK dijo...

Muy bueno tu post ahora aplicaré en mi proyecto de tesis, gracias saludos

Anónimo dijo...

Me encantó, está sencillo y lo entendí bien, gracias por la ayuda

Jefferson Arcos dijo...

Hola creo que algunas de las historias no estan bien escritas ya que tienen terminos muy tecnicos y una de las bases para escribir historias de usuario es que sean tomadas directamente de la terminologia del cliente