La Historia de Usuario y el Planning Poker - Grandes herramientas parael desarrollo y la estimación ágil.

Lo ágil está de moda y voy a aprovechar el tirón para empaparme de alguno de los conocimientos que nos ofrece el mundo agilista.

Este año tuve la gran fortuna de dar Procesos Software en la URJC, cuyos profesores fueron Javier Garzás y Verónica Bollati.

Ellos me enseñaron la importancia de seleccionar adecuadamente el modelo de procesos software para cada empresa, así como las metodologías existentes y su historia, en resumen: una grata experiencia.

Destacaron el impacto metodologías ágiles, su historia, evolución y situación actual en el panorama mundial. (Prometo que haré una serie de artículos sobre SCRUM)

Por otro lado tengo la oportunidad de realizar el trabajo de fin de grado con los chicos del departamento de Tecnología Electrónica de la URJC y me he propuesto introducirnos en el mundo agilista y de paso desarrollar el proyecto con metodologías ágiles (SCRUM).

El TFG se encuentra en la etapa de estimaciones y la técnica de estimación Planning Poker me ayuda a resolver ese problema (el de estimar, que es altamente complejo) de una manera divertida y elegante.


* Pero antes de comenzar con la técnica, permitidme que os explique brevemente que son las Historias de Usuario:

En el mundo ágil, existe un término llamado Historias de Usuario, que no debemos confundir con los requisitos funcionales/no funcionales. Éstas nos permiten tener un control de las funcionalidades que deben desarrollar el equipo en base a la prioridad que tiene para el Product Owner (normalmente es el Cliente, pero ya os lo comentaré en profundidad en el post prometido). A su vez, para que el equipo de desarrollo tenga un control sobre las Historias, esas se dividen en tareas, que pertenecerán al Sprint Backlog.

Las Historias de Usuario se componen físicamente de un "posit de to´ la vida" y en su contenido encontramos:

· Un Identificador: para diferenciar nuestra historia de usuario

· Un Título: un titular para que describa qué es.

· Una descripción: una descripción corta, pero con lo necesario para entenderla que tiene la siguiente forma:

"Como " + ROL en la Aplicación (Véase Usuario/Cliente...) + " quiero que " + lo que quiere el ROL

· Estimación: son unidades que pueden representar el tiempo que tardas en realizar una tarea (por ejemplo dos unidades) o a tu gusto. Otro ejemplo serían unidades de dificultad.

· Valor: Es el valor que tiene para el cliente el desarrollo en el Product BackLog esa Historia de usuario. De tal manera que este puede priorizar dinámicamente (antes de empezar los Sprint, si luego quiere modificar se tiene que esperar al siguiente Sprint) las Historias de Usuario y las tareas.

· Dependencias: estudiamos la trazabilidad que tiene esa Historia de Usuario y el impacto que tiene en las demás.

· Condiciones de Satisfacción: condiciones adicionales para que el Product Owner duerma bien, y además nos pague (soy bestia, si).

A continuación tenéis un modelo de como irían encajados los conceptos dentro del posit:

Fácil,  rápido, sencillo y para toda la familia.

Una vez tenemos nuestras Historias de Usuario, toca pensar: "¿Cuánto vamos a tardar en realizar esto?"

Podéis personalizarlo cambiando el icono de las camisetas o la numeración.

Y aquí empezamos a puntuar.