Volviendo a la formación en ALM, he vuelto a releer el punto en el que se hablaba de la «evaluación de esfuerzo de tareas», donde se explican ciertas cosas muy interesantes entorno a los Story Points, como la técnica del Planning Poker, la cual ya hemos comenzado a implementar en la planificación de algún proyecto.
En el siguiente artículo sobre los Story Points veremos cómo a pesar de no aparecer como una medida del Core sobre ninguna metodología ágil, ni ser imprescindible, podremos sacar gran partido trabajando con ellos.
Los Story Points son un sistema alternativo para la medida del esfuerzo que requerirá una historia de usuario en concreto. La cantidad/carga de trabajo, grado de conocimiento/experiencia entorno a la tarea y complejidad de la misma, se postulan como principales factores a tener en cuenta a loa hora de evaluar el esfuerzo que requerirá cada historia de usuario.
¿Qué debemos conocer sobre los Story Points?
“Obtener un consenso en la previsión de coste. Esta es la mejor manera de obtener una estimación.”
Anthony Borton ALM MVP.
El principal objetivo es obtener de la mejor manera posible, la estimación del coste entorno a cada tarea. Ésta técnica defiende que la forma más precisa y productiva de lograr esta estimación, es hacerlo bajo consenso del equipo, justamente lo que nos facilita trabajar con Story Points.
Existiendo distintas metodologías para el cálculo de los Story Points, se posiciona como más recurrente (y divertida) la de Planning Poker
El Planning Poker es una práctica ágil de estimación de software de naturaleza gamificada. Este método nace con el afán de que todo el equipo pueda participar y llegar a consenso en la estimación de una tarea, evitando alargar posibles discusiones, propias de un grupo de personas tiene que llegar a un acuerdo, y haciendo amena y divertida una actividad que a priori puede resultar aburrida.
El sistema utiliza un rango de valoración basado en la secuencia Fibonacci 0, 1, 1 , 2, 3, 5, 8, 13, 21, 34, 55, 89.
A partir de esta secuencia, se estipula una adaptación que presenta las siguientes opciones: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ∞, (coffee).
0 Recurrimos al 0, cuando se trate de una tarea que podremos resolver gracias a una funcionalidad out of the box.
∞ Aplicamos el infinito cuando se considera que el esfuerzo para realizar la tarea es superior a las opciones anteriores, en cuyo caso habría que descomponer la tarea en varias.
? El interrogante lo mostraremos cuando nuestra respuesta sea “No estoy seguro..” Se recomienda que si en 30 segundos no puedes determinar qué esfuerzo requiere esa tarea, no deberías mostrar ninguna carta, puesto que careces de la experiencia/criterio para poder evaluar.
Café Entorno al café existen dos teorías posibles:
a) “Necesito un descanso”
b) El coste de la tarea resta el mismo tiempo que el de tomar un café.
Para poder trabajar con Planning Poker en Visual Studio Team Services, haremos uso de la herramienta Estimate, extensión disponible en Visual Studio Team Services Extensions.
La valoración mediante Planning Poker se realizará durante una reunión que convoque al equipo al completo, donde por cada historia de usuario, cada uno mostrará simultáneamente el valor que considere al resto de los compañeros. Originalmente se trabajaba con una baraja de cartas física, mientras que, en nuestro caso, ya transformados digitalmente 😉 hacemos uso de nuestra herramienta Estimate desde TFS.
En los siguientes puntos detallamos paso por paso como desarrollamos una estimación mediante Planning Poker:
* Sobre este punto hay controversia, existiendo teorías que recomiendan directamente, descartar las estimaciones más bajas y más altas, quedándose con la estimación media o más repetida. En nuestro caso no aplicamos esta práctica, partiendo de la premisa que explica que en Planning Poker no hay democracia, y que siempre se debe llegar a un consenso. Entendiendo así, que elegir la estimación de la mayoría sería un error.
Como principal ventaja, aparte de lograr valores estimativos de esfuerzo que se ajustarán de manera más veraz al requerido finalmente, el hecho de trabajar haciendo uso de esta metodología, permite al equipo conocer los recursos que tiene a su alcance, y que quizás no conocía.
Siempre puede darse el caso en que un miembro del equipo justifique una previsión de esfuerzo más liviana que la del resto entorno a una tarea, por contar con el recurso/herramienta/conocimiento/experiencia para realizar esa tarea con menos esfuerzo…
Acerca de esto, debemos valorar la importancia de conocer los puntos fuertes de cada componente del grupo, ya que además de hacer más eficiente al equipo (permitiendo lograr una mejor estimación de las tareas), influirá positivamente a nivel individual, puesto que todo el equipo sabrá a quién recurrir para empaparse de esos nuevos recursos, y así sacar el mayor partido posible.
A la hora de hablar de desventajas, apuntaremos que en el caso de no ser exquisitos con la valoración que apliquemos, no respetando el rango de valoración o bien estimando algo con una puntuación media (por aquello de «no saber qué puntuar”), podemos caer en generar una estimación que no se ajuste a la dedicación real.
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)