Universidad Adventista de Centro Amrica

Escuela de Ingeniera de Sistemas Computacionales

Material anexo de:

Propuesta de implementacin del marco de desarrollo gil
(SCRUM) en el departamento de sistemas y en el curso
Anlisis de Sistemas II de la Escuela de Ingeniera en
UNADECA.
Ttulo a optar:
Licenciatura en Ingeniera de Sistemas
Autor:
Lucy M. Andrade
Ana M. Baza
Asesor:
Lic. Jorge Ulate, MBA, MGP
Fecha:
Septiembre 2016

Gua Rpida de Scrum

CONTENIDO

Introduccin a las metodologas giles ............................... 3

Concepto de scrum .............................................................. 3
El equipo de scrum.............................................................. 4
Product owner ................................................................. 4
Development Team ......................................................... 5
Tamao del development team ................................... 5
Scrum Master .................................................................. 6
Artefactos de scrum ............................................................ 7
Product Backlog .............................................................. 7
User Stories ..................................................................... 8
Sprint Backlog ................................................................ 9
Scrum Taskboard ............................................................ 9
Burndown Chart ............................................................ 10
Eventos de scrum .............................................................. 10
Sprints ........................................................................... 11
Sprint 0 (preparacin) ............................................... 11
Product Backlog Refinement Meeting .......................... 12
Sprint Planning Meeting ............................................... 13
Daily Scrum .................................................................. 14
Sprint Review................................................................ 15
Sprint Retrospective ...................................................... 15
Estimacin gil ................................................................ 17
Definicin de Terminado y Listo ............................... 19

Gua Rpida de Scrum

Glosario ............................................................................. 20
Referencias Bibliogrficas ................................................ 22

Gua Rpida de Scrum

INTRODUCCIN A LAS METODOLOGAS G ILES

Las metodologas tradicionales han sido efectivas y

utilizadas para un gran nmero de proyectos; pero tambin
han presentado problemas en muchos otros.
Como resultado de esto han surgido nuevas
metodologas se basan en el manifiesto para un desarrollo
de Software gil, el cual expone formas mejores de
desarrollar software, desarrollndolo y ayudando a otros a
desarrollarlo. A travs de ese trabajo hemos empezado a
valorar: individuos e interacciones por sobre procesos y
herramientas, software funcionando por sobre
documentacin completa, cooperacin con el cliente por
sobre negociacin de contratos, respuestas frente a cambios
por sobre seguimiento de un plan.

CONCEPTO DE SCRUM

Es un framework (marco de trabajo) en el que la

gente puede hacer frente cambios frecuentes haciendo ms
productiva y creativa la entrega de productos.
Scrum no es un proceso o una tcnica para la
construccin de productos; ms bien, es un marco dentro
del cual se puede emplear varios procesos y tcnicas.
Scrum consiste en Equipos Scrum y sus funciones
asociadas, eventos objetos y reglas. Donde cada elemento
tiene su propsito especfico y es esencial para el xito y el
uso de Scrum.
Scrum emplea un enfoque iterativo e incremental
para optimizar la previsibilidad y control de riesgos.
3

Gua Rpida de Scrum

EL EQUIPO DE SCRUM

El Equipo de Scrum consiste en:

Product Owner (Dueo del Producto).
Deverlopment Team (Equipo de Desarrollo).
Scrum Master.
Los Equipos Scrum son autoorganizados y
multifuncionales.
Los Equipos Scrum entregan productos de forma
iterativa e incremental, maximizando las oportunidades de
obtener retroalimentacin. Las entregas incrementales de
producto Terminado aseguran que siempre estar
disponible una versin potencialmente til y funcional del
producto.

PRODUCT OWNER
El Product Owner es el nico responsable de
gestionar el Product Backlog (lista de producto). La gestin
incluye:

Expresar claramente los elementos del Product

Backlog.
Ordenar los elementos segn la prioridad de
entrega.
Asegurar que el Product Backlog sea clara para
todos.

El Product Owner es una nica persona, no un comit.

Gua Rpida de Scrum

DEVELOPMENT TEAM
El Development Team es responsable de desarrollar
el producto. Las actividades de cada uno de los miembros
del equipo estn alineadas de tal manera que se alcancen
los objetivos asociados a un sprint especfico.
Los Equipos de Desarrollo tienen las siguientes
caractersticas:

Son auto organizados.

