Cerrar

Scrum

Aprende a utilizar scrum con lo mejor de él

¿Qué es scrum?

Scrum es un marco de trabajo que permite el trabajo colaborativo entre equipos. Al igual que un equipo de rugby (de donde proviene su nombre) cuando entrena para el gran parido, scrum anima a los equipos a aprender a través de las experiencias, a autorganizarse mientras se trabaja en un problema y a reflexionar sobre sus victorias y derrotas para mejorar continuamente.

Aunque son los equipos de desarrollo de software los que utilizan con mayor frecuencia el scrum del que estoy hablando, sus principios y lecciones se pueden aplicar a todo tipo de trabajo en equipo. Esta es una de las razones por las que es tan popular. Aunque se considera a menudo un marco de trabajo de gestión de proyectos ágil, scrum describe un conjunto de reuniones, herramientas y funciones que trabajan de forma coordinada para ayudar a los equipos a estructurar y gestionar su trabajo.

En este artículo, analizaremos cómo se compone un marco de trabajo tradicional de scrum con la ayuda de la guía de scrum y David West, director ejecutivo de Scrum.org. También incluiremos ejemplos de cómo nuestros clientes se desvían de estos principios para satisfacer sus necesidades específicas. Para ello, nuestra propia Megan Cook, gestora de productos de grupo para Jira Software y anteriormente orientadora ágil, proporcionará consejos y trucos en la serie de vídeos de orientador ágil:

Scrum articles

[CONTINUED]

El marco de trabajo

Se suele pensar que scrum y la metodología ágil son lo mismo porque scrum se centra en la mejora continua, que es un principio básico de la metodología ágil. Sin embargo, scrum es un marco de para realizar el trabajo, mientras que la metodología ágil es una mentalidad. En realidad, uno solo no puede "adoptar una metodología ágil", ya que requiere la dedicación de todo el equipo para cambiar la forma de pensar a la hora de ofrecer valor a los clientes. Lo que sí puedes usar es un marco de trabajo como scrum, para ayudar a tu equipo a empezar a pensar de esa manera y poner en práctica la construcción de principios de metodología ágil en tu comunicación y trabajo diarios.

El marco de trabajo de scrum es heurístico. Se basa en el aprendizaje continuo y en la adaptación a los factores fluctuantes. Reconoce que el equipo no lo sabe todo al inicio de un proyecto y evolucionará a través de la experiencia. Scrum está estructurado para ayudar a los equipos a adaptarse de forma natural a las condiciones cambiantes y a los requisitos de los usuarios, con el cambio de prioridades integrado en el proceso y ciclos de lanzamiento breves para que tu equipo pueda aprender y mejorar constantemente.

El marco de trabajo de scrum | Orientador ágil de Atlassian

Aunque scrum está estructurado, no es del todo rígido. Su ejecución se puede adaptar a las necesidades de cualquier organización. Existen muchas teorías acerca de cómo deben trabajar los equipos de scrum exactamente para tener éxito. Sin embargo, después de más de una década ayudando a los equipos ágiles a realizar el trabajo en Atlassian, hemos aprendido que la comunicación clara, la transparencia y la dedicación a la mejora continua siempre deben ser el núcleo del marco de trabajo que elijas. Y, el resto, depende de ti.

Artefactos de scrum

Empecemos identificando los tres artefactos en scrum. Cuando hablamos de "artefactos" nos referimos a algo que fabricamos, por ejemplo, una herramienta para solucionar un problema. En scrum, estos tres artefactos son un backlog del producto, un backlog de sprint y un incremento con tu definición de "finalizado". Estas son las tres constantes en un equipo de scrum que seguimos revisando y en las que continuamos invirtiendo horas extra.

  • Backlog del producto: es la lista principal del trabajo que debe realizar el propietario del producto o el gestor de producto. Se trata de una lista dinámica de funciones, requisitos, mejoras y correcciones que actúa como la entrada para el backlog de sprint. Básicamente, se trata de la lista de "cosas por hacer" del equipo. El propietario del producto está constantemente revisando, cambiando las prioridades y realizando el mantenimiento del backlog del producto, ya que, a medida que sabemos más o que cambia el mercado, es posible que los elementos ya no sean relevantes o que los problemas se solucionen de otras maneras.
  • Backlog de sprint: se trata de la lista de elementos, historias de usuario o correcciones de errores, seleccionadas por el equipo de desarrollo, para su implementación en el ciclo actual de sprint. Antes de cada sprint, en la reunión de planificación de sprint (que analizaremos más adelante en el artículo), el equipo elige los elementos en los que trabajará para el sprint del backlog del producto. El backlog de sprint puede ser flexible y puede evolucionar durante un sprint. No obstante, no se puede poner en peligro el objetivo fundamental del sprint, lo que el equipo quiere lograr con el sprint actual.
  • Incremento (u objetivo del sprint) es el producto final utilizable de un sprint. En Atlassian, solemos demostrar el "incremento" durante la demostración de fin de sprint, donde el equipo muestra lo que se ha completado en el sprint. Es posible que no escuche la palabra "incremento" en ningún sitio, ya que a menudo se la conoce como la definición del equipo de "Finalizado", un hito, el objetivo del sprint o incluso una versión completa o una épica lanzada. Solo depende de la definición de "Finalizado" de tus equipos y de cómo defines tus objetivos del sprint. Por ejemplo, algunos equipos eligen lanzar algo a sus clientes al final de cada sprint. Por tanto, su definición de "finalizado" se correspondería con "lanzado". Sin embargo, es posible que esto no sea realista en otros tipos de equipos. Supongamos que trabajas en un producto basado en servidor que solo se puede lanzar a los clientes cada trimestre. Podrías elegir trabajar en sprints de 2 semanas, pero tu definición de "finalizado" podría corresponderse con la finalización de parte de una versión más grande que planeas lanzar toda junta. Por supuesto, cuanto más se demore el lanzamiento del software, mayor será el riesgo de que el software no cumpla lo que se espera de él.

