La Historia de Usuario y el Planning Poker - Grandes herramientas parael desarrollo y la estimación ágil.
julio 19, 2012
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:
Una vez tenemos nuestras Historias de Usuario, toca pensar: "¿Cuánto vamos a tardar en realizar esto?"
Una vez puntuada la Historia de Usuario, nos vamos a su casilla de Estimación y le colocamos el numero final.
Aquí os dejo la plantilla ya preparada para estimar nuestras Historias de Usuario.
Espero que os haya gustado.
Fuentes donde podéis encontrar información más completa:
· Libro Gestión Ágil de J.Garzás, Emanuel Irrazábal y Juán A. Enríquez
· Apuntes URJC 2011/2012 - Procesos Software
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. |
* Y aquí entra en juego la técnica del Planning Poker:
Nuestro objetivo va a ser estimar entre todos los programadores implicados en realizar el desarrollo y para ello nos vamos a reunir en una sala con un mazo de cartas.
¿Qué mazo de cartas usar?, pues se suele usar la sucesión de Fibonacci hasta el 100 incluído y dos tarjetas comodines, una interrogación que representa que no se tiene toda la información para poder evaluar la Historia y otra para tomar un café. Adicionalmente podemos poner una con el símbolo infinito si en la reunión hay programadores muy poco experimentados, y este será descartado del turno, pero por regla general no hace falta.
Podéis personalizarlo cambiando el icono de las camisetas o la numeración. |
En la reunión se irá analizando una a una cada Historia de Usuario y cada uno de los programadores pondrá una carta sobre la mesa cada vez que le toque con la puntuación que el crea conveniente para esa Historia de Usuario. Esto se repite hasta en cuatro ocasiones para evaluar finalmente con una nota media final.
Visualmente sería algo así:
Y aquí empezamos a puntuar. |
Una vez puntuada la Historia de Usuario, nos vamos a su casilla de Estimación y le colocamos el numero final.
Aquí os dejo la plantilla ya preparada para estimar nuestras Historias de Usuario.
Espero que os haya gustado.
Fuentes donde podéis encontrar información más completa:
· Libro Gestión Ágil de J.Garzás, Emanuel Irrazábal y Juán A. Enríquez
· Apuntes URJC 2011/2012 - Procesos Software
1 comentarios
no encuentro en el enlace indicado la plantilla personalizable.
ResponderEliminarGracias!!!
Sé respetuoso/a, en este blog caben todo tipo de opiniones con respeto y serenidad.