<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=160269078105920&amp;ev=PageView&amp;noscript=1">

Iteraciones: ¿Cuánto Tiempo Deberían Tardar?

Martes 08 de Septiembre 2020.
Tiempo de Lectura: 7 minutos.
Por Esteban Elizondo



Al hablar de metodologías ágiles, muchas veces escuchamos el término desarrollo iterativo. Quizás esto no aplique si se trabaja con Kanban, el cual implementa flujos de trabajo continuos sin el concepto de ciclos o iteraciones - sin embargo, aún en este escenario, se tendrían que aplicar ciclos para las métricas (no me gusta perder una discusión). Pero al aplicar otras metodologías, como Scrum, el concepto de iteraciones es realmente necesario.

¿Por qué se han vuelto tan populares las iteraciones? Como muchas cosas en la vida, debemos analizar el pasado para entender nuestro presente así como nuestro futuro. Hace mucho tiempo, durante el reino del Desarrollo en Cascada, cuando un equipo recibía un proyecto, se les decía cuáles funcionalidades debían incluir para poder completar el trabajo. Debido a esto, el cliente no participaba en el proceso de desarrollo hasta el final - donde, por lo general, se daba cuenta que la app que el equipo había desarrollado no era lo que buscaba. Esto se traducía en una pérdida de tiempo, recursos y dinero. 

Luego entró Agile al escenario y añadió al cliente a la ecuación (proceso), así que ahora este puede presenciar la evolución de los resultados de su producto y brindar retroalimentación cuando sea necesario. Esto dió origen a una pregunta muy importante: ¿cuántas veces a lo largo del proceso se debería dar esta retroalimentación? Ésta interrogante procedió a convertirse en una cuestión técnica para el equipo de desarrollo: ¿cada cuánto deberían presentar el trabajo en proceso al cliente o a los ‘stakeholders’? Como Agile debe presentarle valor al cliente desde el comienzo, era necesario encontrar una respuesta adecuada.

Scrum nos dió la solución que ahora aplican la mayoría de las empresas: “trabajemos con iteraciones llamadas sprints, y estos sprints tendrán un plazo fijo cuya duración puede ir de una a cuatro semanas” (en algunos documentos encontramos plazos de hasta seis semanas). Así que la pregunta actual es la siguiente: ¿trabajamos con un sprint de dos semanas? ¿O mejor un sprint de una semana? ¡Oh, no! ¿Y ahora cómo sé cuál es mejor para mi proyecto?

¡No hay de qué preocuparse! En este artículo discutiremos las ventajas y desventajas de las distintas duraciones de sprint y brindaremos recomendaciones.

Sprints de Una Semana

Si le preguntamos a los desarrolladores acerca del sprint de una semana, es probable que no les agrade del todo; seguramente lo asocien a microgestión y presión. Así que se podría pensar que esta duración de sprint no es la mejor opción para un equipo. Sin embargo, los inconvenientes suceden en cualquier proyecto y hay veces en que es necesario ver cómo progresa el trabajo constantemente y brindar valor lo antes posible. 

Las desventajas de los sprints de una semana incluyen:

  • Si esta es la duración de sprint que normalmente se aplica para un proyecto, el equipo lo resentirá eventualmente. Su energía y dedicación se verán afectados con el tiempo.
  • Esta duración obviamente reduce el tiempo que se le dedica a otras ceremonias, así que las reuniones de retroalimentación y retrospectiva se verán afectadas ya que el equipo sentirá la urgencia de seguir con su trabajo.
  • Los bloqueos pueden afectar el objetivo del sprint. Si se descubre un problema en el proceso y éste se debe solucionar primero, es posible que no se logre el objetivo del sprint. No existe mucha flexibilidad de tiempo para abordar alternativas.

 

Las ventajas, por otra parte, incluyen:

  • La gerencia, los clientes y los stakeholders verán valor frecuentemente y pueden detectar desviaciones temprano en el proceso.
  • Fomenta un sentimiento de urgencia hacia las tareas que se deben completar, lo cual puede resultar en una mayor dedicación por parte del equipo. 
  • El equipo aprenderá y se adaptará más rápido.
  • De vez en cuando existen equipos que logran adaptarse al paso y a los cuales realmente les gusta esta opción de sprint. 

Tomando en cuenta las ventajas y desventajas, recomendamos aplicar esta modalidad de sprint para momentos específicos de un proyecto y no a lo largo de toda su duración. Es clave asegurar que el Dueño de Producto (PO por sus siglas en inglés) sea muy bueno brindando descripciones de los criterios de aceptación de los tiquetes; una sola descripción ambigua puede causar un atraso de un día, lo cual suma a un 20% del sprint. Y, finalmente, se debe considerar lo siguiente: ¿puede el PO dividir las funcionalidades para que éstas encajen bien en periodos de una semana? Tal vez es mejor probar este tipo de sprint una vez, ver cómo se siente el equipo al respecto y determinar si los resultados fueron los esperados. 

Sprints de Dos Semanas

Un análisis comparativo deja claro que dos semanas es la duración de sprint más común. Hasta los ‘frameworks’ más populares como SAFe recomiendan esta duración para su implementación. Así que analicemos esta opción y comencemos con sus ventajas:

  • Se recibirá una buena cantidad de retroalimentación. Por ejemplo, el equipo presentará una demo dos veces al mes, así que recibirán ideas y retroalimentación dos veces al mes. Para un proyecto de 6 meses, esto sumaría a 12 puntos de control y aprobaciones. Suena bien, ¿no?
  • Si el equipo se está familiarizando con Scrum, esta duración de sprint les ayudará a adaptarse al paso del ‘framework’ sin que pase demasiado tiempo entre reuniones cómo retrospectivas y evaluaciones (esto también aplica para los sprints de tres semanas).
  • Las funcionalidades se dividen en partes más pequeñas, lo cual ayuda a priorizar y a abordar tareas más complejas (el principio de ‘dividir para conquistar’). 
  • Los problemas que surjan se identificarán a tiempo y se trabajarán más frecuentemente, por lo que su impacto será menor.

Sin embargo, también existen desventajas como:

  • El equipo quizás sienta el impacto de los tiempos de reunión; por ejemplo, si se agregan sesiones de refinamiento al sprint, se disminuye el tiempo para trabajar tiquetes y si el equipo está aprendiendo, esto puede resultar en tareas que se arrastran de sprint a sprint.
  • Algunas personas sienten que trabajar con sprints de dos semanas no deja tiempo para la innovación ni para la refactorización. 

Se debe proseguir con cuidado. Esta puede ser una buena opción pero se le debe prestar atención al valor real que se le presenta al cliente al final de cada sprint. Algunas veces las métricas pueden engañar porque se ven bien, pero a la hora de la verdad, lo que se le presenta al cliente no es lo esperado. En este tipo de situación, tal vez sea mejor agregar una semana más. Por ejemplo, el equipo puede tener una velocidad de 30 puntos por sprint y logra cumplir esos 30 cada sprint, lo cual es un buen indicador. Pero cuando se le presenta el progreso al cliente, usualmente existe mucha lógica y esfuerzo oculto, así que no percibe ningún progreso en el producto en sí. Este puede ser un problema para el cliente y puede afectar su percepción de lo que se logró durante el sprint.

