En mis veinte años de experiencia como ingeniero de software, he estado en muchas revisiones de sprint. Las he visto hacer bien y he visto que a veces se las usa para que las personas hagan un alto en una sala de reuniones por un par de horas cada sprint.

Realizada de manera correcta, la revisión de sprint puede ser la clave para mantener al día tu proyecto. Por el contrario, las revisiones de sprint hechas de forma incorrecta son peor que el tiempo malgastado en ellas, ya que disminuyen la confianza de las personas en la metodología Scrum.

En este artículo, te voy a guiar a través de algunas ideas y el paso a paso para hacer que tu revisión de sprint tenga más valor.

¿Qué es una revisión de sprint?

Una revisión de sprint es una sesión corta que se realiza al final de cada sprint, usualmente cada un par de semanas.

Esta sesión permite al equipo mostrar el trabajo realizado a través de demos, obtener feedback y decidir qué es lo que sigue.

Al hacerse de forma correcta, la revisión de sprint muestra progreso y crea confianza a las personas que tienen un interés en el producto y el proyecto.

Por supuesto, es posible decirles a los interesados que el proyecto está al día, pero si pueden verlo con sus propios ojos durante la revisión de sprint, estarán más contentos.

¿Quién debería estar en la revisión?

En resumen, cualquier persona que así lo quiera. Cualquier persona que sea parte interesada en cualquier capacidad puede y debería estar presente en estas reuniones.

El propio equipo scrum se encuentra en el centro de la reunión, pero también pueden estar los de Ventas, los subgerentes generales, otros equipos scrums y project managers.

Si alguien tiene algo para aportar al proyecto o cree que puede beneficiarse por aprender algo del proyecto, deberían asistir,

¿Qué hacer antes de la revisión de sprint?

Para que la reunión se lleve a cabo sin ningún problema, es necesario asegurarse que quienes vayan a presentar estén preparados y con una demo lista para mostrar.

Por experiencia propia, las demos en vivo no funcionan. Algunas sí, pero en su mayoría no.

Puedes decirles a quienes tengan una demo que al menos se graben mostrando el flujo de trabajo antes de la reunión. De esta manera, si insisten en hacer una demo en vivo, van a tener un video grabado a modo de resguardo si todo sale mal.

También deberías tener una lista con las personas que van a presentar y en qué orden. Agrúpalas por similitud del tema. No importa quién presenta y cuándo lo hace mientras que las presentaciones estén agrupadas por tema.

Por ejemplo, si tienes seis ingenieros - dos trabajando en una página de inicio de sesión, dos más trabajando en servicio back-end nuevo y otros dos trabajando en la performance de la base de datos- asegúrate que en tu lista de presentadores estas tres areas distintivas estén juntas.

Si hay dos demos que son similares, puedes explicar el contexto una sola vez y después correr las demos una seguida de la otra. Se eficiente, ya que tienes a muchas personas en esta reunión y todos saben que las reuniones son costosas.

Durante la revisión

Los ingenieros de software que hayan trabajado en alguna parte del proyecto harán la presentación a los otros miembros del equipo scrum (Producto, QA y otros) y también a los interesados que estén en la reunión.

Después de la presentación de cada ingeniero, cualquiera de los presentes en la reunión puede hacer preguntas o comentarios sobre el trabajo realizado o la presentación.

Estas preguntas pueden ir desde detalles sobre el proyecto para quienes no conozcan, lo conozcan en su totalidad o pueden ser preguntas sobre porque se decidió seguir un curso de acción en particular.

Desde Producto o miembros de la audiencia que estén más enfocados en la parte del negocio pueden dar feedback sobre si lo que fue presentando coincide con la intención de negocio de lo que se pidió entregar.

Una vez que todas las preguntas y comentarios son respondidos, el próximo ingeniero presentará su trabajo.

En una revisión de sprint, si bien todos pueden hablar, generalmente solo lo hacen los ingenieros que presentan. Entonces, el ingeniero presenta sobre el trabajo que realizaron y luego Producto, QA, Ba y los demás pueden dar feedback y hacer preguntas específicas sobre lo que el ingeniero presentó.

Revisión de ejemplo

Demos una mirada a una revisión de ejemplo y a lo que podría contener.

Vamos a usar el ejemplo de los seis ingenieros de más arriba: dos trabajando en la página de inicio de sesión, dos trabajando en un servicio back-end y dos trabajando en la performance de la base de datos. En ese caso, la lista de presentadores se ve así:

Presentaciones

1. Larry: El usuario supera la cantidad máxima de intentos de inicio de sesión y la cuenta se bloquea después del quinto intento incorrecto. El usuario tiene que pedir un nuevo password antes de poder iniciar sesión de nuevo.
2. David: El usuario hace clic en el enlace de contraseña olvidada y se emvia un enlace a su correo electrónico. El usuario hace clic en el enlace y puede restablecer su contraseña.
3. Premilla: Un servicio de reporte consume el evento "Usuario excede la cantidad máxima de intentos de inicio de sesión" y lo publica en el tablero de reportes.
4. Akshat: Un servicio de reporte consume el evento "Usuario hace clic en el enlace de restablecimiento de contraseña" y lo publica en el tablero de reportes.
5. Olga: Un usuario administrador puede ver el tablero durante un mes y cargar el reporte dentro de los 2 segundos.
6. Trevor: Un usuario administrar puede ver los eventos de varios usuarios en un mismo tablero y cargar el reporte dentro de los 2 segundos.

Como puedes ver, las dos presentaciones sobre la página de inicio de sesión de usuario se hicieron primero, después las dos presentaciones sobre los servicios de reportes, y por último las dos presentaciones sobre la velocidad de respuesta de la base de datos. Esto requiere un menor cambio de contexto para los miembros de la audiencia y también que es posible dar el contexto en la primera de las dos presentaciones agrupadas (esto es, las presentaciones 1, 3 y 5).

Después de la presentación 1 (realizada por Larry), Producto puede preguntarle por qué eligió cinco intentos como el número máximo de intentos antes de que se bloquee la cuenta. Larry puede tener o no una respuesta. Producto puede pedirle un seguimiento sobre este tema e investigar cuál es el estándar de la industria y aplicar la misma lógica que Larry o dejarlo así.

Después de las seis presentaciones, puede haber preguntas, comentarios o pedidos de cambio de cualquier persona de la audiencia. Usualmente, esto va a precipitar una conversación entre los presentes sobre cuál puede ser la mejor manera de realizar estos cambios.

Por ejemplo, de nuevo en el ejemplo de Larry, algunos podrían sugerir que ni se debería usar un nombre de usuario y contraseña, sino una dirección de correo electrónico y un enlace mágico. Esto es lo bueno de la revisión. Tenemos a un montón de gente inteligente en la habitación contribuyendo con su propia experiencia y sabiduría.

Consejos accionables

Here are some tips for what to show, how to show it, and what actually matters during the meeting itself.  Aquí tienes un par de consejos sobre qué mostrar, cómo mostrarlo, y lo que realmente importa durante la reunión en sí.

1. Mostrar entregables reales

Primero, siempre muestra software en funcionamiento o demos que funcionen en vez de diapositivas estáticas. Por ejemplo, si estuviste trabajando en una nueva función de inicio de sesión, haz una demostración en vivo. Esto hace que la revisión sea más auténtica y muestre avances tangibles.

2. Alienta el feedback

Segundo, invita a la audiencia a hacer preguntas. Recuérdale a las partes interesadas que sus ideas pueden ayudar a desarrollar nuevas funcionalidades. Anota sus sugerencias y confírmales si alguno de los cambios irán de inmediato a tu lista de pendientes.

3. Sé claro y mantente enfocado

Tercero, mantén un formato simple. Por ejemplo, empieza con un pantallazo general del objetivo del sprint, ve a las demostraciones y termina con un debate corto sobre los próximos pasos.

Evita entrar en profundidad sobre los detalles técnicos. Si el tema requiere más tiempo, organiza una reunión de seguimiento.

4. Coordina los próximos pasos.

Seguido de esto, actualiza tu lista de pendientes con base en lo aprendido en la reunión. Si una funcionalidad requiere un ajuste extra, agrega la tarea de manera inmediata.

Esto ayuda a mantener informado a todo el equipo sobre el plan para el siguiente sprint.

5. Mantenla corta y termina en horario

En la reunión deberías revisar el trabajo del equipo scrum de un solo sprint (dos o tres semanas)

Si la reunión se hace demasiado larga, esto puede significar que tu equipo scrum es demasiado grande (en ese caso, deberías pensar en dividir el equipo en grupos más pequeños) o que no estás siendo eficiente con tus demostraciones.

