thumb|Ciclos de desarrollo.

thumb|Marco de Trabajo SCRUM Scrum es un modelo de desarrollo de software para desarrollo ágil de software que se ha expandido a otras industrias.

Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo y obtener el mejor resultado posible de proyectos, caracterizado por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto. Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados. Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada. Las metodologías ágiles, en que se basa scrum, son aquellas que permiten adaptar la forma de trabajo a las condiciones del proyecto, consiguiendo flexibilidad, eficacia e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las circunstancias específicas del entorno.

Historia Este modelo fue identificado y definido por Ikujiro Nonaka y Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986).."The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka (1986)

En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formación de scrum de los jugadores de Rugby, a raíz de lo cual quedó acuñado el término.

Aunque esta forma de trabajo surgió en empresas de productos tecnológicos, es apropiada para cualquier tipo de proyecto con requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.

En 1995, Ken Schwaber presentó “Scrum Development Process” en OOPSLA 95 (Object-Oriented Programming Systems & Applications conference), un marco de reglas para desarrollo de software, basado en los principios de Scrum, y que él había empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation (compañía que en los macrojuegos de compras y fusiones, se integraría en VMARK, y luego en Informix y finalmente en Ascential Software Corporation).

Características de Scrum Scrum es un marco de trabajo que define un conjunto de eventos, prácticas y roles, y que puede tomarse como conjunto base para definir el proceso de producción que usará un equipo de trabajo o dentro de un proyecto.

Los roles principales en Scrum son el Scrum Master, que procura facilitar la aplicación de Scrum y gestionar cambios, el Product Owner, que representa a los stakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás elementos relacionados con él.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo más corta posible), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los da a conocer al equipo. Entonces, el equipo conversa con el Product Owner buscando la claridad y magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.Métodos Ágiles. Scrum, Kanban, Lean, Carmen Lasa, Rafael de las Heras, Alonso Álvarez, Anaya, 2017, 400pp, ISBN 978-8441538887

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de los miembros del equipo, y la comunicación verbal entre los miembros y disciplinas involucrados en el proyecto.

La metodología se basa en:

El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos. Se da prioridad a lo que tiene más valor para el cliente. El equipo se sincroniza diariamente y se realizan las adaptaciones necesarias. Tras cada iteración (un mes o menos entre cada una) se muestra al cliente el resultado real obtenido, para que este tome las decisiones necesarias en relación con lo observado. Se le da la autoridad necesaria al equipo para poder cumplir los requisitos.

Fijar tiempos máximos para lograr objetivos.

Equipos pequeños (de 3 a 9 personas cada uno).

Principales características de Scrum Gestión regular de las expectativas del cliente, accesos anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, o, equipo motivado. Se hace uso de equipos autodirigidos y autoorganizados. Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no dura más de 15 minutos con el objetivo de obtener realimentación sobre las tareas del equipo y los obstáculos que se presentan.

Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software; requiere muy poco esfuerzo para comenzarse a utilizar. Así, si se utiliza una pizarra con notas autoadhesivas cualquier miembro del equipo podrá ver tres columnas: trabajo pendiente ("backlog"), tareas en curso ("in progress") y hecho ("done"). De un solo vistazo, una persona puede ver en qué están trabajando los demás en un momento determinado.

Roles en Scrum

Roles principales Product Owner (o Propietario del producto) El Product Owner se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner ayuda al usuario a escribir las historias de usuario, las prioriza, y las coloca en el Product Backlog.

Scrum Master (o Facilitador) Es el responsable del cumplimiento de las reglas del marco scrum. Se asegura que estas son entendidas por la organización y de que se realiza el trabajo conforme a ellas. Elimina los obstáculos que impiden que se desarrolle el objetivo del sprint. Asesora y da la formación necesaria al propietario del producto y al equipo de desarrolladores.

Desarrollador/a Cada uno de los profesionales que realizan la entrega del incremento de producto generado en cada sprint (denominado incremento). Es recomendable un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

Roles auxiliares Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados ("pandemoldes"). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc) Son las personas que hacen posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su desarrollo. Solo participan directamente durante las revisiones del "sprint".

Artefactos miniaturadeimagen|Ejemplo de diagrama de evolución de un lanzamiento, que muestra el alcance completado al final de cada Sprint.

Pila del producto (o product backlog) Registra y prioriza los requisitos desde el punto del vista del cliente. Empieza con una visión inicial del producto y crece y evoluciona durante el desarrollo del producto. Los requisitos suelen denominarse "historias de usuario"

Pila del sprint (o sprint backlog) Registro de los requisitos desde el punto de vista de los desarrolladores. Es la lista de tareas que se deben realizar durante un sprint para lograr el incremento previsto.

Incremento Resultado de cada sprint.

Flujo de trabajo Sprint El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado.

Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto que, potencialmente, se puede entregar al cliente.

Así mismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos que su falta amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.

El tiempo mínimo de un Sprint es de una (1) semana y el máximo es de cuatro (4) semanas.

Planificación de sprint

Al comienzo de un sprint, el equipo de scrum tiene un evento de planificación de sprint.

Uno de los objetivos de la reunión es identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.

Scrum diario También llamado Daily Standup. Cada día durante la iteración, tiene lugar una reunión de estado del proyecto. Su objetivo es que los miembros del equipo se mantengan actualizados unos a otros sobre el trabajo de cada uno desde el último standup, qué problemas han encontrado o prevén encontrar, y qué planean hacer.

La reunión tiene una duración fija de máximo 15 minutos. Los asistentes obligados son los Developer, la asistencia del Scrum Master y del Product Owner es opcional Se recomienda hacerla de pie para recordar que debe ser una reunión breve y centrada en su objetivo, sin divagaciones. Es obligatorio parar todo lo que se está haciendo para concentrarse en la reunión. Si se requiere ampliar un tema, se hará tras el Daily Standup, pero no se interrumpe la dinámica del Standup para elaborar una discusión. Se hace siempre a la misma hora y en el mismo lugar, ya que la consistencia reduce la complejidad. Si falta alguien, no se pospone la reunión.

Revisión de sprint

Al final de un sprint, el equipo realiza dos eventos: la revisión del sprint y la retrospectiva del sprint.

En la reunión de revisión de sprint se presentan los trabajos completados y su duración no debería ser superior a 4 horas para un Sprint de 1 mes.

Retrospectiva del sprint

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua de la implementación de Scrum. La duración de la retrospectiva es, como máximo, de tres horas para Sprints de un mes.

Consideración de Riesgos