Desarrollo de software. La dificultad de medir objetivamente el incremento de la velocidad

Se entiende que un equipo de proyecto irá incrementando la velocidad de desarrollo (volumen de trabajo que se puede afrontar en una iteración) hasta alcanzar una cierta estabilidad tras una serie de sprints (cambios en el equipo de proyecto ya sea de personas, en número, etc… afectarán a la velocidad, también cambios drásticos relacionados con el contexto de trabajo: tecnologías, entornos, metodologías, etc…).

Es bastante razonable que eso sea así salvo que la deuda técnica ofrezca cada vez una mayor resistencia.

Todo esto es teoría, si bien es la situación que se puede dar con mayor probabilidad.

Pero, ¿cómo medimos objetivamente el incremento de velocidad? Es decir, notaremos que el equipo puede afrontar una mayor cantidad de trabajo porque estimarán en menos tiempo el desarrollo o modificación de las pantallas, de la realización de informes, etc…, ¿pero cuánto realmente es esa mejora?, ¿en qué lo medimos?, ¿vale la pena el esfuerzo necesario para medirlo?.

Ahí estriba la dificultad porque lo ideal sería traducir los esfuerzos necesarios a una únidad genérica común, lo que en algunas metodologías se denominan puntos función, puntos por caso de uso, puntos por historia de usuario, etc… Esa traducción tiene un alto componente de subjetividad y se requerirá tiempo de perfeccionamiento conseguir una traducción con una cierta fiabilidad a esa unidad genérica común.

¿Invertimos esfuerzo en ello? Depende de en la fase en la que nos encontremos en la implantación de estrategias de desarrollo ágiles, si todavía no se tiene madurez (y para que exista se requiere tiempo) es mejor esperar a que se tenga una cierta estabilidad en la aplicación de estas dinámicas de trabajo de manera que el equipo tenga ya asimilados ciertos automatismos, una vez hecho eso, puede ser interesante empezar a medir.

No obstante, una cosa es medir en base a unidades genéricas y otra que no se haga un seguimiento de la velocidad en el sprint ya que resulta importante conocer (y eso se puede hacer con un esfuerzo mínimo) si el número de días de trabajo estimado para terminar los trabajos es congruente con la fecha de finalización del sprint por si fuera necesario (o posible) tomar alguna medida que permita reconducir desviaciones y/o gestionar las expectativas.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: