Si te has informado acerca de metodologías ágiles, la palabra Sprint te resultará familiar. En caso de que sea la primera vez que escuches este tipo de metodologías, te recomiendo que leas nuestro artículo sobre metodologías ágiles primero, y luego vuelvas a éste.

Qué es una Sprint

Es la esencia de las metodologías ágiles. Es un conglomerado de requisitos que se deben de desarrollar durante un período de tiempo determinado, no más de un mes, y ser integrado con el producto final. Se usa tanto para un nuevo producto e ir segmentándolo para controlar las etapas de cada desarrollo, y también se usa para desarrollar evolutivos e ir integrándolos en el entorno productivo.

“Divide y vencerás”, es el lema principal de segmentar el desarrollo de un proyecto en Sprints. Te permiten secuenciar sets de requisitos de forma secuencial, de esta manera el cliente sabe en todo momento qué funcionalidad estará disponible al final de cada Sprint. También te permite ir modificando las prioridades de las Sprints futuras, ya que el equipo de desarrollo está siempre centrado en la Sprint actual.

Cuanto más tiempo dure una Sprint, más requisitos saldrán al final pero si el cliente quiere realizar un cambio o re-priorizar ciertas peticiones, tendrá que esperar más tiempo ya que sólo puede modificar Sprints futuras. Cuanto menos dure una Sprint, el cliente será capaz de ver actualizaciones constantes en el entorno productivo pero más tiempo de no desarrollo se tendrá que invertir.

Las fases que contiene una Sprint

Contiene 5 fases, algunas de ellas son reuniones clave, para poder dar por terminada una Sprint. No son fases rígidas, es decir, no es necesario que todas sigan el mismo orden, sólo algunas de ellas. Luego cada proyecto adapta su propia metodología cogiendo como base la siguiente estructura.

Sprint Planning

Es la primera reunión que se realiza el primer día de una Sprint. En esta reunión, el cliente debe tener escrito los requisitos que quieren que se desarrollen en la Sprint que va a empezar. Es recomendable que el cliente haya definido más requisitos de los que cree que podrán ser incluídos, para que quede un remanente y, en ningún caso, el equipo de desarrollo se quede sin asignación.

En esta reunión, el cliente es el encargado de presentar al equipo de desarrollo la lista de requisitos que ha priorizado para la Sprint que va a dar comienzo y el equipo de desarrollo tiene todo el día para realizar estimaciones acerca de ese listado. A final de día, el Scrum Master será el encargado de comunicar a todo el equipo la lista definitiva de los requisitos que van a ser incluídos en la Sprint actual en base a las horas disponibles de desarrollo y las estimaciones. Las estimaciones, personalmente, prefiero que se hagan tanto en horas como en Story points (puntos de complejidad).

He trabajado en proyectos en los que el cliente prepara la lista deseada de requisitos mucho antes de esta reunión y el equipo de desarrollo también realiza las estimaciones de antemano. En este caso la Sprint Planning es un mero trámite para calcular los requisitos a incluir y, en el mismo día, el equipo de desarrollo empieza a desarrollar. Si se realiza de esta manera, hay que reservar ciertas horas durante el Sprint para dedicarlas a la estimación de futuros requisitos.

Daily meetings

Reuniones diarias de no más de 15 minutos en las que participa tanto el cliente (con un rol de sólo escucha y responder preguntas), Scrum Master y equipo de desarrollo. Realmente es una reunión hecha para el equipo de desarrollo, para que reporte a todo el equipo los siguientes puntos:

• Qué hicieron ayer
• Qué van a hacer hoy
• Qué impedimentos tienen para avanzar

Estas 3 preguntas las tienen que responder cada uno de los integrantes del equipo de desarrollo. En caso de haber dudas, las responde el cliente. En caso de que surja algún impedimento, el Scrum Master es el encargado de perseguir a la persona pertinente para poder desbloquear dicho impedimento.

Sprint Development

Es el tiempo, en días y horas, reservado para el desarrollo de los requisitos acordados en una Sprint Planning. Es el tiempo efectivo de los desarrolladores, incluyendo la fase de testing interno.

Si una Sprint es de 2 semanas (10 días), no se cogen todas las horas como efectivas para el desarrollo. El primer día va asignado a la Sprint Planning, el último día para la Sprint Demo y la integración con el entorno productivo, y el penúltimo día para el testing integral. Asimismo, no es recomendable contar con que las 8 horas que tiene una jornada laboral sean 100% efectivas de desarrollo. Actividades inevitables como: chat, email, interrupciones en el entorno de trabajo, etc, son parte del proceso y no se deben contar como horas de desarrollo. Si las contases, seguramente te saldría al final de cada Sprint que no entregáis lo que se había estimado.

Personalmente, a una jornada laboral de 8 horas prefiero contar con 6 horas efectivas por cada desarrollador y dejar 2 horas para dichas actividades.

Sprint Demo

Es una reunión que se realiza el último día de la Sprint o durante los últimos días. En ella el equipo de desarrollo presenta los requisitos ya desarrollados en un entorno de test para que el cliente valide que todo está correcto.

Hay que ir con cuidado con esta reunión. Idealmente el equipo de desarrollo lo ha hecho todo perfecto y el cliente está contento, por tanto, durante el mismo día se suben los evolutivos a producción. Pero en realidad no es así. Somos humanos, y por una razón u otra siempre hay puntos en que el cliente no está de acuerdo, ya sea porque no se entendió bien lo que se pedía o porque el desarrollador lo ha desarrollado mal. En este caso se necesita de tiempo para la corrección y volver a presentarlo. Puedes solventar este contratiempo de varias maneras:

-Reservando ciertas horas durante una Sprint para corregir errores de la Sprint anterior y que se vuelvan a presentar en la actual. -Dejar los últimos 3 días de Sprint para corregir errores y realizar una fase de UAT (User Acceptance Testing) en el que todo el equipo está enfocado a ello.

En cualquiera de las dos soluciones sacrificas tiempo de desarrollo por tiempo de corrección. Pero es totalmente necesario y ya te avanzo que aunque aunque sea un equipo con mucha experiencia y muy cohesionado, siempre salen correcciones.

Sprint Retrospective

Es la última reunión que se realiza como cierre de una Sprint. En esta reunión se revisa cómo ha ido el desarrollo y el cumplimiento de los requisitos pedidos mediante informes que, a día de hoy, la gran mayoría de herramientas web de Sprints ya llevan integrados. Algunos ejemplos son: Informe de requisitos incluídos en una Sprint versus requisitos entregados. Informe del transcurso de cierre de requisitos a medida que han ido pasando los días (Burndown chart). Informe de cohesión del equipo: las Story points que han sido capaces de entregar. Se debería ver un incremento Sprint tras Sprint en Story points entregados sin modificar la duración de una Sprint.

A parte de analizar dichos informes, cada uno de los integrantes del equipo entero (cliente, scrum master y equipo de desarrollo) debe de mencionar los aspectos que cree que han ido bien durante la Sprint y los aspectos a mejorar para las siguientes. El Scrum Master toma nota y añade acciones a realizar para realizar cambios relacionados con los aspectos a mejorar.

Conclusión

Muchas personas creen que tanta reunión y tanta burocracia lo único que hace es ralentizar la entrega del producto final y la puesta en el mercado. En ciertas situaciones es posible que lo retrase, por tanto se debería estudiar cada caso y ver si se puede implementar una variante más simple. Sin embargo, la gran mayoría de veces que alguien piensa así, le suele salir más barato y termina teniendo un mejor producto en mucho menos tiempo que si aplica metodologías en cascada.

El principal motor de estas metodologías es la agilidad de poder realizar cambios a mitad de desarrollo o incluso cambiar el rumbo en tiempo récord. Uno de los aspectos más importantes son las personas que forman el equipo. Es necesario que haya cohesión y buen ambiente entre ellos, afecta directamente al resultado del producto. En un equipo en el cual no hay buen ambiente, se recomienda invertir en coaches para entender los puntos a mejorar y aumentar la cohesión entre ellos.

Espero que te haya servido de ayuda este artículo y no dudes en compartirlo en tus redes sociales si crees que le puede servir a más personas.