La vida de un Sprint
Introducción
Aquí estamos. El Backlog formado, priorizado y estimado, por lo que ahora es posible organizar la fase de realización del proyecto. El objetivo de este capítulo es mostrarle en detalle cómo se desarrolla la vida de un Sprint, concretando los requisitos previos y detallando el modo operativo para las diferentes ceremonias.
Nos centraremos en darle una visión lo más práctica posible de las cosas.
¿Cuál es la duración para los Sprints?
La elección de la duración de los Sprints no es trivial y vale la pena dedicar un poco de tiempo a este aspecto antes de lanzarse.
El método simplemente dice que un Sprint tiene una duración máxima de un mes.
Es necesario no olvidar que, en agilidad, cuanto más corta es la iteración mayor es la posibilidad de realizar el cambio (al contrario que en la gestión de proyecto clásica).
Si su iteración es corta, los errores van a aparecer pronto y por lo tanto se podrán corregir rápidamente.
No existe una duración ideal pero, como regla general, un Sprint durará 2, 3 o 4 semanas. Consideramos que una semana es una duración realmente difícil de aplicar.
Para un equipo poco experimentado, puede ser complicado seguir un ritmo de Sprints de 2 semanas. Sin embargo, si el proyecto dura solo algunos meses, se prestará atención a no elegir una duración demasiado larga (concretamente, en una Release de 6 meses con un ritmo del Sprint mensual, solo tendríamos 6 Sprints, lo que ofrece pocas oportunidades de adaptación).
A la inversa, un equipo bien ajustado sacará ventaja de un ritmo de 2 semanas, entregando resultados de manera más frecuente.
Preste atención también a elegir un ritmo realista respeto a la disponibilidad del PO, si no se dedica al 100% al proyecto:...
¿Debe haber un Sprint 0?
Algunas veces oímos hablar de "Sprint 0" antes del inicio de los "verdaderos Sprints". En primer lugar, seamos claros sobre el hecho de que esta noción no existe oficialmente en el método Scrum.
Como regla general, lo que se llama Sprint 0 es un periodo preparatorio a lo largo del cual, según los casos, es establecen los elementos técnicos necesarios para el proyecto o durante el que se decide la arquitectura.
También hay que ser cauteloso respeto a esta noción, porque no debe provocar una vuelta a un tipo de ciclo en V, con una duración de fase de especificación inicial. Además, uno de los valores principales de Scrum es entregar a lo largo del proyecto funcionalidades que tienen valor de negocio.
Sin embargo, si se mira desde un punto de vista pragmático, se puede prever un periodo de preparación inicial, bien determinado en el tiempo si entendemos que esto permitirá facilitar el desarrollo de los Sprints, por ejemplo, para establecer todos los elementos de la plataforma técnica y las herramientas de desarrollo, pruebas e integración continua.
El ritmo del Sprint: vista de conjunto
En cierto modo ya hemos hablado de esto en páginas anteriores, pero si queremos representar de manera concreta cómo es el ritmo de un Sprint con sus diferentes ceremonias, como resultado tendríamos lo siguiente (aquí sobre una duración de 3 semanas):
Por lo tanto, a lo largo del capítulo vamos a abordar el desarrollo concreto de los eventos.
Preparación del Sprint
1. Entorno de trabajo
El primer requisito previo de un Sprint afecta al entorno de trabajo. Además del aspecto técnico (hardware, licencias, etc.), es necesario asegurarse de que se presentan las condiciones necesarias para el bienestar del equipo y para que pueda desempeñar un trabajo eficaz.
Scrum se basa en la comunicación y el intercambio. Es útil, si tenemos la posibilidad, prever un espacio dedicado para el equipo, que también se utilizará para los eventos Scrum y para las sesiones de trabajo que necesiten reunir a varias personas, sin molestar al resto.
También se pueden utilizar las paredes para mostrar toda la información útil (Scrum Board, Burn Downs, etc.): si no hay sala privada, prever superficies de visualización (paredes, ventanales, etc) en el espacio de trabajo del equipo para este efecto.
Evidentemente, si el equipo no está físicamente junto este espacio dedicado es todavía más importante (con todo el equipamiento para organizar reuniones por vídeo-conferencia) y será necesario invertir en herramientas de comunicación y compartición de documentos eficaces.
2. Equipo
No nos detendremos mucho en este punto, pero antes de comenzar un Sprint conviene asegurarse de que el equipo está disponible y es idéntico al que ha realizado la planificación. Sin este requisito previo, la puesta...
Reunión de planificación de Sprint
La reunión de planificación del Sprint (o Sprint Planning) es una ceremonia importante en el método Scrum. Una planificación del Sprint mal realizada puede poner en riesgo un Sprint completo.
La sesión de planificación del Sprint, habitualmente guiada por el Scrum Master, se desarrolla en tres partes:
-
Presentación de las User Stories por el Product Owner.
-
¿Qué trabajo se realizará durante el Sprint? (Objetivo del Sprint).
-
¿Cómo realizar ek trabajo previsto? (División de las User Stories en tareas de desarrollo).
Antes de detallar todo esto, vamos a ver por qué la presencia del Product Owner es indispensable durante esta reunión.
1. ¿Por qué la presencia del Product Owner es importante?
Durante la primera planificación está presente el Product Owner y después, a lo largo de las planificaciones (antes de cada inicio del Sprint), puede ser que intente escabullirse porque piense que las User Stories en el Product Backlog tienen suficientes detalles y, a su parecer, "hay otras cosas que hacer" ese día.
Si usted es el Scrum Master de este proyecto, entonces conviene recordar que hay que llamar al orden al Product Owner, con el objetivo de que sea consciente de la necesidad de su presencia.
Solo él puede definir el objetivo concreto del siguiente Sprint y explicitar las User Stories a todo el equipo. Este es el principio fundamental de los métodos ágiles, que dan mucha importancia a la colaboración directa entre "el cliente" y el equipo de desarrollo.
Veremos que la estimación es responsabilidad del equipo de desarrollo. Si el Product Owner no está presente durante la reunión de planificación, entonces el equipo, que no tiene una visión precisa de cada User Story, tendrá dificultades para estimar el esfuerzo de realización y la planificación será imposible.
2. Definition of Ready
Estamos en el momento ideal para introducir la noción de "Definition of Ready" (o DoR). Al igual que su prima DoD, normalmente también está ausente o se respeta poco. Se trata de un conjunto de criterios comunes a todas las Stories que, se rellenan, indican que una Story tiene todos los atributos disponibles para poder ser estimada y tratada en un Sprint....
Melé diaria (Scrum Meeting/Daily Scrum)
Con el objetivo de respetar los tres pilares del método Scrum (Transparencia, Inspección y Adaptación) que permiten anticipar cualquier eventual desvío, es indispensable evaluar la situación a diario.
En este momento podemos ser transparentes, expresando las dificultades encontradas y mostrando el trabajo realizado, así como comprobar la adaptación a la diferente información generada.
1. Un protocolo a respetar
El Scrum Meeting forma parte de las ceremonias de Scrum y, por consiguiente, debe seguir directivas concretas:
-
Esta evaluación debe reunir a todo el equipo de realización y al Scrum Master delante del tablero de tareas y del gráfico de seguimiento (Burn Down u otro).
-
Puede ser útil que el Product Owner (o alguno de sus representantes) participe, pero debería estar de oyente.
-
Puede haber invitados (miembros del management, ayudantes externos del equipo, etc.) pero estos últimos deben tener también un papel pasivo.
-
La duración no puede exceder 15 minutos.
-
La reunión se debe desarrollar diariamente a la misma hora, en un momento en el que todos los participantes cuya asistencia sea obligatoria puedan estar presentes (normalmente es oportuno tenerla por la mañana, pero no es obligatorio si el equipo está distribuido, se evitará lo máximo posible tener esta ceremonia con cada uno en su puesto de trabajo o por teléfono: se pedirá a los participantes agruparse en una sala en cada lugar).
-
Los participantes deben permanecer de pie (de ahí el nombre "Stand up meeting" que algunas veces se da a esta ceremonial), lo que evitará que se pase demasiado tiempo en este tipo de reuniones.
2. Una melé eficaz y útil
El primer objetivo del Scrum Meeting es ser transparente sobre el trabajo realizado desde el punto anterior y dar una visión precisa de la situación del Sprint a los participantes. Para ello, cada miembro del equipo...
La revisión del Sprint (Sprint Review)
El Sprint ha terminado. Es el momento para que el equipo de desarrollo muestre lo que ha realizado (o no), a través de una demostración.
Durante un primer Sprint no hay necesariamente muchas cosas que mostrar, pero insistimos en el hecho de que esta revisión del Sprint se debe realizar.
1. ¿Qué, quién, cuánto tiempo?
Los participantes que realizan la revisión del Sprint son:
-
el Product Owner,
-
el Scrum Master,
-
el equipo de desarrollo,
-
los usuarios invitados,
-
los miembros del management invitados,
-
cualquier persona interesada por el proyecto, que haya sido invitada.
La revisión del Sprint es informal. Por lo tanto, el objetivo de la revisión del Sprint es ser un momento para hablar y observar las reacciones sobre la demostración, así como un lugar donde tener una visión precisa de lo que se ha producido y para mejorar la colaboración.
Creemos que es importante insistir en la atención que hay prestar en su preparación. El Scrum Master tendrá interés por preguntar a todo el equipo (por ejemplo, el día anterior), con el objetivo asegurarse de que cada uno sabe lo que debe presentar (se puede hacer una pequeña planificación de las presentaciones), y asegurarse de que el entorno técnico adecuado esté disponible (proyector de vídeo, videoconferencia o equivalente, si alguno...
La retrospectiva del Sprint
La retrospectiva no se debe descuidar porque es el momento preferido para aplicar la noción de mejora continua que propone el método.
El Scrum Master facilita la retrospectiva del Sprint. Su objetivo es examinar al equipo y proponer un plan de acción a adoptar para el Sprint siguiente.
A lo largo de esta reunión de una duración de tres horas para un Sprint de un mes, el objetivo que se tiene después de la revisión del Sprint es que cada uno se exprese y que se definan acciones de manera colectiva, con el objetivo de resolver los problemas que se han identificado y que el equipo quiera tratar a lo largo del siguiente Sprint.
Los participantes en la retrospectiva son:
-
el equipo de desarrollo,
-
el Product Owner,
-
el Scrum Master (como responsable de proceso Scrum).
1. Un método que le va a ayudar
La animación de una retrospectiva del Sprint no es siempre fácil de realizar, porque esta ceremonia incrementa los problemas y la naturaleza del propio ser humano, no quiere enfrentarse a sus dificultades.
No hay una única manera de proceder, pero vamos a exponer algunas aquí que puede adaptar a sus necesidades (y por qué no, inventar su propio método), sabiendo que cambiar de método de vez en cuando es un buen sistema para combatir la rutina que se podría instalar.
2. Estado de ánimo
Es importante recordar a todos los participantes que el objetivo de la retrospectiva es ver lo que se ha desarrollado correctamente, y aquello que no se ha hecho tan bien.
En este último caso, el objetivo no es hacer críticas individuales o aprovechar la ocasión para ajustar cuentas: se debe dejar la agresividad en el vestuario.
Por el contrario, es importante no dejar asuntos importantes "sin expresar" por miedo a molestar a alguien, por ejemplo: la transparencia es la regla.
Para terminar, todo el mundo se debe expresar: si nos damos cuenta...
Dejar al equipo descansar
No es raro ver equipos que implementan por primera vez Scrum encadenar las revisiones, retrospectivas y planificaciones del Sprint en el mismo día. Preste atención a esto.
En efecto, vivir un Sprint es un recorrido intenso y fatigoso. Imagine una planificación de un Sprint de 4 horas un viernes a medio día, después de la revisión y la retrospectiva por la mañana: esto no tiene ningún sentido porque no olvidemos que el Product Owner eventualmente debe recibir el contenido del Product Backlog.
Una opción puede ser hacer revisiones y retrospectivas del Sprint el viernes por la mañana y el viernes a medio día se dedica al estudio de las nuevas API, pruebas técnicas, etc., que se podrían poner en marcha en el Sprint siguiente.
De esta manera, los desarrolladores pueden centrarse en temas nuevos, lo que les permite respirar un poco y mantenerse técnicamente actualizados.
¿Y si comenzamos de nuevo?
De esta manera, se completa el Sprint. Pero nunca hay que perder de vista que un Sprint se debe preparar con antelación a la fase y que una parte del trabajo, en particular la del Product Owner (escritura de las nuevas User Stories, priorización, etc.), se hace en paralelo al Sprint actual.
Y uno de los puntos que no hay que olvidar es tomar el enfoque adecuado para probar en modo ágil: esto es lo que vamos a tratar en el siguiente capítulo.