Cómo se Desarrolló Scrum: Orígenes y Aplicación de la Metodología
Scrum es una metodología de desarrollo ágil con una distribución de roles única dentro del equipo y una organización distintiva de las iteraciones. Scrum, como otros métodos de gestión de proyectos ágiles, enfatiza un enfoque de equipo, iteraciones cortas y mejora continua durante el trabajo. Estos principios se realizan a través de un conjunto de roles, reglas, procesos y herramientas específicas, lo que permite a los equipos producir productos el doble de rápido.
En los equipos de Scrum, los roles clave son el Scrum master y el product owner, las iteraciones comienzan con planificación donde los miembros del equipo “juegan” al póker de planificación, y terminan con una demostración y retrospectiva.
La metodología Scrum fue creada por los estadounidenses Jeff Sutherland, un investigador y consultor empresarial, y Ken Schwaber, un programador en ejercicio, en 1993. En 1995, los autores presentaron oficialmente su enfoque en una conferencia científica de la Association for Computing Machinery en Austin, Texas.
La idea de los coautores era novel: tomaron tanto el concepto como el nombre del trabajo de los investigadores de gestión japoneses Takeuchi y Nonaka, "El Nuevo Juego de Desarrollo de Productos", publicado en 1986. Los fabricantes japoneses ya estaban utilizando enfoques que formaban la base de Scrum. El nombre de la metodología proviene del rugby, donde "scrum" – una jugada – resalta la importancia del trabajo en equipo para la victoria en el campo.
Aplicación de Scrum en TI y Más Allá
Scrum se aplicó por primera vez en empresas productoras de software. El primer proyecto gestionado por Sutherland antes de la presentación oficial de Scrum fue desarrollar software para una red de cajeros automáticos (1983). Los programadores en empresas y departamentos de TI siguen siendo los principales usuarios de Scrum. Sin embargo, el creador de la metodología insiste en que Scrum se puede usar para resolver cualquier tarea, citando ejemplos en manufactura, construcción, educación, política e incluso tareas del hogar como la limpieza general u organizar eventos.
Según el informe de 2016 de Scrum Alliance informe, el 21% de los proyectos completados usando Scrum no estaban relacionados con TI. Varios departamentos usan Scrum con éxito:
Scrum vs. Ágil vs. Cascada
Scrum pertenece al grupo de metodologías ágiles. Ágil no es una metodología separada, sino una filosofía de desarrollo. Sus principales principios están enumerados en el "Manifiesto para el Desarrollo Ágil de Software" (2001), resaltando la importancia del equipo, el enfoque en el producto, la transparencia del proceso, la mejora continua y resultados rápidos.
Scrum es uno de los marcos ágiles, una metodología formalizada para el trabajo en proyectos. Otras metodologías ágiles incluyen XP, Crystal, Kanban, Lean, Desarrollo Rápido de Aplicaciones, Scrumban, etc. Así que, Scrum es ágil, pero ágil no es solo Scrum.
Para visualizar las diferencias y similitudes entre Scrum y Ágil:
Scrum | Ágil | |
Filosofía | - | + |
Metodología | + | - |
Rituales | + | - |
Roles | + | - |
Artefactos* | + | - |
Transparencia | + | + |
Iteraciones Cortas | + | + |
Despliegues Frecuentes | + | + |
Gestión del Cambio | + | + |
| Mejora Continua | + | + |
*Los artefactos en Scrum son objetos creados por el equipo durante el proyecto. Incluyen la lista de productos, la lista de tareas del sprint y el incremento del producto – un fragmento funcional que se demuestra al final del sprint.
Las metodologías ágiles contrastan con el modelo en cascada, ampliamente utilizado por los equipos de desarrollo en los 90. Este modelo implica una ejecución secuencial, comenzando cada fase solo después de que la anterior esté completa.
Cómo Trabajar Según Scrum
Roles en Scrum:
- Equipo Scrum: El núcleo de Scrum es el equipo – un grupo cohesionado de profesionales. Los equipos Scrum son autónomos, decidiendo cómo completar las tareas por sí mismos.
- Scrum Master: El líder formal del equipo Scrum, asegurando la correcta aplicación de la metodología y la moral del equipo. Son responsables del “cómo” del trabajo.
- Product Owner: Responsable de la funcionalidad del producto. Gestiona la lista de tareas del proyecto y se comunica con el cliente.
- Cliente: El usuario final del proyecto o cliente, ya sea externo o interno (por ejemplo, el departamento de ventas que solicita un sistema de CRM).
Reuniones Regulares de Scrum en Worksection
- Planificación: La primera reunión inicia el sprint. El equipo, junto con el Scrum master y el product owner, selecciona tareas de la parte superior de la lista para completar.
- Reunión Diaria: Cada día a la misma hora, los miembros del equipo discuten el progreso del trabajo, respondiendo:
— ¿Qué hice ayer para ayudar al equipo a alcanzar su objetivo?
¿Qué haré hoy?
¿Qué obstaculizó mi trabajo? - Revisión del Sprint: Cuando termina el sprint, se muestra una demostración de la funcionalidad completada al cliente.
- Retrospectiva: El equipo discute las tareas completadas, los problemas enfrentados y formas de mejorar.
Algoritmo: ¿Qué Viene Después?
- Elegir un product owner para definir claramente los objetivos.
- Formar un equipo Scrum.
- Asignar un Scrum master.
- Crear una lista de tareas del proyecto que enumere todas las tareas potenciales.
- Estimar las tareas de la lista utilizando valores relativos (por ejemplo, números de Fibonacci).
- Planificar el sprint, seleccionando tareas y asignándolas.
- Configurar un tablero Scrum dividido en ">Por Hacer,", "En Progreso," y "Hecho."
- Realizar reuniones diarias.
- Al final del sprint, llevar a cabo una revisión y retrospectiva.
- Iniciar el siguiente sprint con la planificación.
Qué Leer Para Entender Mejor Scrum
- Guía de Scrum (Ken Schwaber, Jeff Sutherland)
- Scrum: El Arte de Hacer el Doble de Trabajo en la Mitad de Tiempo (Jeff Sutherland)
- Manifiesto Ágil para el Desarrollo de Software
Ventajas y Desventajas de Scrum en TI
Ventajas:
- Transparencia: Intercambio de información abierta y colaboración.
- Autonomía del Equipo: Los equipos deciden cómo trabajar, motivando la libertad y la responsabilidad.
- Minimización de Riesgos: Respuesta rápida a cambios en el proyecto.
Desventajas:
- No es adecuado para proyectos con requisitos vagos del producto final.
- Difícil de aplicar en proyectos a gran escala sin modificaciones.