Son multifuncionales.
Scrum no reconoce ttulos para los miembros del
equipo, todos son desarrolladores.
Scrum no reconoce sub-equipos.
Los miembros individuales pueden tener
habilidades especializadas y reas en las que estn
ms enfocados, pero la responsabilidad recae en el
Equipo de Desarrollo como un todo.

TAMAO DEL DEVELOPMENT TEAM

El tamao ptimo del Equipo de Desarrollo es lo
suficientemente pequeo como para permanecer gil y lo
suficientemente grande como para completar una cantidad
de trabajo significativa.
Tener menos de tres miembros reduce la interaccin
y resulta con ganancias de productividad ms pequeas
encontrndose con limitaciones en cuanto a habilidades
necesarias durante un sprint.
Tener ms de nueve miembros requiere demasiada
coordinacin.
5

Gua Rpida de Scrum

Los roles de Product Owner y Scrum Master no

cuentan con el clculo del tamao del equipo a menos que
tambin estn contribuyendo a trabajar en el Sprint Backlog
(Lista de Pendientes del Sprint).

SCRUM MASTER
El Scrum Master es el responsable de asegurar que
Scrum es entendido y adoptado; asegurndose de que el
Equipo Scrum trabaja ajustndose a la teora, prcticas y
reglas de Scrum. Tambin es un lder que est al servicio
del Equipo Scrum.
El Scrum Master ayuda a las personas externas al
Equipo Scrum a entender qu interacciones con el Equipo
Scrum pueden ser de ayuda y cules no. Es responsable de
dirigir y planificar la logstica necesaria para las reuniones.

Gua Rpida de Scrum

ARTEFACTOS DE SCRUM

Los artefactos definidos por Scrum est diseados

para asegurar que todos tengan el mismo entendimiento del
proyecto.
Los artefactos en Scrum son:

Product Backlog
User Stories
Sprint Backlog
Task Boards
Burndown Chart

PRODUCT BACKLOG
Es una lista del producto ordenada de todo lo
necesario en el producto (requisitos) y es la nica fuente
para cualquier cambio.
El Product Owner es el responsable de la lista,
incluyendo su contenido y priorizacin.
El Product Backlog va evolucionando a medida que
el producto y el entorno
tambin lo hacen es decir
que es dinmica y cambia
contantemente para
identificar los que el
producto necesita para ser
competitivo y til.
El Product
Backlog Producto
7

Gua Rpida de Scrum

enumera todas las caractersticas, funcionalidades,

requisitos, mejoras y correcciones que constituyen
cambios a ser hechos sobre el producto para entregas
futuras. Y tienen como atributo la descripcin, la
ordenacin la estimacin y el valor.

USER STORIES
Los User Stories son las descripciones de las
funcionalidades que tendr el software; y sern el resultado
de la colaboracin entre el Product Owner y el Scrum
Team.
Se sugiere una determinada forma de redactar los User
Stories:
Como (rol) Necesito/quiero (funcionalidad) Para
(beneficio)
Ejemplo: Como estudiante necesito comprar un
pase de estacionamiento para poder estacionar mi vehculo
en la universidad.
Prstamo de Libro
Cmo cliente quiero que los socios puedan pedir
prestado un libro, para ser llevados fuera de la
biblioteca pero indicando su nmero de socio y la
referencia del libro, siempre y cuando no tengan ya tres
libros prestados en ese momento.

Gua Rpida de Scrum

SPRINT BACKLOG
Es la lista de tareas que se elaboran durante la
planificacin del sprint y que formarn parte del prximo
incremento. Tambin debe ser un plan con un nivel de
detalle suficiente como para que los cambios en el progreso
se puedan entender en el Scrum Diario.
El Development Team modifica el Sprint Backlog y
las nuevas tareas se aaden al estado de pendientes; a
medida que el trabajo se ejecuta o se completa, se va
actualizando la estimacin y el estado de la tarea.
Estas tareas son asignadas a cada persona del
Development Team y el tiempo que queda en terminarlas.

SCRUM TASKBOARD
Generalmente, las tareas a completar se suelen
gestionar mediante el scrum taskboard, se usan post-its
que se van moviendo de columna para cambiar el estado.

Gua Rpida de Scrum

BURNDOWN CHART
El progreso del equipo se realiza un seguimiento
mediante un Burndowns Chart que representa visualmente
el progreso de un proyecto. El Burndown Chart
proporciona una medida de da a da del trabajo que queda
en un sprint o liberacin dada.
La pendiente de la grfica, o la burndowns velocity,
se calcula comparando el nmero de horas trabajadas a la
estimacin original del proyecto y muestra la tasa promedio
de la productividad para cada da.

