formula12

La mal llamada “Velocidad del Equipo”


En las metodologías ágiles se utiliza una medida para calcular el ritmo en el que el equipo es capaz de ir avanzando en las tareas, mal llamada velocidad del equipo. Voy a intentar explicar por qué lo veo un mal nombre.

La idea es que el equipo mide su velocidad para poder hacer previsiones. Las tareas se estiman bien en horas o en puntos de historia y cuando se van completando, se mide el número de horas o puntos por unidad de tiempo. Así por ejemplo podríamos decir que la velocidad del equipo es de 18 puntos de historia por Sprint, siendo un Sprint de 2 semanas por ejemplo. Si tenemos un proyecto o fase que se ha valorado en 50 puntos de historia necesitaremos 3 Sprints para completarlo, y por tanto podemos decir, de forma simplificada, que en 6 semanas lo tendremos.

El método está muy bien pensado, se trata simplemente de disminuir la incertidumbre entre lo que crees que vas a tardar y lo que tardas finalmente. Cuando valoras una tarea normalmente piensas en una situación ideal en la que no hay imprevistos, nadie te interrumpe con tareas no planificadas, no tienes teléfono ni mail ni facebook, y estás aislado en un búnker antinuclear. En realidad esta situación nunca se da y siempre se tarda un poco más en terminar la tarea, por una serie de factores que influyen ya no en la tarea sino en nuestro día a día. Por enumerar algunos:

  • Interrupciones: llamadas, mails, mensajería instantánea, redes sociales…
  • Imprevistos: Tareas previas no finalizadas, dependencias con otros componentes no detectadas, refactorings, tareas adicionales necesarias y no planificadas.
  • Retrasos e ineficiencias externas: El Product Owner no está 100% disponible para preguntarle, el funcional no está completo y hay que refinarlo, las maquetas no están completas.
  • Nuevas peticiones, sobre todo los pequeños retoques o “ya que …” que no pasan por la gestión del cambio
  • Los sistemas, la no disponibilidad de algunos entornos cuando se necesitan, licencias que caducan en el peor momento, requisitos de software no previstos, sistemas caídos, firewalls sin abrir.
  • La propia incertidumbre de las arquitecturas actuales de software.
  • La naturaleza normalmente optimista de quién hace la valoración.

Aunque algunos de ellos se pueden de alguna manera controlar o minimizar, por ejemplo con una buena gestión del tiempo, la mayoría son externos e incontrolables para el equipo. Y es aquí donde está el problema para mí, llamar a esto velocidad del equipo es presuponer que todos los factores son intrínsecos al equipo, cuando la mayoría no lo son. No es que el equipo solo sea capaz de rendir al 70 o 80 por ciento de una capacidad presupuesta, sino que hay una serie de factores que limitan su capacidad y de trabajo no reflejado en esa valoración.

Por esto propongo algunos nombres alternativos como por ejemplo factor de riesgo, factor de incertidumbre o mi preferido, ratio de valoración global.

Que conste que a lo que me refiero es a factores difícilmente previsibles y controlables para el equipo, no me estoy refiriendo a tareas adicionales al desarrollo, como por ejemplo el tiempo de análisis y de aprendizaje, los tiempos de testing, despliegues a entornos y estabilización.

También te puede interesar...

Resumen User Stories Applied de Mike Cohn ¿Qué es una historia de usuario?¿qué elementos debe cumplir?¿cómo se crean? El libro User Stories Applied de Mike Cohn nos da respuesta a éstas y c...
Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *