CRITERIOS PARA LA IMPLEMENTACIÓN DEL ESTÁNDAR SCRUM COMO

MARCO DE TRABAJO PARA EL DESARROLLO DE PROYECTOS

INTEGRANTES:

CARLOS ANDRÉS BARCO

PAOLA ANDREA GUZMÁN

ALVARO JOSÉ VIVAS

DIRECTOR: RONALD ROJAS ALVARADO

COORDINADOR: LUIS FELIPE GRANADA

UNIVERSIDAD SAN BUENAVENTURA CALI

FACULTAD DE INGENIERIAS

ESPECIALIZACION EN GESTION INTEGRAL DE PROYECTOS

CALI, 2014

1
CRITERIOS PARA LA IMPLEMENTACIÓN DEL ESTÁNDAR SCRUM COMO
MARCO DE TRABAJO PARA EL DESARROLLO DE PROYECTOS

CRITERIA FOR IMPLEMENTING SCRUM AS STANDARD FRAMEWORK FOR

DEVELOPMENT PROJECTS

INTEGRANTES:

CARLOS ANDRÉS BARCO

PAOLA ANDREA GUZMÁN

ALVARO JOSÉ VIVAS

Trabajo de grado presentado como requisito para optar el título de

ESPECIALISTA EN GESTIÓN INTEGRAL DE PROYECTOS

UNIVERSIDAD SAN BUENAVENTURA CALI

FACULTAD DE INGENIERIAS

ESPECIALIZACION EN GESTION INTEGRAL DE PROYECTOS

CALI, 2014

2
 Nota de aceptación

El trabajo de grado titulado CRITERIOS

PARA LA IMPLEMENTACIÓN DEL
ESTANDAR SCRUM COMO MARCO
DE TRABAJO PARA EL DESARROLLO
DE PROYECTOS, presentado por los
estudiantes CARLOS ANDRÉS
BARCO, PAOLA GUZMÁN, ALVARO
JOSÉ VIVAS, cumple con los requisitos
exigidos por la UNIVERSIDAD DE SAN
BUENAVENTURA SECCIONAL CALI
para optar al título de ESPECIALISTA
EN GESTIÓN INTEGRAL DE
PROYECTOS.

_______________________________
Firma del presidente del jurado

_______________________________

Firma del jurado

_______________________________

Firma del jurado

Santiago de Cali, Agosto de 2014

3
 CONTENIDO

Pág.

1 DESCRIPCIÓN DEL PROBLEMA .................................................................... 10

1.1 PREGUNTA DE INVESTIGACIÓN ........................................................................................... 10
2 OBJETIVOS...................................................................................................... 11
2.1 OBJETIVO GENERAL ............................................................................................................. 11
2.2 OBJETIVOS ESPECÍFICOS ...................................................................................................... 11
3 JUSTIFICACIÓN............................................................................................... 11
4 MARCO REFERENCIAL .................................................................................. 12
4.1 ANTECEDENTES ................................................................................................................... 12
4.2 MARCO CONCEPTUAL ......................................................................................................... 14
4.2.1 EVOLUCIÓN DEL CONCEPTO GERENCIA DE PROYECTOS ............................................ 14
4.2.2 EVOLUCIÓN ESTANDAR DE PROYECTOS ..................................................................... 16
4.2.3 EVOLUCIÓN DEL ESTANDAR SCRUM ........................................................................... 17
4.3 MARCO TEORICO ................................................................................................................. 19
4.3.1 ROLES DE LA METODOLOGIA SCRUM ......................................................................... 19
4.3.2 ETAPAS DE LA METODOLOGÍA SCRUM ....................................................................... 19
4.3.3 CERTIFICACION EN SCRUM Y ENTIDADES QUE LA OFRECEN: ..................................... 23
5 METODOLOGÍA ............................................................................................... 24
6 ANÁLISIS.......................................................................................................... 24
7 CONCLUSIONES ............................................................................................. 26
8 BIBLIOGRAFIA ................................................................................................. 29

4
 LISTADO DE TABLAS

Pág.

Tabla 1. Antecedentes ..................................................................................................................... 12

Tabla 2. Evolución del Concepto Gerencia de Proyectos .......................................................... 15

Tabla 3. Evolución Estándar de Proyectos .................................................................................. 16

Tabla 4. Evolución estándar SCRUM............................................................................................ 18

Tabla 5. Autores vs Etapas de SCRUM (Variables) ................................................................... 21

Tabla 6. Autores vs Etapas de SCRUM (Covariables) ............................................................... 22

Tabla 7. Relación entre ciclo de vida de un proyecto y ciclo de vida de SCRUM.................. 25

LISTADO DE FIGURAS

Figura 1. Roles, artefactos y eventos principales de SCRUM ................................................. 19

5
 RESUMEN

Este trabajo se realiza con el fin de determinar los criterios para la implementación
del estándar Scrum, como una herramienta de gestión y administración del
desarrollo de proyectos, por medio de una metodología ágil, utilizando un enfoque
cuantitativo, de tipo descriptivo transversal, basada en el diseño de tablas, que
recopilan información de los diferentes autores especializados, las cuales son
analizadas y procesadas; esto permite evidenciar posteriormente, que al aplicar
esta metodología en las organizaciones, reducirán el porcentaje de sus proyectos
fallidos y elevará la satisfacción del usuario final, esto debido a que en lugar de dar
instrucciones a los equipos sobre la forma como deben realizar el trabajo, usando
documentación extensa con la descripción detallada de las tareas del proyecto,
Scrum proporciona un ambiente de trabajo que permite exponer cualquier problema
que se presente, explorando formas de solución pronta por medio de una
negociación flexible, a través de etapas iterativas que comprenden actividades
relacionadas, incrementando la agilidad, la flexibilidad y la productividad. Esta
metodología permite realizar entregas con regularidad, generando avances
continuos y dando visibilidad a la organización sobre el progreso del proyecto
durante toda su ejecución.

Palabras claves. Criterios para la Implementación del Estándar Scrum, solución

pronta, negociación flexible, entregas con regularidad, avances continuos.

ABSTRACT

This work is done in order to determine the criteria for the implementation of Scrum
standard as a tool for management and administration of project development,
through an agile methodology, using a quantitative approach, cross-descriptive,
based on design tables that collect information from different specialized authors,
which are analyzed and processed; this allows then show that by applying this
methodology in organizations, reduce the percentage of failed projects and raise the
satisfaction of the end user, this because instead of giving instructions to the teams
about how work should be performed, using extensive documentation with a
detailed description of project tasks, Scrum provides a work environment that allows
you to expose any problems that arise, exploring ways to early resolution through a
flexible trading through iterative steps comprising related activities, increasing the
agility, flexibility and productivity. This methodology allows for regular deliveries,
generating continuous progress and giving visibility to the organization on the
progress of the project throughout its implementation.

Key words: Criteria for Implementation of Standard Scrum, early, flexible trading,
regular deliveries, continuous progress.

6
 INTRODUCCIÓN

Este trabajo de grado hace parte del proyecto de investigación Criterios para la
Implementación del Estándar SCRUM como Marco de Trabajo para el Desarrollo
de Proyectos del Grupo de Investigación Nuevas Tecnologías, trabajo y gestión de
la Especialización en Gestión Integral de Proyectos del Programa Ingeniería
Industrial de la Universidad de San Buenaventura Cali. Para alcanzar los objetivos
de este proyecto se realizaron tres actividades: i) Revisión digital y física de la
literatura especializada, propuestas por diferentes autores sobre el estándar
SCRUM, ii) Analizar de la literatura seleccionada, los criterios básicos,
considerando los principios y conceptos que fundamenten la implementación del
estándar SCRUM y finalmente iii) Redactar una monografía con el análisis de la
información encontrada, donde se establezcan los criterios básicos para la
implementación del estándar, destacando la importancia de utilizar metodologías
ágiles dentro del desarrollo de proyectos. Se logra observar la evolución de los
conceptos de gerencia de proyectos, de estándar de proyectos y posteriormente se
genera la necesidad de tener un nuevo estándar en el campo de proyectos de
informática, para lograr concentrar los esfuerzos de los equipos de desarrollo de
software en lo más importante, como son los entregables solicitados por los
interesados, disminuyendo la carga del equipo al no requerir de extensa
documentación, agilizando la realización, entrega y puesta en marcha del proyecto.
En la Figura 1, ubicada en el Marco Teórico, página 19, etapas de la metodología
SCRUM, se observan los roles, artefactos y eventos principales utilizados en el
proceso de implementación de la metodología Scrum, estas son las principales
características que se deben recrear para llevar a cabo una buena práctica e
implementación de esta metodología. En el Análisis, numeral 6 de este documento
se observa la tabla 7, donde se presenta la relación entre los grupos de procesos
del ciclo de vida de un proyecto y las etapas del ciclo de vida de la metodología
SCRUM.

GLOSARIO

Backlog de Impedimentos:
El backlog de impedimentos es la lista de situaciones que están impidiendo que el
equipo progrese. Estas son situaciones que el Scrum Master debe quitar del
camino para ayudar a que el equipo trabaje mejor. (Hundermark, Un mejor Scrum,
2011)

Backlog Grooming:
El equipo debe reunirse con el Product Owner (PO) a lo sumo una vez por sprint
para planificar los sprint futuros. Entre todos los participantes de la reunión deben
escribir las actividades para el sprint futuro. (Schwaber & Sutherland, 2010)

Burndown de Release o de Producto:

Mide el ritmo de entrega de funcionalidades testeadas a lo largo del tiempo. Este
ritmo es conocido como la velocidad del equipo. (Hundermark, Un mejor SCRUM,
2009)

7
Burndown del Sprint:
Gráfico de Tareas que ayuda al equipo, en la monitorización del progreso y es el
indicador principal que informará sobre las posibilidades de alcanzar los
compromisos al finalizar el sprint. (Hundermark, Un mejor Scrum, 2011)

Incremento de Producto:
El incremento es la parte de producto producido en un sprint, y tiene como
características, que está completamente terminada, operativa y en condiciones de
ser entregada al cliente final. (Palacio & Ruata, 2011)

Product Backlog (Pila de Producto):

Es una lista priorizada de todo lo que podría ser necesario en el producto. Los
requisitos para el producto están listados en el Product Backlog. (Schwaber &
Sutherland, 2010)

Product Owner (PO):

Es el responsable de gestionar uno de los artefactos de esta metodología conocido
como Product Backlog y de maximizar el valor del trabajo realizado por el equipo.
Se encarga de mantener el Product Backlog y asegurar que sea visible para todos.
(Schwaber & Sutherland, 2010)

Retrospectiva:
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 en el
siguiente sprint. Es la última reunión del sprint. Sigue inmediatamente después de
la Revisión del Sprint y antes de la siguiente Reunión de Planificación del Sprint.
(Schwaber & Sutherland, 2010)

Reunión de Estimación:
Se realiza para estimar el costo de nuevos ítems del backlog o recalcular el tamaño
de ítems de gran costo, que deberán ser subdivididos en otros más pequeños, de
modo que se desarrollen en otro sprint. (Hundermark, Un mejor Scrum, 2011)

Reunión de Planificación de la entrega:

Establece el plan y las metas que los Equipos Scrum y el resto de las
organizaciones puedan entender y comunicar. El plan de entrega establece el
objetivo de la entrega. (Schwaber & Sutherland, 2010).

Reunión de Planificación del Sprint:

Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a
ser el trabajo y los objetivos que se deben conseguir en la iteración. (Schwaber &
Sutherland, 2010)

8
Revisión del Sprint:
Es una reunión con duración máxima de cuatro horas para un Sprint de un mes.
Para Sprints de menor duración, hay que asignar proporcionalmente menos tiempo
de la longitud total para esta reunión. (Schwaber & Sutherland, 2010)

Scrum Diario:
Cada equipo se reúne todos los días 15 minutos en una reunión de inspección y
adaptación llamada Scrum Diario. El Scrum Diario se lleva a cabo a la misma hora
y en el mismo lugar a lo largo de todos los Sprints. (Schwaber & Sutherland, 2010)
Scrum Master:
El Scrum Master es responsable de asegurar que el equipo Scrum se adhiere a los
valores, prácticas y normas Scrum, y de ayudar a que el equipo y la organización
adopten Scrum. Es el responsable de asegurar que el proceso es comprendido y
seguido. (Schwaber & Sutherland, 2010)

Sprint:
Son iteraciones de 1 a 4 semanas que se van sucediendo una detrás de otra. Es
de duración fija, termina en una fecha específica aunque no se haya finalizado el
trabajo y nunca se alarga. Se limita en tiempo. (Pete Deemer, Scrum Primer. Una
introducción básica a la teoría y práctica de Scrum. Versión 2.0., 2012)

Sprint Backlog (Pila de sprint):

Es una lista de tareas para convertir el Product Backlog a un Sprint, en un
incremento del producto potencialmente entregable. Se compone de las tareas que
el equipo realiza para convertir los elementos del Product Backlog en un
incremento. (Schwaber & Sutherland, 2010)

Team:
Es el equipo de trabajo que está formado por desarrolladores con las capacidades
necesarias para transformar los requerimientos del PO, es decir, convertir el
Product Backlog en incrementos de funcionalidad entregable en cada Sprint.
(Schwaber & Sutherland, 2010)

Técnica CPM (Camino crítico):

El camino crítico en un proyecto, es la sucesión de actividades que dan lugar al
máximo tiempo acumulativo. Determina el tiempo más corto que podemos tardar en
hacer el proyecto, si se dispone de todos los recursos necesarios. Es necesario
conocer la duración de las actividades. (Rodriguez, 2011)

Técnica PERT:
Conjunto de modelos abstractos para la programación y análisis de proyectos de
ingeniería. Estas técnicas nos ayudan a programar un proyecto con el coste
mínimo y la duración más adecuada. (Rodriguez, 2011)

9
 1 DESCRIPCIÓN DEL PROBLEMA