Saber si o no el proyecto est en el tiempo,

temprano, o correr detrs puede ayudar a los equipos hacer
los ajustes que har que todo vuelva a la pista.

EVENTOS DE SCRUM

10

Gua Rpida de Scrum

Con Scrum el producto es construido en series de

iteraciones predefinidas llamadas Sprints.
Iteraciones cortas refuerzan la importancia de una
buena estimacin de tiempo y una retroalimentacin rpida
de las pruebas.
Scrum solicita cuatro eventos que aporten estructura a
cada sprint.

Product Backlog Refinement Meeting

Sprint planning
Daily Scrum
Sprint Review
Sprint retrospective

SPRINTS
El corazn de Scrum es el Sprint, es un bloque de
tiempo (time-box) de un mes o menos durante el cual se
crea un incremento de producto Terminado, utilizable y
potencialmente desplegable.
Cada nuevo Sprint comienza inmediatamente
despus de la finalizacin del Sprint previo.
Cada Sprint tiene una definicin de qu se va a
construir, un diseo y un plan flexible que guiar la
construccin y el trabajo y el producto resultante.

SPRINT 0 (PREPARACIN)
11

Gua Rpida de Scrum

Es la fase inicial en donde se intenta comprender el

caso de negocio para tomar decisiones que agreguen valor
al producto.
Durante esta fase se producen inexactitudes con las
estimaciones, pero es normal. En lugar de buscar
estimaciones exactas se busca invertir ese tiempo en el
producto.
Las tareas en el sprint 0 son:

Definir el proyecto
Definicin del Backlog Inicial
Definicin de los entregables (criterios, fechas de
reuniones)

PRODUCT BACKLOG REFINEMENT MEETING

Asisten: Product Owner, Scrum Team (no es
necesario todo el equipo).
Cuando: Se realiza despus de que el Product
Owner ha definido el Product Backlog y antes que se
realice la planeacin del sprint siguiente, preferiblemente
tres das antes del final del sprint actual.
Propsito: En la reunin se aaden ms detalles a
los User Stories, estimaciones y priorizacin.
Al Scrum Team se le da la ocasin de formular
preguntas que normalmente surgiran durante el Sprint
Planning. Preguntndose esto antes, al Product Owner se le
da la oportunidad de responder con tiempo a cualquier
pregunta que l o ella pueda que no est preparado para
12

Gua Rpida de Scrum

hacerlo de manera inmediata y ser presentada en el Sprint

Planning Meeting.
Si estas preguntas surgen en el sprint planning
meeting por primera vez, pueda ser que muchas no sean
contestadas, podra ser necesario poner un elemento de
Product Backlog de alta prioridad a un lado y no trabajar en
l durante el Sprint.

SPRINT PLANNING MEET ING

Asisten: Development Team, Scrum Master,
Product Owner.
Cuando: al principio del Sprint.
Propsito: el product owner tendr un product
backlog priorizado. Discuten cada elemento con el
development team y el grupo estima colectivamente el
tiempo que supone.
El development team tendr que hacer un pronstico
del sprint con respecto a la cantidad de trabajo que el
equipo puede entregar referente al backlog. Este cuerpo de
trabajo se convierte en el sprint backlog. Solo el Equipo
de Desarrollo puede evaluar qu es capaz de lograr
durante el Sprint que comienza.
La reunin alienta a los miembros del equipo para
bosquejar las tareas de todas las historias, bugs, y tareas
que entran en el sprint.

13

Gua Rpida de Scrum

DAILY SCRUM
Asisten: Development Team, Scrum Master.
Opcionales: Product Owner, inversionistas.
Cuando: una vez por da, normalmente en la
maana.
Duracin: no ms de 15 minutos. Sin reservar una
sala de conferencias y llevar la reunin a cabo de pie. Estar
de pie ayuda a mantener la reunin corta.
Propsito: la reunin est diseada para ser rpida
e informar a todos lo que est sucediendo en los equipos.
No es una reunin detallada; debera ser ligera y divertida,
pero informativa. El Scrum Diario es una reunin para que
el Equipo de Desarrollo sincronice sus actividades y cree
un plan para las siguientes 24 horas.
Cada miembro del Development Team explica:

Qu hice ayer?
Qu har hoy?
Veo algn impedimento?

El Scrum Master se asegura de que el Development Team

