Introducción a Scrum

Sprint Planning

Antes de que comience un Sprint, el Product Owner (con la ayuda del Scrum Master) revisa la lista de todas las funciones nuevas, mejoras, solicitudes de cambio e informes de errores acumulados a lo largo del tiempo para decidir cuáles son más importantes en ese momento. Si se trata de un proyecto nuevo, la lista incluye las características que debe proporcionar el nuevo sistema. La lista completa de elementos se llama Product Backlog y cada elemento debe incluir una descripción de lo que se solicita, la prioridad para el negocio y estimaciones aproximaciones. El trabajo del Product Owner es asegurarse de que esta lista esté siempre actualizada.

Scrum otorga un alto grado de control al Product Owner durante la vida de un producto, ya que le permite cambiar las prioridades a su gusto en cada reunión de planificación (es decir, cada dos semanas o cada 30 días, dependiendo del tamaño de su Sprint). Incluso si el Product Backlog ha sido priorizado antes, el Product Owner puede cambiar la prioridad de los elementos en cada reunión de planificación.

Dado que los Product Owners representan la empresa, normalmente tienen una idea de lo que quieren los clientes y de lo que deben entregarse primero. Armado con este conocimiento y estimaciones preliminares, el Product Owner selecciona un subconjunto de elementos del Product Backlog para su consideración en la reunión de planificación del Sprint.

La reunión de planificación de Sprint tiene dos partes. Durante la primera mitad de la reunión (las primeras 2-4 horas), el Product Owner describe las características al equipo Scrum que le gustaría ver implementadas durante la próxima iteración. Los desarrolladores y el control de calidad hacen preguntas al Product Owner para obtener estimaciones “suficientemente buenas” para cada artículo. Esta no es una reunión de diseño. El hecho de que se trata de una reunión breve obliga al equipo a no perder demasiado tiempo analizando en exceso cada elemento. El Scrum Master ayuda a mantener esta reunión enfocada y dentro del tiempo acordado.

Una vez que el equipo ha proporcionado las estimaciones, si hay más trabajo estimado que tiempo disponible en el Sprint, es trabajo del Product Owner decidir qué elementos del Product Backlog se eliminarán del Sprint y cuáles se conservarán. Es muy importante conservar solo los elementos suficientes que los desarrolladores crean que pueden completar. También es importante dejar que el Product Owner (y no los desarrolladores) decida cuáles deben mantenerse en el Sprint. En resumen: el equipo de desarrollo estima, pero el Product Owner prioriza.

Por muy tentador que sea extender la duración de un Sprint “solo unos días más” para hacer espacio y exprimir algunos elementos más, los practicantes de Scrum recomiendan que el tamaño del Sprint se mantenga fijo. El Scrum Master aplica esta práctica durante la reunión de planificación. El encajonamiento del tiempo obliga al Product Owner a tomar decisiones y centrarse en elementos de alta prioridad en lugar de intentar incluir todas las características posibles en una iteración. Recuerda que Scrum es iterativo; habrá más iteraciones. Si los elementos omitidos siguen siendo muy importantes, aparecerán en la parte superior de la lista en la próxima reunión de planificación de Sprint.

Los elementos que se mantienen en el Sprint se denominan Sprint Backlog. Estos elementos serán el foco del equipo durante la duración del Sprint. Durante la segunda mitad de la reunión de planificación del Sprint (las últimas 2-4 horas), el equipo elabora un plan para llevar a cabo los elementos del Sprint Backlog. Por ejemplo, el equipo puede dividir algunos de los elementos en bloques más pequeños para que varios desarrolladores puedan trabajar en ellos, decidir cómo se van a probar las funciones, qué funciones depende unas de otras y cuáles deben manejarse primero en el Sprint.

Sprint

Un Sprint es una iteración en la que el equipo de desarrollo trabaja en el Sprint Backlog. Durante este tiempo, el Product Owner debe estar disponible para responder preguntas y proporcionar comentarios sobre las funciones a medida que comienzan a evolucionar. Al final del Sprint, el equipo de desarrollo tiene la responsabilidad de proporcionar un código potencialmente enviable. El código potencialmente enviable significa que ha sido codificado, probado y está listo para entrar en producción, incluso si no pasará a producción inmediatamente. Scrum recomienda que el equipo le dé una demostración al Product Owner del software con las nuevas funciones al final del Sprint.

Un Sprint suele durar dos semanas o 30 días. La literatura inicial sobre Scrum recomendaba 30 días, pero últimamente ha visto a la mayoría de los equipos haciendo Sprints de dos semanas. Prefiero Sprints de dos semanas por varias razones. Primero, un período de tiempo más corto hace que sea más fácil para el equipo planificar, estimar y completar dos semanas de trabajo en lugar de cuatro o seis. Un período de tiempo más corto hacer que las reuniones de planificación de Sprint sean más cortas y tiende a hacer estimaciones más precisas porque el Sprint es más pequeño. En segundo lugar, los Sprints de dos semanas permiten al Product Owner la libertad de cambiar las prioridades con más frecuencia, lo que ayuda al equipo a adaptarse rápidamente a las presiones del mercado.

Independientemente del marco de tiempo que elijas para tus Sprints, asegúrate de que estén encuadrados. El encajonamiento temporal le da al equipo una meta tangible (por ejemplo, al final de dos semanas habrás completado estas cuatro nuevas funciones). La gente trabaja mejor cuando saben que pueden tener éxito y cuando se vislumbra un final. Obligar a los equipos a tener un código potencialmente enviable al final de cada Sprint también evita que los equipos entren en un estado perenne de “85% terminado” en el que el equipo siempre está muy cerca de concluir algo, pero nunca se logra. El encajonamiento del tiempo también anima al equipo a mantener estable el sistema, ya que saben que hay un punto de control al final del Sprint en el que deberán demostrar una versión del sistema que funciona y que puede enviarse. Esto es bueno para el equipo de desarrollo, el Product Owner y los clientes.

Mantener la duración del Sprint constante durante la dirección del producto también es una buena práctica porque proporciona ritmo al equipo.

Los Product Owners no pueden agregar más trabajo a un Sprint una vez que comienza. Deben retrasar los nuevos requisitos hasta la próxima reunión de planificación del Sprint. Sin embargo, dado que los Sprints suelen ser de corta duración e incluyen lo que el Product Owner pensó que era más importante, los Product Owners suelen ser receptivos a la idea de esperar unos días hasta que el Sprint finalice para cambiar las prioridades. Recuerda que pueden cambiar las prioridades en cada reunión de planificación de Sprint. Es posible detener y cancelar un Sprint en curso si el Product Owner no puede esperar y es necesario cambiar las prioridades en medio del Sprint. En mi experiencia, esto sucede con poca frecuencia en Scrum.

Scrum también se diferencia de otros procesos de desarrollo de software en que no el Scrum Master ni el Product Owner asignan tareas específicas al equipo de desarrollo. En los equipos Scrum, una vez que se ha definido el Sprint Backlog, los miembros del equipo deciden entre ellos cómo lograrlo. Algunos equipos prefieren preasignar todos los elementos entre ellos durante la reunión de planificación, mientras que otros asignan solo un puñado de elementos y los miembros recogen los elementos restantes a medida que completan los primeros.

El trabajo principal del Scrum Master durante el Sprint es asegurarse de que se satisfagan las necesidades del equipo y eliminar los obstáculos. Esto incluye asegurarse de que los desarrolladores y control de calidad tengan acceso a todos los recursos necesarios (personas, documentos, hardware, software), facilitan las reuniones con partes externas, reducen las distracciones (por ejemplo, personas que trabajan en cosas que no forman parte del Sprint Backlog), asesoran al Product Owner y equipo de desarrollado cuando se deben tomar decisiones y, en general, asegurarse de que los desarrolladores y el control de calidad pueden trabajar en el mejor entorno posible.

El Product Owner debe ser fácilmente accesible durante el Sprint para responder preguntas sobre los elementos de Sprint Backlog, revisar el trabajo en progreso con el equipo de desarrollo y asegurarse de que las funciones se muevan en la dirección correcta.

Durante la duración del Sprint, los desarrolladores y el control de calidad trabajan entre sí a diario. En algunos equipos, control de calidad trabaja codo con codo con los desarrolladores para diseñar, desarrollar y probar funciones, mientras que, en otros, prueban funciones pocas horas después de su desarrollo (no semanas después). Este circuito estrecho entre los desarrolladores y el control de calidad es fundamental para garantizar que el código potencialmente se pueda enviar al final del Sprint. Es muy poco probable que el código escrito, pero no probado esté potencialmente listo para enviarse a producción.

Daily Meeting

Durante el Sprint, los miembros del equipo se reúnen a diario para informar el estado al equipo. La reunión diaria de Scrum, o Scrum Diario, es un tiempo de reunión corto encuadrado en 14 minutos en el que cada participante responde tres preguntas:

• ¿Qué hiciste desde la última reunión diaria?
• ¿Qué harás desde ahora hasta la próxima reunión diaria?
• ¿Hay obstáculos en tu camino?

Aunque todo el equipo está presente en la reunión diaria, es muy importante notar que la reunión diaria es para que los miembros del equipo informen sobre el estado a sus pares, no al Scrum Master o al Product Owner. Esta reunión mantiene el ritmo del equipo visible a diario para todos los involucrados en el equipo. Si el equipo avanza según lo planeado, será evidente durante estas reuniones. Asimismo, si alguien está teniendo dificultades, no pasará desapercibido. Los informes frecuentes a sus compañeros ayudan a los equipos a autoorganizarse de manera eficiente a medida que avanza el Sprint y proporciona responsabilidad entre los miembros del equipo. Es importante que el Product Owner y el Scrum Master estén presentes en esta reunión para detectar obstáculos y actuar sobre ellos lo antes posible.

Para que la reunión sea breve, es necesario dejar de lado las discusiones que solo involucran a uno o dos miembros del equipo y que pueden llevar más de unos minutos. Es común tener la reunión diaria como una reunión de pie. Esto ayuda a que la reunión sea breve, ya que a las personas generalmente no les gusta estar de pie más de 15 minutos para discutir nada.

