En una entrega anteior ya mencionamos el principio de Time Boxing, que implica asignar un tiempo determinado a los eventos y reuniones durante el proceso de desarrollo. Estas reuniones son llamdas Rituales y se les denomina así ya que tienen características que buscan diferenciarlas de las reuniones regulares en las organizaciones.
Estas son reuniones que son preferentemente realizadas en persona, todo el equipo debe estar presente durante su realización (los invitados en algunos casos son aceptados pero no pueden intervenir) y se realizan de forma definida durante la ejecución del proyecto. Algunas de sus características son las siguientes.
Con esto, expliquemos brevemente cada uno de estos.
Es el corazón del proceso mismo, ya que es en el que se realizan todas las actividades del proyecto. Su duración, como ya se ha mencionado, se acuerda por parte del equipo SCRUM y puede ser entre una a seis semanas, dependiendo de la complejidad de las historias de usuario que se van a atender, mismas que son priorizadas por parte del product owner.
Calcular el tiempo de duración puede realizarse en base a diferentes técnicas de valoración, pero sigue siendo una aproximación de acuerdo a la percepción del equipo basado en su experiencia y en la velocidad de trabajo que hayan alcanzado. Algunos equipos tienden a dar un cierto puntaje a cada historia de usuario, de acuerdo a su complejidad, para utilizarlo de base para calcular el tiempo necesario, del 1 al 20.
Un promedio muy utilizado es de dos semanas en la mayoría de los sprints, ya que permite cubrir la mayoría de las historias de usuario y la frecuencia de los ritules no interfiere con la productividad o hace que se pierdan de vista los demás rituales, sin que esto sea una regla.
Let's face it, most companies are terrible at meetings.
Este es el ritual previo al inicio de todo sprint, el product owner presenta las historias de usuario, que ha seleccionado de acuerdo a su prioridad, para que se realicen durante este ciclo; el equipo esta invitado a revisarlo, hacer los comentarios pertinentes y calcular sus implicaciones y si bien, pueden debatir respecto al impacto y dependencias que detectan de cada una, la decisión final la realiza el propietario del producto, ya que es quien debe velar por el aporte total del proyecto.
En general, se considera que 4 horas es un tiempo promedio aceptable para realizar este ritual y obtener los compromisos por parte del equipo para mantener la continuidad.
Sin embargo, es importante anotar que previo a llegar a este ritual el product owner debe de trabajar con varios de los miembros del equipo para que las historias de usuario, contenidas en el product backlog, que se van a presentar sean claras y alcanzablen, además de entendibles para todos los participantes.
Esto se realiza de varias formas, pero incialmente se calcula el esfuerzo relativo que requieren realizar estas actividades, en base a la experiencia del equipo y las historias previas. En muchos proyectos, es común que el equipo asigne un valor en base a un puntaje de 1 (menor esfuerzo) al 20 (máximo esfuerzo) para determinar tanto el tiempo como los recursos que se requieren para completarse. Una ventaja adicional del sistema de puntajes es que permite medir la duración de los sprints subsecuentes en base a los puntajes de los previos.
Un tipo de historia al que no se asignan puntos son los bugs, que difieren del concepto informático de una falla en la programación, sino se les llama así en SCRUM a los requerimientos que no fueron incluídos en una historia de usuario en proceso o completada y que debe considerar en una posterior (es importante que no se intente incluír en una historia que esté en proceso a menos a que sea factible, ya que eso puede causar retrasos importantes en esa entrega).
En ocasiones, puede haber historias que fueron completadas y aceptadas por el product owner, pero posteriormente se detectó está falla, por lo que se debe incluir en cuanto sea posible.
A las tareas o tasks tampoco se le asignan puntos, estas son actividades que el equipo debe realizar para mantener manejable los elementos del proyecto, como cambios en la infraestructutra, documentación de código o revisión de otras actividades, que no agregan valor a los ojos del usuario pero son requeridas para su funcionalidad a futuro y se pueda mantener la velocidad en las entregas.
En los casos en que se tenga necesidad de obtener información o procesos adicionales y que están fuera de los conocimientos o experiencia del equipo, es necesario realizar estas investigaciones a las que se denomina spikes, mismas que tampoco tienen un puntaje pero igualmente, es necesario invertir recursos para resolverlo.
Una vez que ya se tienen todas las historias de usuario definidas para el sprint, es necesario agregarlas al Producto Backlog, anotando la puntuación que se da a cada una, misma que debe ir en línea con las puntuaciones de sprints anteriores y que haga sentido con la duración.
Un punto importante es que el equipo esté en general de acuerdo con las historias que se van a trabajar y el tiempo que se invertirá en cada una, siendo esta etapa el último momento para agregar cambios, cambiar el orden de ejecución o correlacionar unas con otras, de acuerdo a lo que, en su experiencia, permita un mejor resultado. No obstante, debemos recordar que el product owner sigue teniendo la última palabra.
Este es el ritual más conocido de la metodología, un daily standup es una reunión que se realiza diariamente, durante la ejecución de cada sprint, con todo el equipo SCRUM y el product owner, generalmente de pie, en la que los integrantes deben responder tres preguntas básicas:
La conversación debe ser puntual, en la última pregunta se puede expresar la forma de resolver y el SCRUM master es el encargado de apoyar con este impedimento, ya sea con ayuda de los miembros del equipo o resolviéndolo fuera, con los stackholders alguien más dentro de la organización.
Estos puntos son los únicos que se deben atender, todos los participantes los deben mencionar e incluírse en el SCRUM Board, la duración promedio es de 15 minutos y la dirige el SCRUM master, quien debe revisar que la conversación no toque otros temas ni se busque ahondar en alguno en particular, lo que se puede realizar al finalizar esta sesión. Es importante mencionar que los invitados (stackholders) están permitidos, pero ellos no deben participar, sino sólo ser oyentes y en caso necesario, pueden acercarse a alguno o algunos de los miembros para revisar lo visto durante la sesión, pero sólo al terminar esta.
Al finalizar el sprint, los miembros del equipo deben presentar el producto terminado para cada historia de usuario a los demás, al SCRUM master, product owner y todos los involucrados en esta entrega, en donde se revisará contra la especificación y los criterios de aceptación, para poder dar por cerrada esa historia de usuario o no.
El tiempo que se asigna es por lo general de medio día, pero eso depende de la cantidad de historias de usuario que se realizaron y su complejidad, es frecuente que se calcule de acuerdo al puntaje que se le asignó al iniciar el sprint.
Un dato importante es que este ritual no sólo permite ver los entregables y aceptarlos o rechazarlos, sino que también muestra el avance total del proyecto, la velocidad general del equipo y la capacidad de atender cada sprint de acuerdo a su puntaje.
Al igual que en otros rituales, los invitados pueden estar presentes pero no está permitido que interactuen, salvo que el product owner o el SCRUM master les invite a hacerlo.
No debe ser extraño que por un lado, al revisar los criterios de aceptación, se detecte que estos no fueron formulados correctamente o estén incompletos, en caso de suceder así, la historia de usuario se evaluará con los que se definieron originalmente y los escenarios faltantes se considerarán para un sprint posterior. Por otra parte, algunas historias de usaurio pueden no ser aprobadas, por lo que se revisarán las diferencias y de igual forma, se agregará para un ciclo futuro.
Al final, el SCRUM master deberá de sumar los puntos de las historias de usuario completadas y ese será el puntaje final, que se agregará al total para obtener el avance total del proyecto.
Debemos recordar que el proceso de interacción contínua, uno de los principios de SCRUM, contempla la integración de los entregables en el producto para ir generando el producto final de forma recurrente, sin embargo, en el caso que el equipo lo considere apropiado, se pueden ir agregandolos productos de cada historia de forma escalonada para que los usuarios puedan probarlos de forma ininterrumpida, hacerlo por bloque al terminar el sprint o en la candelarización que les convenga. No hay una regla específica, pero de deberá respectar el itinerario de liberación para que se pueda construir el producto final de forma consistente.
La retrospectiva es el ritual que mejor ejemplifica la filosofía de las metodologías ágiles. La Sprint Retrospective es con frecuencia realizada después de terminar el demo del sprint y es la oportunidd del equipo para revisar el proceso, su avance y poder corregir o adecuar estos para los ciclos posteriores.
Todos los miembros del equipo están invitados a participar en el mismo, en esta ocasión los invitados son raramente incluídos y el SCRUM master es el encargado de dirigirlo. Por lo general, se le asigna medio día, como ya mencionamos, luego de terminar la demo.
Toda retroalimentación, positiva y negativa, debe ser expresada y el anfitrión debe llevar un registro de todo lo que se expresa y de hecho, es recomendado que los miembros ya tengan en mente los puntos a tratar. Por lo general, es preferible que se expresen por turnos lo que estuvo bien del sprint y luego lo que no lo fue, para que al terminar, se pueda discutir y poder tomar decisiones.
Al final, el equipo debe llegar a unos cuatro o cinco puntos específicos que se incluirán en el proceso de generación de entregables y comenzarán a atenderse en el siguiente sprint, con la mira puesta en que los cambios deben ser manejables y alcanzables, ya que en caso contrario, afectarán el proceso en vez de mejorarlo.
Y con esto, concluimos la revisión a los cuatro rituales fundamentales de SCRUM, mismos que deben ser atendidos de forma recurrente para que el proceso de la metología avance como se supone que es y se logre la entrega del producto en el tiempo y calidad necesarios.
En la siguiente entrega, hablaremos los los artefactos utilizados en la metodología para el control y gestión del proceso.
Tu opinión