Debido a los avances tecnológicos, surge un incremento de los desarrollos en
aplicaciones software. Las empresas dedicadas a esto, deben crear estructuras,
que den organización y agilidad a sus proyectos, procesos implementados, que
sean eficaces y que puedan mostrar a corto plazo, la evolución, logros y cambios
requeridos en un producto a realizar; que no se pierda tiempo y dinero al ejecutar
los ajustes pertinentes, esto debido a una planificación y seguimiento detallado de
las grandes cantidades de actividades y procesos, detección de fallas a tiempo y
respuesta rápida a cambios, dando como resultado final, el éxito del proyecto.
(Mohamed, 2011).
Por esta razón, se presenta la necesidad de implementar un marco de trabajo,
donde los individuos e interacciones, estén sobre los procesos y las herramientas,
ya que los dos primeros, son finalmente los que se encargan de cumplir
exitosamente los objetivos trazados en el proyecto; donde el software funcionando
con alta calidad, prime sobre la documentación extensa que muchas veces se
vuelve innecesaria; donde la colaboración con el cliente sea más importante que
las negociaciones contractuales, donde la respuesta al cambio, de la cual depende
el éxito de los proyectos, se haga de manera rápida y eficaz. (Mohamed, 2011).
La propuesta, que da solución a las necesidades mencionadas, es una
metodología ágil incremental/iterativa llamada SCRUM, en la cual no existen
proyectos extensos, sino que basándose en tiempos cortos estos se ejecutan en
muchas etapas, pero cada una se realiza en todas sus fases, a saber: toma de
requisitos, desarrollo de software, realización de pruebas de funcionamiento y
entrega al cliente. Se continúa con las siguientes etapas de la misma manera,
hasta que se da por finalizado el proyecto con éxito. (Mohamed, 2011).
Teniendo en cuenta que hoy en día los proyectos se mueven bajo el concepto de
procesos ágiles, es necesario establecer unos criterios básicos que permitan dar
una solución oportuna e integral a las dificultades que se presentan en la
realización de los proyectos. Es de resaltar que actualmente existen variedad de
metodologías las cuales se utilizan dependiendo de las necesidades del cliente y
los requerimientos que él establezca en tiempo, costo y calidad. (Acuña K. B.,
2009). De todo lo anterior se deriva la siguiente pregunta de investigación.

1.1 PREGUNTA DE INVESTIGACIÓN

¿Cuáles son los criterios para la implementación del estándar SCRUM como marco
de trabajo para el desarrollo de proyectos?

10
 2 OBJETIVOS

2.1 OBJETIVO GENERAL

Determinar los criterios para la implementación del estándar SCRUM como marco
de trabajo para el desarrollo de proyectos.

2.2 OBJETIVOS ESPECÍFICOS

A. Generar una base de datos digital y/o física con la literatura especializada en
el estándar SCRUM.

B. Analizar de la literatura seleccionada los criterios básicos para la

implementación del estándar SCRUM.

C. Redactar una monografía con el análisis de la información seleccionada para

la implementación del estándar SCRUM.

3 JUSTIFICACIÓN
Este proyecto entregará una base de datos digital y/o física con la literatura
especializada en el estándar SCRUM, luego de haber revisado y seleccionado los
criterios básicos para la implementación del estándar, para finalmente redactar
una monografía con el análisis de la información encontrada. La monografía
establecerá los criterios básicos para la implementación del estándar SCRUM, el
cual dejará en claro la importancia de utilizar metodologías ágiles dentro del
desarrollo de proyectos, de esta manera se pasa de trabajar de una forma
tradicional, en donde se presentaban más dificultades, a un modelo donde se
puede minimizar el riesgo entre cada una de las etapas del proyecto, asegurando la
obtención de mejores resultados. Esta metodología permite que los miembros de
un equipo trabajen bajo un estándar, en donde se obtendrán entregables a corto
plazo y en los cuales se podrán realizar las modificaciones requeridas por el cliente
antes de pasar a la siguiente iteración; esta forma de trabajo ayuda a tener una
comunicación constante mediante reuniones diarias, las cuales brindarán
información sobre cada una de las actividades que realiza cada miembro del
equipo y las dificultades o restricciones que está presentando dentro de la
realización del proyecto. Las reuniones realizadas ayudarán a recopilar
información que permita hacer las modificaciones respectivas entre cada una de las
iteraciones generadas de cada sprint, permitiendo así realizar cambios dentro del
proyecto de manera rápida y eficiente. (Acuña K. , 2009)

11
 4 MARCO REFERENCIAL

4.1 ANTECEDENTES

El primer paso en Scrum consiste en que el dueño de producto articule la visión del
producto. Al final esto evolucionará hacia una lista priorizada de funcionalidades
llamada la pila de producto. Esta pila de producto existe (y evoluciona) a lo largo de
la vida del proyecto; es el plan de trabajo del producto. En este punto, la pila de
producto es la vista única y definitiva de “todo lo que podría ser hecho por el equipo
en algún momento, en orden de prioridad”. (Pete Deemer,(The Scrum Primer),
2009).
Se comienza con la visión general del producto, especificando y dando detalle a las
funcionalidades o partes que tienen mayor prioridad de negocio, y que pueden
llevarse a cabo en un periodo de tiempo breve. Cada uno de estos periodos de
desarrollo es una iteración (sprint) que finaliza con la entrega de una parte
(incremento) operativa del producto. ( Palacio & Ruata, 2011).
Todos los días el equipo se reúne brevemente para informar del progreso y
actualizan unas gráficas sencillas que les orientan sobre el trabajo restante. Al final
del Sprint, el equipo revisa el Sprint con los interesados en el proyecto, y les
enseña lo que han construido. La gente obtiene comentarios y observaciones que
se puede incorporar al siguiente Sprint. (Pete Deemer, Informacion basica de
Scrum, 2009).
Scrum pone el énfasis en productos que funcionen al final del Sprint, que realmente
estén “hechos”, en el caso del software significa que el código esté integrado,
completamente probado y potencialmente para entregar. (Pete Deemer,
Información Básica de SCRUM (The Scrum Primer), 2009).
A continuación, se presentan los aspectos más importantes de manera cronológica
de los estudios realizados en la metodología SCRUM, esta se consolidó teniendo
en cuenta las investigaciones realizadas por los diferentes autores y sus resultados
obtenidos, los cuales se resumen en la Tabla 1.

Tabla 1. Antecedentes

Autor y año Objetivo Método Resultado Conclusión

Ken Definir Scrum, los Metodología Un marco de trabajo Scrum es gratuito. Los
Schwaber, J. roles, eventos y Scrum a través del cual las roles, artefactos,
S. (2010) artefactos de esta personas puede eventos y reglas de
metodología acometer problemas Scrum son inmutables,
complejos aunque es posible
adaptativos, a la vez implementar solo partes
que entregar de Scrum, el resultado
productos del no es Scrum. Scrum
máximo valor posible solo existe como un
productiva y todo y funciona bien
creativamente. como contenedor para
otras técnicas,
metodologías y
prácticas

12
Autor y año Objetivo Método Resultado Conclusión
Pete Proporcionar el Metodología Según encuestas Scrum no soluciona los
Deemer, G. siguiente nivel de Scrum realizadas la problemas de
B. (2009) detalle al productividad de los desarrollo; los hace
conocimiento equipos que dolorosamente visibles,
básico de implementaron la y proporciona un marco
SCRUM metodología SCRUM de trabajo para
mejoró una media del que las personas
36%. exploren formas de
solucionar problemas
en ciclos cortos y
mediante pequeños
experimentos de mejora
COLLAZOS, Presentar a Agile Metodología Tras la Proporciona a las
C. P.-J.-C. SPI – Process con Agile SPI implementación en MiPyMEs un proceso
(Julio de 21 como un proceso Process. varias empresas de mejora de procesos
de 2009) de mejora de Colombianas los de software adaptado a
procesos basado resultados obtenidos sus características, las
principalmente en reflejan que: cuales no disponen de
metodologías y Se ganó confianza los medios y recursos
principios ágiles, sobre el trabajo de suficientes para la
requerimientos SPI y la visualización aplicación de modelos
livianos y continua de los de mejora de procesos
adaptaciones de cambios de mejora tradicionales
modelos rápidos y ágiles propuestos por el SEI o
internacionales. permitió mantener el la ISO.
interés de los
proyectos de mejora.
Así mismo, debido a
la disminución del
esfuerzo, la
retroalimentación
continua, la
actualidad y ajuste de
los modelos, los
casos de estudio han
podido desarrollarse
exitosamente.

Tomaselli, G. Establecer las Análisis Se obtienen un Se analizaron diferentes

P., Acuña, C. diferencias y mediante conjunto de tips o propuestas de
J., Estayno, semejanzas entre investigación buenas prácticas: desarrollo ágil, con el
M., & las diferentes de  Definición Clara objetivo de establecer
Lenkovich, propuestas de recopilación de “Hecho”. las diferencias y
C. (s.f.). () desarrollo ágil, y bibliográfica.  Ubicación Física semejanzas entre las
que en conjunto de los Equipos. mismas, y que en
permitan definir  Definición de conjunto permitan
una guía uniforme Reglas. definir una guía
en métodos,  Gestión Visual de uniforme en métodos,
artefactos, Tareas. artefactos, actividades y
actividades y  Utilización de roles que caracterizan
roles que Métricas un proceso de
caracterizan un desarrollo ágil.
proceso de
desarrollo ágil.

13
Autor y año Objetivo Método Resultado Conclusión
Palacio y Características y Aplicación de Desarrollo de Neutralidad y sencillez
Ruata, beneficios metodologías software. en la formulación del
(2009) aportados por agiles. proyecto.
SCRUM.
Hicks y Mejorar la Metodología Aplicación de la Permite un aumento en
Foster, dinámica del SCRUM. metodología, la productividad,
(2010) grupo de mediante la gracias a la mejora
investigación de realización de continua en la
trabajo. reuniones diarias comunicación de los
entre estudiantes, grupos.
tutores y grupos de
investigación de
doctorado.
Orientación a
alcanzar resultados
esperados.
Sutherland y Gestión de Metodología Agilidad en los Los principios ágiles
Hegarty, organizaciones SCRUM procesos pueden funcionar como
(2009) sin fines de lucro, organizacionales. un poderoso agente de
como en el cambio a nivel
caso de grupos organizacional.
de iglesias
norteamericanas.
Schild, Curso sobre Adaptación de Elaboración de Mejoramiento en la
Walter y desarrollo de metodología productos tangibles lo comunicación de
Masuch, videojuegos. SCRUM cual brindaba una Equipos pequeños y
(2010) experiencia flexibles.
Relevante para el Aumento en la
futuro laboral de los responsabilidad de los
estudiantes. estudiantes
Fuente: autores, a partir de la literatura revisada.

4.2 MARCO CONCEPTUAL

4.2.1 EVOLUCIÓN DEL CONCEPTO GERENCIA DE PROYECTOS

Desde tiempos remotos las empresas han entendido la importancia de realizar sus
trabajos mediante el uso de proyectos esto, les ha ayudado a tener un mejor
control sobre cada una de las actividades realizadas. Este modelo de trabajo les
ha permitido sacar ventaja sobre otras organizaciones mediante la utilización de
metodologías que vuelvan más eficaces sus procesos. La evolución de la gerencia
de proyectos se remonta desde los primeros trabajos realizados por culturas
antiguas, las cuales trabajaban en equipos interdisciplinarios para diferentes tareas
propuestas y así alcanzar los objetivos que se habían trazado.
A continuación se presenta de manera cronológica los cambios que ha tenido el
concepto de gerencia de proyectos el cual se ha venido modificando desde su
primera versión del PMBOK en el año 1996 hasta la versión actual. En la tabla 2
se pueden observar los cambios que se han dado en cada una de sus ediciones.

14
 Tabla 2. Evolución del Concepto Gerencia de Proyectos

AUTOR Y AÑO DESCRIPCIÓN DE MEJORAS E INNOVACIÓN

PMBOK, Edición 1, 1987 La gestión de proyectos es la aplicación de conocimientos,
habilidades, herramientas y técnicas
para proyectar las actividades con el fin de cumplir o superar las
necesidades y expectativas de los interesados
de un proyecto.
La primera edición del PMBOK fue publicada en 1987, era el
resultado de los talleres iniciados a principios de los 80s pero el PMI.
En paralelo fue desarrollado un código de ética y pautas para la
acreditación de los centros de entrenamiento y certificación de
individuos.

PMBOK, Edición 2, 1996 Una segunda versión del PMBOK fue publicada entre 1996 y 2000,
- 2000 basado en los comentarios recibidos de parte de los miembros. El
PMBOK fue reconocido como estándar por el American Nartional
Standart Institute (ANSI) en 1998, y más adelante por el instituto de
los ingenieros electrónicos y eléctricos (IEEE).

PMBOK, Edición 3, 2004 La tercera versión de la guía de PMBOK fue publicada en 2004, con
mejoras importantes en la estructura del documento, adiciones a los
procesos, términos y dominios del programa y de portafolios.
PMBOK, Edición 4, 2008 La cuarta edición que fue publicada en 2008, con mejoras generales
en toda la guía. Entre las principales diferencias con la tercera edición
descritas por Armando Peralta (2008) están:
Los nombres de proceso en formato verbo-sustantivo
Enfoque estándar para explicar los factores ambientales de la
empresa y los activos de los procesos de la organización.

Enfoque estándar para explicar:

Cambios solicitados
Acciones preventivas
Acciones correctivas
Reparación de defecto 0073
Disminución de procesos de 44 a 42
Se efectuó una distinción entre el plan para la dirección del proyecto y
los documentos del proyecto
Se eliminan diagramas de flujo de procesos que estaban al inicio de
cada área de conocimiento
Se crea un flujo de datos para cada uno de los 42 procesos
Se incorpora anexo que aborda las habilidades interpersonales
PMBOK, Edición 5, 2012 La quinta versión del PMBOK fue publicada en el año 2012 e
incorporo los siguientes cambios con respecto a la cuarta versión:
Nuevas tendencias en la parte introductoria
Cambio en el nombre de un proceso y reordenamiento de entradas,
T&T y salidas, más diferencia en elementos (3,2,-2)
Contenido más amplio en un 15%, en solo 4% de incremento de
elementos
Cambios en la forma de ver los documentos de salida

Fuente: Los autores a partir del PMBOK en cada versión.

15
4.2.2 EVOLUCIÓN ESTANDAR DE PROYECTOS

Los proyectos han existido a lo largo de la historia, desde épocas muy antiguas el
hombre ha buscado planificar la realización de las cosas a través de diferentes
metodologías que le permitan ser más eficiente en los procesos. En la tabla 3 se
muestra como ha sido la evolución estándar de los proyectos hasta el día de hoy.

Tabla 3. Evolución Estándar de Proyectos

AUTOR Y AÑO CONCEPTO

1917. Desarrollo del Henry Gantt, es muy bien conocido por crear una gráfica de
Diagrama de Gantt por calendarización que lleva su propio nombre, el Diagrama de Gantt. Esta
Henry Gantt (1861- fue una idea radical y una innovación de importancia para todo el
1919) mundo en la década de 1920. Uno de sus primeros usos fue en el
proyecto Hoover Dam iniciado en 1931.
1956. Se forma la Los primeros profesionales de la administración de proyectos y de las
American Association especialidades asociadas de planificación y calendarización; estimación
of Cost Enginers de costos, costos y calendarización formaron la AACE en 1956.
(ahora AACE
International)
1957. El método de Dupont Corporation creó el CPM que es una técnica utilizada para
ruta crítica o Critical predecir la duración de un proyecto al analizar cuáles secuencias de
Path Method (CPM) actividades tienen la menor cantidad de flexibilidad dentro del
inventado por Dupont calendario. Dupont lo diseñó para abordar los procesos complejos de
Corporation cierre de plantas químicas para actividades de mantenimiento, y una
vez que éste concluyera reiniciar las operaciones.
1958. La Armada de PERT es un método que permite analizar las tareas involucradas en la
los Estados Unidos realización de un proyecto, especialmente el tiempo necesario para
inventa la Técnica de completar cada tarea e identificar el tiempo mínimo requerido para
Revisión y Evaluación concluir el proyecto total.
de Programas
(Program Evaluation
and Review Technique
o PERT), utilizada
para el Proyecto.
1962.El Departamento La WBS es una estructura exhaustiva representada por un árbol
de Defensa de los jerárquico de entregables y tareas que se necesitan llevar a cabo para
Estados Unidos poder completar el proyecto. Más tarde adoptada por el sector privado,
ordena aplicar la la WBS se mantiene como una de las herramientas más comunes y
Estructura de efectivas dentro de la administración de proyectos.
Desglose de Trabajo
(Work Breakdown
Structure, WBS)
1965. Se funda la IPMA fue la primera asociación de administración de proyectos en el
International Project mundo. Comenzó en Viena, Austria por un grupo a manera de un foro
Management de project managers para generar redes de trabajo y compartir
Association (IPMA) información.
1969.- Nace en los Cinco voluntarios fundaron el PMI® como una organización profesional
Estados Unidos el sin fines de lucro dedicada a contribuir con el avance de la práctica,
Project Management ciencia y profesión de administración de proyectos. La Mancomunidad
Institute (PMI®) de Pensilvania, E.E.U.U. publicó artículos de incorporación del PMI® en
1969, lo cual significó su inicio oficial.

16
 AUTOR Y AÑO CONCEPTO
1986. Se nombra a SCRUM es un modelo de desarrollo ágil de software fundamentado en
SCRUM como un el trabajo de múltiples equipos pequeños de una forma intensiva e
nuevo estilo de independiente. Aunque SCRUM fue pretendido para la dirección de
administración de proyectos de software, también puede utilizarse para ejecutar equipos
proyectos de mantenimiento de software o como un proyecto general y un
enfoque de gestión de programa.
1987. Se publica por El PMBOK® surge inicialmente como un reporte o intento por
primera vez la Guía de documentar y homologar las prácticas e información de administración
los Fundamentos para de proyectos aceptadas. Su primera edición fue publicada en 1996,
la Dirección de seguida por otra en el 2000, la siguiente en el 2004 y la cuarta edición
Proyectos (PMBOK®) en el 2008. Este cuerpo de conocimientos es referencia primordial para
por el PMI® todos los vinculados al mundo de los proyectos actualmente y se ha
convertido en un estándar global para la industria.
1989.- Se desarrolla el La Agencia Central de Informática y Telecomunicaciones del Gobierno
Método de Desarrollo del Reino Unido, publicó Projects IN Controlled Environments
PRINCE a partir de (PRINCE) transformándolo en el estándar para todos los proyectos de
PROMPTII sistemas de información del gobierno.
1998.- El PMBOK® se El Instituto Estadounidense de Estándares Nacionales (American
convierte en un National Standards Institute, ANSI) reconoció al PMBOK® como un
Estándar ANSI estándar. Poco después en ese mismo año El Instituto de Ingenieros
Electrónicos y Eléctricos (IEEE) hace lo propio.
2008.- El PMI® lanza La cuarta edición continúa la tradición de excelencia del PMI® en
la 4° edición del materia de administración de proyectos con un estándar que es más
PMBOK® fácil de entender y poner en práctica, con mejora en su consistencia y
mayor claridad. Esta edición muestra dos nuevos procesos que no
habían aparecido en versiones anteriores.
2009.- Revisión a Bajo el nombre de PRINCE2® 2009: Refresh, en el verano de 2009 la
fondo de PRINCE2® Oficina de Comercio del Gobierno hizo el método más simple y
por la Oficina de fácilmente personalizable, atendiendo a una petición común de los
Comercio del usuarios.
Gobierno de Reino
Unido
2011.- Aparición de la Con esto el Project Management Institute demostró que no está
nueva credencial del cerrado a las metodologías ágiles, únicamente a favor de los marcos
PMI® Agile Certified rígidos donde aunque siempre presentes, los procesos de cambio no
Practitioner son deseados, porque pueden implicar la corrupción del alcance del
proyecto.

Fuente: Tomada de Duncan Haughey, 2012

4.2.3 EVOLUCIÓN DEL ESTANDAR SCRUM

A partir del concepto de estandarización de proyectos y del planteamiento de las

metodologías ágiles, se genera la necesidad de un estándar especializado para los
proyectos de informática, específicamente para el desarrollo de software, Los
autores de SCRUM GUIDE Ken Schwaber y Jeff Sutherland, son en realidad los
inventores del proceso ágil de desarrollo de software y a partir de esta primera
fuente comienza la evolución del estándar Scrum, en la tabla 4 se puede evidenciar
este proceso a través de la historia.

17
 Tabla 4. Evolución Estándar SCRUM

AUTOR Y AÑO CONCEPTO

Ken Schwaber y Jeff La primera fuente que se considera para llevar a cabo este estudio es
Sutherland desarrollada y mantenida por los autores Ken Schwaber y Jeff
Sutherland, quienes son en realidad los inventores del proceso ágil de
desarrollo de software conocido como SCRUM. En su obra SCRUM
GUIDE, plasman los conceptos principales y fundamentales de la
metodología en cuestión, es decir lo que no debería cambiar según se
adapte el modelo a las distintas realidades.
Hundermark, P. (11 de En febrero de 2001 diecisiete expertos en metodologías “livianas” se
2009). Un mejor encontraron para discutir y tratar de llegar a una definición en común
SCRUM de las maneras de trabajo que estaban utilizando. Entre ellos se
encontraban Jeff Sutherland y Ken Schwaber, fundadores de Scrum,
junto a Mike Beedle, quien trabajó en desarrollar los patrones iniciales
y en la redacción del primer libro sobre Scrum. Este grupo se
autodenominó “The Agile Alliance” (la Alianza Ágil) y definió de común
acuerdo el Manifiesto para el Desarrollo Ágil de Software.
Acuña, K. B. (2009). Según otro artículo publicado por Ailin Orjuela Duarte y Mauricio
Seleccion de Rojas titulado “Las Metodologías de Desarrollo Ágil como una
metodologias de Oportunidad para la Ingeniería de Software Educativo” fue realizada
desarrollo para otra reunión en marzo de 2001, la cual fue convocada por Kent Beck
aplicaciones web en la donde se acuñó el término “Métodos Ágiles” para definir a los
facultad de informatica métodos que estaban surgiendo como alternativa a las metodologías
de la Universidad de formales a las que se consideraba “pesada” y rígida por su carácter
Cienfuegos normativo y fuerte dependencia de planificaciones detalladas previas
al desarrollo. Los integrantes de esta reunión resumieron los
principios sobre los que se basan los métodos alternativos en cuatro
postulados, lo que ha quedado denominado como Manifiesto Ágil.
Plantea además este artículo que las metodologías de desarrollo ágil
son más orientadas a procesos de pocas semanas y con bajos
niveles de formalización en la documentación requerida, es decir,
proyectos pequeños.
Hundermark, P. (11 de El Manifiesto Ágil y sus doce principios han permanecido incólumes
2009). Un mejor durante ya diez años. Continúan siendo hoy en día la mejor manera
SCRUM de juzgar si un método de trabajo es o no realmente ágil. La mayor
crítica que ha recibido se debe al sesgo que presenta hacia el
desarrollo de software, dado que los métodos ágiles pueden aplicarse
en muchos más campos.
Canós José H., L. P. Realizando un análisis histórico del termino “Metodologías Ágiles” se
(2010) Metodologias puede decir que estos términos empiezan a emplearse para
ágiles en el desarrolo caracterizar aquellos métodos de trabajo luego de una reunión
de software celebrada en Utah-EEUU en febrero de 2001, se dice que fue en esa
reunión donde un grupo de 17 expertos esbozaron los valores y
principios que deberían permitir a los equipos desarrollar software
rápidamente y respondiendo a los cambios que puedan surgir a lo
largo de los proyectos.

Fuente: Autores, a partir de la literatura revisada.

18
4.3 MARCO TEORICO

La estructura del marco teórico del presente trabajo, está conformada por las
variables de investigación definidas, para dar respuesta al objetivo general y a la
variable dependiente establecida. En este sentido las variables independientes
definidas son: i) Product Backlog, ii) Planificación de SPRINT, iii) SPRINT
Backlog, iv) Burndown del SPRINT, v) SPRINT, vi) Incremento de Producto, vii)
Burndown de Producto, viii) Backlog de Impedimentos, ix) Retrospectiva, y estas a
su vez con sus respectivas covariables i) Descripción, ii) Estimado, iii) Emergente,
iv) Priorizado, v) Identificador de Funcionalidad, vi) Ordenación, vi) Resumen, vii)
Participantes, viii) Duración, ix) Lista de Tareas, x) Responsable/Voluntario, xi)
Estado de la tarea, xii) Tiempo estimado.

4.3.1 ROLES DE LA METODOLOGIA SCRUM

Un aspecto importante en la metodología Scrum son los roles en el equipo, que

intervienen en su desarrollo y son los siguientes:

ROL 1: Product Owner (PO)

ROL 2: Team (Equipo de Trabajo)
ROL 3: Scrum Master

4.3.2 ETAPAS DE LA METODOLOGÍA SCRUM

La metodología SCRUM funciona bajo la realización de nueve etapas, las cuales

operan de manera sistemática con la opción de poder obtener entregables luego de
la finalización de cada sprint. Esta metodología ágil, permite tener flexibilidad en la
realización de un proyecto, ya que se pueden realizar cambios de mejora
acordados en las reuniones establecidas por cada uno de los miembros del equipo.
En la Figura 1. Se observan los roles, artefactos y eventos principales utilizados en
el proceso de implementación de la metodología SCRUM.

Figura 1. Roles, artefactos y eventos principales de SCRUM (Pete

Deemer,2009)

19
A continuación se presentan cada una de las etapas utilizadas en un proyecto que
adopta la metodología SCRUM:

ETAPA 1: Product Backlog (Pila o Lista de Producto)

ETAPA 2: Planificación de SPRINT
ETAPA 3: SPRINT Backlog (Pila o Lista de SPRINT)
ETAPA 4: Burndown del SPRINT
ETAPA 5: SPRINT
ETAPA 6: Incremento de Producto
ETAPA 7: Burndown de Release o Producto
ETAPA 8: Backlog de Impedimentos
ETAPA 9: Retrospectiva

Adicional a esto existen técnicas como PERT y CPM, para la planificación de los
proyectos, que permiten realizar una evaluación más eficiente, determinar los
elementos críticos en las diferentes etapas y la duración del proyecto por
actividades.

En la literatura se pueden encontrar diferentes autores los cuales han realizado

aportes significativos para entender el porqué de cada etapa y su uso dentro de un
proyecto, en algunos casos se ha observado que todos no le dan la misma
importancia y uso a cada una de las etapas, omitiéndolas y haciendo uso de otras.
En las tablas 5 y 6 se puede observar la relación entre cada uno de los autores y la
importancia que han dado a las etapas de la metodología. En la tabla 5 se
encuentran especificadas las etapas principales y la frecuencia con la que son
mencionadas por los diferentes autores de la bibliografía especializada. En la tabla
6 se listan los subprocesos de cinco etapas principales, comunes entre los
diferentes autores, donde se puede observar de manera detallada las actividades
que los conforman.

20
 Tabla 5. Autores vs Etapas de SCRUM (Variables)

