Agile se convirtió en el grupo de metodologías de trabajo más popular en el desarrollo de software. La mayoría de los desarrolladores hemos escuchado hablar de Scrum o Kanban (entre otros) o incluso puesto en práctica, sin embargo ¿qué sabemos realmente de Agile?.

Muchas veces nos unimos a equipos, con listas de funcionalidades, deadlines o sprints ya definidos, pero ¿alguna vez nos hemos preguntado como desarrolladores como surge todo esto?.

Este artículo pretende develar qué hay detrás de escena de algunos conceptos claves que algunas de estas metodologías comparten, con las cuales trabajamos en el día a día como es la priorización de features o la definición de la duración de los sprints. Además quizás te inspire a dar un nuevo giro a tu carrera, u odiar un poquito menos al Product Owner o Scrum Master.

Planificación Ágil

Si trabajas con Scrum quizás la parte no tan divertida son las comúnmente llamadas “Sprint Planning”, reuniones previas a cada inicio de sprint para planificar el trabajo de esa iteración.

Pero antes de profundizar en este tema veamos la siguiente imagen llamada Planning Onion:

Lo que se puede apreciar de esta imagen son los diferentes horizontes de planificación. Normalmente estamos acostumbrados a focalizar hasta el “Release Plan”, y de hecho se pretende que así sea para el equipo de desarrollo. Sin embargo me gustaría hacer foco en el hecho de cómo un plan engloba a otro y cómo un cambio puede afectar a las otras capas que engloba.

Ahora bien, ¿por qué tanta planificación? Recordemos que detrás de todo proyecto hay un negocio con sus prioridades y que la planificación Ágil se dirige hacia a donde hay más valor para dicho negocio, el cual puede ser muy variante a lo largo del proyecto.

Es por eso que el foco se encuentra más en la planificación que en el plan en sí mismo, lo cual ayuda a promover los cambios y se debe dar a lo largo de todo el proyecto. Los cambios son importantes y absolutamente necesarios para obtener nuevos resultados; no es menor destacar que esta es en parte la clave del éxito de Agile dado que da más flexibilidad y tolerancia que las metodologías tradicionales.

En el desarrollo la planificación también juega un rol importante a la hora de intentar encontrar una solución óptima a lo que se pretende desarrollar.

Pero además una buena planificación ayuda a:

• Reducir riesgos.
• Reducir incertidumbres.
• Aumentar la confianza del proyecto.
• Mejorar la toma de decisiones.
• Transmitir información mediante reportes periódicos.

Iteraciones

El producto cambia, la gente cambia, el mercado cambia, por lo tanto el plan también y es de allí donde cobra tanta importancia iterar.

Si trabajamos con Scrum sabemos que en cada iteración se obtiene como resultado un entregable que aporta valor, es por eso que el equipo tiene que trabajar como uno, con el mismo propósito y foco; de aquí juega un rol clave la definición del largo de las iteraciones (Sprints).

Probablemente estemos acostumbrados a sprints de dos semanas, pero ¿por qué no una semana, o cuatro? Bueno, eso depende de muchos factores:

• Qué tan largo es el Release Plan.
• El nivel de incertidumbre del proyecto, se recomienda hacer iteraciones más cortas cuanta más incertidumbre haya.
• Elegir el largo para maximizar el feedback, se debe planear en base a los aprendizajes.
• Suficientemente cortas para que no cambien las prioridades durante la iteración.
• Último y no menos importante, debe ser suficiente para trabajar comprometidos a llegar a los entregables, pero sin estrés.

Es por eso que las iteraciones de dos semanas han tomado popularidad, suelen ser más organizadas y menos apresuradas, puesto que en una iteración muy corta el deadline está muy próximo y no deja tiempo de recuperación en caso de enfermedad de un miembro del equipo o si algo va mal durante dicho periodo. Por su contraparte una iteración muy larga tiende a empezar muy tranquilo, pero terminar muy desenfrenado, sin mencionar que se queda propenso a que el plan cambie durante la iteración.

Velocity

Ahora que ya se tiene definido el largo de cada iteración, hay que calcular cuánto trabajo asignarle a cada miembro del equipo, y es aquí donde entra en juego los conceptos de Velocity y Story Points.

Comencemos por Velocity, ¿cómo se calcula? Hay tres formas de hacerlo:

1. Usar valores históricos: Probablemente el más usado, pero para que sea efectivo hay que cumplir las siguientes condiciones.
   • Las tecnologías y herramientas son las mismas.
   • El equipo y ambiente de trabajo es el mismo.
   • Las estimaciones son hechas por las mismas personas.