Spring de Tres a Cuatro Semanas (También Denominados como Iteraciones más largas

Aunque la literatura habla de sprints de seis semanas, el límite máximo más común es de cuatro. Hay buenas razones detrás de esto, por ejemplo, limitar el sprint a un mes en el calendario también lo asocia a los pagos, así que se recibirá valor cada vez que se realiza un pago. Las metodologías Agile fueron creadas para manejar los cambios de la mejor manera posible, así que es fácil ver cómo este tipo de sprint se ve afectado por las probabilidades.

Comencemos con las ventajas:

  • Esta modalidad de sprint es más apropiada para proyectos que involucran muchos picos y pruebas. Todas las fases de investigación, selección de opciones, implementación y resultados pueden calzar mejor en sprints más largos.
  • Si el PO no puede dividir las funcionalidades y éstas requieren esfuerzos más prolongados, esta modalidad de sprint es apropiada. 
  • Pasarán una o dos semanas sin muchas reuniones, por lo que el equipo puede ser mucho más productivo (no tendrán demos, retrospectivas y planeamiento).

Las desventajas incluyen:

  • Diferentes tipos de riesgos pueden incrementar durante períodos más largos de tiempo. 
  • Es más probable que cambie el objetivo del sprint, lo cual puede resultar en su cancelación (mejor ni imaginar lo que es pagar la cuenta de un sprint cancelado). Es posible que esto suceda debido a cambios en el mercado o cambios en las expectativas del cliente. 
  • Los puntos de inspección y adaptación del progreso no suceden tan a menudo como es deseable.
  • Es más difícil para el PO planificar sprints de tres/cuatro semanas.
  • Si entra una solicitud de cambio, es más difícil que el PO se espere hasta el final del sprint antes de añadirla.
  • Las sesiones de retrospectiva son importantes para el equipo. Trabajar sprints más largos reduce su espacio para pensar y discutir mejoras.

¿Qué Recomendamos?

La mayoría de artículos acerca de este tema concluyen que todas las duraciones de sprint tienen sus ventajas y desventajas o sugieren hacer pruebas para ver cuál modalidad es mejor para un equipo en particular… ¡y todo esto es cierto! Pero me gustaría brindar algunas ideas adicionales basadas en mi experiencia colaborando con muchos equipos de distintas culturas y áreas a lo largo de muchos años de trabajar con Agile.

Si el equipo es nuevo, quizás sea mejor probar con sprints de tres semanas. El equipo no sentirá la presión de tener retrospectivas y evaluaciones tan a menudo (presentar una demo puede ser aterrador dependiendo de la audiencia). Tendrán una semana de solo ‘stand-ups’ - y quizás sesiones de refinamiento - pero estos se pueden programar durante la primera o tercera semana para darles un respiro.

Se puede continuar con esta modalidad durante varios sprints, y si es necesario recibir retroalimentación con más frecuencia o si es necesario brindarle valor al cliente más a menudo, se puede hacer el cambio a sprints de dos semanas. Sí, sé muy bien que esto puede afectar la velocidad, pero nada está escrito en piedra y es mejor obtener resultados al igual que valor con un equipo contento.

La modalidad de sprints de una semana se debe evitar durante tiempos prolongados ya que el equipo se puede agotar. Si esto sucede, puede convertirse en un gran problema. Los sprints de una semana se pueden aplicar cuando se desea obtener resultados lo antes posible y si el PO es un verdadero especialista en dividir historias.

El estatus del proyecto se debe monitorear continuamente, así como los avances, las expectativas del cliente y cómo se siente el equipo. A veces es bueno cambiar de modalidad de sprint simplemente para romper el status quo.

Puntos Clave

  1. Los sprints de una semana se recomiendan cuando se desea obtener resultados rápidos y el PO es muy bueno dividiendo las funcionalidades, pero no deberían ser el modus operandi durante periodos largos.
  2. Los sprints de dos semanas son los que se implementan más comúnmente pero el valor que se le presenta al cliente al final de cada sprint debe ser evaluado para determinar si esta modalidad es la mejor para el proyecto o para el equipo.
  3. Los sprints de tres a cuatro semanas son los mejores para equipos que se están familiarizando con Scrum ya que no sentirán tanta presión, pero solamente se deben implementar durante las fases iniciales. 
Acerca de Avantica


En Avantica trabajamos como un socio de software que le ayuda a cumplir sus objetivos comerciales y dar solución a cada reto que se le presente. Ofrecemos equipos dedicados y buscamos constantemente las mejores metodologías para brindarle los mejores resultados.

 

ANTERIOR
Transición de Proveedor Tecnológico: Tres Consideraciones Cruciales
SIGUIENTE
La Importancia de Pruebas de Seguridad en Apps Móviles

¿Qué calificación merece este artículo?