AUTOR/AÑO ETAPA 1 ETAPA 2 ETAPA 3 ETAPA 4 ETAPA 5 ETAPA 6 ETAPA 7 ETAPA 8 ETAPA 9
Product Planificación SPRINT Burndown SPRINT Incremento Burndown Backlog de Retrospectiva
Backlog de SPRINT Backlog del Sprint de Producto de Release Impedimentos
(Pila o (Pila o Lista o Producto
Lista de de SPRINT)
Producto
Pete Deemer, G. B. X X X X X X
(2012). Scrum
Primer. Una
introducción básica a
la teoría y práctica
de Scrum
Juan Palacio, C. R. X X X
(2011). Scrum
Manager: Gestión de
Proyectos.

Ken Schwaber, J. S. X X X
(2010). The Scrum
Guide.

Hundermark, P. (11 X X X X X
de 2009). Un mejor
SCRUM

21
 Tabla 6. Autores vs Etapas de SCRUM (Covariables)
AUTOR/AÑO ETAPA 1 Product Backlog ETAPA 2 ETAPA 3 ETAPA 4 ETAPA 6 ETAPA 7 ETAPA 8 ETAPA 9
Planificación de SPRINT SPRINT Backlog Burndown del Sprint / ETAPA 5 Incremento Burndown Backlog de Retrospectiva
SPRINT de de Impedimentos
Producto Release o
Producto

IDENTIFICADOR LISTA ESTADO

DESCRIPCION RESPONSABLE/ TIEMPO
ESTIMADO EMERGENTE PRIORIZADO DE ORDENACION RESUMEN PARTICIPANTES DURACION DE DE LA RESUMEN PARTICIPANTES DURACION
/DETALLADO VOLUNTARIO ESTIMADO
FUNCIONALIDAD TAREAS TAREA

Pete X X X X X X X X X X X X X
Deemer, G.
B. (2012).
Scrum
Primer. Una
introducción
básica a la
teoría y
práctica de
Scrum
Juan Palacio, X X X X X X X X
C. R. (2011).
Scrum
Manager:
Gestión de
Proyectos.

Ken X X X X X
Schwaber, J.
S. (2010).
The Scrum
Guide.

Hundermark, X X X X X X
P. (11 de
2009). Un
mejor
SCRUM

22
4.3.3 CERTIFICACION EN SCRUM Y ENTIDADES QUE LA OFRECEN:

Actualmente la certificación en Scrum más conocida es la de Scrum Master

(CSM). El certificado originalmente era emitido directamente por Ken Schwaber
durante 2002 y 2003, ya en 2004, Ken pasó a formar la Scrum Alliance y continuó
desde allí dictando los cursos de certificación.

Scrum Alliance:

Uno de los organismos más antiguos, serios y respetados, con la mayor

reputación en el mercado que brinda las siguientes certificaciones:

- Scrum Master Certificado (CSM)

- Propietario de Producto (CPO)
- Desarrollador Scrum (CSD)

Antes de 2012, los que asistían a un curso oficial de la Scrum Alliance recibían
automáticamente el certificado de CSM, en algunos casos sin evaluación o
examen y en otros con trabajos prácticos. Ante muchas críticas, la Alianza Scrum
cambió el proceso de certificación en la primera parte de 2012 y los candidatos
actualmente están obligados a pasar por un proceso de tres etapas para obtener
el certificado de CSM las cuales incluyen, familiarizarse con los conceptos básicos
de Scrum, asistir a un curso de CSM y obtener su certificación CSM después de
completar el curso y por ultimo pasar una evaluación CSM.

A su vez, se ofrecen dos certificaciones para aquellos que requieran

especializarse:

- Profesional Certificado en Scrum (CSP)

- Coach de Scrum (CSC)

Para obtener la certificación de Scrum Master, se debe realizar un curso con un

profesor certificado por Scrum Alliance (Certified Scrum Trainer) y luego hacer un
examen que se puede realizar desde la casa. El examen de profesional de Scrum
(CSP), es bastante complejo y debe rendirse en un centro certificado, lo cual
brinda mayor valor a quien lo obtiene y es comparable al examen de Practicante
Ágil de PMP. Para mantener la certificación, esta debe ser renovada cada dos
años. (Erichbuhler, 2014)

Organización Scrum (Scrum.org):

En el año 2009, Ken Schwaber se retiró de la Scrum Alliance y creó la Scrum.org

ofreciendo el curso de Professional Scrum Máster, entre otros. La Scrum.org
ofrece los certificados de:

23
- Scrum Master Profesional 1 y 2 (PSM I, PSM II)
- Propietario de Producto Profesional 1 y 2 (PSPO I, PSPO II)
- Desarrollador Profesional 1 (PSD I)

(Figuerola, 2013)

PMI-ACP (pmi.org):

El Instituto de gestión de proyectos, ofrece la certificación de Practicante Ágil

luego de llevar adelante un período de prueba durante 2011. Ellos cuentan con
una comunidad de práctica de Ágil y recomiendan decenas de libros para la
preparación del examen (muchos de los cuales son los mismos que sugiere Scrum
Alliance) y también hay ediciones específicas que se centran en la preparación del
examen. El nivel y preguntas son comparables al de Profesional Certificado de
Scrum Alliance (CSP). (Erichbuhler, 2014)

5 METODOLOGÍA

La investigación tiene un enfoque cuantitativo de tipo descriptivo transversal. La

metodología utilizada para alcanzar los objetivos específicos, partió del diseño de
tablas que recogen la información de la literatura especializada consultada desde
el punto de vista de autor, metodología, resultados y conclusiones. Anexo 1. Para
generar la base de datos con la literatura especializada, se realizó una recolección
de información mediante búsqueda en bases de datos especializadas, artículos
científicos y conferencias realizadas, de la cual se seleccionó la más relevante.
Una vez recopilada la información, se realizó el análisis de esta, considerando y
seleccionando los diferentes criterios para la implementación del estándar SCRUM
en el campo de la informática para el desarrollo de proyectos. Estos criterios se
seleccionaron con base en el historial literario, teniendo en cuenta las
metodologías utilizadas por los diferentes autores. Posterior a la selección de los
criterios, se procedió a redactar la monografía con el análisis de la información
recopilada.

6 ANÁLISIS

En general los proyectos de gestión, siguen un ciclo de vida compuesto por 5

fases o etapas clásicas, determinados por los grupos de procesos que son, inicio,
planificación, ejecución, monitoreo y control, y cierre, estas etapas, corresponden
con las etapas del ciclo de vida de la metodología SCRUM y se relacionan de la
siguiente manera (Tabla 7):

24
 Tabla 7. Relación entre ciclo de vida de un proyecto y ciclo de vida de
SCRUM

ETAPAS CICLO DE ETAPAS CICLO DE

VIDA PROYECTO VIDA SCRUM DESCRIPCIÓN
(PROCESOS) (PROCESOS)

Es una lista priorizada de todo lo que podría ser

Product Backlog (Pila de
INICIO necesario en el producto. Los requisitos para el producto
Producto)
están listados en el Product Backlog.

Jornada de trabajo previa al inicio de cada sprint en la

Planificación del Sprint que se determina cuál va a ser el trabajo y los objetivos
que se deben conseguir en la iteración.

PLANIFICACIÓN Es una lista de tareas para convertir el Product Backlog a

un Sprint, en un incremento del producto potencialmente
Sprint Backlog (Pila de
entregable. Se compone de las tareas que el equipo
Sprint)
realiza para convertir los elementos del Product Backlog
en un incremento.

Son iteraciones de 1 a 4 semanas que se van

sucediendo una detrás de otra. Es de duración fija,
Sprint
EJECUCIÓN termina en una fecha específica aunque no se haya
finalizado el trabajo y nunca se alarga. Se limita en
tiempo.

Gráfico de tareas que ayuda al equipo en la

Burndown del Sprint monitorización del progreso y es el indicador principal,
que informará sobre las posibilidades de alcanzar los
compromisos al finalizar el sprint.

Burndown de Release o Mide el ritmo de entrega de funcionalidades testeadas a

MONITOREO Y
de Producto lo largo del tiempo. Este ritmo es conocido como la
CONTROL velocidad del equipo.
El backlog de impedimentos es la lista de situaciones
que están impidiendo que el equipo progrese. Estas son
Backlog de
situaciones que el Scrum Master debe quitar del camino
Impedimentos
para ayudar a que el equipo trabaje mejor.

El incremento es la parte de producto producida en un

Incremento de Producto sprint y tiene como característica que está
completamente terminada y operativa, en condiciones de
ser entregada al cliente final.

CIERRE La retrospectiva es la última reunión del sprint. Sigue

inmediatamente después de la revisión y nunca debe ser
omitida.
Mientras que la revisión está centrada en el producto, la
Retrospectiva
retrospectiva se encuentra enfocada en el proceso—la
manera en la que el equipo Scrum trabaja de manera
conjunta, incluyendo habilidades técnicas, prácticas y
herramientas de desarrollo.
Fuente: Autores con base en PMBOK

25
 7 CONCLUSIONES

Se generó una base de datos digital con la literatura especializada, sobre los
criterios para implementar el estándar SCRUM como marco de trabajo para el
desarrollo de proyectos. La literatura fue revisada y seleccionada, donde se obtuvo
la información más relevante para la implementación de proyectos de software por
medio de una metodología ágil y efectiva, ya que permite cumplir con los objetivos
del proyecto, sin que se vea afectada la planificación del alcance, tiempo y costo
de la entrega.

Al revisar y analizar la literatura especializada, se concluye que una organización

que decida implementar el estándar SCRUM, reducirá el porcentaje de sus
proyectos fallidos y elevará la satisfacción del usuario final. Para incorporarla, se
debe estar en constante negociación con el cliente, el cual recibirá entregas
parciales según sus requerimientos y así podrá efectuar cambios sobre estos si lo
desea.

A partir de este trabajo, donde se determinan los criterios para la implementación

del estándar SCRUM, las organizaciones podrán dar valor al producto que
ofrecen, ya que el seguimiento de los proyectos se realiza por medio de una
negociación entre todos los interesados (stakeholders), los cuales podrán expresar
su satisfacción o inconformidad, y se podrán realizar cambios a tiempo, sin afectar
el éxito del proyecto.

Otro beneficio de la implementación de la metodología SCRUM consiste en la

posibilidad de tener un producto que se puede introducir al mercado antes que la
competencia, al tener sus características principales en funcionamiento sin estar
100% finalizado.

Una desventaja del uso de esta metodología ágil, es que presupone que el cliente
no exige ni necesita toda la documentación que manejan actualmente las
empresas y la que requieren las diferentes normativas nacionales o
internacionales.

26
 Anexo 1.

Tabla 1. Tabla de Antecedentes

Autor y año Objetivo Método Resultado Conclusión

Fuente: Autores

Tabla 2. Tabla de Evolución del Concepto Gerencia de Proyectos

AUTOR Y AÑO CONCEPTO

Fuente: Autores

Tabla 3. Tabla de Evolución Estándar de Proyectos

AUTOR Y AÑO CONCEPTO

Fuente: Autores

Tabla 4. Tabla de evolución estándar SCRUM

AUTOR Y AÑO CONCEPTO

Fuente: Autores

27
 Tabla 5. Tabla de Autores vs Etapas de SCRUM (Variables)

AUTOR/AÑO ETAPA 1 ETAPA 2 ETAPA 3 ETAPA 4 ETAPA 5 ETAPA 6 ETAPA 7 ETAPA 8 ETAPA 9
Product Planificación SPRINT Burndown SPRINT Incremento Burndown Backlog de Retrospectiva
Backlog de SPRINT Backlog del Sprint de Producto de Release Impedimentos
(Pila o (Pila o o Producto
Lista de Lista de
Producto SPRINT)

Fuente: Autores

Tabla 6. Tabla de Autores vs Etapas de SCRUM (Covariables)

AUTO Etapa 1 Product Backlog Etapa 2 Etapa 3 Etapa 4 ETAP ETAP ETAPA ETAPA
R/AÑO Planificación de Sprint Sprint Backlog Burndown del Sprint / A6 A7 8 9
Etapa 5 Incre Burn Backlo Retros
Sprint mento down g de pectiva
de de Impedi
Produ Relea mentos
cto se o
Prod
ucto
descri esti emer priori identifi orden resu partici dura list respon est tiem resu partici dura
pción mad gente zado cador ación men pantes ción a sable/ ado po men pantes ción
/detall o de de volunt de esti
ado funcion tar ario la mad
alidad ea tar o
s ea

Fuente: Autores

Tabla 7. Relación entre ciclo de vida de un proyecto y ciclo de vida de

SCRUM

ETAPAS CICLO DE ETAPAS CICLO DE

VIDA PROYECTO VIDA SCRUM DESCRIPCIÓN
(PROCESOS) (PROCESOS)

Fuente: Autores

28
 8 BIBLIOGRAFIA

Acuña, K. B. (2009). Seleccion de metodologias de desarrollo para aplicaciones web en la facultad

de informatica de la universidad de cienfuegos. Obtenido de
www.eumed/libros/2009c/584

Duncan Haughey, P. (13 de Julio de 2012). Manual de Administracion de Proyectos. Obtenido de

http://www.liderdeproyecto.com/manual/breve_historia_sobre_la_administracion_de_pr
oyectos.html

Erichbuhler. (5 de 2 de 2014). 7 lugares donde obtener tu certificación Agile/Scrum. Obtenido de

http://agilib.org/2014/02/05/7-lugares-donde-obtener-tu-certificacion-agilescrum/

Figuerola, N. (2013). Certificaciones Scrum Master: cuál es la mejor? Obtenido de

http://articulosit.files.wordpress.com/2013/10/scrum-master-certificaciones.pdf

Haughey, D. (2012). Lider de proyecto. Breve historia sobre la administración de proyectos:

http://www.liderdeproyecto.com/manual/breve_historia_sobre_la_administracion_de_pr
oyectoshtml

Hundermark, P. (11 de 2009). Un mejor SCRUM - Un conjunto no oficial de consejos e ideas sobre
cómo implementar Scrum. Obtenido de http://www.scrumsense.com/wp-
content/uploads/2012/03/Un-mejor-Scrum-2.pdf

Hundermark, P. (2011). Un mejor Scrum.

Mohamed, N. (27 de Octubre de 2011). Presentación de la Metodología SCRUM: Nicolás Mohamed

(BogoDev 27 de octubre 2011) - YouTube. Obtenido de
https://www.youtube.com/watch?v=itGb7uE2GGI

Palacio, J., & Ruata, C. (2011). Scrum Manager Gestión de Proyectos. Safe Creative. Obtenido de
http://www.scrummanager.net/files/sm_proyecto.pdf

Pete Deemer, G. B. (2009). Información Básica de SCRUM (The Scrum Primer). Obtenido de
http://collection.openlibra.com.s3.amazonaws.com/pdf/Informacion_Basica_Scrum.pdf?A
WSAccessKeyId=AKIAIGY5Y2YOT7GYM5UQ&Signature=%2FZh59SDG9GG%2F5jgIZH5eYlve
MLo%3D&Expires=1393999183

Pete Deemer, G. B. (2012). Scrum Primer. Una introducción básica a la teoría y práctica de Scrum.
Versión 2.0. Obtenido de http://www.scrumprimer.org/primers/es_scrumprimer20.pdf

Rodriguez, R. (2011). Tecnicas Gantt, Pert y CPM.

Schwaber, K., & Sutherland, J. (2010). The Scrum Guide.

29