Ohne Titel

¿QUE 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 partido, scrum anima a los equipos a aprender mediante las experiencias, a organizarse de forma autónoma 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 ágiles, scrum hace referencia a un conjunto de reuniones, herramientas y funciones que trabajan de forma coordinada para ayudar a los equipos a estructurar y gestionar su trabajo.

Folie 2

• 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 de 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 del orientador ágil
• 

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 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 publicación breves para que tu equipo pueda aprender y mejorar constantemente.

Folie 4

• 
• 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.
• El backlog del producto es la lista de trabajo maestra que se tiene que realizar y que debe mantener el propietario del producto o el gestor del producto. Es una lista dinámica de funciones, requisitos, mejoras y correcciones que actúa como entrada para el backlog del sprint. Se trata, básicamente, de la lista de tareas del equipo. El propietario del producto revisa, vuelve a priorizar y realiza el mantenimiento del backlog del producto constantemente porque, conforme más aprendemos o cambia el mercado, los elementos pueden dejar de ser relevantes o los problemas se pueden resolver de forma distinta.
• El backlog del sprint es la lista de elementos, historias de usuario o resolución de errores seleccionados por el equipo de desarrollo para implementarlos en el ciclo de sprint actual. Antes de cada sprint, en la reunión de planificación del sprint (de la que hablaremos más adelante en este artículo), el equipo elige en qué elementos del backlog del producto va a trabajar durante el sprint. Un backlog de sprint puede ser flexible y puede evolucionar a lo largo del sprint. No obstante, no se puede poner en peligro el objetivo fundamental del sprint, es decir, lo que el equipo quiere lograr con el sprint actual.

Folie 6

• El incremento (u objetivo del sprint) es el producto final que se puede usar y que se obtiene de un sprint. En Atlassian, solemos mostrar el incremento en la demo del fin del sprint, en la que el equipo muestra lo que se ha completado durante el sprint. Puede que no escuches la palabra "incremento" muy a menudo, ya que se utilizan otros términos para referirse a él, como la definición del equipo de "terminado": un hito, objetivo del sprint o incluso versión completa o epic lanzado. Depende de la definición de "terminado" de tu equipo y de cómo estableces tus objetivos de sprint. Por ejemplo, algunos equipos eligen publicar cosas para los clientes al final de cada sprint. Su definición de "terminado" coincidiría con "lanzado". No obstante, esta definición puede no ser la adecuada para otros tipos de equipos. Imagina que trabajas en un producto basado en servidor que solo se puede lanzar a los clientes una vez por trimestre. Puedes elegir que la duración de tus sprints sea de dos semanas, pero tu definición de "terminado" se referirá a completar parte de una versión más amplia que lanzarás en conjunto. Por supuesto, cuanto más se tarde en publicar software, mayor es el riesgo de que no esté a la altura.
• 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.

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.
• Organizar el backlog: en ocasiones denominado "limpieza del backlog". Esta acción es responsabilidad del propietario del producto. Las tareas principales del propietario del producto consisten en orientar el producto hacia la visión de él que tiene y estar pendiente del mercado y los clientes de forma constante.
• Planificación de sprints: el trabajo que se va a realizar (alcance) durante el sprint actual se planifica en esta reunión, en la que participa el equipo de desarrollo completo. El experto en scrum dirige la reunión, en la que el equipo decide el objetivo del sprint.

Folie 8

• Sprint: un sprint es el periodo real en el que el equipo de scrum trabaja en conjunto para finalizar un incremento. La duración de un sprint suele ser de dos semanas, aunque algunos equipos consideran que una semana es un periodo más sencillo para establecer el alcance o que un mes funciona mejor para entregar un incremento valioso. Dave West, de Scrum.org, advierte que cuanto más complicado y desconocido sea el trabajo, más cortos deben ser los sprints.
• Scrum diario o reuniones rápidas: es una reunión diaria muy breve, siempre a la misma hora (normalmente por la mañana) y en el mismo sitio. Muchos equipos intentan que su reunión no dure más de 15 minutos, pero es solo una recomendación.
• En la reunión rápida, debéis compartir todas las preocupaciones que tengáis con respecto al cumplimiento del objetivo del sprint o cualquier impedimento.
• Una forma habitual de dirigir una reunión rápida es que cada miembro del equipo responda a tres preguntas relacionadas con lograr el objetivo del sprint:
• • ¿Qué hice ayer?
• • ¿Qué tengo previsto hacer hoy?
• • ¿Se presenta algún obstáculo?
• No obstante, hemos visto que algunas reuniones tratan solo de leer las agendas del día anterior y la del día siguiente. La teoría que subyace a las reuniones rápidas es que se traten de una charla distendida, para que el equipo pueda centrarse en su trabajo durante el resto del día, por lo que, si se convierten en una lectura diaria de la agenda, no tengas miedo de sacar tu creatividad y cambiar la mecánica.

Folie 9

• Revisión del sprint: al final del sprint, el equipo se reúne en una sesión informal para ver la demo del incremento o analizarlo.
• Retrospectiva del sprint: la retrospectiva es el momento en el que el equipo se reúne para documentar y comentar lo que ha funcionado y lo que no ha funcionado en un sprint, un proyecto, una herramienta, entre las personas o relaciones o incluso en un protocolo
• 

El propietario del producto de scrum

• Los propietarios del producto son los mayores expertos en su producto. Se centran en conocer los requisitos empresariales, de los clientes y del mercado, y priorizan el trabajo que debe realizar el equipo de ingeniería de acuerdo con esta información. Los propietarios de producto eficaces realizan estas tareas:
• Crean y gestionan el backlog del producto.
• Establecen una estrecha asociación con la empresa y el equipo para asegurarse de que todo el mundo conoce los elementos de trabajo del backlog del producto.
• Les proporcionan a los equipos directrices claras acerca de las siguientes funciones que se van a proporcionar.
• Deciden cuando se lanza el producto, con predisposición a que la entrega se realice de forma frecuente.

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 del producto y a la empresa en el proceso de scrum, y buscan formas de perfeccionar 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 trabajo. Como moderador principal, planifica los recursos necesarios (tanto humanos como logísticos) para organizar la planificación de 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 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" ideada 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 organizan de forma autónoma 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.

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 ayuda, en realidad, 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 delimitació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 percibir progreso en poco tiempo.
•