Scrum es un marco de gestión de proyectos que enfatiza el trabajo en equipo, la responsabilidad y el progreso iterativo hacia objetivos claramente definidos. Comienza con una premisa sencilla: empieza con lo que puedes ver o saber. Luego, rastrea el progreso y ajusta según sea necesario.
Los tres pilares de Scrum
Scrum se basa en el empirismo, que afirma que el conocimiento proviene de la experiencia y que las decisiones deben basarse en lo que se sabe. Estos tres pilares unen a Scrum.
¿Por qué Scrum?
Scrum entrega funcionalidad de forma incremental, mientras que Waterfall solo la entrega en fases. El desarrollo tradicional Waterfall es un proceso secuencial y basado en fases en el que el valor no se entrega hasta el final del proyecto. Scrum transforma este modelo al entregar nuevas funciones en cada sprint—típicamente cada 2 a 4 semanas—en lugar de centrarse en un gran lanzamiento futuro.
Scrum descompone el trabajo complejo en piezas manejables, divide a las grandes organizaciones en pequeños equipos y transforma proyectos impactantes en una serie de periodos cortos y acotadossprints.
A través del desarrollo iterativo e incremental, las empresas pueden entregar los productos y servicios que los clientes realmente necesitan más rápido y de manera más eficiente. Con Scrum, puedes recibir e integrar el feedback del cliente al final de cada sprint, lo que significa que tus resultados se moldean por el uso real del mundo, en lugar de por suposiciones. Esto facilita mantener a los clientes y a los principales interesados activamente involucrados.
Ágil frente a Scrum
Ágil es una práctica que permite la iteración continua en el desarrollo y pruebas durante todo el ciclo de vida del software. Ágil divide los productos en componentes más pequeños y manejables.Scrum es solo uno de muchos procesos de desarrollo de software ágil iterativos e incrementales que nos permiten centrarnos en entregar valor empresarial en el menor tiempo posible.
Scrum generalmente trata con requisitos que pueden cambiar o son desconocidos al inicio de un proyecto. Scrum se caracteriza por:
- Ligero
- Fácil de entender
- Difícil de dominar
Beneficios de Scrum
Estos son los beneficios que Scrum aporta a las organizaciones, equipos, productos e individuos:
- Mejor calidad: Existe un marco para alcanzar la visión o los objetivos. Scrum proporciona retroalimentación continua y visibilidad para garantizar que la calidad sea tan alta como sea posible. Scrum ayuda a garantizar la calidad mediante prácticas como:
- Tiempo de mercado reducido: Scrum ha demostrado entregar valor a los usuarios finales un 30%–40% más rápido que los métodos tradicionales.
- Mayor retorno sobre la inversión (ROI): Un tiempo de mercado más corto es una razón clave por la que los proyectos Scrum logran un mayor ROI. La acumulación temprana de ingresos y beneficios significa retornos totales más altos. Esto se basa en el principio fundamental del cálculo del Valor Actual Neto (VAN).
- Mayor moral del equipo: Trabajar con personas felices y comprometidas es satisfactorio y productivo. La autorregulación coloca las decisiones que normalmente toman los gerentes o las organizaciones en manos deEquipo Scrum miembros.
- Colaboración más fuerte del equipo: Cuando los equipos Scrum son dueños del proyecto y del producto, pueden lograr excelentes resultados. Los equipos Scrum colaboran y mejoran la calidad y el rendimiento del proyecto mediante un compromiso y una comunicación mejorados.
Marco Scrum
Scrum es simple. No es un conjunto de mandatos rígidos e interconectados. Scrum no es una metodología. Scrum encarna el método científico del empirismo. Reemplaza los enfoques algorítmicos procedimentales con métodos heurísticos, respetando a las personas y la autorregulación para abordar la imprevisibilidad y resolver problemas complejos. El diagrama siguiente muestra Scrum en acción, tal como se describe por Ken Schwaber y Jeff Sutherland en su libro «Scrum: El arte de hacer el doble de trabajo en la mitad del tiempo», ilustrando el recorrido desde la planificación hasta la entrega de software.
Componentes del proceso Scrum
El marco Scrum en sí es simple. Define solo unas pocas directrices generales, con un número pequeño de reglas, roles, artefactos, y eventos. Sin embargo, cada uno de estos componentes es crucial para propósitos específicos y esencial para utilizar con éxito el marco.
Los componentes principales del marco Scrum son:
- Roles Scrum: Scrum Master, Propietario del producto, y el equipo Scrum
- Artefactos: Backlog de sprint, Backlog del producto, Gráfico de eliminación, registros, etc.
- Eventos Scrum: Planificación de Sprint, Revisión de Sprint, Reunión Diaria de Scrum, Retrospectiva de Sprint, etc.
- Sprints
El diagrama siguiente muestra los elementos clave del marco Scrum. El proceso ha sido visualizado utilizando el Mesa de Proceso Scrum de las herramientas de software ágiles de Visual Paradigm.
Roles de Scrum
Cuando una organización adopta Scrum, lo primero que hay que entender es cómo los roles de Scrum difieren de los roles tradicionales de gestión de proyectos. Aunque solo hay tres roles principales en Scrum, no se alinean automáticamente con títulos de trabajo familiares. Comencemos con definiciones breves de cada uno:
Propietario del Producto
El Propietario del Producto es el rol de Scrum responsable de representar a la comunidad empresarial o de usuarios. Trabaja estrechamente con los usuarios para definir características en el backlog del producto. Las responsabilidades clave incluyen:
- Definir la visión y la estrategia del producto, incluyendo objetivos a corto y largo plazo;
- Proporcionar o recopilar conocimientos sobre el producto o servicio;
- Comprender y comunicar las necesidades del cliente al equipo de desarrollo;
- Recopilar, priorizar y gestionar los requisitos del producto o servicio;
- Asumir la responsabilidad de la presupuestación del producto o servicio, incluida la rentabilidad;
- Determinar las fechas de lanzamiento del producto o servicio;
- Responder preguntas y tomar decisiones diariamente con el equipo de desarrollo;
- Aceptar o rechazar el trabajo completado durante el Sprint;
- Presentar los principales entregables del equipo al final de cada Sprint;
- Gestionar el backlog del producto.
Máster de Scrum
El Máster de Scrum es el facilitador del equipo de desarrollo ágil. Scrum permite que los equipos se organicen a sí mismos y se adapten rápidamente basándose en principios ágiles. El Máster de Scrum gestiona el flujo de información. Responsabilidades clave:
- Actuar como coach para ayudar al equipo a seguir los valores y prácticas de Scrum;
- Ayudar a eliminar obstáculos y proteger al equipo de distracciones externas;
- Facilitar una buena colaboración entre el equipo y los interesados;
- Promover el sentido común y la transparencia dentro del equipo;
- Proteger al equipo de las interrupciones organizativas.
Equipo Scrum
El equipo Scrum (también conocido como equipo de desarrollo) está compuesto por 3 a 9 miembros que deben poseer colectivamente todas las habilidades técnicas necesarias para entregar el producto o servicio. Son guiados directamente por el Scrum Master, pero no gestionados en el sentido tradicional. Deben ser autogestionados, multidisciplinarios y responsables de completar todas las tareas necesarias.
El equipo de desarrollo es responsable de entregar un incremento potencialmente entregable del producto al final de cada Sprint, cubriendo análisis, diseño, desarrollo, pruebas y redacción técnica. Las características importantes de un equipo Scrum incluyen:
- Autogestionado: Todos los miembros del equipo gestionan su propio trabajo para completar las tareas asignadas. En Scrum ágil, no existe un líder de equipo ni un gerente directo. Todos deben comprometerse lo suficiente para impulsar sus propias actividades y contribuir al éxito del equipo. Si uno falla, todos fallan.
- Multidisciplinario: Todos los miembros del equipo deben poseer todos los conocimientos y habilidades necesarios para entregar un producto de alta calidad, potencialmente entregable. Los expertos pueden ser invitados para brindar orientación, pero únicamente para transferir conocimientos al equipo y cerrar brechas de habilidades.
- El Propietario del Producto requiere una visión empresarial: El Propietario del Producto representa la voz del cliente y debe traducir sus necesidades en elementos accionables para el Scrum Master y el equipo de desarrollo. Este suele ser un rol de tiempo completo.
- El Scrum Master no es un gerente directo: Ayudan a capacitar al equipo de desarrollo y eliminan los obstáculos que dificultan el progreso.
Artefactos Scrum
Los artefactos Scrum ayudan a definir el trabajo que entra al equipo y el que actualmente se está desarrollando. Aunque existen más artefactos, como historias de usuario, listas de lanzamiento y gráficos de desgaste, aquí nos enfocamos en los tres principales:
Lista de Producto
La Lista de Producto es una lista priorizada de historias de usuario que representan las características que el equipo de producto necesita o espera. Normalmente, el Propietario del Producto mantiene esta lista.
Lista de Sprint
La Lista de Sprint contiene un conjunto de elementos seleccionados para completar durante el Sprint actual. Dos puntos clave sobre la relación entre la Lista de Sprint y la Lista de Producto:
1. El equipo decide qué agregar al Sprint. Por lo tanto, el equipo es dueño y responsable de entregar estos elementos.
2. Antes de mover un elemento de la Lista de Producto a la Lista de Sprint, el equipo debe asegurarse de tener toda la información necesaria. El equipo suele definir una lista de verificación de criterios que deben cumplirse antes de que un elemento pueda agregarse.
Lista de Producto frente a Lista de Sprint
La Lista de Sprint es la lista de tareas que el equipo Scrum se compromete a completar durante el Sprint. Durante la reunión de planificación del Sprint, el equipo suele seleccionar unas pocas Elementos de la Lista de Producto en forma de historias de usuario y determina las tareas necesarias para completar cada una, como se muestra a continuación:
Gráfico de desgaste
Un gráfico de desgaste es una representación gráfica del trabajo pendiente a lo largo del tiempo. El trabajo pendiente (o trabajo de la lista) se muestra en el eje vertical, con el tiempo en el eje horizontal. Es un gráfico continuo del trabajo que queda por hacer. Puede usarse para predecir cuándo se completará todo el trabajo. Es comúnmente utilizado en métodos de desarrollo de software ágil como Scrum, pero puede aplicarse a cualquier proyecto con progreso medible a lo largo del tiempo. El trabajo pendiente puede medirse en tiempo o en puntos de historia.
Eventos Scrum
¡La comunicación es clave! Scrum se basa en la transparencia en todos los aspectos (Pilar de Scrum #1). Dado este principio fundamental, el marco está construido alrededor de una serie de eventos clave para garantizar los otros dos pilares—Inspección y Adaptación—como se muestra en la tabla a continuación:
| Evento | Inspección | Adaptación |
|---|---|---|
| Planificación del Sprint |
|
|
| Reunión Diaria |
|
|
| Revisión del Sprint |
|
|
| Retrospectiva del Sprint |
|
|
Nota: Durante cada Sprint, hay cinco reuniones clave en Scrum, como se muestra a continuación:
Planificación del Sprint
Cada Sprint comienza con la planificación. El equipo debe determinar y comprometerse con lo que entregará como parte del Sprint. Los elementos posibles siempre se extraen del Backlog del Sprint, como se muestra a continuación:
Aquí es donde el Scrum Master puede destacar. El Propietario del Producto define lo que se necesita desde una perspectiva de negocio/usuario, el equipo Scrum determina lo que cree que puede entregar, y el Scrum Master asegura la mejor adaptación para ambos lados.
Reunión Diaria del Scrum
Una vez que el equipo se compromete con lo que entregará como parte del Sprint, realiza una Reunión Diaria de Pie. El objetivo principal es asegurar que cada miembro del equipo (y posiblemente observadores) entienda plenamente el estado y el progreso del trabajo:
- ¿Qué hice ayer?
- ¿Qué haré hoy?
- ¿Qué me está bloqueando?
Esta actualización diaria proporciona retroalimentación inmediata al equipo. Las reuniones son breves—no más de 3 minutos por persona.
Nota:Los observadores están allí para observar. El Scrum Master debe minimizar las distracciones externas e internas.
Reunión de Revisión del Sprint
La Revisión del Sprint o la Demostración se realiza al final del Sprint para inspeccionar el Incremento. El equipo demuestra el Incremento según la Definición de Terminado, centrándose en el Objetivo del Sprint. El Propietario del Producto revisa y acepta el Incremento entregado.
Retrospectiva del Sprint
La Retrospectiva del Sprint es típicamente la última actividad del Sprint. Muchos equipos la realizan inmediatamente después de la Revisión del Sprint. Todo el equipo—incluyendo al Scrum Master y al Propietario del Producto—debe participar. Una retrospectiva de una hora suele ser suficiente. Esta reunión permite al equipo reflexionar sobre:
- ¿Qué deberíamos empezar a hacer?
- ¿Qué deberíamos dejar de hacer?
- ¿Qué deberíamos seguir haciendo?
El objetivo es mejorar continuamente la eficiencia del equipo.
Refinamiento del Backlog
Piensa en el Backlog del Producto como el mapa de ruta del proyecto. A medida que el equipo colabora, crea y actualiza una lista de todos los elementos necesarios para completar el proyecto, asegurando que se cumplan todos los requisitos necesarios.
Sprints
En el marco Scrum, todas las actividades necesarias para implementar un elemento del Backlog del Producto Scrum se realizan dentro de un Sprint (también llamado “Iteraciones”). Los Sprints siempre son breves—típicamente de 2 a 4 semanas. Cada Sprint sigue un proceso definido, como se muestra a continuación:
Como se señaló, los elementos del Backlog del Producto se priorizan y se seleccionan para el Backlog del Sprint. Un Sprint contiene solo unos pocos elementos principales—cualquier subestimación del trabajo para un solo elemento puede afectar significativamente al Sprint. Dado que los elementos más grandes suelen ser más difíciles de estimar y comprender, aumenta el riesgo de fracaso del Sprint. Los equipos Scrum experimentados dedican tiempo y esfuerzo a descomponer elementos complejos o grandes (por ejemplo, funciones de usuario o Epics) en historias de usuario más pequeñas (o incluso en tareas o sub-tareas).
Epic
Un Epic captura un gran volumen de trabajo. Es esencialmente una “gran historia de usuario” que puede descomponerse en muchas historias más pequeñas. Completar un Epic puede tomar varios Sprints. Por lo tanto, al utilizar Epics en el desarrollo, deben descomponerse en historias de usuario más pequeñas.
Los Epics se introducen temprano en el ciclo de vida del proyecto. Son puntos funcionales de alto nivel, casi enfocados al marketing.
Llamamos a las historias grandes “Epics” para transmitir su escala. Piénsalo como una película. Si te digo que una película es de “acción-aventura”, obtienes una idea de lo que puedes esperar—posiblemente persecuciones en coche, disparos, etc. De manera similar, etiquetar una historia como “Epic” puede a veces transmitir contexto adicional.
Historia de Usuario
Una Historia de Usuario es una declaración breve de un requisito del producto o un caso de negocio. Suele escribirse en un lenguaje sencillo para ayudar a los lectores a comprender qué debe hacer el software. El Propietario del Producto crea la historia. Luego, los miembros del equipo Scrum descomponen la historia en una o más tareas Scrum.
Las historias de usuario suelen ser funciones visibles para el usuario final. Sigue el formato: «Quiero [hacer algo] para que pueda alcanzar un objetivo». Brindan valor al cliente/usuario. Este es el requisito del producto del cliente.
Ejemplo: «Como cliente, quiero crear una cuenta para poder ver mis compras del año pasado y ayudarme a planificar mi presupuesto el próximo año».
Tarea
En contraste, una tarea es más técnica. Las tareas a menudo implican código, diseño, creación de datos de prueba, automatización, etc. Estas suelen ser responsabilidades individuales. Las tareas no se redactan en formato de historia de usuario. Son más técnicas.
Ejemplo: «Evaluar el ángulo de la interfaz de usuario utilizando Material Design» o «Enviar la aplicación a la App Store».
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish