Scrum 1

Scrum
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.
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
Scrums. Ciclos de desarrollo.

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.[1] 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».[cita requerida] 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),[2] 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.[cita requerida] Por aquel tiempo Jeff Sutherland desarrolló una
aproximación similar en Easel Corporation y fue el primero en denominarla scrum.[3] 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.[cita requerida] 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..

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 Team que 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.[4] Durante el sprint, nadie puede cambiar el Sprint
Scrum 2

Backlog, lo que significa que los requisitos están congelados durante el sprint.
Scrum permite la creación de equipos autoorganizados 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.

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án inspirados en el chiste sobre un cerdo y una gallina que se relata a continuación.[5]
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, "Tú sólo
estarías involucrada mientras que yo estaría comprometido".
De esta forma, los 'cerdos' están comprometidos a través de sus aportes 'directos' en la construcción de software,
mientras que las 'gallinas' están involucradas a través de sus aportes 'indirectos'.
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.

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".
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.
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.
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).
Scrum 3

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.

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? Aqui la definicion sería Si el software no es usado ¿fue alguna vez escrito?.
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.
Managers
Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum

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:[6]
• ¿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).

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?
Scrum 4

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”

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

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.

Documentos

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 retorno sobre la inversión (ROI) . 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.

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.

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
Scrum 5

algunos tramos.

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 [7]. 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

Notas
[1] Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)
[2] Peter DeGrace, Leslie Hulet Stahl, Wicked problems, righteous solutions, 1990, ISBN 0-13-590126-X
[3] Jeff Sutherland, Agile Development: Lessons Learned From the First Scrum, 2004 (http:/ / jeffsutherland. com/ scrum/ FirstScrum2004. pdf)
[4] Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X
[5] page 7
[6] page 135
[7] http:/ / www. acm. org/ sigs/ sigplan/ oopsla/ oopsla96/ oopsla96. html

Referencias
• (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams (http://
members.cox.net/risingl1/Articles/IEEEScrum.pdf) Retrieved March 15, 2007
• (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process (http://jeffsutherland.
com/scrumpapers.pdf) Retrieved July 01, 2010
• (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google (http://video.
google.com/videoplay?docid=8795214308797356840) Retrieved 2007-12-15
• (video) Ken Schwaber in Scrum et al. (http://video.google.com/videoplay?docid=2531954797594836634)
Retrieved 2008-01-19
Scrum 6

Véase también
• Ciclo de vida del producto
• Desarrollo ágil de software
• Desarrollo de software
• Agilmática

Enlaces externos

Comunidades o grupos de usuarios

• Asociación Agile-Spain (http://www.agile-spain.com) : la comunidad agilista en España
• Ágiles (http://agiles.org) : la comunidad agilista latinoamericana
• ScrumManager (http://www.scrummanager.net/ok) : Plataforma profesional de conocimiento libre

Libros originales o traducciones al español

• Libro gratuito sobre Scrum (http://www.navegapolis.net/content/view/694/61/)
• Traducción de "The Scrum Primer" (http://scrumtraininginstitute.com/library)
• "Scrum y XP desde las trincheras", traducción de "Scrum and XP from the trenches" por Henrik Kniberg (http://
www.proyectalis.com/2008/02/26/scrum-y-xp-desde-las-trincheras/)

Portales temáticos y blogs

• proyectosAgiles.org: base de conocimiento gratuita de Scrum en español (http://www.proyectosagiles.org)
• Metodología de gestión de proyectos basada en Scrum (http://navegapolis.metocube.com/)
• Artículos sobre Scrum de Rodrigo Corral (http://geeks.ms/blogs/rcorral/archive/tags/Scrum/default.aspx)
• Blog de Scrum en Español (http://scrumenespanol.blogspot.com)

Artículos y otros recursos

• Hoja Excel para gráficos de progreso scrum (http://www.navegapolis.net/index.php?option=com_content&
task=view&id=268&Itemid=84)
• Artículo de introducción a Scrum (http://www.chuidiang.com/ood/metodologia/scrum.php)
• Explicando Scrum a mi abuela por Jorge Serrano (http://geeks.ms/blogs/jorge/archive/2007/05/09/
explicando-scrum-a-mi-abuela.aspx)
• Artículo sobre Scrum en Español (http://swsaber.com/scrum/)
• PPT reutilizable de introducción a Scrum, original de Mike Cohn, traducción de Ernesto Grafeuille (http://www.
mountaingoatsoftware.com/system/asset/file/66/SpanishRedistributableIntroToScrum.ppt)
• Sencillo generador online de gráficas burndown (http://www.burndowngenerator.com/)
• Bloque de Conocimiento de Scrum, en español, basado en una wiki abierta (http://www.epidataconsulting.com/
tikiwiki/tiki-index.php?page=Scrum)
Fuentes y contribuyentes del artículo 7

Fuentes y contribuyentes del artículo

Scrum  Fuente: http://es.wikipedia.org/w/index.php?oldid=40924054  Contribuyentes: Alexav8, C lamarque, Caskete, Diegusjaimes, Dodo, EGA Futura, Ecelan, Fpablos, Fran.naranjo, Fritz11,
Hhiroshi, J.M.Domingo, Jacorream, Jdemarcos, Jgalgarra, Jmbeas, Jmdmmx, Juan.palacio, Julie, Kamusclown, Kijote, Leoparra86, Mac1800, Maldoror, Martingala, Mescalier, Mushii, Oscar .,
Parlamento, Penelopina, Qwertyytrewqqwerty, RNL89, Raggha, Ray iceman, Santiagobas, Savh, Sindestino, Susibel, Xavier Albaladejo, Ynnek, 97 ediciones anónimas

Fuentes de imagen, Licencias y contribuyentes

Archivo:Ciclos de desarrollo.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Ciclos_de_desarrollo.png  Licencia: Creative Commons Attribution 2.5  Contribuyentes:
Juan.palacio, WikipediaMaster
Archivo:Ficha scrum.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Ficha_scrum.png  Licencia: Creative Commons Attribution-Sharealike 2.5  Contribuyentes: Juan.palacio,
KTo288

Licencia
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/