Como puedes ver, hay muchas variaciones, incluso dentro de los artefactos, que tu equipo puede elegir definir. Por eso es importante estar abierto a la evolución en la forma de mantenimiento, incluso de los artefactos. Tal vez tu definición de "finalizado" hace que tu equipo tenga que deshacer tareas, y necesitas revisarla y elegir una nueva definición.

Consejo de experto

Debes ser tan ágil con tu marco de trabajo como lo eres con tu producto. Tómate el tiempo que necesites para comprobar cómo van las cosas, hacer los ajustes necesarios y no fuerces las cosas simplemente por razones de uniformidad.

Protocolos o eventos de scrum

Algunos de los componentes más conocidos del marco de trabajo de scrum son el conjunto de eventos secuenciales, protocolos o reuniones que los equipos de scrum realizan de forma periódica. En los protocolos es donde observamos la mayoría de las variaciones para los equipos. Por ejemplo, algunos equipos consideran que realizar todos estos protocolos es engorroso y repetitivo, mientras que otros los utilizan como un registro necesario. Nuestro consejo es empezar usando todos los protocolos para dos sprints y ver cómo va. Después, puedes realizar una retrospectiva rápida y ver en qué puntos es necesario realizar ajustes.

 

A continuación, se muestra una lista de todas los protocolos clave en los que un equipo de scrum puede participar:

  1. Organización del backlog: este evento, que a veces se conoce como limpieza del backlog, es responsabilidad del propietario del producto. Los principales trabajos del propietario del producto son dirigir el producto hacia su visión del producto y estar al tanto del mercado y los clientes. Por tanto, él o ella realiza el mantenimiento de esta lista utilizando los comentarios de los usuarios y del equipo de desarrollo para ayudar a priorizar y mantener la lista limpia y a punto para trabajar sobre ella en cualquier momento. Puedes obtener más información sobre cómo mantener un backlog de la forma más adecuada aquí.

  2. Planificación de sprint: en esta reunión, todo el equipo de desarrollo planifica el trabajo que se va a realizar (alcance) durante el sprint actual. Esta reunión la dirige el experto en scrum y, en ella, el equipo decide el objetivo del sprint. Posteriormente, se añaden historias de usuario específicas al sprint desde el backlog del producto.  Estas historias siempre se adecuan al objetivo y también son acordadas por el equipo de scrum para que sea factible implementarlas durante el sprint.

    Al final de la reunión de planificación, cada miembro del scrum debe tener claro qué se puede entregar en el sprint y cómo se puede entregar el incremento.

  3. Sprint: un sprint es el periodo real en que el equipo de scrum trabaja de forma conjunta para finalizar un incremento. La duración de un sprint suele ser de dos semanas, aunque algunos equipos manifiestan que les resulta más fácil una semana para el alcance o un mes para entregar un incremento valioso. Dave West, de Scrum.org, advierte de que cuanto más complejo sea el trabajo y más incógnitas haya, más corto debería ser el sprint. Pero realmente esto depende de tu equipo, y no debes tener miedo de cambiarlo si no funciona. Durante este periodo, el propietario del producto y el equipo de desarrollo podrán renegociar el alcance, en caso de que sea necesario. Aquí está el quid de la naturaleza empírica del scrum.

    Todos los eventos (desde la planificación hasta la retrospectiva) tienen lugar durante el sprint. Una vez que se establece un determinado intervalo de tiempo para un sprint, debe seguir siendo coherente durante todo el periodo de desarrollo. Esto ayuda al equipo a aprender de las experiencias pasadas y a aplicar ese conocimiento a futuros sprints.

  4. Scrum diario o reunión rápida: se trata de una reunión diaria de muy corta duración que tiene lugar siempre a la misma hora (normalmente, por las mañanas) y en el mismo sitio para simplificarla. Muchos equipos tratan de finalizar la reunión en 15 minutos, pero eso es solo una guía. Esta reunión también se denomina "reunión rápida diaria" y con ello se hace hincapié en que debe ser rápida. El objetivo del scrum diario es que todos los miembros del equipo estén en sintonía, se adecuen al objetivo del sprint y obtengan un plan para las próximas 24 horas.

    La reunión rápida es el momento de expresar cualquier inquietud que tengas con el cumplimiento del objetivo del sprint o de notificar los impedimentos existentes.

    Una forma habitual de realizar la reunión rápida es que cada miembro del equipo responda tres preguntas en el contexto de alcanzar el objetivo del sprint:

    •      ¿Qué hice ayer?
    •      ¿Qué tengo planificado para hoy?
    •      ¿Hay algún obstáculo?

    Sin embargo, hemos observado que la reunión se ha convertido rápidamente en personas que leen sus agendas del día anterior y del día siguiente. La teoría detrás de la reunión diaria es que las conversaciones que pueden suponer una distracción tengan lugar en la reunión diaria, para que el equipo pueda concentrarse en el trabajo el resto del día.  Entonces, si se convierte en una lectura en voz alta de la agenda diaria, no tengas miedo de cambiarla y ser creativo.

  5. Revisión de sprint: al final del sprint, el equipo se reúne en una sesión informal para ver una demostración o inspeccionar el incremento. El equipo de desarrollo muestra los elementos del backlog que ahora están "finalizados" a las partes interesadas y a los compañeros de equipo para recibir comentarios. El propietario del producto puede decidir si lanza o no el incremento, aunque en la mayoría de los casos el incremento se lanza.

    Esta reunión de revisión también se produce cuando el propietario del producto repasa el backlog del producto basado en el sprint actual, que se puede utilizar en la próxima sesión de planificación de sprint. Para un sprint de un mes, pon el límite de tu revisión de sprint en un máximo de cuatro horas.

  6. Retrospectiva de sprint: la retrospectiva es donde el equipo se reúne para documentar y analizar qué ha funcionado y qué no ha funcionado en un sprint, un proyecto, en las personas o relaciones, herramientas o incluso para determinados protocolos. La idea es crear un lugar donde el equipo pueda centrarse primordialmente en lo que salió bien y en lo que debe mejorarse para la próxima vez, y menos en lo que salió mal.

Tres funciones esenciales para alcanzar el éxito con scrum

El equipo de scrum debe componerse de tres cargos específicos: el propietario del producto, el experto en scrum y el equipo de desarrollo. Y, puesto que los equipos de scrum son interdisciplinares, el equipo de desarrollo está formado por evaluadores, diseñadores, especialistas en experiencia de usuario e ingenieros de operaciones, además de desarrolladores.  

El propietario del producto de scrum

Los propietarios de producto son quienes más conocen el producto. Están centrados en entender los requisitos empresariales, de los clientes y del mercado, para luego priorizar el trabajo que el equipo de ingeniería debe realizar para cumplirlos. Los propietarios de producto eficaces:

  • Crean y gestionan el backlog del producto
  • Se asocian estrechamente con el negocio y el equipo para asegurarse de que todo el mundo entiende los elementos de trabajo en el backlog del producto.
  • Aportan al equipo directrices claras sobre qué funcionalidades entregar a continuación.
  • Deciden cuándo lanzar el producto con predisposición hacia una entrega más frecuente

El propietario del producto no siempre es el gestor de proyectos. Los propietarios de producto se centran en asegurarse de que el equipo de desarrollo entrega el mayor valor a la empresa. Asimismo, es importante que el propietario de producto sea una única persona. Ningún equipo de desarrollo desea directrices cruzadas de varios propietarios de producto.

El experto en scrum

Los expertos en scrum son los mayores especialistas de scrum en el equipo. Proporcionan formación a los equipos, a los propietarios de producto y a la empresa en el proceso de scrum, y buscan formas de afinar su práctica.

Un experto en scrum eficaz conoce profundamente el trabajo que realiza el equipo y puede ayudarlo a optimizar su transparencia y flujo de entrega. Como conseguidor principal, planifican los recursos necesarios (tanto humanos como logísticos) para organizar los plazos de los sprints, las reuniones rápidas, la revisión de sprints y las retrospectivas de sprints.

El equipo de desarrollo de scrum