tenga la reunin y que todos sus miembros participen, pero
el Development Team es el responsable de dirigir el Scrum
Diario.
Los Daily Scrum mejoran la comunicacin,
eliminan la necesidad de mantener otras reuniones,
identifican y eliminan impedimentos relativos al desarrollo,
resaltan y promueven la toma de decisiones rpida, y
mejoran el nivel de conocimiento del Equipo de Desarrollo.
14

Gua Rpida de Scrum

SPRINT REVIEW
Asisten: Development Team, Scrum Master,
Product Owner. Opcionales: inversionistas.
Cuando: al final del sprint o hito importante.
Duracin: 30 60 minutos.
Propsito: la revisin del sprint es un momento
para mostrar el trabajo del equipo. Puede ser casual como
o ms una reunin ms formalmente estructurada. Este es el
tiempo para que el equipo celebre sus logros, demuestre el
trabajo finalizado dentro del sprint y obtiene feedback
inmediato por parte de los inversionistas. Recodar que el
trabajo debe estar completamente demostrable y cumplir la
barra de calidad del equipo dentro de la consideracin de
completo; listo para mostrar en la revisin.

SPRINT RETROSPECTIVE
Asisten: Development Team, Scrum Master,
Product Owner.
Cuando: al final del sprint.
Duracin: 30 60 minutos.
Propsito: Las retrospectivas ayudan al equipo a
entender que funcion bien y que mal; no solo son un
momento para quejarse sin hacer nada, sino ms bien
tomarse el tiempo para encontrar soluciones creativas y
desarrollar un plan de accin.

15

Gua Rpida de Scrum

En conclusin, 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.

16

Gua Rpida de Scrum

ESTIMACIN GIL

La buena estimacin ayuda a los products owners a

optimizar para obtener eficiencia e impacto.
Deben tomar en cuenta serie de factores que
ayudar al product owners realizar decisiones que afectan
todo el equipo y el negocio. Con todo lo que est en juego
no es de extraar que todos los desarrolladores se sientan
vulnerables a cometer un error. Pero eso est incorrecto, ya
que la estimacin es solo eso: una estimacin; no un
juramento de sangre.
A continuacin, se enumeran algunas maneras de
hacer de la estimacin lo ms acertado posible.
Colaboracin con el product owner
Cuando el equipo de ingeniera comienza el proceso
de estimacin, las preguntas normalmente surgen acerca de
los requerimientos y los user stories. Y eso es bueno: estas
preguntas ayudan a todo el equipo a entender el trabajo ms
ampliamente. Para product owners especficamente, separar
historias en pequeas tareas y estimarlas ayuda a priorizar
todo (y potencialmente escondidas) reas de trabajo. Y una
vez que se obtiene la estimacin del development team, no
es raro para el product owner reordenar estos elementos en
el backlog. A esta reunin se le llama goomming meeting o
backlog refinement meeting.
La estimacin gil involucra a un equipo completo
Incluyendo a todos (desarrolladores, diseadores,
testers, deployers, todos) en un equipo es la clave. Cada

17

Gua Rpida de Scrum

miembro del equipo tiene una diferente perspectiva del

producto y el trabajo requerido para realizar el user story.
Story points vs. Horas
Los quipos de software tradicionales realizan estimaciones
en formato de tiempo: das, semanas, meses. Muchos
equipos giles, sin embargo, han cambiado a story points.
Los story points valoren el
esfuerzo relativo en formato
Fibonacci: 0, 1, 2, 3, 4, 8.

1
2
3
4
8

Very small
Small
Medium
Large
Very large

Los equipos que comienzan

con los story points pueden usar el
ejercicio llamado planning pker. El equipo agarra un
elemento del backlog, lo discuten brevemente y cada
miembro har una estimacin mental. Despus cada uno
toma una carta con el nmero que refleja su estimacin. Si
todos est de acuerdo, excelente; si no se tomara unos
minutos para entender el porqu de las diferentes
estimaciones.
Estimar inteligentemente dividiendo el trabajo en tareas
Un trabajo individual no debera ser ms de 16
horas de trabajo. (Se estn utilizando story points, puedes
decidir que 20 puntos es el lmite). Es simplemente muy
difcil estimar un trabajo individual mayor con un alto
grado de confianza.
Cuando algo es estimado por encima de las 16 hrs (o
20 puntos), es la seal para dividir en partes y reestimar la
tarea.

18

Gua Rpida de Scrum

Aprender de las estimaciones pasadas

La estimaciones se pueden realizar de dos maneras:
1. De forma aploximada: se debate el story points
hasta llegar a un acuerdo. Suele fuincionar de
forma correcta si los sprints son cortos.
2. Por medio de calculo de velocidad.
DEFINICIN DE TERMINADO Y LISTO