El tiempo y la atención de las personas son costosos y escasos. Mantén las reuniones a un ciclo ultradriano. Personalmente, trato de limitar todas las reuniones a un máximo de 90 minutos.

Por último, establece un límite firme para la reunión así los participantes se sienten confiados al dar su feedback sin alargar el debate.

Terminar a horario significa respetar el calendario de los demás y mantener al equipo descansado y preparado para el próximo sprint.

En conclusión

Una revisión de sprint les da a las partes interesadas una mirada real sobre el trabajo realizado, las mantiene alineadas sobre los próximos pasos, y permite obtener el feedback que necesitas para hacer crecer tu producto de forma efectiva.

Si te enfocas en mostrar avances reales, tener un dialogo abierto y mantienes las cosas de forma concisa, verás una mejoría en como tu equipo entrega valor.

En su tiempo libre, Ben escribe su blog de tecnología "Just Another Tech Lead" y administra un sitio donde crea calculadoras gratuitas llamado "CalculatorLord.com".

Ágil consta de cuatro principios básicos:

1. Individuos e interacciones sobre procesos y herramientas
2. Software de trabajo sobre documentación completa
3. Colaboración con el cliente a través de la negociación de contratos
4. Responder al cambio sobre el seguimiento de un plan

Revisaré estos principios más adelante y daré más sentido a ellos. Para hacerlo, es importante dar un paso atrás y comprender las prácticas de desarrollo de software que se usaban anteriormente.

Waterfall

El desarrollo de Waterfall es un enfoque muy lineal para construir un producto. Tiene poco o ningún espacio para retroalimentación o iteración hasta que el producto esté completamente construido y probado.

Así es como funciona: los equipos pasan semanas (y a veces meses) redactando documentos de requisitos de productos..

Antes de que se escriba realmente cualquier código, los gerentes de producto, analistas y diseñadores reunirán un documento masivo que describa los requisitos del producto con extremo detalle.

Por decir lo menos, este es un proceso largo y laborioso en el que, inevitablemente, se pierden algunas cosas.

Aquí hay un experimento mental simple. Piensa en la búsqueda de Google o en un buscador de correo electrónico de cliente.

Ahora intenta tratar de imaginar el documento de requisitos para estos productos.

Sin lugar a dudas, las cosas importantes se perderán. Uno simplemente no puede concebir el caso de uso o la escala o el alcance de cómo estos productos evolucionarán con el tiempo.

Si haz creado un producto, como constructor en solitario o como miembro de un equipo, es probable que puedas relacionarte con esta afirmación.

Cuando todo está acordado, las especificaciones se entregan al equipo de ingeniería que luego construye el producto para especificar, aprovechar cualitativamente y cuantificar datos e insumos.

Cuando todo está codificado, comienza la prueba.

Si se trata de un producto complejo, las pruebas y la corrección de errores pueden tomar semanas o meses ya que todo el producto debe pasar por una revisión rigurosa. Cuando los probadores y los gerentes de producto firman los requisitos de la prueba, el producto está listo para enviarse a la producción.

Hay una serie de deficiencias en el desarrollo de Waterfall, y aquí hay algunas.

Falta de mecanismos de retroalimentación

¿Qué pasa si el equipo de desarrollo sigue exactamente las especificaciones y resulta que al ver el producto cobrar vida simplemente no es tan convincente como el equipo de producto pensó que habría sido? O peor aún, ¿qué pasa si hay un error en el documento de especificación?

En el desarrollo de Waterfall, no sabrá la respuesta a estas preguntas hasta que el producto ya esté construido.

El desarrollo de productos puede conducir a grandes costos fijos. Si el producto no funciona, estos costos podrían convertirse en costos hundidos.

Los costos hundidos son el enemigo del constructor porque un costo hundido es un costo que ya se ha incurrido y no se puede recuperar.

¿Qué pasa si la hoja de ruta cambia?

Esto sucede todo el tiempo. Sucede en el equipo que está utilizando para leer este artículo, sucede en su empresa, y sucede en las empresas de tecnología grandes y pequeñas.

¿Qué pasa si la hoja de ruta cambia y el equipo necesita dirigir su atención a otra cosa? Bajo Waterfall, te quedas con un producto inutilizable. Piense: rigidez.

Una vez más, si tu no puedes convertir tus costos fijos en algo flexible que te quedará con una factura grande y no hay mucho que mostrar para ello.

