INTRODUCCIÓN

Scrum es una metodología para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software; Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrum.
Scrum es una metodología ágil, y como tal:

• Es un modo de desarrollo de carácteradaptable más que predictivo.

• Orientado a las personas más que a losprocesos.


• Emplea la estructura de desarrollo ágil:
Incremental basada en iteraciones yrevisiones.

ANTECEDENTES

2.1. Historia
En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales. Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual las fases se traslapan de manera intensa y el proceso completo es realizado por un equipo con funciones transversales, como en el rugby, donde el equipo entero «actúa como un solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro».Los casos de estudio provienen de las industrias automovilísticas, así como de fabricación de máquinas fotográficas, computadoras e impresoras.
En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous Solutions (A problemas malvados, soluciones virtuosas), se refirieron a esta aproximación como scrum (melé en inglés), un término propio del rugby mencionado en el artículo por Takeuchi y Nonaka.

A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a poner en práctica el scrum en su compañía, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla scrum. En 1995 Schwaber y Sutherland, durante el OOPSLA '95 desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo scrum, siendo ésta la primera aparición pública de la metodología. Durante los años siguientes, Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a lo que ahora se le conoce como scrum.[cita requerida] En 2001, Schwaber y Mike Beedle describieron la metodología en el libro Agile Software Development with Scrum..

Desde 1995 miles de proyectos en todo el mundo han utilizado Scrum para el desarrollo de productos, tanto en empresas pequeñas, “startups” con tan sólo 5 personas desarrollando un producto, como en multinacionales, entre las que se encuentran las siguientes:



En la actualidad, Scrum se está utilizando en diferentes tipos de negocio y, especialmente, en el desarrollo de software. La Scrum Alliance es la organización sin ánimo de lucro que se encarga de difundir Scrum en este ámbito.

2.2. Fundamentos
Scum se basa en:
• El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita).

• La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración.

• El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.

• La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la autoridad necesaria para organizar su trabajo.

• La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el cliente.

• El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados.

2.3. Características de Scrum
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o internos), y el Teamque incluye a los desarrolladores.
Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el equipo), 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. 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 hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.
Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

2.4. Roles en Scrum
En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. El nombre de los grupos estáinspirado en el chiste sobre un cerdo y una gallina que se relata a continuación.
Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La gallina piensa un poco y contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tú solamente estarías involucrada".
De esta forma, los cerdos están comprometidos a construir software de manera regular y frecuente, mientras que el resto son gallinas: interesados en el proyecto pero realmente irrelevantes porque, si éste falla, no son un cerdo, es decir, no son los que de manera comprometida ponen su propio pellejo (y carne) para sacar el proyecto adelante. Las necesidades, deseos, ideas e influencias de los roles gallina se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum.

2.4.1. Roles "Cerdo"
Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato".

2.4.1.1. Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

2.4.1.2. ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

2.4.1.3. Equipo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc.).

2.4.2. Roles "Gallina"
Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse 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 (stakeholders). 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.
Análisis de la frase "Rol gallina":
La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero.

2.4.2.1. Usuarios
Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software no es usado ¿fue alguna vez escrito?

2.4.2.2. Stakeholders (Clientes, Proveedores, Inversores)
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint.

2.4.2.3. Managers
Es la gente que establece el ambiente para el desarrollo del producto.

DESARROLLO

Scrum controla de forma empírica y adaptable la evolución del proyecto, empleando las siguientes prácticas de la gestión ágil:

3.1. Revisión de las Iteraciones
Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una revisión con todas las personas implicadas en el proyecto. Este es el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto.

3.2. Desarrollo incremental
Durante el proyecto, las personas implicadas no trabajan con diseños o abstracciones.
El desarrollo incremental implica que al final de cada iteración se dispone de una parte del producto operativa que se puede inspeccionar y evaluar.

3.3. Desarrollo evolutivo
Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos.
Intentar predecir en las fases iniciales cómo será el producto final, y sobre dicha predicción desarrollar el diseño y la arquitectura del producto no es realista, porque las circunstancias obligarán a remodelarlo muchas veces.
Para qué predecir los estados finales de la arquitectura o del diseño si van a estar cambiando. En Scrum se toma a la inestabilidad como una premisa, y se adoptan técnicas de trabajo para permitir esa evolución sin degradar la calidad de la arquitectura que se irá generando durante el desarrollo.
El desarrollo Scrum va generando el diseño y la arquitectura final de forma evolutiva durante todo el proyecto. No los considera como productos que deban realizarse en la primera “fase” del proyecto. (El desarrollo ágil no es un desarrollo en fases)

3.3.1. Auto-organización
Durante el desarrollo de un proyecto son muchos los factores impredecibles que surgen en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos.
En Scrum los equipos son auto-organizados (no auto-dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas.

3.3.2. Colaboración
Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. Ésta es necesaria, porque para que funcione la auto organización como un control eficaz cada miembro del equipo debe colaborar de forma abierta con los demás, según sus capacidades y no según su rol o su puesto.

3.3.3. Desarrollo Ágil
Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad dedesarrollo y que pueden llevarse a cabo en unperiodo de tiempo breve (normalmente de 30días).
Cada uno de estos periodos de desarrollo es unaiteración que finaliza con laproducción de unincremento operativo del producto.
Estas iteraciones son la base del desarrollo ágil, yScrum gestiona su evolución a través dereuniones breves diarias en las que todo elequipo revisa el trabajo realizado el día anterior yel previsto para el día siguiente.



3.3.4. Reuniones en Scrum
3.3.4.1. Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:
• La reunión comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc.).
• Todos son bienvenidos, pero solo los "cerdos" pueden hablar.
• La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
• Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
• La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
• Durante la reunión, cada miembro del equipo contesta a tres preguntas:
• ¿Qué has hecho desde ayer?
• ¿Qué es lo que estás planeando hacer hoy?
• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

3.3.4.2. Scrum de Scrum
Cada día normalmente después del “Daily Scrum”
• Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
• Asiste una persona asignada por cada equipo.
• La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:
• ¿Qué ha hecho tu equipo desde nuestra última reunión?
• ¿Qué hará tu equipo antes que nos volvamos a reunir?
• ¿Hay algo que demora o estorba a tu equipo?
• ¿Estás a punto de poner algo en el camino del otro equipo?


3.3.4.3. Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
• Seleccionar que trabajo se hará
• Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
• Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint
• Ocho horas como límite
• Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”


3.3.4.4. Reunión de Revisión del Sprint (Sprint Review Meeting)
• Revisar el trabajo que fue completado y no completado
• Presentar el trabajo completado a los interesados (alias “demo”)
• El trabajo incompleto no puede ser demostrado
• Cuatro horas como límite

3.3.4.5. Retrospectiva del Sprint (Sprint Retrospective)
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 del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.


3.3.5. Documentos
3.3.5.1. Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su valor para el negocio (business value). Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

3.3.5.2. Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.

3.3.5.3. Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

3.3.6. Scrum aplicado al desarrollo de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.



La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:
• Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
• Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.
• Reuniones.
• Planificación del sprint, Revisión diaria, Revisión del sprint.
• Sprint

ANALISIS

Scrum es una “carrocería” para dar forma a losprincipios ágiles. Es una ayuda para organizar alas personas y el flujo de trabajo; como lo puedenser otras propuestas de formas de trabajo ágil:Cristal, DSDM, etc.

• La carrocería sin motor, sin los valores que dansentido al desarrollo ágil, no funciona.
• Delegación de atribuciones (empowerment) al equipo para que pueda auto organizarse ytomar las decisiones sobre el desarrollo.
• Respeto entre las personas. Los miembrosdel equipo deben confiar entre ellos yrespetar sus conocimientos y capacidades.
• Responsabilidad y auto-disciplina (nodisciplina impuesta).
• Trabajo centrado en el desarrollo de locomprometido.
• Información, transparencia y visibilidad deldesarrollo del proyecto.

4.1. Ventajas
• Se obtiene software lo más rápido posible y este cumple con los requerimientos más importantes.
• Se trabaja en iteraciones cortas, de alto enfoque y total transparencia.
• Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son importantes.
• Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado.
• Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias.
• Permite producir software de una forma consistente, sostenida y competitiva.
• Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento

4.2. Desventajas
• Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario.
• Es una metodología que difiere del resto, y esto causa cierta resistencia en su aplicación para algunas personas.

CONCLUSIONES

Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas. Es más, Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes.
Se puede decir que para el 90% de los proyectos y empresas, es una metodología válida, pero no es una metodología válida al 100%. Es más, no hay metodología mejor que otra ni válida al 100% para todas las personas y empresas.



Scrum es por lo tanto, una metodología más de las muchas que hay.
Scrum no es ni la mejor metodología ni la única, pero es una metodología que está empujando muy fuerte por la facilidad de implantación y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparación con otras metodologías.
Por un lado, Scrum evita la burocracia y la generación documental. No es que con Scrum no se deba o no se pueda documentar, si no que con Scrum no se exige documentar nada para iniciar un proyecto, algo que en otras metodologías es impensable.
Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prácticamente desde el primer momento y empezar a sacar frutos de ese trabajo para que el cliente vaya viendo los avances y se quede satisfecho con lo que se está haciendo y cómo se está haciendo.
La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se pueda reconducir el proyecto en un momento dado, y que afecte lo menos posible a los costes, los tiempos y al equipo de trabajo.