Una guía breve y sencilla de Scrum

Mientras trabajas para crear tu aplicación web o móvil, probablemente oirás pronto a los desarrolladores mencionar el desarrollo ágil de software y el marco Scrum. En esta publicación aclararemos estos términos y te guiaremos por un ciclo típico de Scrum.

tl;dr: Scrum es un marco ágil ligero que funciona en ciclos cortos e iterativos (por ejemplo, dos semanas), al final de los cuales el equipo de desarrollo entrega software funcional y recibe comentarios de las partes interesadas. Las distintas reuniones y los artefactos incorporados en Scrum permiten que el equipo se mantenga organizado y sea transparente mientras se adapta continuamente a esos comentarios.

¿Qué son Agile y Scrum?

Agile es un enfoque de desarrollo de software que destaca la importancia de colaborar con el cliente, adaptarse a requisitos cambiantes, entregar valor continuamente y trabajar en un equipo que se organiza por sí mismo y busca mejorar su eficiencia de forma constante. Se basa en algunos de los principios que han guiado los procesos de fabricación de Toyota desde la década de 1950, como el trabajo sostenible y evitar el desperdicio de recursos. Estas ideas empezaron a adaptarse al desarrollo de software en la década de 1990 y se consolidaron en el Manifiesto por el Desarrollo Ágil de Software en 2001, cuando 17 desarrolladores de software buscaban mejorar las prácticas de la época.

Scrum es un marco ágil que permite a los equipos de desarrollo organizarse y organizar su trabajo. Ofrece formas prácticas de aplicar los principios ágiles al trabajo diario. En Scrum, el trabajo se completa en ciclos cortos e iterativos llamados sprints, y el progreso se mide mediante la gestión de un backlog del producto, pero pronto profundizaremos en estos conceptos. Scrum se centra en la comunicación clara y la transparencia, la inspección del trabajo del equipo para buscar mejoras y la adaptación de los procesos para optimizar el uso del tiempo y los recursos.

Entonces, ¿qué es exactamente un «sprint»?

Un sprint es el intervalo de tiempo definido que engloba incrementos de trabajo en Scrum. Es un período regular y predeterminado que va de una semana a un mes. En sophilabs solemos trabajar en sprints de dos semanas. Al final de un sprint, el equipo de desarrollo entrega software utilizable. Las partes interesadas dan sus comentarios al equipo, que determina cómo puede mejorar durante el siguiente sprint.

¿Qué son los «artefactos» de Scrum?

En Scrum, los artefactos son los documentos que ayudan al equipo de desarrollo a seguir su trabajo y mantener la transparencia con el cliente y entre sus integrantes. Cada artefacto tiene un propósito específico.

Backlog del producto

En pocas palabras, el backlog del producto es una lista descriptiva de todos los elementos que el producto necesitará. Cada requisito suele tomar la forma de una historia de usuario, que describe brevemente una función específica y el objetivo que esta ayudaría al usuario a alcanzar. Una historia de usuario suele seguir este formato: Como [tipo de usuario], quiero [una función o funcionalidad], para poder [alcanzar mi objetivo].

Las historias de usuario mantienen las necesidades del usuario y el valor de negocio en primer plano durante todo el proceso de desarrollo. Pueden incluir criterios de aceptación, que son los atributos específicos que detallan cómo cumplir la funcionalidad y suelen ser propios de cada función.

En el backlog del producto, las historias de usuario se priorizan según las necesidades de las partes interesadas del producto. Las historias al comienzo de la lista también deben ser las más específicas y refinadas, para que el equipo de desarrollo tenga claro lo que implican y pueda agregarlas fácilmente al siguiente sprint.

Backlog del sprint

El backlog del sprint es la lista de historias de usuario que el equipo completará en un sprint determinado. Es un subconjunto del backlog del producto, generalmente tomado de su parte superior.

Tablero Scrum

El tablero Scrum permite seguir las tareas en las que trabaja el equipo durante el sprint actual. Cada tarea debe ubicarse en una de al menos tres columnas; normalmente estas categorías incluyen Por hacer, En curso y Hecho. El tablero Scrum ayuda a los integrantes del equipo a hacerse responsables de su trabajo y permite la transparencia sobre el progreso del equipo durante el sprint.

Los integrantes del equipo usan la Definición de Hecho (DOD) para determinar cuándo está completa cada función o historia de usuario. La DOD es un acuerdo entre el equipo Scrum y las partes interesadas sobre la calidad y los elementos funcionales que debe tener cada función para considerarse terminada y potencialmente publicarse.

Gráfico burn-down/up

Un gráfico burn-down o burn-up muestra cuánto ha logrado el equipo durante un período. El tiempo aparece en el eje horizontal x y el alcance del proyecto se representa en el eje vertical y.

¿Quiénes integran un equipo Scrum?

En Scrum hay tres roles definidos dentro de un equipo de desarrollo. Veamos cuáles son.

Product Owner

El Product Owner es responsable de maximizar el valor que el producto en desarrollo entrega a sus partes interesadas. Lo logra asegurándose de que todas las necesidades del producto que estas han descrito estén debidamente documentadas y organizadas en el backlog del producto.

El Product Owner puede ser alguien del lado del cliente (por ejemplo, quien funda una startup o un ejecutivo de tecnología) o del lado del proveedor de software (en sophilabs, nuestros responsables de producto pueden asumir este rol). Depende del grado de participación que quiera tener una persona emprendedora en el proceso de desarrollo de software.

Scrum Master

El Scrum Master es responsable de guiar al equipo durante el proceso Scrum, acompañarlo ante los desafíos y brindar apoyo cuando sus integrantes encuentran obstáculos. Es la persona experta del equipo en Scrum y Agile.

Integrante del equipo

Los integrantes del equipo son los diseñadores y desarrolladores de software que diseñan y construyen el producto. Son responsables de comunicarse abiertamente, colaborar para resolver problemas y trabajar juntos para mejorar la eficiencia del equipo.

¿Cómo funciona un sprint?

Ahora que entendemos cómo se estructura el equipo Scrum y qué materiales se usan para organizar el trabajo y seguir el progreso, es momento de ver Scrum en acción. Para ello, analizaremos las ceremonias de Scrum que ocurren durante el sprint. Ceremonia es el término que Scrum usa para los distintos eventos y reuniones de este marco. Hay cuatro tipos de ceremonias que se realizan en cada sprint.

Planificación del sprint

El equipo realiza esta reunión al comienzo de cada sprint. El propósito de la planificación del sprint es determinar qué es lo más valioso que se puede construir a continuación para el producto y definir un objetivo concreto que el equipo se comprometa a cumplir al final del sprint. Para ello, el equipo elige del backlog del producto historias de usuario alineadas con ese objetivo y adecuadas para el sprint. Por último, define un plan táctico sobre cómo se hará ese trabajo.

Daily Scrum

A veces también llamado standup, el daily Scrum es una reunión breve (de no más de 15 minutos) que el equipo hace todos los días. Cada integrante comparte el trabajo que completó o los desafíos que enfrentó desde el último daily Scrum. El equipo también usa esta oportunidad para empezar a pensar en soluciones a los obstáculos que puedan estar enfrentando sus integrantes. El daily Scrum mantiene a todos informados sobre el progreso hacia el objetivo del sprint y los problemas que necesitan abordar.

Revisión del sprint

La revisión del sprint ocurre al final de cada sprint. Es una reunión en la que el equipo Scrum muestra a las partes interesadas el progreso mediante una demostración del software funcional que construyó durante ese sprint. Luego, las partes interesadas dan sus comentarios (generalmente documentados como nuevas historias de usuario o tareas en el backlog del producto), permitiendo que el equipo siga mejorando el producto según sus necesidades.

Retrospectiva del sprint

Esta reunión ocurre después de la revisión del sprint y antes de la siguiente sesión de planificación. Durante la retrospectiva del sprint, o retro, el equipo de desarrollo (generalmente sin las partes interesadas) examina cómo trabajó en conjunto durante el último sprint. Sus integrantes comparten lo que creen que salió bien y lo que podría mejorar. El propósito de la retrospectiva es que el equipo identifique áreas de mejora y acuerde cómo mejorarlas. Es una de las formas en que Scrum apoya los cambios incrementales y promueve la mejora continua.

Reflexiones finales

Scrum es un marco ligero que ayuda a los equipos a mantenerse organizados y ágiles. En sophilabs nos encanta cómo Scrum facilita la comunicación constante dentro del equipo y los comentarios regulares de las partes interesadas.

¡Esperamos que nuestra breve introducción a Scrum te haya ayudado a comprender los conceptos básicos! ¹ Si necesitas repasarlos rápidamente o quieres aprender más términos y conceptos ágiles, consulta nuestro práctico Glosario de desarrollo ágil.