Sprint Retrospective

Scrum es un proceso adaptativo. Una de las formas en que los equipos Scrum logran esto es mediante la realización de reuniones retrospectivas periódicas para hablar sobre lo que tuvo éxito en el último Sprint, lo que podría mejorarse en el siguiente y las nuevas formas en que el equipo podría mejorar. Se trata de reuniones francas en la que participa todo el equipo.

Idealmente, el equipo llevará a cabo estas reuniones al final de cada Sprint. Las reuniones retrospectivas brindan un foro para que el equipo exprese sus inquietudes y se jacte de las cosas que salieron bien. Es muy importante equilibrar la reunión con los éxitos y las áreas de mejora. Para lograr este equilibrio puede solicitar que cada participante traiga a la reunión una lista de dos o tres prácticas que ayudaron al equipo a desempeñarse bien y dos o tres áreas en las que el equipo necesita mejorar.

Las reuniones retrospectivas pueden ser difíciles de gestionar, ya que pueden convertirse fácilmente en discusiones emocionales. Para evitar esto, es muy importante mantener la reunión enfocada en cómo trabajar mejor como equipo y no en un foro para ataques personales. He descubierto que las reuniones retrospectivas son de gran valor para permitir que los equipos desahoguen las cosas que los frustran y obtengan ideas de todo el equipo sobre cómo abordar estos problemas. Del mismo modo, cuando las cosas van bien, es bueno que el equipo hable sobre lo que los hace exitosos y se asegure de que todos sean conscientes de lo que el equipo debe mantener para mantener el impulso. Estas reuniones también refuerzan el concepto de que todos los involucrados trabajan juntos como un solo equipo y que necesitan colaborar entre sí.

En una reunión retrospectiva, los equipos podrían discutir cosas como “debemos asegurarnos de que nuestra pruebas unitarias se mantengan actualizadas, ya que cuando las ignoramos en el último Sprint, los problemas se escabulleron más allá de nuestro control” o “Me pareció realmente útil hacer una demostración de las nuevas pantallas a Jane desde el principio en lugar de al final del Sprint” o “necesitamos una mejora comunicación entre los desarrolladores y el control de calidad, ya que muchos errores no se probaron al principio porque los desarrolladores no los marcaron como listos para ser probados en hora”.

Es importante dar seguimiento a lo que el equipo acuerda durante estas reuniones. Si el equipo comentó que quería comenzar a hacer algo nuevo, como un trabajo de demostración en progreso antes para el Product Owner, el Scrum Master debe ayudar al equipo a asegurarse de que las demostraciones se realicen antes. El Scrum Master también necesita traer este tema de regreso a la próxima reunión retrospectiva para ver si el equipo siente que se está moviendo en la dirección correcta.

Después de la reunión retrospectiva, el equipo está listo para un nuevo Sprint. El equipo se reúne para una nueva reunión de planificación de Sprint y luego repite el ciclo. Dado que el código se puede enviar potencialmente al final de cada Sprint, el proceso de prueba de regresión se simplifica considerablemente. Algunos equipos tienen un tipo especial de Sprint llamado Release Sprint en el que todo lo que hacen es implementar el sistema en el entorno de prueba, realizar pruebas de regresión, solucionar cualquier problema encontrado durante este proceso y luego promover a producción las características completadas en los Sprints desde la última versión.

En esencia, Scrum es extremadamente simple; algunos incluso podrían decir que es simplemente sentido común. Sin embargo, si nunca has gestionado un producto con Scrum, te recomiendo que empieces poco a poco. Como ocurre con la mayoría de las iniciativas de cambio de procesos, el éxito dependerá de que las personas adopten verdaderamente el nuevo paradigma. El rol de coaching de Scrum Master durante las etapas iniciales es crucial para que los equipos lo adopten y tengan éxito con él.

Scrum funciona muy bien con equipos de cinco a diez miembros, incluidos el Product Owner, los desarrolladores, el control de calidad, los analistas y el Scrum Master. Puedes escalarlo para que funcione con equipos más grandes y distribuidos, pero te sugiero que comiences con un equipo pequeño.

Del mismo modo, si estás utilizando iteraciones de seis meses en tu proceso de desarrollo actual, quizás el concepto de Sprints de dos semanas sería demasiado impactante para tu organización. Si ese es el caso, comienza con Sprints de 30 días, ve cómo funciona para tu equipo por un tiempo y luego reevalúa si necesitas hacer iteraciones más cortas.

Scrum proporciona un marco para que los equipos autoorganizados multifuncionales trabajen juntos hacer un objetivo común. Los principios de progreso visible e inspección constante brindan transparencia a los equipos y les permiten adaptarse rápidamente a los cambios en el entorno. En el acelerado mundo actual de nuevas tecnologías, requisitos cambiantes y mayor presión para llegar al mercado, las prácticas de Scrum pueden ayudarlo a entregar software que funcione, con las características adecuadas, con más frecuencia a sus clientes.