2. Si no se tienen datos históricos, simplemente ejecutar iteraciones y visualizar la velocidad. Esto sí, mientras más iteraciones previas a la estimación, menos incertidumbre.
3. Hacer un pronóstico: Aquí vienen los cálculos; se estima que las personas usan el 55-80% de su tiempo para el proyecto*, teniendo en cuenta meetings, sincronización, el cafecito de la mañana y los debates del partido del fin de semana 😬. Sabiendo lo anterior y los recursos disponibles, calculamos con el siguiente ejemplo:
   • 4 personas en el equipo, 8 horas diarias cada uno.
   • Por lo tanto, 6 horas disponibles por día (considerando el 80% del tiempo).
   • Iteración de dos semanas (10 días hábiles).
   • 10 días x 6 horas x 4 personas = 240 -> Horas por iteración

*Cohn, Mike. 2005. Agile estimating and planning. Prentice Hall

Story Points

En la diaria estamos acostumbrados a estimar las tareas/stories con dicha unidad pero no vamos a mentir, en nuestras cabezas al dar una estimación lo traducimos en horas ya que sigue siendo aún un concepto abstracto que no lo terminamos de entender del todo.

Imaginemos que nos piden estimar cuánto tiempo nos llevaría terminar de leer un libro. En una primera instancia debemos saber el tamaño del libro, pues no es lo mismo leer un libro de 100 páginas que uno de 350. Además hay que tener en cuenta el tópico y que tanto estamos relacionado con este, ya que quizás se nos sea más complejo leer y entender un libro de Mecánica Cuántica, que “Bajo la misma estrella”. Basados en eso y la disponibilidad diaria en horas para leer el libro, podemos estimar cuándo lo vamos a terminar.

Lo mismo ocurre en un proyecto de Software, para estimar la duración de un proyecto se comienza por estimar su tamaño, de aquí surge protagonismo los Story Points. Básicamente lo que hacemos al estimar con esta medida es decir que una tarea/story es más grande o pequeña que otra, la cual va a conllevar más o menos esfuerzo.

Estimaciones

Probablemente ahora nos estemos preguntando, ¿y cómo encontrar la unidad mínima de estimación? Independientemente de la unidad escojamos (como por ejemplo los números de Fibonacci) hay dos formas de definirlo:

1. Tomar una story que se considere más pequeña del resto y estimarla con un punto.
2. Tomar una story mediana y asignar puntos del medio dentro del rango de Story Points.

Una vez que tenemos esta estimación y una aproximación de la velocidad del equipo, estamos en condiciones de estimar la duración de lo que estamos planificando.

¿Por qué no estimar en tiempo directamente? Una de las grandes ventajas de los story points es que son auto-corregibles, no se devalúan y se adaptan a todos los miembros del equipo. Si por alguna circunstancia en una iteración hubo una velocidad menor a la estimada, simplemente se vuelve a recalcular el número de iteraciones que el proyecto va a requerir.

Cuando hablamos de estimar la duración en tiempo, hay que tener en cuenta el “Tiempo ideal” vs “El tiempo transcurrido”. Es aquí donde entran en juego los factores que pueden afectar ese “Tiempo ideal”, como las reuniones, trainings, demos, enfermedad, etc. Es por eso que en la mayoría de los casos es más difícil estimar en tiempo, en donde la estrategia de estimación cambia por completo (dicha explicación quedará para otro artículo), pero sigue siendo una opción válida para implementar.

Prioridades

Para culminar este artículo, me gustaría hablar sobre el cambio de prioridades. Independientemente de la metodología que usamos dentro de Agile, a todos nos duele ver como una feature que hicimos con tanto esmero y dedicación es sacada del tablero, o que el Product Owner con la voz temblorosa nos dice a mitad de sprint que este debe cambiar.

Como mencionamos al principio de este artículo, la planificación Agile está dirigida hacia dónde hay más valor y eso puede variar por diversos factores:

• Valor en el mercado
• Costos
• Nuevos conocimientos: mientras más se conoce hay menos incertidumbres
• Riesgos: ya sean funcionales, problemas presupuestales, etc.

Así que la próxima vez que veas estas variaciones, recuerda que hay muchos factores en juego que a veces el propio cliente no puede controlar o predecir.

Conclusión

Estas son algunas de las cosas que nos encontramos a diario con Agile y que por alguna razón las asumimos porque funcionan, y muy bien. Pero la verdad es que hay mucho más detrás, estudios, pruebas y errores que hace esta metodología tan efectiva y flexible para cada proyecto en particular frente a otras metodologías tradicionales.