Tarea de: Ingeniera de Software l GR2

Tema: Scrum

Introduccin

El desarrollo de software no es una tarea fcil de realizar y por ello

existen diversas metodologas centradas en diferentes aspectos tales
como los procesos en las tradicionales o las personas en las agiles.

Las metodologas tradicionales abordan el desarrollo de software de

manera efectiva y sumamente necesario en proyectos de gran
alcance y tamao con respecto al tiempo y recursos, donde
comnmente se demanda un alto grado de formalidad en el proceso.
Las metodologas agiles aparecen como resultado de develar
falencias en las tradicionales, un cambio de paradigmas y prioridades
dando menos valor a la estandarizacin para ser cambiada por el
valor hacia las personas, el cliente y los cambios en donde se
pretende reducir rpidamente los tiempos de desarrollo sin perder
una alta calidad. Esta metodologa mediante el manifiesto gil
pretende dar una alternativa a los procesos de desarrollo de software
tradicionales distinguidos por ser rgidos y regidos por la
documentacin estricta que debe ser generada en cada una de las
etapas alcanzadas.

En el manifiesto gil lo que se valora y destaca es:

Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas.
Desarrollar software que funciona ms que conseguir una buena
documentacin.
La colaboracin con el cliente ms que la negociacin de un
contrato.
Responder a los cambios ms que seguir estrictamente un plan.
Se debe destacar que lo mencionado a la izquierda de la oracin tiene
ms valor y prioridad que lo mencionado a la derecha (lo cual
permitira tambin realizar dichas actividades).
A partir de ello surgen 12 principios fundamentales [1]:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la

entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en
etapas tardas del desarrollo. Los procesos giles aprovechan el
cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
ms corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos
juntos de forma cotidiana durante todo el proyecto.
 5. Los proyectos se desarrollan en torno a individuos motivados.
Hay que darles el entorno y el apoyo que necesitan, y confiarles
la ejecucin del trabajo.
6. El mtodo ms eficiente y efectivo de comunicar informacin al
equipo de desarrollo y entre sus miembros es la conversacin
cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos giles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
9. La atencin continua a la excelencia tcnica y al buen diseo
mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseos emergen
de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cmo ser
ms efectivo para a continuacin ajustar y perfeccionar su
comportamiento en consecuencia.

Para un mejor entendimiento de las diferencias entre ambas

metodologas tenemos:

Scrum [2]
SCRUM es un marco metodolgico que puede ser aplicado a porfolios,
programas o proyectos de cualquier tamao y complejidad aplicando
principios y tcnicas giles que benefician el desarrollo de los
proyectos y mejoran significativamente su ROI (retorno de la
inversin)
 Scrum [3] adems es un proceso para el desarrollo de software que
aplica un conjunto de buenas prcticas para trabajar
colaborativamente por medio de iteraciones logrando obtener el
mejor resultado y valor al proyecto. Consiste en un proceso iterativo
no mayor a 30 das donde se realizan entregas funcionales a los
clientes, las cuales pueden ser validadas con ellos. Es una
metodologa de desarrollo simple que requiere trabajo porque no se
basa en el seguimiento de un plan sino en la adaptacin continua a
las circunstancias que se presentan durante la evolucin del proyecto.

Scrum se basa en tres principios [2]:

Transparencia: garantiza que los aspectos del proceso que afectan
el resultado, son visibles para aquellos que administran ese resultado.
Inspeccin: todos los aspectos del proceso deben ser
inspeccionados frecuentemente para detectar variaciones
inaceptables en el mismo o en el producto resultante.
Adaptacin: si se determina a travs de la inspeccin que uno o
ms aspectos del proceso estn fuera de los lmites aceptables y que
el producto resultante ser inaceptable, se debe ajustar el proceso
para minimizar una desviacin mayor.

Conceptos y componentes [3]

1. Product Backlog (Lista de requisitos priorizada, pila del producto):

Es una lista priorizada que incluye las necesidades del proyecto o
requerimientos para el sistema que sern desarrollados, los cuales
se toman de la visin general del producto, especificando aquellas
funcionalidades que tienen mayor prioridad de negocio y pueden
llevarse a cabo en un periodo de tiempo determinado.
El Product Backlog evoluciona como el producto y el entorno en el
cual ser usado, es dinmico, realiza una gestin constante de
cambios para identificar que productos necesitan ser apropiados,
competitivos y tiles. Contiene los objetivos o requisitos de alto nivel
del producto o proyecto que se expresan en forma de historias de
usuario (USER stories). Para cada requisito se indica el valor que
aporta al cliente y se establece un presupuesto para completarlo.

Para obtener un buen Product Backlog se deben realizar las

siguientes actividades:

Visin del Sistema: Identificacin de aspectos claves de un

proyecto. El proyecto nace como una idea y la visin es el
camino para capturarla eficientemente. Es expresada en alto
nivel y debe reflejar las expectativas del cliente.
Lista de Requisitos: son las funcionalidades que representan
la visin y expectativas del cliente con respecto al producto que
se va a desarrollar.
Priorizacin de Requisitos: se realiza de acuerdo al valor que
aporten los requisitos al negocio. Una forma de utilizar este
 proceso consiste en dividir los tems (historias) en tres grupos:
Imperativas, Importantes y Prescindibles. La prioridad puede
cambiar, pero el tamao definido para las historias de usuarios
debe mantenerse fija de acuerdo a la estimacin inicial.
Determinar Presupuesto: Especificacin general de los
costos del proyecto.

2. Sprint Backlog (Lista de tareas de la iteracin, Pila de Sprint): Es

una lista de tareas que elabora el equipo de trabajo para realizar en
un Sprint como plan para completar los requisitos seleccionados
para la iteracin y que se compromete a demostrar al cliente al
finalizarla en forma de un incremento de producto.

Para ello se realiza lo siguiente:

Detalle de tareas. Consiste en desglosar la lista de requisitos

priorizados en tareas para que cada una tome
aproximadamente de 4 a 16 horas para ser terminadas.
Determinar Responsables. Cada tarea tiene asignado un
responsable de realizar el trabajo y tiempo estimado para su
finalizacin.
Identificar Riesgos. Son una caracterstica esencial de los
productos. Cada decisin con respecto al proyecto (Explcita o
implcitamente) tiene un riesgo asociado. Al detallar la lista de
requisitos se pueden ver aquellas donde el equipo est teniendo
problemas, permitiendo la identificacin de posibles riesgos y
poder tomar decisiones al respecto.
Grficos de Trabajo Pendiente Burn Chart. Permiten
visualizar la velocidad con que se estn completando los
requisitos durante el desarrollo del proyecto y si el equipo podr
cumplir con los compromisos en el tiempo estimado.
Se pueden utilizar los siguientes grficos de trabajo pendiente:
o Das pendientes para completar los requisitos del
proyecto (Product Burndown Chart), el cual es realizado
a partir del Product Backlog. - Horas pendientes para
completar las tareas de la iteracin (Sprint Burndown
Chart), el cual es realizado a partir de la lista de tareas de
la iteracin.
 Tablero de tareas (Task Board). Es un tablero que consta de
tres columnas hacer, haciendo y hecho, con la finalidad
de ver en qu estado se encuentran las tareas asociadas a un
Sprint. Esta herramienta es til para los equipos Scrum ya que
se mantienen informados acerca de sus labores diarias. Es
importante que cada persona reporte sus tareas.

3. Sprint Es una iteracin o ciclo que est acotada en el tiempo, con

una duracin de 30 das calendario, donde el equipo trabaja para
convertir la lista de requerimientos en Incrementos del producto
potencialmente productivos. Es el ncleo central que proporciona la
base de desarrollo iterativo e incremental.
El incremento es la funcionalidad del proyecto que es desarrollada
por el equipo durante cada Sprint, el cual puede contener diseo,
codificacin, creacin de activos, depuracin y optimizacin,
necesarios para producir un entregable.

Los Sprints contienen y consisten de la Reunin de Planificacin del

Sprint (Sprint Planning Meeting), los Scrums Diarios (Daily Scrums), el
trabajo de desarrollo, la Revisin del Sprint (Sprint Review), y la
Retrospectiva del Sprint (Sprint Retrospective).
 Durante el Sprint:
No se realizan cambios que puedan afectar al Objetivo del
Sprint (Sprint Goal);
Los objetivos de calidad no disminuyen; y,
El alcance puede ser clarificado y renegociado entre el Dueo
de Producto y el Equipo de Desarrollo a medida que se va
aprendiendo ms.
4. Incremento del Producto: Scrum requiere que los equipos
construyan un incremento de la funcionalidad del producto en cada
Sprint, el cual debe ser potencialmente entregable ya que el
propietario del producto puede decidir liberar la funcionalidad
inmediatamente.

Actividades [3]

1. Reunin de Planificacin de Sprint (Sprint Planning

Meeting): El trabajo a realizar durante el Sprint se planifica en
la Reunin de Planificacin de Sprint. Este plan se crea
mediante el trabajo colaborativo del Equipo Scrum completo.

La Reunin de Planificacin de Sprint responde a las siguientes

preguntas:
Qu puede entregarse en el Incremento resultante del Sprint
que comienza?
Cmo se conseguir hacer el trabajo necesario para entregar
el Incremento?

