Curso Metodologías Ágiles y TDD, parte I

Published on Monday, 07 July 2014

Curso de Metodologías Ágiles y TDD, Parte I.

Historias de Usuario

Introducción

Qué es una historia de usuario

Una historia de usuario es la descripción de una funcionalidad que aporta valor a un usuario del sistema. Se compone de tres aspectos:

A traveler can make reservations in hotels
        

Una historia de usuario suele representarse en un trozo de papel o tarjeta y simboliza el vínculo entre el desarrollador y el dueño del producto. Su valor es efímero, empieza cuando surge la necesidad de un nuevo desarrollo y termina una vez se entrega la funcionalidad. Por lo tanto, a largo plazo una historia de usuario no aporta valor documental, ni contractual.

Teniendo en cuenta la naturaleza cambiante del software y de las necesidades de negocio al que éste responde, las historias de usuario suponen un gran ahorro respecto a la tradicional documentación exhaustiva del desarrollo en cascada. En lugar de mantener innumerables versiones sobre la documentación, ésta se escribe a medida que el software evoluciona mediante los tests de aceptación. Los tests son la única documentación viva y veraz de las necesidades que la funcionalidad cubre.

Historias épicas e historias microscópicas

Las historias demasiado grandes reciben el nombre épicas. Las historias épicas suelen ser más difíciles de estimar y planificar, y se componen de varias sub-funcionalidades. Una historia épica puede descomponerse en otras más pequeñas:

A traveler can make reservations in hotels
        
- A traveler can search hotel rooms by city, price and quality
        - A traveler can access to the room details.
        - A traveler can place reservations on available rooms.
        - The hotel wants to be informed when a reservation is placed on its rooms.
        

Las historias microscópicas son aquellas que abordan con demasiado detalle una funcionalidad, y que están tan cerradas que no dan lugar a conversación. La proliferación de estas historias tiene un impacto negativo en la estimación global y suponen mayor esfuerzo en su gestión, ya sea mediante tarjetas de cartón o con herramientas informáticas. Por ello es aconsejable unificar estas microhistorias en historias con mayor entidad.

- A traveler can see the hotel address.
        - A traveler can see the hotel telephone.
        - A traveler can see the hotel email
        - ...
        
- A traveler can see the hotel's contact details.
        

Quién escribe las historias

Las historias de usuario se escriben en un lenguaje no-técnico, cercano al dominio del negocio al que pertenecen. Esto facilita que sea el propio cliente (Product Owner) el que escriba las historias. Sin embargo, hay algunos inconvenientes que dificultan que el Product Owner se encargue él mismo de realizar esta tarea.

Por ello es frecuente utilizar proxies del Product Owner. Los proxies son miembros del equipo de desarrollo o de otras áreas de la empresa que, por su mejor conocimiento del dominio de negocio, representan al Product Owner participando en la redacción de las historias. Un proxy puede ser una única persona o un equipo formado por diseñadores, testers, desarrolladores, etc...

En cualquier caso, es importante que el Product Owner valide las historias y sus prioridades.

Cómo escribir historias

Las historias de usuario deben ser:

- A traveler can make a reservation paying with a Visa card.
        - A traveler can make a reservation paying with a MasterCard.
        - A traveler can make a reservation paying with a American Express.
        

Las anteriores historias son muy interdependientes. La realidad es que no todas ellas tendrán el mismo coste de desarrollo, casi con toda seguridad será la primera la más costosa.

Por lo tanto tal vez sea mejor reformular las anteriores historias:

- A traveler can make a reservation paying with one type of credit card.
        - A traveler can pay with two credit card alternatives.
        

Roles

En algunos proyectos se tiende a simplificar los roles del sistema generalizándolos bajo el término Usuario. Una mejor definición de los distintos roles que utilizarán el sistema permitirá detectar las necesidades a cubrir desde una óptica más cercana a los receptores del valor.

Para identificar roles es importante la participación del Product Owner y de tantos desarrolladores como sea posible. Cada participante toma unas tarjetas de una pila, escribe los roles que se le ocurran y los deposita en un tablón o mesa. Durante el brainstorming no existe debate, solo se escriben roles y se depositan.

Una vez terminado el brainstorming, las tarjetas se colocan por proximidad según se solapen unos roles con otros. Una vez colocados, algunos roles se pueden unir, otros se pueden refinar, etcétera. También se descartan aquellos roles que no son importantes en el proyecto.

Estimar y planificar historias

Una vez escritas las historias de usuario, el equipo se reúne con el fin de estimarlas. La técnica más reconocida se conoce como estimación con Story Points. Un Story Point es una unidad de medida que no tiene un valor concreto en sí mismo. Simboliza el esfuerzo estimado para terminar una tarea en relación con las demás.

El valor de un Story Point, por tanto, es otorgado por el equipo. Una historia que pese 1 SP será aproximadamente el doble de costosa que una historia de 2 SPs.

En metodologias ágiles, la estimación no supone un contrato de ningún tipo, por lo que no puede utilizarse para presionar al equipo si la estimación no se cumple.

Le conoce como velocidad a la cantidad media de Story Points que un equipo puede liberar durante una iteración.

Una vez estimadas las historias, el Product Owner es el responsable de priorizarlas y decidir qué historias se desarrollarán en cada iteración. Las iteraciones son bolsas cuya capacidad depende de la velocidad del equipo. Si la velocidad media en las últimas iteraciones es de 25, el Product Owner seleccionará un conjunto de historias cuyo peso total en ningún modo sobrepase los 25 SPs.

Cuando un equipo se inicia en metodologías como SCRUM no conoce su velocidad. Una técnica para empezar es estimar a ojo las primeras tres iteraciones, y a partir de ahí extraer una media.

Definición de hecho

Una historia se considera terminada cuando las pruebas de aceptación están automatizadas y pasan en verde. Sin tests, la historia no puede considerarse terminada.

Cómo medir la evolución del proyecto

El burndown chart permite medir de una manera muy gráfica la evolución del proyecto. Consiste en un gráfico cuyo eje vertical son los SPs totales del proyecto, y cuyo eje horizontal es el número de iteraciones previstas. En un color se dibuja la linea que representa el progreso estimado, que unirá el punto más alto del eje Y con el más alejado del eje X.

A medida que terminen las iteraciones se irá dibujando la línea que representa el progreso real.

Burndown chart

SCRUM

SCRUM es un Framework de desarrollo ágil, iterativo e incremental para la gestión de proyectos.

Roles

Eventos

Artefactos

Kanban

Kanban (en japonés, panel), es una metodología mucho más libre de reglas que Scrum. Se basa en seis prácticas:

Las 12 prácticas de Extreme Programming

Bibliografía: