Scrum (desarrollo de software)

ESTRUCTURA Y CONTENIDO

1. OBJETIVOS Y CARACTERÍSTICAS

Se describirá el propósito de las metodologías ágiles, sus diferencias frente a las pesadas
y se identificarán sus características y condiciones principales.

2.¿PARA QUÉ TIPO DE PROYECTOS SON ADECUADAS?

Enlazando con el punto anterior, se analizarán los tipos de proyectos, según sus
características y naturaleza, para los que la aplicación de las metodologías ágiles son
más ventajosas. 

3. EJEMPLOS DE LAS MÁS UTILIZADAS

Se describirán brevemente las metodologías ágiles más utilizadas actualmente:

SCRUM, KANBAM y XP.

4. SCRUM

Se toma SCRUM como modelo para el resto del curso al ser la más utilizada. Aquí se
estudian sus particularidades y especificaciones.

5. PROCESO DE UN SPRINT

Los estudiantes se familiarizan con el concepto de Sprint, unidad sobre la que se basa la
metodología SCRUM. Se analiza un sprint completo desde el inicio hasta el desarrollo
de un producto entregable.

6. ROLES, ARTEFACTOS Y REUNIONES.

Scrum (desarrollo de software)
Ir a la navegación Ir a la búsqueda

Este artículo o sección tiene referencias, pero necesita más para complementar su
verificabilidad.
Este aviso fue puesto el 15 de febrero de 2018.

No debe confundirse con medio scrum.

Ciclos de desarrollo.

Marco de Trabajo SCRUM

Scrum es un marco de trabajo 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:1

 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 auto organizados, 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.

Índice
 1 Historia
 2 Características de Scrum

o 2.1 Principales Características de Scrum

 3 Roles en Scrum

o 3.1 Roles Principales

o 3.2 Roles Auxiliares

 4 Artefactos

o 4.1 Pila del producto (o product backlog)

o 4.2 Pila del sprint (o sprint backlog)
o 4.3 Incremento

 5 Flujo de trabajo

o 5.1 Sprint
o 5.2 Planificación de sprint
o 5.3 Scrum diario
o 5.4 Revisión de sprint
o 5.5 Retrospectiva del sprint

 6 Beneficios de Scrum
 7 Documentos

o 7.1 Product backlog

o 7.2 Sprint backlog
o 7.3 Burn down chart
o 7.4 Definition of Done
 o 7.5 Definition of ready

 8 Véase también
 9 Referencias
 10 Enlaces externos

Historia
Este modelo fue identificado y definido por Ikujiro Nonaka y 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).

En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con

el avance en formación de melé (scrum en inglés) de los jugadores de Rugby, a raíz de
lo cual quedó acuñado el término “scrum” para referirse a ella.

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)(SCRUM
Development Process), 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,2 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.3

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.4 Durante el sprint, nadie puede
cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante
el sprint.5

Scrum permite la creación de equipos auto organizados 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, resultados anticipados, flexibilidad y

adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, o,
equipo motivado.
 Se hace uso de equipos auto-dirigidos y auto-organizados.
 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 proceso ("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.6

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
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.4

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 dos (2) semanas 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.4

 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.7

 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.4

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. Esta
reunión tiene un tiempo fijo de cuatro horas.

Beneficios de Scrum
 Flexibilidad a cambios. Gran capacidad de reacción ante los cambiantes
requerimientos generados por las necesidades del cliente o la evolución del
mercado. El marco de trabajo está diseñado para adecuarse a las nuevas
exigencias que implican proyectos complejos.
 Reducción del Time to Market. El cliente puede empezar a utilizar las
características más importantes del proyecto antes de que esté
completamente terminado.
 Mayor calidad del software. El trabajo metódico y la necesidad de obtener
una versión de trabajo funcional después de cada iteración, ayuda a la
obtención de un software de alta calidad.
 Mayor productividad. Se logra, entre otras razones, debido a la eliminación de
la burocracia y la motivación del equipo proporcionado por el hecho de que
pueden estructurarse de manera autónoma.
 Maximiza el retorno de la inversión (ROI). Creación de software solamente
con las prestaciones que contribuyen a un mayor valor de negocio gracias a la
priorización por retorno de inversión.
 Predicciones de tiempos. A través de este marco de trabajo se conoce la
velocidad media del equipo por sprint, con lo que es posible estimar de
manera fácil cuando se podrá hacer uso de una determinada funcionalidad
que todavía está en el Backlog.
 Reducción de riesgos. El hecho de desarrollar, en primer lugar, las
funcionalidades de mayor valor y de saber la velocidad a la que el equipo
avanza en el proyecto, permite despejar riesgos efectivamente de manera
anticipada.8
Documentos
Product backlog

El product backlog se trata como un documento de alto nivel para todo el proyecto. Es
el conjunto de todos los requisitos de proyecto, el cual contiene descripciones genéricas
de funcionalidades deseables, priorizadas según su retorno sobre la inversión (ROI) .
Representa el qué va a ser construido en su totalidad. Es abierto y solo puede ser
modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos,
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 (KEV) 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 menor tiempo de desarrollo tendrá
probablemente más prioridad, debido a que su ROI será más alto.

Sprint backlog

El sprint backlog es el subconjunto de requisitos que serán desarrollados durante el

siguiente sprint. Al definir el sprint backlog, se describe el cómo el equipo va a
implementar los requisitos durante el sprint. Por lo general los requisitos se subdividen
en tareas, a las cuales se asignan ciertas horas de trabajo pero ninguna tarea con una
duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en
otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los
miembros del equipo del modo que les parezca adecuado.

Burn down chart

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.

Definition of Done

El Definition of Done es un documento con una serie de criterios comunes para

determinar cuando una tarea está completamente hecha.

Definition of ready

Este debe ser una lista de requerimientos necesarios para iniciar el desarrollo de una
Historia de Usuario o un Incremento, por lo general estos requerimientos dependen de
actores externos al Scrum Team.
Véase también
 Agilmática
 Arquitectura orientada a servicios
 Back office
 Ciclo de vida del producto
 Desarrollo ágil de software
 Desarrollo de software
 Kanban
 Lean software development

Referencias
1.

 «Qué es SCRUM». Proyectos Ágiles. 4 de agosto de 2008. Consultado el 8 de abril de 2019.

  «¿Qué es Scrum?». Consultado el 11 de marzo de 2021.

  «Scrum tools» (en inglés). Consultado el 11 de marzo de 2021.

  Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004,
163pp, ISBN 0-7356-1993-X

  Métodos Ágiles. Scrum, Kanban, Lean, Carmen Lasa, Rafael de las Heras, Alonso Álvarez,
Anaya, 2017, 400pp, ISBN 978-8441538887

  Leader Summaries (ed.). «Resumen del libro Scrum, de Jeff Sutherland». Consultado el 25
de enero de 2016.

  Error en la cita: Etiqueta <ref> no válida; no se ha definido el contenido de las

referencias llamadas schwaber2

8.  «Beneficios de Scrum». Proyectos Ágiles. 4 de agosto de 2008. Consultado el 17 de

abril de 2017.

Enlaces externos
 The New New Product Developement Game, por Hirotaka Takeuchi (Hitotsubashi
University) y Ikujiro Nonaka. Harvard Business Review, January 1986.
 (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small
Teams Retrieved March 15, 2007
 (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process
Retrieved July 01, 2010
 (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation
at Google Retrieved 2007-12-15
 (video) Ken Schwaber in Scrum et al. Retrieved 2008-01-19
 The Scrum Guide