2. Scrum Diario (Daily Scrum): El Scrum Diario es una reunin

con un bloque de tiempo de 15 minutos para que el Equipo de
Desarrollo sincronice sus actividades y cree un plan para las
siguientes 24 horas. Esto se lleva a cabo inspeccionando el
trabajo avanzado desde el ltimo Scrum Diario y haciendo una
proyeccin acerca del trabajo que podra completarse antes del
siguiente.

Durante la reunin, cada miembro del Equipo de Desarrollo

explica:

Qu hice ayer que ayud al Equipo de Desarrollo a lograr el

Objetivo del Sprint?
Qu har hoy para ayudar al Equipo de Desarrollo a lograr el
Objetivo del Sprint?
Veo algn impedimento que evite que el Equipo de Desarrollo
o yo logremos el Objetivo del Sprint?

El Scrum Master se asegura de que el Equipo de Desarrollo tenga

la reunin, pero el Equipo de Desarrollo es el responsable de dirigir
 el Scrum Diario. Ensea al Equipo de Desarrollo para que
mantenga el Scrum Diario en los lmites del bloque de tiempo de
15 minutos.

3. Revisin de Sprint (Sprint Review): Al final del Sprint se lleva

a cabo una Revisin de Sprint para inspeccionar el Incremento y
adaptar la Lista de Producto si fuese necesario. Durante la
Revisin de Sprint, el Equipo Scrum y los interesados colaboran
acerca de lo que se hizo durante el Sprint. Basndose en esto, y
en cualquier cambio a la Lista de Producto durante el Sprint, los
asistentes colaboran para determinar las siguientes cosas que
podran hacerse para optimizar el valor.

4. Retrospectiva de Sprint (Sprint Retrospective): La

Retrospectiva de Sprint es una oportunidad para el Equipo
Scrum de inspeccionarse a s mismo y crear un plan de mejoras
que sean abordadas durante el siguiente Sprint.

El propsito de la Retrospectiva de Sprint es:

Inspeccionar cmo fue el ltimo Sprint en cuanto a
personas, relaciones, procesos y herramientas;
Identificar y ordenar los elementos ms importantes que
salieron bien y las posibles mejoras; y,
Crear un plan para implementar las mejoras a la forma en
la que el Equipo Scrum desempea su trabajo.

Roles

1. 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.
El propietario del producto hace que las necesidades de los clientes
y usuario final sean entendidas por el equipo, mediante la creacin,
perfeccionamiento y comunicacin de los requerimientos.
2. ScrumMaster (o Facilitador): El Scrum es facilitado por un
ScrumMaster, cuyo trabajo primario es eliminar los obstculos
que impiden que el equipo alcance el objetivo del sprint. El
ScrumMaster no es el lder del equipo (porque ellos se auto-
organizan), sino que acta como una proteccin 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.
El Scrum master acta como un entrenador (coach), para guiar al
equipo a altos niveles de cohesin, organizacin y rendimiento del
mismo. Mientras la entrega del equipo es el producto, el entregable
del Scrum master es la auto organizacin del equipo.
3. Equipo: El equipo tiene la responsabilidad de entregar el
producto. Un pequeo equipo de 5 a 9 personas con las
habilidades transversales necesarias para realizar el trabajo
(diseador, desarrollador, etc).
Debe transformar las tareas del Sprint Backlog en un
incremento de funcionalidad en el software.
Desarrollar el producto con calidad.
Auto-gestionado
Auto-organizado.
Multi-funcional
Scrum no reconoce sub-equipos en los equipos de desarrollo, no
importan los dominios particulares que requieran ser tenidos en
cuenta, como pruebas o anlisis de negocio; no hay excepciones a
esta regla; y,
Los Miembros individuales del Equipo de Desarrollo pueden tener
habilidades especializadas y reas en las que estn ms
enfocados, pero la responsabilidad recae en el Equipo de
Desarrollo como un todo.
4. Stakeholders (interesados): Los interesados con aquellas
personas quienes tienen deseos, necesidades y son la razn por
la que el equipo desarrolla el software.

Funcionamiento e interaccin de Scrum

Bibliografa
[1 Autores del manifiesto Agil, [En lnea]. Available:
] http://agilemanifesto.org/iso/es/principles.html. [ltimo acceso: 2016].

[2 SCRUMstudy, A Guide to the SCRUM BODY OF KNOWLEDGE (, Phoenix,

] Arizona: VMEdu, Inc, 2013.

[3 I. A. M, Desarrollo gil con Scrum, 2010. [En lnea]. Available:

] http://cic.puj.edu.co/wiki/lib/exe/fetch.php?
media=materias:sg07.p02.scrum.pdf. [ltimo acceso: 2016].