Estimar y planificar en Scrum: superando el «talón de aquiles» del desarrollo

Estimar y planificar un proyecto de desarrollo de software es fundamental. En un desarrollo con enfoque tradicional, se estima el producto deseado, se planifica el desarrollo y luego se procede a la ejecución, ejecución que por supuesto debe cumplirse al pie de la letra. A mi criterio y el de muchos colegas, el problema fundamental en esta planificación es que define el desarrollo como una actividad predecible cuando realmente no lo es.

El desarrollo de software es un proceso de transformación y creación de conocimientos y por tanto, no puede ser previsto y estimado con exactitud. El primer paso hacia la planificación con enfoque ágil es la aceptación de este concepto, por cuanto la planificación y estimación deben ser actividades adaptativas en vez de predictivas.

La verdadera realidad, es que las probabilidades de que una organización esté dispuesta a pactar un desarrollo de software sin tener siquiera una idea aproximada de cuánto va a costar, o cuándo va a estar el producto son mínimas. Por tanto, se debe tener claridad en las métricas o técnicas que se pueden aplicar a favor de lograr una medición y planificación acorde a las características del producto que se desea.

Antes de incorporar un procedimiento de medición, se debe cuestionar su conveniencia, y la forma en la que se aplicará. No se deben implantar procesos de medición a la ligera. Tomar una lista de métricas, e incorporarla a los procedimientos de la empresa puede seducir al ofrecer un marco de trabajo monitorizado con indicadores y mediciones, pero no dice mucho a favor de las razones por las cuales se han adoptado.

Puntos de Historia

Los Puntos de Historia (PH), son la medida de estimación utilizada cuando se trabaja con Historias de Usuario (HU). Es una unidad de medida creada para expresar el tamaño global de una actividad.

Los PH son relativos y no absolutos. Si una historia tiene 1 PH y otra 3 PH, esto puede indicar que una es el triple de la otra, esto es relativo teniendo en cuenta las características de cada Scrum Team. Es decir 3 PH para un equipo, no tiene por qué significar lo mismo que para otro equipo.

La primera acción que debe hacer un Development Team sobre cada HU es determinar su “tamaño”, tomando en cuenta que este valor se utiliza para determinar el trabajo que se debe llevar a cabo en la realización de un Sprint.

Tamaño:

Cuando se estima en PH, se intenta dar un valor al “tamaño de la historia”.

• Complejidad: Nivel de complejidad que tiene la tarea.
• Esfuerzo: En este caso puede haber tareas que aunque tienen una complejidad baja, puede ser necesario repetirla varias veces.
• Riesgo: A veces se trabaja con una tecnología desconocida y el equipo necesita tiempo para familiarizarse con ella.

Velocidad:

La velocidad es el factor que sirve para ver cuánto trabajo se es capaz de entregar en cada Sprint. Si por ejemplo la velocidad de un miembro del equipo es de 15 PH, se puede interpretar como que éste, entrega 15 PH promedio en cada iteración. Con esto, se puede conseguir ese factor de conversión de los PH a fechas, es la manera que se puede tener para poder decir al cliente cuándo se estima la entrega del producto

Se debe tener minucioso cuidado con esto, ya que se puede caer en la tentación de hacer cuentas y empezar a pensar en tiempo en lugar de estimaciones (1 hombre / 8 horas = 1 PH), es posible que haya HU de 1 PH, que se tarden más en hacer que una de 2 PH.

El proceso de estimación se puede basar en 2 aspectos. Unidad de medida a utilizar y las limitaciones que puede haber.

Unidad de medida

1 Punto de Historia = Historia o tarea que requiere el menor esfuerzo

Cuando se estima por esfuerzo se le asignarían 2 PH si el esfuerzo realizado con el patrón de unidad de medida es el doble, o 3 PH si el esfuerzo es el triple.

En la medida en que avanza el equipo y adquiere mayor experiencia en el desarrollo, debe aumentar los números de PH que puede realizar en un Sprint. Este elemento de tomar como referencia una HU o tarea, se elige en el primer Sprint y debe ser una tarea pequeña.