Scrum es un proceso ágil para administrar proyectos de desarrollo de software.
El desarrollo se realiza en forma iterativa e incremental. Cada ciclo, denominado “sprint” termina con una pieza de software ejecutable que incorpora nuevas funcionalidades. Los sprints en general tienen una duración de 2 a 4 semanas.
En Scrum se da prioridad al trabajo en función del valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de inversión.
Está diseñado especialmente para adaptarse a los cambios en los requerimientos. Los requerimientos y las
prioridades se revisan y se ajustan en intervalos muy cortos y regulares. De esta forma se puede adaptar en forma temprana el producto que se está construyendo a las necesidades del cliente. Se busca entregar software que realmente resuelva las necesidades, aumentando la satisfacción del cliente.
En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por el otro lado, la gestión de un proyecto Scrum se focaliza en definir cuales son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en remover cualquier obstáculo que pudiera entorpecer la
tarea del equipo de desarrollo. Se busca que los equipos sean lo más efectivos y productivos que sea posible.
Scrum tiene un conjunto de reglas muy pequeño y muy simple y está basado en los principios de inspección continua, adaptación, auto-gestión e innovación.
El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto con cada sprint y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa.
Por otro lado, los desarrolladores encuentran un ámbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivación de los integrantes del equipo.
Hay estudios estadísticos de la industria del software que muestran que casi la mitad de la funcionalidad que se implementa no es utilizada. En Scrum se construye primero la funcionalidad que resulte en el mayor beneficio para el negocio y se evita en todo momento desarrollar cosas que no serán de utilidad para el cliente. De esta manera, se puede desarrollar un sistema en menos tiempo, evitando el trabajo innecesario.

El entorno de trabajo (SCRUM Framework)


 
Roles (SCRUM Roles)
Product Owner: conoce y define las características del producto a producir. Decide fechas, prioridades y contenido de releases. Es responsable por el ROI del producto.
Scrum Master: es responsable por el desempeño del equipo. Elimina “barreras” y asegura la cooperacion. Protege al equipo de “interferencias” externas. Se asegura que se siga el proceso. Invita y coordina las reuniones (SCRUM, Review,Planning ).
The Team: es el equipo de trabajo, preferentemente de 5 a 7 miembros. Son responsables de las estimaciones, de realizar el diseño e implementación de la solución. Seleccionan los objetivos del sprint. Organizan su tiempo y su trabajo. Realizan la demo al Product Owner.

Reuniones de trabajo (SCRUM Meetings)
Estimation Meeting: el Team se junta con el Product Owner a discutir los ítems de del Backlog para definir el tamaño relativo de cada uno. Esto ocurre antes de cada sprint.
Planning Meeting: ocurre al inicio de cada sprint. El Team y el Product Owner negocian qué ítems del product Backlog formarán parte del sprint.
Daily Scrum: reunión diaria de aproximadamente 15 minutos. Se actualiza el taskboard con las tareas realizadas y se cuentan qué hizo cada uno y qué impedimentos o novedades tienen.
Review Meeting: se inspecciona y adapta el producto. El Team se reúne con el Product Owner al final de cada sprint para hacerle una demostración del software ejecutable con las funcionalidades incorporadas.
Retrospective: se inspecciona y adapta el proceso. El Team se reúne con el Scrum Master para examinar qué anduvo bien y qué puede ser mejorado.

Elementos de trabajo (SCRUM Artifacts)
Product Backlog: es una lista priorizada de todos los requerimientos conocidos acerca del producto a desarrollar. Representa los alcances del proyecto. Está sujeto a cambios.
Committed Backlog: es la parte del Product Backlog comprometido para realizar en el presente sprint. No está sujeto a cambios. Los ítems complejos pueden ser subdivididos en Tareas.
Impediment List: lista priorizada de trabas o impedimentos para el proceso de desarrollo. Puede estar dividida o agrupada por áreas de la empresa o competencias técnicas del equipo de trabajo o interesados.
Product Increment: es el trabajo realizado al final de cada sprint. Es aceptado (o rechazado) por el Product Owner e interesados.

Historia de Scrum
El término “Scrum” viene de un estudio de 1986 de los japoneses Hirotaka Takeuchi e Ikujiro Nonaka. En el artículo The New Product Development Game [Harvard Business Review Ene-Feb 1986] ponen de manifiesto que:

  • El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.
  • Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.
  • El mercado exige ciclos de desarrollo más cortos.

El artículo compara al desarrollo tradicional de ciclo de vida formado por fases separadas y equipos especializados con las carreras de relevos, donde un equipo pasa el testigo al siguiente hasta finalizar el desarrollo del producto. Siguiendo el símil deportivo, se compara al nuevo modelo de desarrollo, basado en el solapamiento de las fases y en un único equipo multi-disciplinar, con la evolución del juego del rugby; y de él se toma el término scrum.
Nonaka y Takeuchi extraen las bases de scrum de las prácticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard; y son:

  • Inestabilidad consustancial al entorno de desarrollo.
  • Equipos auto-organizados.
  • Solapamiento de las fases del desarrollo.
  • Multi-aprendizaje.
  • Control sutil.
  • Transferencia de aprendizaje a nivel organizacional.

Posteriormente, Ken Schwaber formalizó el proceso y lo abrió a toda la industria del software en 1995.