Todo el trabajo dedicado, los plazos estresantes, el calandrado de la pizarra y las noches no conducirán a los resultados que deseabas al comienzo del proyecto.

El producto recoge el polvo hasta que finalmente se envía

En lugar de entregar mejoras incrementales a la producción durante un período de tiempo, la metodología de Waterfall espera para entregar todo el producto hasta el final.

Si bien este es un enfoque razonable para construir un automóvil, este no es un gran enfoque para el software.

El software, a diferencia de los automóviles, es flexible en las entradas de diseño.

La gente no puede usar autos a medias. Pero usamos software medio construido todo el tiempo.

Entra a ágil

Agile ayuda a resolver estos problemas al permitir que equipos de desarrollo de productos crean continuamente características que agregan valor. También permite a los equipos obtener constantemente comentarios sobre su trabajo y realizar los cambios según sea necesario.

Con el empleo de métodos ágiles, los equipos de manera consistente y predecible envían pequeñas piezas de código a la producción a un ritmo rápido.

Una vez que han completado cualquier tipo de característica que agregua valor, lo prueban y lo liberan al mundo. Este es un enfoque iterativo para la construcción de tecnología.

En lugar de tomar meses para construir un producto final y ejecutar una prueba de extremo a extremo, el desarrollo ágil permite a los equipos construir continuamente piezas más pequeñas del producto final y agregarlas a la producción a lo largo del tiempo.

Esto significa que las pruebas son más rápidas ya que solo está probando la compatibilidad del último fragmento de código. Esto también significa que los usuarios y las partes interesadas están más felices porque pueden ver y utilizar las últimas mejoras de productos de forma continua.

Considera ambos enfoques para un verdadero ejemplo de la palabra de remodelación de una cocina. Digamos que tomará seis meses hacer bien el trabajo de remodelación.

Waterfall sugeriría que el contratista y su equipo reconstruyan toda la cocina, luego revelen toda la cocina al cliente después de que se acaben los seis meses.

Mientras que el trabajo se hace en la misma cantidad de tiempo, el propietario se queda en la oscuridad. Preguntas simples como el "¿cómo?", va ir en gran parte sin respuesta. Lo peor de todo es que los propietarios no pueden usar ninguna parte de la cocina hasta el final.

Con Agile, el contratista en su lugar averiguaria lo que su equipo podría hacer cada pocas semanas, y luego permitir que su cliente lo vea y lo use mientras remodelan el resto.

Tal vez puedan reemplazar los gabinetes en el primer mes, las encimeras en el segundo mes, y en el tercer mes instalan una nueva nevera y estufa. No es un mal resultado para ambas partes!

En el segundo enfoque, el propietario obtiene el beneficio de usar partes de la cocina antes de que todo esté completo. En lugar de que la nueva estufa este allí acumulando polvo, en realidad se está utilizando tan pronto como se pueda usar.

¿Y tal vez el propietario de la cocina quiera cambiar un gabinete por un estante?

El contratista ahora puede al menos planificar ese cambio antes de que se acaben los seis meses y dejar saber al propietario cómo afectará la línea de tiempo del proyecto.

Al parecer, ambas partes pueden trabajar juntas y comunicarse de manera transparente para garantizar los resultados y que el trabajo sea termido.

Estos son algunos de los muchos beneficios de Agile. Ambas partes están mejor.

Trate de llevar esta lección adelante a medida que aprendas nuevas habilidades de desarrollo en freeCodeCamp y aplicar tus habilidades en proyectos.

Consideremos algunos otros ejemplos en el mundo del software

Revisando los cuatro principios de Agile, ahora podemos comenzar a encontrar ejemplos de la aplicación de Agile en los mundos real y digital.

Por ahora espero que puedan ver cómo estos principios son un asalto directo al proceso de cascada.

Principio #1: Individuos e interacciones sobre procesos y herramientas

Tener un proceso sólido y un conjunto de herramientas es muy importante en Agile. Sin embargo, la valoración de los individuos y las interacciones sobre las herramientas permite una mayor creación de valor y producción.

Los miembros individuales del equipo pueden innovar.

En lugar de obligar a las personas a cumplir con estrictas ideaciones y especificaciones, puede darles más ancho de banda para experimentar.

Parte de colocar a los individuos sobre las herramientas es la experimentación con nuevos flujos de trabajo. Un ejemplo que es relevante para la innovación en el desarrollo de software ágil es el códec, un programa informático que codifica o decodifica señales de datos digitales.

El códec H266 / VVC utiliza aproximadamente la mitad de los datos para transmitir videos 4K. Y se reconoce como la solución de codificación más eficiente para el futuro 4K e incluso 4K VR streaming en tiempo real.

¿Cómo se hizo este descubrimiento? Fue hecho por personas que usan Agile para resolver problemas de compresión de video.

Específicamente, se hizo porque a las personas se les dio libertad para construir, probar, experimentar e innovar durante un período de tiempo. No se les dijo que construyeran la cocina desde cero y regresaran en seis meses.

Tomaron pequeños pasos en la dirección correcta. Este resultado es instructivo.

Aquí hay un segundo ejemplo: cuando Lastpass fue adquirido por LogMeIn, LogMeIn estaba tan interesado en la tecnología como en la cultura del diseño que Lastpass había implementado para construir productos.

¿Qué tipo de cultura era esa? Uno que priorizó Agile.

Agile no solo lleva los productos al mercado más rápido, sino que crea resultados creativos y sinérgicos que son valiosos.

La creación de valor está incrustada en la cultura de Agile.

Principio #2: Trabajar software sobre documentación completa

Este debería ser obvio por ahora. En lugar de especificaciones detalladas y planificación, simplemente escriba algunas líneas de código que funcionen.

Pruébalo. Obten comentarios sobre él. Envialo.

Después, hazlo de nuevo.

Repite.

Un ejemplo muy relevante de este proceso de repetición se encuentra en "Forms on Fire".

Crearon un software para facilitar la recopilación de datos móviles. No escribieron toda su empresa antes del lanzamiento; escribieron algunas líneas de código, lo probaron y lo enviaron.

A medida que adquirieron impulso, aceleraron sus pruebas y pasos iterativos.

Y repitieron lo que funcionó y arrojaron lo que no. Los resultados hablan por sí mismos.

Principio #3: Colaboración del cliente sobre la negociación del contrato

Agile promueve un ciclo de retroalimentación rápida para obtener comentarios de clientes y del accionista.

¿Qué podría ser mejor que trabajar al revés de lo que los usuarios y clientes reales quieren?

Tengo un mentor de negocios que aconsejó que en lugar de sobre-analizar lo que los clientes quieren a través de una planificación sin fin, simplemente mantenerlo simple. "Mitigar las distracciones", dijo.

He escrito sobre el principio KISS en freeCodeCamp y ese consejo ciertamente es cierto en Agile: construye algo pequeño y ver si tus clientes les gusta.

Si les gusta, sigue adelante.

Principio # 4: Responder al cambio sobre el seguimiento de un plan

Los bucles de retroalimentación rápida generan cambios y ajustes rápidos. Esto es lo que hace que Agile sea tan bueno para los equipos de desarrollo.

Esta es la razón por la que debes abrazarlo.

Las hojas de ruta siempre cambian, esta es una constante conocida. Utilizando metodologías ágiles, los equipos pueden responder al cambio escuchando los comentarios de los clientes y haciendo los ajustes necesarios.

Hay momentos en que responder al cambio significa ajustar su producto o cambiar la forma en que piensa acerca de los usuarios o la competencia.

Un ejemplo clásico que los estudiantes ágiles pueden ver en el espacio de comercio electrónico es la venta en Amazon. ¿Cómo se adapta rápidamente a la competencia? Una forma es construir comunidades cerradas o probar diferentes estrategias de lanzamiento de productos.

Es aconsejable implementar soluciones tácticas y maleables.

Hay un maravilloso proverbio: "No podemos cambiar la dirección del viento. Solo podemos ajustar nuestras velas.”

Cuando pienso en Agile, pienso en este dicho.

Ágil es sobre el aprendizaje, Ágil es sobre la enseñanza. Ágil se trata de flexibilidad.

Puedes practicar Agile en tu trabajo diario o tomar cursos en línea para seguir desarrollándote.

Algunas personas son lo suficientemente inteligentes como para predecir lo que quiere su cliente. Ellos saben de qué manera sopla el viento.

Pero para nosotros los mortales, Agile es una metodología para navegar alrededor de nuestras deficiencias en la comprensión de lo que los clientes quieren.

Es el sistema que nos permite ajustar constantemente nuestras velas.

Traducido del artículo de Adam Naor - Agile Methods and Methodology for Beginners – Agile Software Development and Agile Project Management Examples