Revisiones de sprint de metodología ágil

Tres pasos para obtener mejores revisiones de sprint con el equipo ágil.

Dan Radigan Dan Radigan

Las revisiones de sprints no son retrospectivas. Una revisión de sprint consiste en demostrar el duro trabajo de todo un equipo: diseñadores, desarrolladores y el propietario del producto. En Atlassian, nos gusta mantener la informalidad de nuestras revisiones de sprints. Los miembros del equipo se reúnen en torno a un escritorio para demostraciones informales y describen el trabajo que están realizando para esa iteración. Es hora de formular algunas preguntas, probar nuevas funcionalidades y ofrecer feedback. Compartir el éxito es una parte importante de la construcción de un equipo ágil.

Let’s first review why the team’s definition of ‘done’ is so important to this agile ceremony.

Paso 1: Define "finalizado"

Como usuario habitual de Jira, nada me satisface más que mover una tarea del estado de "revisión del código" al de "finalizado". Ese movimiento de una tarjeta ágil representa el trabajo completado que nos propusimos lograr como equipo. ¡Hecho y finalizado!

Actualización de una tarjeta ágil en Jira

Cruzar la línea de meta y completar el trabajo requiere una buena planificación, una clara definición de "finalizado" y una ejecución centrada. La mayoría de esto sucede durante la planificación de sprints, pero para tener un sprint y una revisión de sprints, los equipos tienen que hacer algo más que planificar. Tienen que desarrollar una cultura clara de cómo entregar el trabajo, así como lo que significa que esté "finalizado".

Una cultura de entrega

Los equipos eficientes aportan procesos claros y una cultura de desarrollo a todos y cada uno de los elementos de trabajo. Utiliza estas preguntas para evaluar tu proceso, y asegúrate de que este funciona de forma óptima en tu equipo:

  • ¿Han definido bien el propietario del producto, el diseñador y el equipo de ingeniería las historias antes de la implementación?
  • ¿Comprende y vive todo el mundo la cultura y los valores de ingeniería del equipo?

  • ¿Existen definiciones y requisitos claros en torno a la revisión del código, las pruebas automatizadas y la integración continua para fomentar un desarrollo ágil sostenible?

  • Después de que el equipo complete una historia, ¿surgen demasiados bugs? En otras palabras, ¿significa el término "finalizado" realmente eso?

La cultura del equipo en torno a la calidad y la finalización debería estar por encima de cualquier historia de usuario, trabajo de ingeniería y bug. Esta cultura refleja cómo el equipo aborda el desarrollo de software y su entrega.

Definición de "finalizado" en cada trabajo

Una definición clara del término "finalizado" ayuda a los equipos a centrarse en el objetivo final de cada trabajo. Cuando el propietario del producto añade trabajo al backlog del equipo, la definición de los criterios de aceptación es una parte fundamental del proceso de este. ¿Qué implica la finalización de una historia de usuario? En Atlassian, el equipo de Jira realiza un seguimiento de los criterios de aceptación y las notas de las pruebas en consonancia con el resto de la historia de usuario dentro de Jira. De esa forma, el equipo al completo tiene una visión clara del éxito en cada tique. ¿Qué son los criterios de aceptación y las notas de las pruebas?

  • Criterios de aceptación: Mide los usos del propietario del producto para confirmar que la historia se ha implementado de forma satisfactoria.
  • Notas de las pruebas: Breve asesoramiento específico del equipo de QA que permite al ingeniero de desarrollo escribir mejor código de funcionalidades y realizar pruebas automatizadas.

Contar con unos problemas bien definidos durante la implementación permite a todos tener éxito. Con Jira, resulta fácil añadir campos. Como administrador, simplemente haz clic en el botón "admin" (Administrar) en el tique.

Paso 2: Celebración con el equipo

En Atlassian, uno de nuestros principales valores es el de "jugar en equipo". Las revisiones de sprints son fantásticas para celebrar los logros del equipo y de todos los integrantes durante una iteración. Normalmente, organizamos estas revisiones el viernes por la tarde, mientras todos en la oficina se relajan antes del fin de semana. Las revisiones de sprints no son iguales que las retrospectivas, así que asegúrate de organizar la revisión de sprints después de una iteración, pero antes de la retrospectiva. Los participantes externos siempre son bienvenidos a participar, pero en la reunión suelen encontrarse el propietario del producto, el equipo de desarrollo al completo y el experto en scrum. Como buena práctica, recomendamos dedicar entre 30 minutos y 1 hora a cada iteración que se trate en la reunión.

Nos encantan las revisiones de sprints porque protegen la salud y la moral del equipo. Las revisiones de sprints se basan en el trabajo en equipo. La revisión no es un procedimiento acusatorio ni un examen, sino un evento colaborativo entre todo el equipo en el que cada uno muestra su trabajo, plantea sus dudas y obtiene feedback.

Si una revisión de sprints no se convierte en una actividad positiva en el equipo, puede ser indicativo de lo siguiente:

  • El equipo está asumiendo demasiado trabajo y no lo está completando durante una iteración.
  • El equipo lucha contra la deuda técnica.

  • No se están desarrollando de forma sostenible las funcionalidades para garantizar que se introducen nuevos bugs en la base de código.

  • Las prácticas de desarrollo del equipo no está ajustadas como deberían.

  • El propietario del producto está cambiando las prioridades en una iteración, y el equipo de desarrollo ha quedado marginado por la corrupción del alcance.

Nota: Todos los equipos sufren a veces de iteraciones difíciles. Tómate el tiempo necesario para comprender por qué cambia una iteración en la retrospectiva del equipo e idea un plan para abordar los problemas en el siguiente sprint.

Paso 3: Contacta desde distintas geografías

Las empresas con equipos distribuidos se enfrentan a desafíos especiales en torno a la ampliación de ceremonias de la metodología ágil en diversas geografías. Las revisiones de sprints no son una excepción. El equipo de Jira cuenta con miembros en el mundo entero: Sídney, Gdansk, Ho Chi Minh y San Francisco. Aunque estamos repartidos, las revisiones de sprints son una parte importante de nuestra cultura de equipo. Los miembros del equipo crean vídeos informales y los comparten en una página de Confluence para que todo el equipo lo vea.

Estos vídeos informales mantienen a todo el mundo al día del progreso del desarrollo a pesar de las diferencias horarias. Ver una demostración de la funcionalidad de la mano del desarrollador refuerza al equipo de dos formas:

  • Comprensión del producto: Todo el equipo llega a escuchar la intención, el razonamiento y la implementación de la funcionalidad. Amplía el conocimiento que todos tienen del producto completo.

  • Formación de equipos: Los vídeos crean conexiones más personales en todo el equipo. Cada uno de nosotros logra ver quién está detrás de cada detalle de un producto. Los lazos creados mediante esta práctica nos unen más y nos hacen un grupo más integrado a pesar de la distancia.

Un último consejo

Para los equipos que son nuevos en esto de las revisiones de sprints, existe una fuerte tentación de convertir la revisión de sprints en una retrospectiva. Una revisión de sprints es una ceremonia independiente a la retrospectiva de un sprint. Tómate el tiempo necesario para disfrutar del fruto de tu trabajo. Celebra libremente tus logros. Las revisiones de sprints eficaces suben la moral y aumentan la motivación del equipo. Esta idea de celebración no es tan importante para nosotros en el equipo de Jira. Por esa misma razón, hemos añadido la idea de "¡Adelante, celebra!" a nuestra declaración de principios.

Up Next
Standups