Listo
Es el conjunto de caractersticas que User Story
debe cumplir para que el Development Team pueda
comprometerse a su entrega, es decir, incluirla en un Sprint
Backlog. Un tpico criterio de Listo podra ser:

Todos sus pre-requisitos estn resueltos

Terminado
Es el conjunto de caractersticas que un User Story
debe cumplir para que el equipo de desarrollo pueda
determinar si ha terminado de trabajar en ella. Un tpico
criterio de Terminado podra ser:

Todos los criterios de aceptacin funcionan

correctamente
Todos los archivos fuentes estn en el repositorio de
cdigo fuente y el build se ejecut exitosamente.

19

Gua Rpida de Scrum

GLOSARIO

Blacklog: es una lista de historias de usuarios pendientes,

errores y caractersticas para un producto (product backlog)
o sprint (sprint backlog).
Burndown Chart: el burndown chart muestra la cantidad
de trabajo actual y estimado que debe ser hecho en un
sprint.
Development Team: equipo de desarrolladores.
Framework: marco de trabajo. Se diferencia entre la
palabra metodologa y de procedimientos especificados
paso a paso. Un marco de trabajo son un conjunto de
conceptos, criterios, prcticas y acuerdos de trabajo, para
avanzar con determinado proyecto que permiten mantener
el foco y dejar espacio para la creatividad.
Product backlog: es una lista de alto nivel que contiene los
requerimientos del cliente para el proyecto y es realizado
por el product owner.
Product Owner: dueo del producto, cliente. Es quien
ocupa el rol de escuchar e integrar las necesidades
involucradas en determinados productos, cuidando que los
resultados y el valor entregado sean necesarios.
Scrum: Scrum es un marco de desarrollo gil que es
completado por iteraciones sobre un nmero discreto de
periodos de tiempo (sprint).
Scrum Board: un Scrum Board es una pizarra que fue
creada usando los preajustes de Scrum (ver creando una
pizarra).
20

Gua Rpida de Scrum

Scrum Master: facilitador. Es quien ocupa el rol de cuidar

el equipo de personas y el marco de trabajo a travs del
cual avanzan los proyectos.
Sprint: un sprint tambin conocido como iteracin es
un periodo corto (idealmente de dos a 4 semanas) en el cual
el equipo de desarrollo implementa y entrega un
incremento discreto del producto p. ej trabajando en una
versin beta.
Sprint Backlog: el sprint backlog contiene la lista de tareas
necesarias para ser completas y as implementar las
caractersticas planeadas para un sprint en particular.
Idealmente cada tarea en un sprint es relativamente corto y
puede ser escogida por un miembro del equipo en lugar de
ser asignada.
User Story: un user story es un requerimiento del sistema
de software que es expresada en cortas oraciones
preferiblemente no usando lenguaje tcnico.
Story Point: un story points es una estimacin de la
complejidad relativa de una historia.
Tarea: una tarea es una unidad de trabajo contenida dentro
de una historia.
Velocidad: la velocidad del equipo es una medicin de
cuanto trabajo el equipo puede manejar dentro de un
periodo especifico de tiempo es decir cunto del product
backlog puede ser completado por un equipo en un sprint.
Versin: una versin es un conjunto de caractersticas y
arreglos lanzados en conjunto como una sola actualizacin
de tu producto.
21

Gua Rpida de Scrum

REFERENCIAS BIBLIOGRFICAS

Alaimo, M. (2006). Anlisis, estimacion y planificacion

gil. Kleer.
Cohn, M. (25 de Abril de 2008). Mountain Goat.
Obtenido de Advantages of the As a user, I want
user story template.: http://www.
mountaingoatsoftware. com/blog/advantages-of-theas-a-user-i-want-user-story-template.
Gupta, S. (14 de 0 de 2013). Performance & Load Testing.
Obtenido de Roles of team members involved in an
AGILE Scrum project:
http://www.quotium.com/performance/roles-teammembers-involved-agile-scrum-project/
Radigan, D. (15 de 8 de 2016). atlassian. Obtenido de
"Have we met?" Four agile ceremonies,
demystified.:
https://www.atlassian.com/agile/ceremonies
Paredes, Arleth (2012). Manifiesto gil.Recuperado el 14
de agosto de 2016 de
https://arlethparedes.wordpress.com/2012/08/25/mani
fiesto-agil/
Schwaber, K. and Sutherland, J. (2013). The Definitive
Guide to Scrum: The Rules of the Game.

22