Los equipos de scrum teams sacan el trabajo adelante. Son los que más conocen las prácticas de desarrollo sostenible. Los equipos de scrum más eficaces tienen una relación estrecha, se encuentran en la misma ubicación y están compuestos por entre cinco y siete miembros Una forma de calcular el tamaño del equipo es usar la famosa "regla de las dos pizzas" acuñada por Jeff Bezos, el director ejecutivo de Amazon (el equipo debe ser lo suficientemente pequeño como para compartir dos pizzas).

Los miembros del equipo tienen distintas habilidades y se forman entre sí para que nadie se convierta en un cuello de botella en la entrega de trabajo. Los equipos de scrum sólidos se autorganizan y enfocan sus proyectos con una clara actitud colectiva. Todos los miembros del equipo se ayudan entre sí para asegurar una finalización satisfactoria del sprint.

El equipo de scrum impulsa el plan de cada sprint. Prevén cuánto trabajo creen que pueden finalizar a lo largo de la iteración en función de su historial de velocidad. Mantener una longitud fija de la iteración aporta al equipo de desarrollo feedback sobre su estimación y proceso de entrega, lo cual a su vez consigue que las previsiones sean cada vez más precisas.

Scrum, kanban y la metodología ágil

Scrum es un marco de trabajo de metodología ágil tan popular que a menudo se malinterpreta scrum y ágil, y se piensa que es lo mismo. También existen otros marcos de trabajo, como kanban, que es una alternativa conocida. Algunas empresas incluso optan por seguir un modelo híbrido de scrum y kanban, que ha adquirido el nombre de "Scrumban o "Kanplan", que es kanban con un backlog.  

Tanto scrum como kanban utilizan métodos visuales como el tablero de scrum o tablero de kanban para realizar un seguimiento del progreso del trabajo. Ambos enfatizan la eficiencia y dividen las tareas complejas en bloques más pequeños de trabajo manejable, aunque sus enfoques hacia la consecución del objetivo son diferentes.

Scrum se centra en iteraciones más pequeñas y de longitud fija. Una vez finalizado el periodo para un sprint, se determinan las historias o las entradas de backlog del producto que se pueden implementar durante este ciclo de sprint. Sin embargo, en kanban, la cantidad de tareas o el trabajo en curso (límite de WIP) que se implementará en el ciclo actual se fija al principio. El tiempo necesario para implementar estas funciones se calcula al revés.

Kanban no cuenta con un marco de trabajo tan estructurado como scrum. Aparte del límite de WIP, está bastante abierto a la interpretación. Scrum, sin embargo, tiene varios conceptos categóricos aplicados como parte de su implementación, como la revisión de sprint, retrospectiva, scrum diario, etc. También insiste en la interdisciplinariedad, que es la capacidad de un equipo de scrum para no depender de miembros externos para lograr sus objetivos. Reunir a un equipo interdisciplinar no es tarea fácil. En ese sentido, el método kanban es más fácil de adaptar, mientras que el scrum puede considerarse como un cambio fundamental en el proceso de pensamiento y el funcionamiento de un equipo de desarrollo.

Entonces, ¿por qué elegir scrum?

El marco de trabajo de scrum es sencillo en sí mismo. Las reglas, artefactos, eventos y funciones son fáciles de entender. Su enfoque semiprescriptivo en realidad ayuda a eliminar las ambigüedades en el proceso de desarrollo, a la vez que ofrece suficiente espacio para que las empresas introduzcan su toque personal.

La organización de tareas complejas en historias de usuario manejables hace que sea ideal para proyectos difíciles. Además, la clara demarcación de funciones y los eventos planificados aseguran que haya transparencia y propiedad colectiva en todo el ciclo de desarrollo. Los lanzamientos rápidos mantienen al equipo motivado y contentos a los usuarios, ya que pueden ver el progreso en un corto periodo.

No obstante, convertirse en experto de scrum puede llevar su tiempo, especialmente si el equipo de desarrollo está aclimatado a un modelo típico de cascada. Los conceptos de iteraciones más pequeñas, reuniones diarias de scrum, revisiones de sprint e identificación de un experto en scrum podrían suponer un cambio cultural difícil para un equipo nuevo.


Pero, los beneficios a largo plazo superan con creces la curva de aprendizaje inicial. El éxito de scrum en el desarrollo de productos de software y hardware complejos en distintos sectores y mercados verticales lo convierte en un marco de trabajo convincente para adoptarlo en tu organización.

 

Claire Drumond
Claire Drumond

Claire Drumond es estratega de marketing, oradora y redactora de Atlassian. Es autora de numerosos artículos publicados en los blogs de Trello y Atlassian, y es colaboradora habitual de varias publicaciones en Medium, como HackerNoon, Art + Marketing y PoetsUnlimited. Habla en conferencias tecnológicas en todo el mundo sobre la metodología ágil, en las que trata de desmontar la estructura tradicional y crear empatía.
Twitter: @claire_drumond // Medium: @cdrumond

Up Next
sprints