El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios.
Scrum, una manera de hacer las cosas procurando centrarse en el producto y no en la documentación asociada, no se exige documentar nada para iniciar el proyecto.
Es una metodología flexible, nos permite ir adaptando el producto conforme vamos descubriendo cosas que no habíamos entendido bien o que no estaban bien definidas.
Scrum prioriza disponer de algo tangible casi desde el primer momento de manera que el cliente pueda tener una referencia sobre la que indicarnos si vamos por buen camino, la idea principal es: “Ponerse a trabajar prácticamente desde el primer momento”.
Scrum es un marco de trabajo iterativo e incremental para el desarrollo de proyectos, productos y aplicaciones. Estructura el desarrollo en ciclos de trabajo llamados Sprints. Son iteraciones de 1 a 4 semanas, y se van sucediendo una detrás de otra. Los Sprints son de duración fija. Al comienzo de cada Sprint, un equipo multi-funcional selecciona los elementos (requisitos del cliente) de una lista priorizada. Al final del Sprint, el equipo lo revisa con los interesados en el proyecto. Scrum pone el énfasis en productos que funcionen al final del Sprint; en el caso del software significa que el código esté integrado, completamente probado y potencialmente para entregar.
Participantes y roles
• Product Owner:
Esta persona representa a los interesados en el producto final, es decir al cliente. Conoce y marca las prioridades del proyecto. Es el responsable de identificar las funcionalidades del producto, poniéndolas en una lista priorizada, decidiendo cuales deberían ir al principio de la lista para el siguiente Sprint, repriorizando y refinando continuamente la lista.
• Scrum Master:
Su tarea es eliminar impedimentos, procurar que no haya colisiones, asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo en cualquier problema.
• Scrum Team:
Personal responsable de implementar la funcionalidad o funcionalidades elegidas por el Product Owner. El equipo es “autoorganizado” (auto-gestionado), con un alto grado de autonomía y responsabilidad.
• Usuario o cliente:
Beneficiaros finales del producto.
Elementos esenciales que constituyen la metodología Scrum:
Product Backlog
Es el equivalente a los requisitos del sistema o del usuario, se toma el proyecto original, y se definir las tareas que lo componen. De esta manera obtendremos una lista con las funcionalidades de la aplicación. Un vez tengamos esto le asignaremos prioridades a cada tarea.
Daily Scrum Meeting
Una vez empezado el Sprint, se realizaran unas reuniones cortas (15 minutos o menos) que se celebraran todos los días a una hora prefijada. Todo el Scrum Team y el Scrum Master asisten a la reunión. El Scrum Team informará a los demás sobre el progreso y los obstáculos;
• Que han hecho desde la última reunión.
• Que tienen planificado hacer antes de la siguiente reunión.
• Cualquier bloqueo o impedimento que tengan.
El Scrum Master se responsabiliza de ayudar a los miembros del Scrum Team que tenga bloqueos o dificultades. El Scrum Diario en una reunión de seguimiento, otro ciclo de inspección y adaptación.
Actualizando el Sprint Backlog
Todos los días el Scrum Team actualiza sus estimaciones de la cantidad de trabajo que queda para terminar sus tareas actuales en la Pila de Sprint.
Revisión del Sprint
El Scrum Team revisa el Sprint junto con el Product Owner, es una actividad de inspección y adaptación del producto. Es la oportunidad de que el Product Owner vea lo que está pasando con el producto y con el Scrum Team; y la oportunidad del Scrum Team de saber cómo va el Product Owner y el mercado.
El Scrum Master es responsable de saber la “Definición de Hecho” que fue definida durante la Planificación del Sprint Backlog, y durante esta reunión es responsable de decir al Product Owner si alguno de los elementos implementados por el Scrum Team no cumple esta definición. De esta forma, hay una mayor visibilidad de la calidad del trabajo; los equipos no pueden simular la calidad presentando software que parece que funciona bien, pero que está implementado con código desordenado, sin probar y de mala calidad.
Retrospectiva del Sprint
Implica inspeccionar y adaptar el proceso. Es una oportunidad para que el Scrum Team hable sobre lo que funciona y lo que no, y acuerden que cambios quieren intentar. “Qué fue bien” y “Qué se podría mejorar” aplicar un número pequeño de cambios en el siguiente Sprint, y se compromete a revisar los resultados en la retrospectiva del próximo Sprint.
Ciclo de vida de la metodología ágil Scrum:
