Mejora de La Metodologia Scrum-Martin Casamayor

Universidad de Belgrano
Facultad de Tecnología Informática

Ingeniería en Informática
Tesina de Grado
MEJORA DE LA
Metodología Scrum
Por Martín Alejandro Casamayor

Carrera: 502
Matricula: 9804
Tutora: Paula Angeleri.
Buenos Aires, febrero de 2010
Contacto: martin.casamayor@escarto.com.ar
Firma del alumno

MEJORA DE LA METODOLOGÍA SCRUM Martín A. Casamayor
Resumen
Scrum es el nombre de una metodología ágil de gestión de proyectos formulada en el
año 1989 por Horitaka Takeuchi y Ikujiro Nonaka.
Sobre la base del conocimiento ganado en la carrera de grado acerca de metodologías
de desarrollo de software, la investigación realizada más dos años experiencia personal en su
utilización intensiva, el presente trabajo se propone descubrir y analizar sus puntos débiles, con
el fin de identificar oportunidades de mejora.
Como resultado, se espera ofrecer las empresas y grupos de personas que desean
utilizarla, orientaciones para aplicarla con mayor eficiencia y para resolver mejor los problemas
que enfrentan, minimizando así las probabilidades de fracaso.
1
Índice
RESUMEN ......................................................................................................... 1
ÍNDICE ............................................................................................................... 2
ÍNDICE DE FIGURAS Y TABLAS ..................................................................... 5
1 INTRODUCCIÓN: ........................................................................................ 6
1.1 Planteamiento y contexto del problema y trabajos relacionados .............................. 7
1.2 Objetivo ............................................................................................................................ 8
1.3 Justificación..................................................................................................................... 8
1.4 Delimitaciones ................................................................................................................. 8
2 MARCO TEÓRICO .................................................................................... 10
2.1 Metodología ágil ............................................................................................................ 10

2.1.1 El Manifiesto Ágil ......................................................................................................... 10
2.1.2 Principios: producto, cliente y equipo .......................................................................... 11
2.1.3 Metodología Tradicional versus Metodología Ágil ...................................................... 12
2.2 Scrum ............................................................................................................................. 17

2.2.1 La historia de Scrum.................................................................................................... 17
2.2.2 La metodología ............................................................................................................ 18
2.2.3 Datos generales de Scrum .......................................................................................... 18
2.2.3.1 Las reuniones .................................................................................................. 19
Los elementos ......................................................................................................... 20
2.2.3.2 .............................................................................................................................. 20
2.2.3.3 Los roles o responsabilidades ......................................................................... 20
2.2.3.4 Responsabilidad del producto: El propietario del producto ............................. 20
2.2.3.5 Responsabilidad del desarrollo: El equipo ...................................................... 21
2.2.3.6 Responsabilidad del funcionamiento de Scrum (Scrum Manager) ................. 21
2.2.4 Reglas de Scrum ......................................................................................................... 21
2.2.4.1 Las reglas de Scrum (I): El Sprint Planning Meeting ...................................... 22
2.2.4.2 Las reglas de Scrum (II): Durante el Sprint ..................................................... 23
2.2.4.3 Las reglas de Scrum (III): El Sprint Review Meeting ....................................... 24
2.2.4.4 Las reglas de Scrum (y IV): El Sprint Retrospective Meeting (Reuniones
retrospectivas) ................................................................................................................. 26
2.2.5 Burn Down ................................................................................................................... 29
2.2.6 Herramientas para la gestión de proyectos ................................................................ 30
2.2.7 Modelo de proceso de Scrum actual ........................................................................... 31
3 ANÁLISIS .................................................................................................. 33
2
3.1 Análisis comparativo entre metodologías .................................................................. 33

3.1.1 Scrum versus XP ......................................................................................................... 33
3.2 Inconvenientes de Scrum ............................................................................................. 34

3.2.1 Inconvenientes al utilizar Scrum .................................................................................. 34
3.3 ¿Qué intentamos realizar? ........................................................................................... 36
4 DISEÑO ..................................................................................................... 39
4.1 ¿Cómo saber si Scrum está funcionando? Puntos claves y débiles de la

metodología ............................................................................................................................... 39
4.1.1 La falta de atención a los detalles ............................................................................... 39
4.1.2 Entender y formar el equipo multidisciplinario ............................................................ 40
4.1.3 Crear y mantener un Product Backlog ........................................................................ 41
4.1.4 Recursos humanos no dedicados ............................................................................... 41
4.1.5 Integración de las tareas de soporte y mantenimiento ............................................... 42
4.1.6 Estimación ................................................................................................................... 42
4.1.7 Documentación............................................................................................................ 43
4.1.8 Calidad ........................................................................................................................ 43
4.2 Mejora de la metodología de Scrum ............................................................................ 44

4.2.1 Requisitos .................................................................................................................... 44
4.2.1.1 Ingeniería de Requisitos (IE): .......................................................................... 44
4.2.1.2 En qué podría mejorar Scrum con IE .............................................................. 47
4.2.2 El equipo: ..................................................................................................................... 48
4.2.2.1 El Product Owner ............................................................................................ 48
4.2.2.2 Esfuerzos Individuales..................................................................................... 49
4.2.3 Desarrollo .................................................................................................................... 50
4.2.3.1 Test Driver Development (TDD) ...................................................................... 50
4.2.3.2 Pair Programming............................................................................................ 50
4.2.3.3 Diseño incremental .......................................................................................... 51
4.2.3.4 Integración continua ........................................................................................ 52
4.2.3.5 Propiedad colectiva del código ........................................................................ 52
4.2.3.6 Ambiente de trabajo informativo ...................................................................... 52
4.2.3.7 Estándares de codificación ............................................................................. 53
4.2.3.8 Ritmo sostenido ............................................................................................... 53
4.2.4 Calidad ........................................................................................................................ 54
4.2.4.1 Quality Assurance (QA) ................................................................................... 54
4.2.4.2 Por qué la calidad no es negociable ............................................................... 55
4.2.5 Diagrama de función de Scrum para tareas ............................................................... 56
4.2.6 Nuevas Reglas ............................................................................................................ 57
4.2.6.1 Las reglas de Scrum (VI): Procesos y herramientas de ingeniería de software
57
5 CONCLUSIÓN ........................................................................................... 60
6 GLOSARIO ................................................................................................ 61
3
7 BIBLIOGRAFÍA ......................................................................................... 63
8 ANEXO 1 ................................................................................................... 66
8.1.1 Modelo iterativo e incremental .................................................................................... 66
8.1.1.1 Etapa de inicialización ..................................................................................... 66
8.1.1.2 9.1.2 Etapa de iteración................................................................................... 66
8.1.1.3 Lista de control de proyecto ............................................................................ 67
4
Índice de figuras y tablas
Tabla 2.1.3-1 Metodología ágil vs Metodología Tradicional (José H. Canós P. L.). .............. 13
Tabla 2.1.3-2 Uso de las metodologías ágiles ........................................................................ 14
Gráfico 2.1.3-1 Uso de las metodologías ágiles ..................................................................... 14
Tabla 2.1.3-3 Comparación de metodologías (Schwaber, SCRUM Development Process,
págs. 10-11) ............................................................................................................................ 16
Gráfico 2.2.3-1 El flujo de trabajo en Scrum ........................................................................... 19
Gráfico 2.2.4.1-1 Sprint Planning Meeting .............................................................................. 22
Gráfico 2.2.4.4-1 Ciclo de Scrum ............................................................................................ 28
Gráfico 2.2.5-1 Burn Down detallado ...................................................................................... 29
Gráfico 2.2.5-2 Burn Down ...................................................................................................... 30
Gráfico 2.2.7-1 Proceso actual de Scrum según reglas (Autor M. Casamayor) ..................... 32
Tabla 3.1.1-1 Scrum Vs XP ..................................................................................................... 34
Gráfico 3.3-1 Mejora de productividad de software ................................................................ 37
Gráfico 4.1.6-1 Scrum enfocado a proyectos informáticos - Autor: Martín Casamayor. ........ 56
5
1 Introducción:
En el inicio de todo proyecto informático es necesario averiguar de qué manera van a

ser gestionadas todas las tareas a realizar. Esto es lo que se conoce como gestión de
proyectos de software. Existen numerosas herramientas, métodos y técnicas que ayudan a
lograr una mayor precisión en cuanto a los plazos, costos, esfuerzo y riesgos que puede
implicar la tarea (Garreta, 2003). Este gran número se debe a que no hay una única
metodología que resulte óptima para todos los proyectos, sino que cada proyecto puede
funcionar mejor con una determinada metodología que con otra, ya sea por alcance,
dimensiones del proyecto, por la cantidad de personas involucradas, por el tema de que se
trata, tecnología a utilizar, etc. (Charvat, 2003).
Al optar por una metodología, para llevar a cabo su implementación se requerirá tiempo
y esfuerzo: se hace necesario comprar o conseguir las herramientas adecuadas y además
capacitar al personal. Esto también ocurre –en algunos casos en menor grado–, si ya se está
aplicando una determinada metodología y se decide cambiar por otra. Es por eso que, antes de
decidirse por una metodología es conveniente estudiarla y evaluar si será la más adecuada
para el desarrollo de nuestro proyecto.
Dentro de la gran variedad existente, encontramos metodologías tradicionales
(conocidas como metodologías pesadas por su gran cantidad de documentación) y
metodologías ágiles. Las metodologías ágiles tienen como característica su tendencia a
enfocarse más en el producto final –sin concentrarse tanto en la documentación, el análisis y el
diseño exhaustivo, etc.– para que, de esta forma, el proyecto pueda entrar cuanto antes en la
fase de producción.
La tendencia demuestra que, en general, debido a su nivel de complejidad, al tiempo
necesario para desarrollarlos y a la cantidad de personal requerido, los proyectos pequeños
suelen aplicar metodologías ágiles, mientras que los proyectos de gran envergadura son
tratados con metodologías tradicionales. Entre las metodologías ágiles encontramos la
Metodología Scrum la cual, en la actualidad, es aplicada con mucha frecuencia a la gestión de
proyectos.
Como ocurre con toda metodología o proceso, al aplicar Scrum se descubren
problemas, dificultades con las reglas o dudas acerca de cómo aplicarlas correctamente. En
muchas oportunidades se observa que son los propios equipos los que modifican las reglas,
adaptándolas para utilizarlas mejor o descartando aquéllas que no estiman útiles para un
proyecto en particular (Abrahamsson, 2008) (Rossberg, 2008). Esto no siempre resulta
conveniente ya que, a veces, la intención de mejorar la metodología de un proyecto termina por
generar un problema aún mayor.
Esto llevó a pensar en una nueva forma de aplicarla, agregando a la forma actual de la
Metodología Scrum, reglas y procesos propios de la ingeniería de software, propuesta que se
desarrolla a lo largo del presente trabajo.
6
Por tratarse de una metodología nacida a mediados de la década de los ‘80, existe
sobre el tema una rica bibliografía y abundantes acreditaciones internacionales. Existen
también herramientas informáticas para administrar los proyectos de desarrollo de software que
aplican Scrum. Esto dio lugar al surgimiento de múltiples foros de discusión, en los cuales se
puede obtener información, lo cual contribuye a llevar a Scrum un paso más adelante.
1.1 Planteamiento y contexto del problema y trabajos

relacionados
Scrum es una metodología de gestión de proyectos relativamente reciente. A pesar de

esto, ya son muchos los equipos que la han implementado. Así se hizo conocida como una
metodología valiosa para proyectos pequeños y cambiantes. Su buena reputación en relación
con ese tipo de proyectos contribuyó también a que sus desventajas hayan sido menos
conocidas o analizadas.
La documentación existente acerca de una metodología pocas veces describe
experiencias de aplicación; más escasa aún en este caso, por tratarse de una metodología
joven. Muchas veces no se especifica ni estudian detalladamente sus posibilidades de
aplicación al proyecto que se emprende, al tipo de personal y de cliente que se tiene, o a la
tecnología que se implementará. También suele suceder que, por tratarse de una metodología
ágil, se aplique la regla de priorizar el producto terminado a la documentación, resultando que
la documentación al final del proyecto es escasa o nula, lo cual generará inconvenientes en el
futuro.
Con la experiencia de haber aplicado esta metodología a distintos proyectos de
software, adoptando los roles de desarrollador como de Scrum Master, se hizo evidente que no
existen acerca de ella herramientas y procesos de la ingeniería para el desarrollo, o existen
poca cantidad de experiencias documentadas, que permitan decidir las acciones a tomar ante
sucesos inesperados, cómo detener una tarea a raíz de cambios o cuándo no es necesario o
no conviene hacerlo. Ninguna de estas circunstancias está prevista en la metodología y sólo se
aprenden a partir de la experiencia y de la modificación de algunas de sus reglas o
características.
En la actualidad la cantidad de foros de discusión acerca de temas relacionados con
Scrum se ha incrementado, así como también los trabajos relacionados con el problema de la
documentación, la no existencia de procesos de ingeniería o la forma de utilizar partes de otras
metodologías para cubrir alguna falencia de ésta. Sin embargo, aun cuando toda la información
necesaria está disponible, con frecuencia se recurre a ella cuando el proyecto está en marcha y
enfrenta problemas graves.
7
1.2 Objetivo
Buscar y encontrar alternativas para mejorar la implementación de la Metodología ágil

Scrum, de manera que resulta más eficaz en sus primeras etapas de implementación en un
equipo nuevo.
1.3 Justificación
Las metodologías ágiles son un recurso relativamente nuevo. No fue sino hasta
mediados de la década de los ‘90 cuando Scrum surgió como una metodología ágil para
proyectos de software. Sin embargo, a pesar de ser relativamente nueva, el uso de Scrum ha
crecido significativamente.
Al momento de comenzar a utilizar una metodología ágil, comienzan a surgir
eventualidades que no favorecen al desarrollo del proyecto. En el ámbito del desarrollo
informático se suele decir que, por tratarse de una metodología ágil, hay muchos aspectos en
los cuales las decisiones quedan a criterio de quien la esté implementando. Un ejemplo de esto
es la documentación.
La “libertad” propia de este tipo de metodologías genera muchas veces un resultado
negativo, ya que no existe una solida base sobre la cual referenciarse, lo que conduce a
entregas tardías, con calidad mediocre, disconformidad del cliente y/o del equipo, etc.
Por otra parte, a pesar que en este tipo de metodologías existen reglas, éstas se
pueden aplicar de diferente manera según el proyecto o el equipo de que se trate. Esto no
debería ocurrir, ya que una regla debe ser invariable. Sin embargo, la variación en cuanto a la
forma de aplicación de las reglas se observa constantemente en los diferentes equipos. Estos
son, precisamente, los puntos que llevan a replantear el tema y proponer una solución.
La solución consiste en establecer una base más robusta y sólida, en la cual no existan
ambigüedades ni tal grado de libertad que dé lugar confusión o errores en el equipo.
Asimismo,, se procurará reducir los retrasos, las deficiencias en la calidad y todo otro tipo de
inconvenientes en los desarrollos que aplican Scrum.
Se espera lograr este objetivo por medio de la incorporación a la Metodología Scrum de
buenas prácticas como la Ingeniería de Requisitos de Desarrollo, utilizada por otras
metodologías y teniendo en cuenta otras exigencias de calidad propias de los proyectos de
software.
1.4 Delimitaciones
Las recomendaciones que surgen de este trabajo se basan en la experiencia personal

y en el análisis detenido de las cuestiones planteadas. Sin embargo, no han sido puestas a
prueba debido a que aplicar una metodología requiere de un proyecto adecuado, así como de
tiempo suficiente para adaptar un equipo y para pulir detalles que estas recomendaciones
necesiten, todo lo cual excede el periodo de preparación de una tesina.
8
La última delimitación consiste en la tecnología de codificación a emplear para el

desarrollo del proyecto. En la Metodología Scrum, la programación deberá ser Programación
Orientada a Objetos (POO). Esto se debe a que las tareas pueden ser divididas y fácilmente
reflejadas en código como objetos o métodos específicos.
9
2 Marco Teórico
2.1 Metodología ágil
Para comenzar a hablar de Scrum es necesario definir, en primer lugar, qué es una
metodología ágil y en qué aspectos difiere de una tradicional. Las metodologías tradicionales
se dividen en fases que son, por lo general, Análisis, Diseño, Desarrollo, Implementación
y Mantenimiento.
Las metodologías ágiles, por su parte, se dividen en pequeños proyectos que se van
llevando a cabo en forma incremental. A continuación se presentan las bases y significado de
las metodologías ágiles.
2.1.1 El Manifiesto Ágil
En el año 2001 un grupo pionero en las metodologías ágiles reunió y estableció las
bases para desarrollarlas. Este enunciado se conoce como ”Manifiesto Ágil” (Kent Beck, 2001)
(Larman, Agile and iterative development: a manager's guide, 2004) (Doug Rosenberg, 2005) y
propone:
Dar más importancia a la interacción entre personas, que a los procesos y
herramientas.
Dar más importancia a los productos que funcionan, que a la documentación
extensiva.
Incentivar la colaboración con el cliente, más que la negociación del contrato.
Responder al cambio es mejor que seguir el plan.
Existen también doce principios para el desarrollo ágil de software, redactados por los
mismos autores. Estos son:
La prioridad es satisfacer al cliente mediante tempranas y continuas entregas
de software que le aporte valor.
Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.
Entregar frecuentemente software que funcione desde un par de semanas a un
par de meses, con el menor intervalo de tiempo posible entre entregas.
La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del
proyecto.
Construir el proyecto en torno a individuos motivados. Darles el entorno y el
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
El software que funciona es la principal medida de progreso.
10
Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener constante
armonía.
La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseños surgen de los equipos
organizados que se organizan a sí mismos.
Periódicamente, el equipo reflexiona acerca de cómo ser más eficaces, y ajusta
su conducta en consecuencia.
2.1.2 Principios: producto, cliente y equipo
El principio de metodología ágil también modifica el concepto de lo que se conoce

como producto, cliente y equipo. Otorga prioridades y significados diferentes según los
mencionados doce principios expresados para el desarrollo ágil de software (Castro,
Metodología de Trabajo Ágil y Eficiente: El método Scrum aplicado a la Gestión de Proyectos
en general). Estos son:
Cliente
La mayor prioridad es satisfacer al cliente a través de la entrega temprana y
continua de productos con valor.
Se aceptan requisitos cambiantes, incluso en etapas avanzadas. Esto es una
ventaja competitiva de los procesos ágiles.
Los responsables del negocio y los empleados deben trabajar juntos
diariamente, a lo largo de todo el proyecto.
Producto
El producto que funciona es la principal medida del progreso.
Se entregan productos con frecuencia.
La simplicidad es esencial.
Los procesos ágiles promueven el desarrollo sostenible.
La atención continua a la excelencia técnica y los buenos diseños mejoran la
agilidad.
Equipo
Se construyen proyectos con profesionales motivados.
Se prioriza la comunicación cara a cara.
Las mejores propuestas, requisitos y diseños surgen de los equipos que se
auto-organizan.
Periódicamente, el equipo reflexiona acerca de cómo ser más efectivo.
11
2.1.3 Metodología Tradicional versus Metodología Ágil
Hasta hace poco, la tarea de desarrollo llevaba asociado un marcado énfasis sobre el
control del proceso por medio de una rigurosa definición de roles, actividades y artefactos,
incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el
desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño
(en cuanto a tiempo y recursos), en los cuales, por lo general, se exige un alto grado de
formalidad en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para
muchos de los proyectos actuales, donde el entorno del sistema es muy cambiante, y en los
cuales se exige reducir drásticamente los tiempos de desarrollo, manteniendo una alta calidad.
Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de
tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir de las reglas de las
“buenas prácticas” de la ingeniería del software, asumiendo el riesgo que esto implica. En este
escenario, las metodologías ágiles surgen como una alternativa para llenar ese vacío
metodológico. Por estar especialmente orientadas a proyectos pequeños, las metodologías
ágiles representan una solución a medida para ese entorno, aportando una notable
simplificación que, sin embargo, no renuncia a las prácticas esenciales para asegurar la calidad
del producto.
Las metodologías ágiles son uno de los temas que en la actualidad despiertan gran
interés en la ingeniería de software, y están ganando espacio en la mayoría de las conferencias
y workshops. Su impacto es tan grande que, inclusive, son el tema central de muchas
conferencias internacionales. (Ciencia y Técnica Administrativa). En la comunidad de la
ingeniería del software, se está viendo con frecuencia un debate abierto entre los que siguen
las metodologías tradicionales y aquellos que apoyan las ideas del “manifiesto ágil”.
La mayoría de los ingenieros de software y de los usuarios de estas nuevas prácticas
sienten que las metodologías ágiles tienen un gran futuro por delante en el campo del
desarrollo de software y en el ámbito industrial. Por un lado, para muchos equipos de trabajo
las metodologías tradicionales representan algo muy diferente de la forma de trabajo actual,
considerando las dificultades para introducirlas y la inversión que implican en cuanto a
capacitación y equipos. Por otra parte, las características de los proyectos para los cuales las
metodologías ágiles han sido especialmente pensadas, se ajustan a un amplio rango de
proyectos industriales de desarrollo de software. Precisamente aquellos en los cuales los
equipos de desarrollo son pequeños, con plazos reducidos, requisitos y alcances cambiantes, y
basados en nuevas tecnologías. (José H. Canós P. L.)
¿Se debe a esto que está siendo tan investigada y utilizada por grupos de desarrollo y
gestión de proyectos? Actualmente la gran mayoría de los proyectos de software son proyectos
de pequeños a medianos, con plazos menores de un año para cumplir las etapas de análisis,
diseño, desarrollo e implementación. Además, no se puede comenzar por hacer un análisis de
los requisitos del momento actual porque, por lo general, cambiarán en el transcurso del
12
desarrollo. Los requisitos no sólo cambian de manera rápida, sino que también es muy difícil
definirlos por la cantidad de información de que se dispone en la actualidad (José H. Canós).
A continuación se presenta una tabla comparativa entre ambos tipos de metodología.
Metodología Ágil Metodología Tradicional
En qué se basa Basada en heurísticas Basadas en normas

provenientes de prácticas de provenientes de estándares
producción de código. seguidos por el entorno de
desarrollo
Cambios durante el proyecto Especialmente preparada Cierta resistencia a los cambios.

para los cambios durante el
proyecto
Quién la impone Impuesta internamente (por Impuesta por un tercero.

el propio equipo)
Procesos Procesos menos Procesos muchos más

controlados, más libertad a controlados con numerosas
la hora de aplicar procesos, políticas / normas.
pocos principios.
Tipo de contratos existentes No existen contratos Existe un contrato prefijado.

tradicionales.
Como actúa el cliente en el El cliente es parte del equipo El cliente interactúa con el
proyecto de desarrollo. equipo de desarrollo mediante
reuniones.
El equipo Grupos pequeños (menos de Grupos grandes y

15 integrantes). probablemente distribuidos.
Artefactos Pocos artefactos. Muchos artefactos.
Roles Pocos roles. Muchos roles.
Diseño y arquitectura Menos énfasis en la La arquitectura del software es

arquitectura del software. esencial y se expresa mediante
modelos.
Entregas El cliente ve progresos en El cliente ve solo la versión final.

intervalos cortos de tiempo.
Definición de requisitos Los requisitos pueden Los requisitos se establecen al

cambiar. principio sin poderse cambiar.
Tabla 2.1.3-1 Metodología ágil vs Metodología Tradicional (José H. Canós P. L.).
13
En consecuencia, en líneas generales, una metodología ágil puede resultar muy útil
para corregir requisitos mal formulados, mal definidos o incompletos. Por otra parte, al ser más
libre y no basarse tanto en el cumplimiento de normas, su costo tiende a ser menor.
A continuación se presenta un gráfico sobre la cantidad de proyectos que utilizan
metodologías ágiles. Agile journal (N°1, Marzo-2006 )1.
Tabla 2.1.3-2 Uso de las metodologías ágiles
Gráfico 2.1.3-1 Uso de las metodologías ágiles
En esta encuesta, también se consultó por qué utilizan estas metodologías. Las
respuestas fueron las siguientes:
Para reducir el tiempo de desarrollo: 45%
Para mejorar la calidad: 43%
Para reducir costes: 23%
Para alinear el desarrollo con los objetivos de negocio: 39%
Otras razones: 12%.
¿Y cuál es el ranking de preferencias entre los modelos ágiles? Estos fueron los
resultados:
1. Extreme Programming (28%)
2. FDD (26%)
3. Scrum (20%)
4. Crystal (6%)
1
Encuesta realizada por CM Crossroad en el año 2006 en los Estados Unidos. (CM Crossroad).
14
5. DSDM (4%)
Llegada la hora de elegir una metodología ágil, estas encuestas permiten prever cuáles
son las metodologías que probablemente tendrán mayor soporte en foros de debate y grupos,
así como documentación acerca de casos ocurridos.
Todas estas consideraciones resultan muy valiosas al momento de decidirse por una.
Sin embargo, existen otros aspectos a tener en cuenta.
Cuando se pretende cambiar de una metodología de desarrollo por otra, el costo del
cambio resulta, por lo general, grande. Este costo, expresado en tiempo y dinero, comprende:
Capacitación: Del equipo que va a emplear la metodología, del cliente en caso
de que éste participe en el equipo, y a su vez para informarlo de cómo serán
las entregas de versiones del producto, etc.
Tiempo de adaptación de las personas del equipo.
Tiempo de adaptación del cliente, si es que este pasa a involucrarse
directamente con el equipo de desarrollo.
Sin embargo, los estudios realizados también revelan que, si se utilizan metodologías
tradicionales que implican normas y políticas a cumplir, aunque comenzar a utilizar una
metodología ágil implica un costo inicial mediano, éste tiende a ser bajo a largo plazo, ya que
las metodologías ágiles en general son gratuitas, hay mucho software para implementarlas y
herramientas para aplicarlas que son gratuitos, todo lo cual representa grande ventajas.
A continuación se presenta un cuadro que refleja las diferencias entre Scrum y otro tipo
de metodologías no ágiles.
Comparación de procesos
Cascada Espiral Iterativo Scrum
Procesos Requerido Requerido Requerido Planificación y

definidos acercamiento
Producto final Determinado Determinado Determinada Determinada

durante la durante la durante el durante el
planificación planificación desarrollo desarrollo
Costo del Determinado Variable Determinada Determinada

proyecto durante la parcialmente durante el durante el
planificación desarrollo desarrollo
Fecha de Determinado Variable Determinada Determinada

finalización durante la parcialmente durante el durante el
planificación desarrollo desarrollo
Estudio del En etapa de En la planificación Al final de cada En todo

impacto del planificación principalmente iteración momento
contexto únicamente
15
Cascada Espiral Iterativo Scrum
Flexibilidad y Limitado Limitado Limitado Ilimitado

creatividad del durante las
equipo iteraciones
Transferencia El El entrenamiento es El El equipo

de entrenamiento más importante entrenamiento trabaja en
conocimiento es más para el proyecto es más conjunto
importante para importante para durante el
el proyecto el proyecto proyecto
Probabilidad de Baja Media - Baja Media Alta

éxito
Tabla 2.1.3-3 Comparación de metodologías (Schwaber, SCRUM Development Process, págs. 10-
11)
16
2.2 Scrum
Scrum (Schwaber, 2004) (Ken, 2007) (Ken Schwaber, 2001) (Cohn, 2004) es una
metodología de gestión de proyectos de software iterativa e incremental. Se aplica sobre la
base de reglas propias, que se deben aplicar en todo momento. También incluye dentro del
equipo de desarrollo a un usuario o dueño del proyecto (Product Owner) y a un líder de
proyecto (Scrum Master).
En la metodología se plantean todas las reglas necesarias para saber si se está
gestionando correctamente un proyecto. Sin embargo, no se plantea ninguna práctica ni
proceso de ingeniería de software para aplicarla. Esto se debe a que Scrum no se enfoca en la
gestión de proyectos de una rama específica, sino que puede aplicarse a proyectos de
informática, de electrónica, de construcción de automóviles, etc.
En la actualidad, Scrum resulta exitosa en el desarrollo de proyectos de informática, ya
que plantea reglas claras acerca de cómo gestionarlos y ofrece libertad a la hora de utilizar
prácticas de ingeniería de software. Esto último puede representar tanto una ventaja como una
dificultad. En varias experiencias se ha visto que surgen problemas al momento de decidir
cuáles procesos de la ingeniería de software aplicar, o qué herramientas para el desarrollo de
la aplicación se va a utilizar, ya que Scrum no recomienda ni menciona ninguna en particular.
Esto puede traer como consecuencia que un equipo sin experiencia en una nueva metodología
utilice, tal vez, herramientas y procesos de la ingeniería que no son los más adecuados o, peor
aún, no utilice ninguno.
A continuación se explicará qué es Scrum en la actualidad, y cuáles son sus diferencias
y similitudes con otras metodologías existentes. A partir de estas definiciones, se procurará
encontrar formas de reducir las desventajas que presenta la metodología al momento de iniciar
la gestión de un proyecto informático.
2.2.1 La historia de Scrum
Scrum es una metodología ágil de gestión de software, que ayuda a administrar,

controlar y desarrollar la gestión de un proyecto por medio de un proceso iterativo. Es por esto
que Scrum es una metodología que se aplica en proyectos de toda índole.
Surge en el año 1986 cuando Hirotaka Takaeuchi e Ikijiro Nonaka describieron una
nueva forma que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos
comerciales. El término Scrum proviene del vocabulario del Rugby, y en ella el desarrollo del
producto emerge de una constante interacción de mano en mano, donde los miembros de un
equipo multidisciplinario trabajan en conjunto, desde el principio hasta el final. (Rossberg, Pro
Visual Studio Team System Application Lifecycle Management, 2008)
17
En el año 1993 se aplicó por primera vez Scrum2 en un desarrollo de software y luego,
en el año 1995, se formalizó3.
Desde entonces, miles de proyectos en todo el mundo han utilizado Scrum, tanto en
pequeñas empresas, como en grandes multinacionales.
En la actualidad, Scrum se está utilizando en diferentes tipos de negocio y,
especialmente, en el desarrollo de software. Existen organizaciones, como Scrum Alliance o
Scrum Management, que se encargan de difundir esta metodología en el ámbito de la
Informática.
2.2.2 La metodología
Scrum se basa en reglas para saber si se está aplicando correctamente la gestión del
proyecto. Estas reglas son la guía para poder aplicar y gestionar la metodología de manera
correcta, de manera que nos diga cómo aplicarlas en los proyectos, al realizar las reuniones,
reaccionar a los cambios de requisitos (Schwaber, 2004) (Corral, 2006).
A continuación se presentan datos generales de Scrum. De esta forma se tiene un
concepto más completo de la metodología para poder comprender de mejor manera las reglas
antes mencionadas.
4
2.2.3 Datos generales de Scrum
Las mencionadas reglas –que presentaremos más adelante– sirven para llevar a cabo
el proyecto. Sin embargo, es necesario saber cómo comenzar a gestionar un proyecto con
Scrum.
Antes de presentar las reglas se relevarán los datos generales de Scrum como el
vocabulario propio de la metodología, los roles que se involucran y los puntos básicos que cada
uno de éstos implica. Una vez presentada esta información, se tratará con mayor detalle cada
punto.
2
Jeff Sutherland, John Scumniotales y Jeff McKenna fueron los primeros en concebir, ejecutar y documentar el
desarrollo ágil en proyectos de software en el año 1993.
3
En 1995 Ken Schwaber formalizó el proceso para la industria de desarrollo de software.
4
Otros datos que son útiles, tipos de reuniones, duraciones y reglas dentro de estas. (10)
18
Gráfico 2.2.3-1 El flujo de trabajo en Scrum
Los componentes y conceptos empleados en Scrum son:
2.2.3.1 Las reuniones

Planificación del sprint:
Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál es el
trabajo y los objetivos que se deben cubrir con esa iteración.
Esta reunión genera la “sprint backlog” o lista de tareas que se van a realizar, y en ella
también se determina el “objetivo del sprint”: lema que define la finalidad de negocio que se va
a lograr.
Seguimiento del sprint:
Breve reunión diaria para dar repaso al avance de cada tarea, y al trabajo previsto para
la jornada. Sólo interviene el equipo, y cada miembro responde a tres preguntas:
1. Trabajo realizado desde la reunión anterior.
2. Trabajo que se va a realizar hasta la próxima reunión de seguimiento.
3. Problemas que es necesario resolver para poder realizar el trabajo.
19
Revisión de sprint:
Análisis y revisión del incremento generado. Esta reunión no debe tomarse como un
“acontecimiento especial” sino como la presentación normal de los resultados.
2.2.3.2 Los elementos

Product Backlog: Requisitos del sistema. Se parte de la visión del resultado que se
desea obtener; y evoluciona durante el desarrollo. Es el inventario de características que el
propietario del producto desea obtener, ordenado por orden de prioridad. Es un documento
“vivo”, en constante evolución. Es accesible a todas las personas que intervienen en el
desarrollo. Todos pueden contribuir y aportar sugerencias. El responsable del product backlog
es una única persona y se la denomina: propietario del producto.
Sprint Backlog: Lista de los trabajos que realizará el equipo durante el sprint para
generar el incremento previsto. El equipo asume el compromiso de la ejecución. Las tareas
están asignadas a personas, y tienen estimados el tiempo y los recursos necesarios.
Incremento: Resultado de cada sprint. Se trata de un resultado completamente
terminado y en condiciones de ser utilizado.
2.2.3.3 Los roles o responsabilidades

El grado de funcionamiento de Scrum en la organización depende directamente de
estas tres condiciones:
Características del entorno (organización y proyecto), adecuadas para
desarrollo ágil.
Conocimiento de la metodología de trabajo por parte de todas las personas de
la organización y las personas implicadas por el lado del cliente.
Asignación de responsabilidades:
o Sobre el producto.
o Sobre el desarrollo.
o Sobre el funcionamiento de Scrum
2.2.3.4 Responsabilidad del producto: El propietario del producto

En el proyecto hay una persona –y sólo una– conocedora del entorno de negocio del
cliente y de la visión del producto. Representa a todos los interesados en el producto final y es
el responsable del Product Backlog.
Se le suele denominar “propietario del producto” y es el responsable de obtener el
resultado de mayor valor posible para los usuarios o clientes.
Es responsable de la financiación necesaria para el proyecto, de decidir cómo debe ser
el resultado final, del lanzamiento y del retorno de la inversión.
En desarrollos internos, quien asume este rol puede ser el Product Manager (o el
responsable de marketing).
20
En desarrollos para clientes externos lo más aconsejable es que sea el responsable del
proceso de adquisición del cliente.
2.2.3.5 Responsabilidad del desarrollo: El equipo

Todo el equipo de desarrollo, incluido el propietario del producto conoce la
metodología Scrum, y son los auténticos responsables del resultado.
Es un equipo multidisciplinario, que incluye todas las habilidades necesarias para
generar el resultado.
Se auto-gestiona y auto-organiza, y dispone, dentro de la organización, de atribuciones
suficientes para tomar decisiones sobre cómo realizar su trabajo.
2.2.3.6 Responsabilidad del funcionamiento de Scrum (Scrum Manager)

La organización debe garantizar el funcionamiento de los procesos y metodologías que
emplea, y en este sentido Scrum no es una excepción.
En el modelo de Scrum definido por Jeff Sutherland, esta responsabilidad se garantiza
integrando en el equipo a una persona con el rol de.
Considerando que las realidades de unas y otras empresas pueden ser muy diferentes,
y que siempre que sea posible es mejor optar por adaptar las prácticas de trabajo a la empresa,
y no al revés, en ocasiones puede resultar más aconsejable:
Que en lugar de una persona con la función de “Scrum Master”, sean las
personas y puestos más adecuados en cada organización los que reciban la
capacitación adecuada y asuman las funciones necesarias para cubrir esta
responsabilidad.
Que al compromiso de funcionamiento del proceso se sume también la
dirección de la empresa, con el conocimiento de gestión y desarrollo ágiles, y
facilitando los recursos necesarios.
Scrum Manager designa por tanto, más que el rol, la responsabilidad de
funcionamiento del modelo. Puede ser al nivel del proyecto o al nivel de la organización. En
algunos casos resultará más apropiado un rol exclusivo (tipo Scrum Master), mientras que en
otros puede ser mejor que las responsabilidades de funcionamiento sean asumidas por los
responsables del Departamento de Calidad o Procesos, o del área de Gestión de Proyectos.
2.2.4 Reglas de Scrum
Las reglas de Scrum son claras, simples y fáciles de implementar. En general, se sabe
que si hay un problema con las reglas, hay un problema con la gestión del proyecto. Sin
embargo, el principal problema que suele aparecer es que algunos integrantes no se saben
adaptar a las reglas.
A continuación se resumen las reglas de Scrum.
21
2.2.4.1 Las reglas de Scrum (I): El Sprint Planning Meeting
Product Owner Equipo de Scrum Clientes
Product Backlog
Capacidades del
equipo
Sprint Planning Meeting Metas del Sprint
Condiciones de
negocio Sprint Backlog
Tecnología
Producto actual
Gestión / Management
Gráfico 2.2.4.1-1 Sprint Planning Meeting
La Reunión de Planificación del Sprint (o Sprint planinng meeting) tiene una duración
máxima de 8 horas, divididas en dos partes. La Primera Parte sirve para seleccionar cual será
el Product Backlog y en la Segunda Parte se prepara el Sprint Backlog con el cual se trabajará.
Los asistentes obligatorios son el equipo, incluyendo al Scrum Master y el
Product Owner. Además puede haber otras personas como los usuarios –que
conocen las necesidades– o personas que puedan brindar más información
acerca del negocio o la tecnología. Sin embargo, estas personas deberán
retirarse una vez que proporcionen la información.
El Product Owner debe preparar el Product Backlog antes de la reunión. De
estar ausente el Product Owner, será reemplazado por el Scrum Master.
El objetivo de la primera parte –es decir, de las primeras 4 horas– es que el
Equipo seleccione aquellos elementos del Product Backlog que cree que puede
comprometerse a transformar en un incremento de funcionalidad
potencialmente entregable. El Equipo deberá mostrar este incremento de
funcionalidad al Product Owner y a los involucrados en la Reunión de revisión
de sprint (o Sprint review meeting) al final del Sprint.
22
o El Equipo puede hacer sugerencias, pero la decisión acerca de qué

elementos del Product Backlog pueden formar parte del Sprint es
responsabilidad del Product Owner.
El Equipo es responsable de determinar qué parte del Product Backlog,
seleccionado por el Product Owner para ese Sprint, va a tratar de implementar
durante el mismo.
Limitar el tiempo de la Primera Parte a 4 horas significa que éste es todo el
tiempo disponible para analizar el Product Backlog. Un análisis más profundo
debe ser realizado durante el Sprint. Si el Product Backlog no es muy detallado
y está detallado en un muy alto nivel, es probable que no sea comprendido con
suficiente profundidad durante esta parte de la Reunión de Planificación del
Sprint y que, como consecuencia, el equipo no sea capaz de completar todos
los elementos del Product Backlog que seleccione.
La Segunda Parte del Sprint Planning Meeting ocurre inmediatamente después
de la Primera y durará también 4 horas, como máximo.
Durante la Segunda Parte, el Product Owner debe estar disponible para el
Equipo para fin de responder aquellas dudas que el Equipo pueda tener acerca
del Product Backlog.
Es labor del Equipo actuar solamente en su propio nombre y sin ninguna
dirección externa al mismo, para encontrar durante esta Segunda Parte cómo
transformar la parte seleccionada del Product Backlog en un incremento de
funcionalidad potencialmente entregable. Nadie más tiene permiso para hacer
nada que no sea observar o preguntar para obtener más información.
El resultado de la Segunda Parte del Sprint planning meeting es una lista –
llamada Sprint Backlog– de tareas, estimaciones de tareas y asignaciones, que
dará comienzo al trabajo del Equipo para desarrollar la funcionalidad. La lista
de tareas puede no ser exhaustiva, pero debe ser lo suficientemente completa
como para reflejar el compromiso mutuo por parte de todos los miembros del
Equipo y guiarlos durante la primera parte del Sprint, etapa en la cual el Equipo
puede encontrar más tareas a añadir en el Sprint Backlog.
2.2.4.2 Las reglas de Scrum (II): Durante el Sprint

Después de hablar de las reglas relativas al Sprint planning meeting le toca el turno a
las reglas que rigen lo que ocurre durante un Sprint:
El Sprint se limita en el tiempo a 30 días corridos. Sin considerar otros factores, ésta es
la cantidad de tiempo necesaria para que un Equipo pueda construir algo de interés
significativo para el Product Owner y los involucrados, y llevarlo a un estado en que sea
potencialmente entregable. Este es también el máximo tiempo que se puede asignar sin que el
Equipo tenga que hacer tanto trabajo que requiera artefactos y documentación para soportar su
23
proceso de razonamiento. Es también el máximo tiempo que la mayoría de los involucrados

esperarán sin perder interés en el progreso del equipo y sin perder la convicción de que el
Equipo está haciendo por ellos algo importante.
Durante el Sprint el equipo puede buscar consejo, ayuda, información y soporte

fuera de sí mismo.
Nadie puede proporcionar consejo, instrucciones, comentarios o dirección al
Equipo durante el Sprint. El Equipo es completamente autogestionado.
El Equipo se compromete con el Product Backlog durante el Sprint planning
meeting. No se permite que nadie cambie el Product Backlog durante el Sprint.
El Product Backlog está “congelado” hasta el final del Sprint.
Si se demuestra que el Sprint no es viable, el Scrum Master puede clausurarlo
e iniciar un nuevo Sprint planning meeting para comenzar un nuevo Sprint. El
Scrum Master puede hacer este cambio por voluntad propia o a pedido del
Product Owner. El Sprint puede no ser viable si la tecnología planteada no se
puede utilizar, si las condiciones del negocio cambian de manera tal que el
Sprint no le resultará de valor, o si el Equipo sufre interferencias de personas
ajenas a él mismo durante el Sprint.
Si el equipo se siente incapaz de completar todo el Product Backlog
comprometido durante el Sprint, puede consultar con el Product Owner acerca
de qué elementos quitar del Sprint actual. Si se eliminan tantos elementos que
el Sprint pierde su valor y significado, el Scrum Master puede clausurar el
Sprint.
Si el Equipo determina que puede abordar más Product Backlog durante el
Sprint que el seleccionado durante el Sprint planning meeting, puede consultar
al Product Owner acerca de qué elementos adicionales del Product Backlog
pueden ser añadidos al Sprint.
Los miembros del Equipo tienen dos responsabilidades administrativas durante
el Sprint: Acudir al Daily Scrum meeting, y mantener actualizado y
públicamente disponible el Sprint Backlog. Se pueden añadir tareas nuevas al
Sprint Backlog a medida que se detecte la necesidad; asimismo, es necesario
mantener permanentemente actualizada la estimación diaria para cada tarea.
2.2.4.3 Las reglas de Scrum (III): El Sprint Review Meeting

El Sprint review meeting proporciona un punto de corte para evaluar el progreso del
proyecto al final de cada Sprint. Sobre la base de esta evaluación es posible hacer
adaptaciones en el proyecto. El Equipo estimó antes en qué punto debía encontrarse al final
del Sprint y estableció su camino hasta allí. Al final del Sprint, el equipo presenta el incremento
del producto que ha sido capaz de implementar. Los gestores, clientes, usuarios y el Product
24
Owner determinan el incremento del producto. Se escucha al Equipo acerca de lo sucedido

durante el Sprint, mientras se expone qué cosas fueron positivas y cuáles negativas. Después
de esto, estarán capacitados para tomar una decisión basada en información, acerca de qué
hacer después. En otras palabras, determinarán el mejor camino a tomar para alcanzar las
metas propuestas.
La duración del Sprint review meeting se limita a 4 horas.
El propósito del Sprint review meeting es que el Equipo presente al Product
Owner y a todos los involucrados, la funcionalidad que se ha completado.
Aunque el significado de "completado" puede variar de una organización a otra,
habitualmente significa que la funcionalidad está completamente desarrollada
y, potencialmente, podría ser entregada o implementada. Si "completado" tiene
otro significado, debemos estar seguros de que el Product Owner y los
involucrados lo entienden. En caso de existir más de un equipo, se realiza la
presentación por parte de cada uno.
La funcionalidad que no está "completa" no puede ser presentada. Se destaca
el término “completa” ya que, para que cada tarea esté “completa”, debe
respetar los puntos establecidos en el principio del Sprint.
No es posible presentar artefactos que no son funcionales no pueden ser
presentados excepto cuando se usan para mejorar el entendimiento de alguna
funcionalidad demostrada en alguna demonstración. Los artefactos no pueden
ser mostrados como productos de trabajo, y su uso debe ser minimizado para
evitar confundir a los involucrados o exigir que estos entiendan cómo funciona
el desarrollo del sistema.
La funcionalidad deberá ser presentada en las máquinas de los miembros del
Equipo y ejecutada desde un servidor lo más parecido posible a uno de
producción; por lo general, un servidor del entorno de Aseguramiento de la
Calidad.
El Sprint review meeting comienza con la presentación de las metas del Sprint,
el Product Backlog comprometido y el Product Backlog completado, por parte
de uno de los miembros del equipo. Los distintos miembros del equipo pueden
alternarse para comentar qué fue lo que anduvo bien y qué fue lo que anduvo
mal en el Sprint.
La mayor parte del tiempo que insume el Sprint review meeting se utiliza para
que los miembros del Equipo encargados de presentar la funcionalidad puedan
responder a las preguntas de los involucrados y descubran los cambios que
éstos desean.
Al final de la presentación, se les pregunta a los involucrados, uno por uno,
acerca de sus impresiones, de los cambios que desean y de la prioridad que le
otorgan a esos cambios. Por lo general, se hace con el Scrum Master, aunque
25
es preferible que se encuentre presente todo el equipo, así todos entienden

qué es lo que se quiere. Esto no debe llevar a cambios en el alcance ni a
nuevos requerimientos.
El Product Owner discute con los involucrados y con el Equipo el potencial
cambio del Product Backlog, sobre la base de las impresiones que recibe
feedback.
Los involucrados son libres de realizar en voz alta cualquier comentario,
observación o crítica sobre el incremento de funcionalidad potencialmente
entregable entre presentaciones.
Los involucrados pueden identificar una funcionalidad que no ha sido
entregada o que no ha sido entregada según sus expectativas, y solicitar que
dicha funcionalidad sea incluida en el Product Backlog para su priorización.
Los involucrados pueden identificar cualquier funcionalidad que se les ocurra
durante la presentación y solicitar que dicha funcionalidad sea añadida al
Product Backlog para su priorización.
El Scrum Master debe intentar determinar el número de personas que se
espera que asistan al Sprint review meeting, y organizar la reunión para darles
cabida.
Al final del Sprint review meeting, el Scrum Master anuncia al Product Owner y
a los involucrados el lugar y la fecha del siguiente Sprint review meeting.
2.2.4.4 Las reglas de Scrum (y IV): El Sprint Retrospective Meeting (Reuniones

retrospectivas)
El Sprint retrospective meeting es una reunión promovida por el Scrum Master en la
cual el Equipo discute el Sprint inmediatamente anterior y determina qué se puede cambiar
para que el siguiente Sprint sea más divertido y productivo. Mientras que el Sprint review
meeting se centra en 'qué' está construyendo el Equipo, el Sprint retrospective meeting se
centra en “cómo” lo está haciendo. La motivación para realizar esta reunión es lograr la mejora
continua del proceso de desarrollo. Scrum no es una metodología prescriptiva sino un marco
metodológico que debe ser continuamente adaptado a cada proyecto, equipo o empresa.
En caso de que haya más de un equipo, lo mejor es que cada uno de ellos se reúna y
realice la tarea descripta más arriba. Luego de esto, las personas que iban a ver a los otros
equipos a la hora de la Daily Meeting se reúnen y hacen lo mismo. En caso de encontrar una
mejor manera de realizar los pasos siguientes, se tomará una decisión junto con el Scrum
Master y se la comunicará a cada uno de los equipos.
La duración del Sprint retrospective meeting se limita a 3 horas.
Sólo asisten el Equipo, el Scrum Master y el Product Owner (la presencia de
este último es opcional).
26
Al comienzo de la reunión todos los miembros del equipo contestan las

siguientes preguntas: ¿Qué ha ido bien durante el último Sprint? ¿Qué se
puede mejorar en el próximo Sprint? ¿Qué fallas o problemas se encontraron?
El Scrum Master anota las respuestas del Equipo en un formulario de resumen.
El Equipo establece en qué orden de prioridades quiere tratar las posibles
mejoras.
El Scrum Master no está en esta reunión para dar respuestas, sino para
facilitar la búsqueda del equipo de las mejores maneras de funcionamiento de
Scrum para ellos.
Aquellos puntos que merezcan especial atención pueden ser añadidos al
siguiente Sprint, considerado como un Backlog no funcional de alta prioridad.
Las reuniones retrospectivas que no aportan nada, que sólo se hacen “para
cumplir” resultan frustrantes y negativas –y pueden ser un síntoma de que algo
no está funcionando bien–.
Además de esto, las reuniones retrospectivas son un excelente momento para
averiguar si Scrum está funcionando o no: bastará con escuchar al equipo, para saber si Scrum
los está ayudando o no. Si Scrum no ayuda al equipo, significa que no está funcionando. Toda
metodología que no ayude al equipo de desarrollo a trabajar mejor y con más facilidad, sufrirá
el rechazo de los desarrolladores. De esta manera, por más que se presione para que el
equipo de desarrollo utilice una metodología, si no le resulta efectiva, la rechazarán.
27
Inicio
Cambios y
ajustes Product
Backlog
Sprint
Sprint
Planning
Retrospective
Meeting
Metas del
Sprint
Fin de Sprint
Sprint Review Sprint Backlog
Cerrar Sprint. Mostrar

Daily Scrum Meeting
Demo (avances)
24Hs – 15 a 30 min.
Gráfico 2.2.4.4-1 Ciclo de Scrum
Cabe destacar que, por más que se trata de respetar y cumplir todas estas reglas,
muchas veces Scrum no funciona. En general, los problemas que aparecen no son
consecuencia de las reglas escritas de Scrum sino de aquellas no-escritas. Por ejemplo: Scrum
no específica ningún proceso de software. Por lo tanto no tiene ninguna regla al respecto. Por
esta razón, el presente trabajo no se enfocó en las reglas que actualmente tiene Scrum, sino
en qué es lo que necesita para transformarla en una metodología de gestión ágil para
proyectos de software.
28
2.2.5 Burn Down
Scrum tiene un gráfico típico llamado Burn Down (Hughes, 2008). Este gráfico se
muestra abiertamente a todos los que participan en el proyecto y refleja la cantidad de
requisitos del Backlog del proyecto que están pendientes al comienzo de cada Sprint.
Si se traza una línea que conecte los puntos de todos los Sprint completados,
podremos apreciar el progreso del proyecto. Así también, trazando una línea entre las tareas
de un Sprint que está en desarrollo, podemos saber de manera simple ”cómo viene” el
proyecto. Lo normal es que esta línea sea descendente (cuando “todo va bien” en el sentido de
que los requisitos fueron bien definidos desde el principio y no variaron nunca, y la estimación
se realizó de manera correcta), hasta llegar al eje horizontal, momento en el cual el proyecto se
ha terminado (no hay más requisitos pendientes, a completar en el Sprint). Si durante el
proceso se añaden nuevos requisitos, la línea mostrará una pendiente ascendente en
determinados segmentos; mientras que, si se modifican algunos requisitos, la pendiente variará
o incluso valdrá cero en algunos tramos. A continuación se presentan algunos casos como
ejemplo:
Gráfico 2.2.5-1 Burn Down detallado
Como se puede ver, en el gráfico 2.2.5-1 se permite apreciar lo que es básicamente el

Burn Down. La línea gris recta representa lo esperado, o el ideal según el cual se debe llevar a
cabo el proyecto. El eje vertical expresa el esfuerzo, o Story points calculados para el Sprint,
mientras que el eje horizontal representa el tiempo en el cual se lleva a cabo. Aparece,
además, una la línea gruesa que no se desarrolla en línea recta y representa “lo real”, lo que va
ocurriendo en el proyecto. Tal como se observa, el gráfico da una idea de cuándo puede haber
problemas (luego, si se desea, es posible identificar por medio del Sprint Backlog cuáles son
las tareas que están ocasionando problemas.
29
Gráfico 2.2.5-2 Burn Down
En el gráfico 2.2.5-2 aprecia la situación real de un Sprint en curso. La línea gris

punteada expresa lo estimado y la línea azul representa lo que ocurrió en la realidad. Antes de
comenzar el proyecto, la fecha de finalización estimada era el 12/11; sin embargo, se avanzó
más rápidamente de lo esperado, por lo que el programa prevé que, si se mantiene esa
velocidad de ejecución, ese Sprint estará terminado el 6/11.
2.2.6 Herramientas para la gestión de proyectos
Para aplicar la metodología existen varias herramientas que dan soporte a la gestión de
proyectos que utilizan metodologías ágiles. En general estas herramientas se pueden aplicar a
cualquier metodología ágil, ya que su forma en si es similar: sólo varían las reglas o procesos
que utilizan, las que no se ven reflejadas en el software.
Estas incluyen, por lo general, las siguientes funcionalidades:
Visión general del proyecto.
Seguimiento de control.
Búsqueda de tareas.
Lanzamientos por release y planificación por iteración.
Foros internos de discusión.
Posibilidad de describir tareas, en forma global o detallada.
Reporte de errores, defectos y correcciones.
Muchos de estos softwares también incluyen otras herramientas, como la posibilidad de
realizar el gráfico de Burn Down según los datos disponibles del proyecto, con detalles sobre
fechas e hitos, exportación de tareas y realización de gráficos de avance, gráficos de esfuerzos
del equipo y detalle de cada miembro, realización de informes de errores, etc.
30
Algunos de los softwares más difundidos son:

Team foundation Server.
AccuRev.
AgileBuddy.
Anthill Pro.
Bugzilla
ScrumWorks Pro.
Version One.
Cruise Control.
Electric Cloud.
Out System.
SubVersion.
WorkLenz.
Estos son algunos de los muchos que existen. Varios de éstos son gratuitos o tienen
sus versiones básicas gratuitas. Otros son open source.
Además de existir software para la utilización de metodologías ágiles, también existen
formas de implementarlas manualmente, con papel, recordatorios tipo post-it, y algunos
marcadores. Otra forma es hacerlo en hojas de cálculo, utilizando sus funciones para realizar
los reportes.
2.2.7 Modelo de proceso de Scrum actual
En el gráfico 2.2.7-1 se muestra el proceso que se lleva a cabo para realizar las tareas
en Scrum, según el texto de Hunt (Hunt, 2005). Estos son los pasos a seguir si se están
aplicando correctamente las reglas de la metodología.
A dicho diagrama se le agregarán los pasos necesarios para que la metodología
ofrezca mayor calidad para terminar una tarea y más precisión en los tiempos estimados (Hunt,
2005).
31
Gráfico 2.2.7-1 Proceso actual de Scrum según reglas (Autor M. Casamayor)
Uno de los inconvenientes de este proceso consiste en que, si se agrega una nueva
tarea al Product Backlog –el cual tiene duración determinada en horas–, existe la posibilidad de
que esta tarea se sub-divida en varias sub-tareas con una duración total en horas mayor que la
original. Aunque en este diagrama no se muestra, luego de una situación como la descripta hay
que actualizar el Product Backlog para adecuarlo a la realidad.
Otro gran inconveniente que existe es que se considera que si la tarea realizada paso
los test está correctamente realizada. Sin embargo, a veces ocurre que aunque la afirmación
anterior es cierta, la calidad con que se realizó la tarea es baja. Sería necesario, pues, agregar
la condición de “buena calidad” dentro del término Done; sin embargo, esta condición
representa algo más que una propiedad.
32
3 Análisis
3.1 Análisis comparativo entre metodologías
3.1.1 Scrum versus XP
Como se sabe, existen numerosas metodologías ágiles además de Scrum. Se eligió

Scrum ya que es la metodología más conocida en mi experiencia pero, además, por ser una de
las implementadas con mayor frecuencia dentro de la gran cantidad que actualmente existe, y
por estar siendo difundida cada día en más empresas.
Scrum posee una gran cantidad de reglas que procuran la aplicación correcta de la
metodología. Las reglas dejan en claro la manera de gestionar la metodología y gestionar un
grupo. Sin embargo, hace falta conocer algo más: qué herramientas de software se han de
aplicar. Presenta además otros problemas, que con frecuencia desconciertan al usuario.
Por eso resultará del mayor interés comparar la metodología Scrum con otra
metodología ágil muy utilizada, eXtreme Programming (o “XP”). El porqué es simple, ambas
metodologías se a pesar de ser ágiles, se complementan en diferentes aspectos. Scrum se
enfoca en el control y la gestión del proyecto, mientras que XP se enfoca en los procesos,
herramientas y técnicas para desarrollar el proyecto. Si se mira lo que le hace falta a cada una,
Scrum no posee procesos, herramientas ni técnicas para el desarrollo, mientras que XP está
muy centrado en el desarrollo, sin importar tanto la gestión del proyecto.
EXtreme Programming (XP): La metodología XP es un enfoque de la ingeniería de
software formulado por Kent Beck. Kent es el autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999).
El primer proyecto llevado a cabo con esta metodología fue desarrollado en el año
1996. Es el más destacado de los procesos ágiles de desarrollo de software. Resulta exitosa
debido a su permanente búsqueda de la satisfacción del cliente. Impulsa a los desarrolladores
a responder de forma segura a los cambios propuestos por los clientes o usuarios, incluso
cuando el proyecto se encuentra en una etapa final. (Extreme Programming: A gentle
Introduction)
Otra razón para comparar Scrum con XP es que esta última no se basa tanto en reglas
acerca de cómo gestionar o qué hacer para la gestión, sino que se enfoca en aplicar bien las
herramientas que incluye por defecto. De marera simple se podría expresar así:
Scrum se enfoca en la gestión y organización del proyecto mientras que XP se enfoca,
en su mayor parte, sobre las actuales prácticas de programación
A continuación se presenta un cuadro (tabla 3.1.1-1) comparativo entre Scrum y XP:
33
Scrum XP
Documentación Requiere una documentación mínima Puede tener o no documentación. Lo

para comenzar a construir el Product principal es el desarrollo de la aplicación.
Backlog, pero luego no es
profundizada.
Procesos e No se aplica ninguno en particular. Incluye muchas prácticas de ingeniería.
ingeniería de Sólo especifican reglas acerca de Por ejemplo, desarrollo manejado por
software que se cómo gestionar el proyecto, pero no tests, arreglos de errores, programación
aplican indica nada relacionado con prácticas de a pares, diseños simples, etc.
de ingeniería de software.
Errores luego Para resolverlos se aplica Se aplica lo mismo que Scrum pero
de cada Sprint nuevamente Scrum, muchas veces durante menos tiempo ya que, en
y realizando un Sprint de corrección de general, los errores se corrigen o el
mantenimiento errores o mantenimiento. En general, mantenimiento se realiza antes de la
no duran más de 1 semana entrega, gracias a los tests que ya posee
la metodología.
Cambios de Son bienvenidos. En caso de que el No está tan preparado como Scrum para
requisitos cambio en los requisitos impacte los cambios de requerimientos.
sobre el actual Sprint, el Scrum Igualmente los acepta, aunque en
Master puede tomar la decisión de muchos casos es necesario programar
finalizarlo, para analizar el cambio de nuevos Sprints para contemplar el
requerimiento y estudiar sus cambio. Es por eso que esta metodología
impactos. sólo se desarrolla para necesidades
actuales y no tan futuras. Si el cambio es
muy drástico, puede llegar a afectar el
proyecto de manera significativa.
Tabla 3.1.1-1 Scrum Vs XP
3.2 Inconvenientes de Scrum
3.2.1 Inconvenientes al utilizar Scrum
Hoy en día Scrum está siendo utilizada muy ampliamente, habida cuenta de lo reciente
que es la metodología. Gracias a esto se puede encontrar más documentación acerca de cómo
utilizarla , cuáles son las debilidades e inconvenientes que presenta, y cuáles casos con los
que nos podemos enfrentar, todo lo cual ayuda a quien lo conozca, a evitar problemas e
incluso fracasos en los proyectos.
Sin embargo, también existen puntos de debilidad por el hecho de que no existen
herramientas de software preparados por defecto para la metodología, lo que conduce a que
con frecuencia se la aplique sin utilizar ninguna, sin aplicar métricas, según sea más cómodo,
aunque no resulte lo más conveniente para el proyecto. Como afirmó Dean Wampler5, “Scrum,
sin las prácticas de ingeniería no funcionará en el largo plazo.”
Es por esto que incorporar prácticas y proceso de la ingeniería de software a la
metodología Scrum daría una notable mejora. Se vería muy reflejado en proyectos en los
5
Líder técnico para equipos de desarrollo de software(www.deanwampler.com)
34
cuales la metodología nunca fue aplicada anteriormente, ya que la posibilidad de fracaso sería
menor.
Si no se cuenta con un excelente Scrum Master que guie todo el proceso, que conozca
esta metodología, sepa cómo respetar las reglas y cómo aplicar las prácticas de la ingeniería
de software, la obtención de buenos resultados será improbable.
A poco que se investigue, se observará también que son muchos los que advierten que
no recurrir a los procesos y prácticas de la ingeniería genera problemas. La solución a este
obstáculo no existe formalmente, ya que en ninguna parte de la metodología se dan
indicaciones o explicaciones acerca de esto.
De vez en cuando se ha tratado de aplicar “parches” a la metodología, adaptándole un
par de procesos con intención de mejorarla; sin embargo, al no tener la metodología reglas
básicas escritas, tampoco estas innovaciones parciales se respetan y, luego de un corto
tiempo, aparecen nuevamente dificultades en los proyectos (el tiempo estimado no es el
correcto, hay problemas de definición de requerimientos, etc.).
Entonces, ¿Qué habría que modificar para que la metodología resulte más útil? ¿Qué
respuesta dar a este problema, ya conocido pero aún sin resolver formalmente? Ese es,
precisamente, el propósito de este trabajo.
En primer lugar, se detallarán los problemas que presenta Scrum. Luego se darán
puntos claves a tener en cuenta para saber si la metodología funciona correctamente o no y,
por último, se aplicarán reglas y se le agregarán procesos de la ingeniera de software de
manera que los proyectos que la aplican tengan mayores probabilidades de éxito.
Entre los puntos a tratar para mejorar la metodología, se cuentan los siguientes:
Cambios de requerimientos: Cómo afrontar de diferente manera los cambios
que se producen en los requerimientos, en el curso de un proyecto. Por lo
general, son excesivos y generan retrasos apreciables en su desarrollo.
Errores de desarrollo: Ver tiempo necesario para la corrección de errores, así
como también prever los mismo con tiempos de contingencia que se agrega en
las estimaciones. También tiempos de test y otros tipos de forma para
minimizar los mismos.
Estimación de tiempos: Se propondrán vías alternativas para estimar con
mayor precisión los tiempos asignados a las tareas.
Equipo: Se estudiará qué perfiles resultan necesarios para llevar adelante el
proyecto con éxito. Además de los perfiles, se apreciarán las aptitudes que
pueden presentar el grupo y cada uno de sus integrantes.
Documentación: Aunque se sabe que las metodologías ágiles están
principalmente enfocadas a mantener en marcha una aplicación antes que a
que contar con la documentación completa, frecuentemente –la mayoría de las
veces– esta última es omitida por completo. De esta forma, gran parte de los
proyectos realizados terminan con documentación inexistente. Si luego de
35
cierto tiempo de terminado el proyecto, surge un error en la aplicación o es

necesario realizar una modificación se pierde mucho tiempo en recopilar
nuevamente toda la información relativa al proyecto, más aún si las personas
que lo implementaron no están presentes.
Calidad: Puesto que las metodologías ágiles se implementan para acelerar el
tiempo de desarrollo, muchas veces se pasan por alto las deficiencias en la
calidad debido a que alcanzar la excelencia requiere tiempo. La calidad no es
en la teoría algo negociable, pero no sucede lo mismo en la práctica. En
consecuencia, se procurará asegurar la calidad de los proyectos que utilicen la
metodología, sin menoscabo de su brevedad.
Entre las propuestas a formular se detallarán, cuando sea posible, herramientas de
software que incluyan la metodología por defecto, de forma que se agilice la aplicación de la
modificación. También se agregarán las reglas necesarias para saber de qué forma se
gestionan estas modificaciones.
3.3 ¿Qué intentamos realizar?
Hasta el momento se ha explicado las reglas, la forma en que se utiliza y las

desventajas que Scrum presenta, las cuales impactan en el proyecto, por ende en la
productividad que tiene el equipo para desarrollar el software. Cuando nos referimos al
“Equipo” en Scrum, estamos hablando del Equipo de desarrollo, el cliente, quienes definen los
requisitos.
Según el siguiente gráfico6, las oportunidades para mejorar la productividad en equipos
de diseño de sistemas se basa en varios aspectos. Cada uno de estos puntos tiene sus
factores clave. A continuación se muestran, en el gráfico, los puntos en los cuales es posible
mejorar la productividad, y cuáles de ellos serán tratados.
6
El gráfico corresponde a la mejora de productividad de software expuesta por Barry W. Boehm´s. (Boehm´s, 2007)
36
Gráfico 3.3-1 Mejora de productividad de software

Staff
Obtener lo mejor de
las personas Facilidades
Gestion del personal.
Herramientas de
software y ambientes.
Optimizar la forma de
realización de las
tareas
Estaciones de trabajo.
Automatizaciones.
Automatizar la
documentación.
Eliminar pasos
inecesarios. QA.
Automatizar la
programación.
Asistencia de
Mejoras de softwares de
productividad conocimientos (Wikis,
documentación, etc).
Practicas modernas de
Eliminar el re trabajo. programación.
Ocultamiento de la
correcta información.
Desarrollos iterativos
e incrementales.
Modelos de procesos.
Construcción de
productos simples.
Prototipados rapidos.
Librerias de
componentes.
Componentes y Generadores de
recursos. aplicaciones.
Lenguajes de 4ta
generación.
37
De todos estos puntos expuestos en el gráfico que antecede, sólo algunos están
comprendidos en la gestión de una metodología. Por ejemplo: la tecnología a utilizar está muy
definida, ya que se sabe que Scrum y otras varias metodologías ágiles están diseñadas para
paradigmas orientados a objetos. Esto se debe a que es posible separar muy bien el código de
cada tarea bien definida. De esta manera, resulta fácil mantener el orden y una administración
de lo realizado.
Por otro lado, hay otros aspectos mejor cubiertos por otras metodologías ágiles. La
más importante, muy utilizada y con ciertas similitudes respecto a Scrum es XP. En
consecuencia, la combinación de estas dos metodologías ágiles, nos puede ofrecer un
complemento único. Esa combinación es, precisamente, la que se describirá a continuación,
con la suma de algunos factores no tenidos en cuenta por ninguna de ambas.
38
4 Diseño
Scrum es una excelente metodología para llevar adelante proyectos de cualquier

índole, definiendo reglas para la gestión de proyectos. Sin embargo, como se explicó más
arriba, no define herramientas ni procesos para su utilización. En la comparación con la
metodología XP se observa que ambas presentan grandes similitudes. Ambas metodologías
son ágiles y abiertas a los posibles cambios que puedan surgir. La diferencia esta dada en que
XP se basa en el desarrollo, procesos y el testeo de la aplicación y el código respectivo,
mientras que Scrum se basa en la gestión del proyecto en sí.
Dado que XP tiene rasgos que complementan a Scrum, se intentó alcanzar una
integración entre ambas, dejando como punto principal la gestión del proyecto –que es lo que
realiza Scrum–, pero agregándole las reglas y objetivos propios de otros puntos que presenta
XP.
Se advierte, no obstante, que algunos de los puntos débiles de Scrum también lo son
en XP. Por ejemplo, la documentación. En consecuencia, en cuanto a este aspecto no nos
referiremos a ninguna de las dos.
A continuación se presentan puntos a tener en cuenta para saber si la metodología
funciona correctamente y las posibles mejoras de los puntos débiles de Scrum.
4.1 ¿Cómo saber si Scrum está funcionando? Puntos

claves y débiles de la metodología
Cuando se comienza a aplicar la metodología Scrum por primera vez existe una
pregunta constante. ¿Cómo saber si Scrum está funcionando? (Corral, Geeks, 2008) La
verdad es que Scrum es simple, ya que se basa en sus reglas para gestionar el proyecto. En
consecuencia, si se respetan las reglas, se puede estar casi seguro de que se el proyecto está
llevando de manera correcta. De todas maneras, se necesita un período de aprendizaje, más
aún si la mayoría de los miembros del Equipo están implementando Scrum por primera vez.
Existen numerosos casos de fracasos al implementar metodologías nuevas que, por lo
general, siempre definen reglas y formas de aplicación. Esto no es ajeno a Scrum. Entonces, si
se respetan las reglas, ¿Por qué se puede fracasar utilizando Scrum?
Aquí es necesario hablar de las dificultades presentes en los equipos que la
implementan, ver qué detalles se observan y hacerlos objeto de análisis. Las principales
dificultades que surgen son generalmente las más básicas y se describen a continuación:
4.1.1 La falta de atención a los detalles
Muchos equipos fracasan en la implantación de Scrum porque no le prestan atención a

los detalles. En Scrum, los detalles son vitales. Sin la Daily Scrum, no hay Scrum. Sin Product
39
Backlog, no hay Scrum. Sin Product Owner, sin Equipo y sin Scrum Master, no hay Scrum. Sin
Sprint Planning Meeting, no hay Scrum. Sin Sprint Review, no hay Scrum.
En definitiva, sin seguir de manera estricta las reglas de Scrum, no hay Scrum. La
solución para este problema es simple: seguir rigurosamente las reglas de Scrum. Es fácil caer
en la tentación de hacer adaptaciones a la metodología para cubrir los aspectos que no son
satisfactorios en el proyecto. Sin embargo, cuando esto sucede en un equipo que es nuevo en
la metodología es probable que resulte contraproducente.
Si se contara con procesos de ingeniería de software que ayuden, las cuales se tengan
que cumplir mediante reglas de la metodología, es altamente factible que no exista necesidad
de realizar modificaciones en la metodología cuando se comienza a utilizar. Si bien es posible
realizar estas adaptaciones, no es recomendable. Es mejor volver al procedimiento normal ya
que, por lo general, luego de una adaptación que no funciona, se trata de adaptar otra cosa y
así sucesivamente, hasta que se deja de aplicar Scrum por completo. El que más atento debe
estar a todo esto es el Scrum Master.
4.1.2 Entender y formar el equipo multidisciplinario
Construir un equipo es muy difícil y construir uno multidisciplinario aún más. Es una de
las metas que se debe alcanzar para poder lograr utilizar Scrum y es una tarea muy dura.
Un equipo multidisciplinario es muy productivo y, además, minimiza los riesgos
asociados a la rotación de personal. Los miembros de este equipo se deben llevar bien entre
sí, colaborar, y cada uno de ellos debe asumir los roles que les corresponden. Sólo de esta
manera se puede decir que esta tarea está cumplida. Además, cada integrante del equipo
debe poner la misma cantidad de esfuerzo en el proyecto. Y ninguna persona debe restar
motivación a las demás.
Cuando se va a asignar una tarea a un miembro del equipo, es necesario tratar de que
éste resulte conforme con la tarea que debe desarrollar. Es posible que esto no siempre ocurra
pero, si se puede, es lo recomendable. De esta forma, el Scrum Master logrará que, al estar
conforme con la tarea que está desarrollando, la calidad del producto de la tarea de cada uno
sea superior. Por otra parte, es importante tratar de evitar los cambios de tareas una vez que
éstas fueron iniciadas. Aunque las reglas de Scrum prohíben esto, la realidad es que ocurre
muchas veces.
Una tarea muy importante del Scrum Master es mantener al equipo constantemente
motivado. Debe encontrar la forma de hacerlo en todo momento, de modo que todos sigan
enfocados en el proyecto. Además de esto, debe mantenerse atento a cualquier detalle o
síntoma que el equipo o cualquier miembro del mismo manifieste. Algunos libros (como “Agile
Project Management with Scrum” por Ken Schwaber) ofrecen consejos recomendaciones de
suma utilidad respecto de este punto.
40
4.1.3 Crear y mantener un Product Backlog
Construir y estimar el Product Backlog es una tarea compleja. Es acá cuando se

capturan todos los requisitos de alto nivel, y es tarea del equipo de Scrum hacerlo de manera
correcta. Según mi experiencia, la captura de requisitos suele ser difícil, pero la mayor dificultad
está a la hora de mantener actualizado e ir refinándolo de manera continua.
Cuando se comienza a trabajar en las tareas del Product Backlog, por lo general
aparecen algunas tareas nuevas que no estaban previstas por desconocimiento del sistema o
del negocio, o por algún otro motivo. A veces se decide dividir estas tareas nuevas en sub-
tareas. Si estas nuevas tareas o sub-tareas no se insertan en el Product Backlog, este último
deja de ser real, ya que habrá horas trabajadas que no quedarán reflejadas en él. De esta
forma, al final del Sprint, probablemente no se alcanzará a realizar todas las tareas, a pesar
que éstas aparentemente no debían demandar más horas de las previstas. Lo mismo ocurre si
una tarea demanda más horas que las estimadas; en ese caso, éstas deben ser actualizadas
en el Product Backlog.
Por otra parte, cada vez que se realicen tareas de mantenimiento o soporte, éstas
también deberían ser agregadas en un Product Backlog. Si el proyecto es muy grande y luego
de varios Sprint queda varias tareas por implementar o corregir, se debe agregar al nuevo
Sprint o, en caso de ser necesario, armar un Sprint solo para la realización de las mismas.
4.1.4 Recursos humanos no dedicados
Muchas empresas no son capaces de mantener recursos dedicados a un proyecto. Si

no se mantienen recursos dedicados se tiene a dañar la productividad por los continuos
cambios de contexto. Muchas organizaciones pasan por alto el costo que representan los
cambios de contexto, y no lo incluyen de sus planificaciones. Sin embargo, los cambios de
contexto son el problema silencioso de muchos equipos de desarrollo.
Un equipo que es sometido continuamente a cambio de contexto, de enfoque, de
alcance, difícilmente resultará productivo. La solución a esto está fuera del alcance del equipo
de Scrum, debido a que pasa en general por culturas o situaciones de las empresas.
Según Stephen R. Covey (Covey, 1989) hoy en día las empresas e individuos tienden
a priorizar lo urgente, reemplazandolo por lo importante. Y es esto lo que se cree que sucede.
Debido a la costumbre de tratar todas las cuestiones como “prioritarias”, atendiendo en cada
momento el asunto que más “ruido” provoca y dejando de lado, con este comportamiento, a la
posibilidad de establecer una planificación razonable. Y la ausencia de esta lleva a problemas
de productividad relacionadas con la ausencia de objetivos.
41
4.1.5 Integración de las tareas de soporte y mantenimiento
Existe una gran dificultad en integrar las tareas de mantenimiento con el nuevo
desarrollo, ya sea de tareas o de proyectos. En general los problemas se deben también a los
recursos no dedicados.
Aquí lo fundamental también es minimizar los cambios de contexto. Lo ideal sería que
quienes realizan mantenimiento de los proyectos pasados sea un equipo diferente al que
realiza el desarrollo de los nuevos. Por el contrario, si se trata de corrección y mantenimiento
de un proyecto reciente lo ideal es que el mismo equipo que lo desarrollo sea el encargado de
esta tarea ya que todavía se tiene en conocimiento como se desarrollo el mismo.
Sin embargo, esto no es siempre posible. Otra táctica habitual consiste repartir el día
entre actividades; por ejemplo, dedicar las mañanas para desarrollar un nuevo producto y las
tardes para las tareas de mantenimiento o soporte de versiones o productos anteriores.
Evidentemente, a la hora de planificar un Sprint, tendremos que restar de la capacidad de
nuestro equipo el esfuerzo que estimamos que será necesario dedicar a tareas de
mantenimiento y soporte.
Se debe tener en cuenta que una tarea a desarrollar a la hora de elaborar un nuevo
producto es la documentación, la cual tiene mucha importancia para el mantenimiento, como
así también para el soporte.
4.1.6 Estimación
La estimación de proyectos es una tarea compleja, este es uno de los puntos más
críticos en todo proyecto de software, ya que si no se hace se es considerablemente preciso,
puede conducirlo al fracaso.
En Scrum, al igual que en otras metodologías, la estimación es un aspecto central y se
trata de mejorarla Sprint tras Sprint. Estimamos el Product Backlog y estimamos las tareas de
cada Sprint. La estimación es el primer paso para todo el proceso de planificación, tanto a
mediano como a corto plazo. Aquí el principal problema con en el que nos encontramos es que
los equipos no tienen experiencia en estimar, sea porque nunca estimaron o porque no
conocen la tecnología o la aplicación sobre la cual van realizar un desarrollo y, por lo tanto, se
les vuelve costoso hacerlo con acierto. Esta dificultad hace que muchos equipos omitan las
actividades que Scrum propone en relación con la estimación.
Resulta imposible hacer una planificación realista sin realizar las actividades de
estimación. Ejecutar los procesos de estimación propuestos por Scrum permite obtener una
estimación realista y, además, aprovechar el propio proceso de estimación para obtener
información acerca de qué debemos y qué se pretende construir.
42
Existen muchos libros acerca de cómo estimar correctamente, algunos de ellos

redactados específicamente para metodologías ágiles8. Sin embargo, a menos que se
conozcan y se tenga idea de cuáles son las mejores técnicas a aplicar, es conveniente seguir
las pautas básicas que proporciona Scrum y aplicar métricas avanzadas para asegurarnos de
que las estimaciones realizadas son acertadas. (Schwaber, SCRUM Development Process,
pág. 18).
4.1.7 Documentación
El Manifiesto Ágil afirma que hay que preferir el software desarrollado por sobre la
documentación completa y correcta. La fórmula para analizar el retorno de inversión de Scrum
es la siguiente:
Valor Generado / Costo = RIO (Retorno de inversión).
Este RIO se calcula por cada tarea. Consecuentemente, las principales tareas serán
aquellas que tienen un RIO mayor. Este valor producido es establecido por el cliente. Y he aquí
que la documentación, especialmente la documentación técnica, es algo que al cliente le
genera un valor nulo.
Sin embargo, este punto de vista cambia cuando piensa ve a mediano o largo plazo.
De surgir la necesidad de modificar el software desarrollado hace ya algún tiempo o de
implementar en él nuevas funcionalidades, el valor de tener una documentación clara y real es
muy alto. Porque evita perder tiempo (que implica un mayor costo) en desentrañar cómo
funciona la aplicación desde el punto de vista técnico.
Por lo general, se documentan datos básicos como métodos, alto los principales rasgos
y algunos procesos del negocio. No obstante, con frecuencia, el código fuente termina por ser
la única documentación acerca de la aplicación. Es por eso que, por lo general, se deberían
agregar tareas orientadas a documentar con sus respectivas horas, o bien agregar a la
definición de “terminado” la documentación acerca de lo realizado.
La documentación también puede ser útil para el usuario final. Aunque se piense que el
usuario aprenderá de la aplicación por medio de la experiencia, no todos proceden así. Cuando
esto sucede, es bueno disponer de documentación para el usuario, como un manual de la
aplicación, de forma que se facilite el aprendizaje. En muchas empresas esta tarea forma parte
del rol del usuario cuando reciben el producto terminado; en otras, del Área de Sistemas;
mientras que en otras no se realiza nunca.
4.1.8 Calidad
La calidad de un proyecto de software es uno de sus valores más importantes por lo

que siempre debe incorporarse. En la calidad de un proyecto intervienen todos sus
8
Agile retrospectives
43
participantes, como ser las personas que toman los requerimientos, quienes los comunican,
quienes desarrollan, etc. La forma en que hacen conocer los requerimientos, el modo en que
éstos se traducen a una forma técnica para que los desarrolladores puedan llevar a cabo el
proyecto, es algo fundamental que también requiere de un proceso, como la ingeniería de
requisitos, capaz de garantizar cierto grado de calidad y éxito.
Hay muchas formas de proporcionar calidad a lo largo de todos estos pasos. En la
realidad suele suceder que ante atrasos que surgen en un proyecto, la calidad es la primera en
ser sacrificada, apresurando la toma de requerimientos, haciendo nulos controles de cambios y
desarrollando apresuradamente sin aplicar los patrones y practicas correspondientes.
En tales momentos, es necesario recordar que, ya sea con apuro o sin él, es necesario
trabajar correctamente para darle calidad a lo realizado. Aunque no sea una tarea fácil, menos
aún si hay presión por retrasos y cuando la base de Scrum no posee prácticas de ingeniería de
software, es necesario vigilar que se trabaje lo mejor posible en este punto.
4.2 Mejora de la metodología de Scrum
Dentro de la mejora se abarcaran los principales puntos débiles de la metodología.

Estos son algunos de los antes mencionados.
4.2.1 Requisitos
Los requisitos son un tema problemático en todo proyecto, ya sea que se gestione con
una metodología ágil o no. Las metodologías ágiles se mantienen abiertas a los cambios de
requisitos o a la llegada tardía de éstos, y esto muchas veces genera problemas.
Todos los atrasos, modificaciones y reformas en los requisitos se deben por lo general
a que no se ha aplicado en ningún momento proceso alguno para la captura de aquéllos. Sin
embargo, la aplicación de la Ingeniería de Requisitos ayudaría a mejorar la captura,
minimizando los cambios, la aparición de requisitos tardíos, o su mala captura, todo lo cual
genera demoras en el desarrollo del código. A continuación se explica cómo se desarrolla la
Ingeniería de Requisitos y como se aplicaría a las metodologías ágiles.
4.2.1.1 Ingeniería de Requisitos (IE):

La Ingeniería de Requisitos constituye la conexión con las necesidades reales de los
usuarios. Consiste en un conjunto de actividades y transformaciones que pretenden
comprender a los usuarios de un sistema de software y convertir la declaración de estos
necesidades en una descripción completa, precisa y documentada de los requerimientos del
sistema siguiendo un determinado estándar.9
9
Blog de discusión acerca de la ingeniería de requisitos. (José Manuel Márquez (Docente de la Universidad de
Valladolid), 2008)
44
En Scrum los requisitos de negocio se obtienen al principio del proyecto. Con éstos se
arma el Product Backlog una vez que el cliente les asigna un valor, el cual deriva del el que le
generará una vez realizado. El equipo, por su parte, también les asigna un valor, pero en este
caso el valor representa el costo de realizarlo. De esta forma se obtiene el RIO.
Los requisitos hasta aquí mencionados son los requisitos generales del negocio. Se
seleccionan para el próximo Sprint aquellos que tengan RIO mayor y, de esta manera, el
Equipo comienza a subdividir estas tareas generales en tareas técnicas. Cuando esto sucede,
el Product Owner debería estar presente ya que, en caso de que se presente alguna duda
sobre una tarea, el Product Owner es la mejor persona para aclararla. Sin embargo, no siempre
está.
Entonces, ¿Por qué la propuesta de aplicar a Scrum la Ingeniería de Requisitos? Si se
analiza la cantidad de cambios de requisitos en un proyecto que utiliza la metodología, se
puede descubrir que el número es alarmante. Se estima que un 35% de los requisitos cambian
constantemente, y que 65% de las funcionalidades implementadas no se usan casi nunca
(Garrido, 2009). Si a esto le sumamos una toma de requisitos mediocre, la posibilidad de
cambios por mala toma es muy grande. A pesar de que la metodología da la bienvenida a
estas modificaciones, el exceso de cambios permanentes hace que el proyecto se atrase, o su
alcance varíe constantemente (Frauke Paetsch, pág. 1).
La Ingeniería de Requisitos especifica que el costo de un requisito mal especificado en
una metodología tradicional, va de un 2% a un 10% en la fase de análisis y diseño, mientras
que en la etapa de desarrollo puede llegar a costar entre 5 a 100 veces más del total
previsto.10
En Scrum, los cambios de requisitos pueden llegar cuando el requisito afectado fue
desarrollado, está siendo desarrollado o todavía no fue desarrollado. Cuando los cambios de
requisitos impactan sobre elementos ya desarrollados o que están en proceso de desarrollo, el
costo es mayor. A pesar de que estos cambios de requisitos impactan sobre el desarrollo y, en
consecuencia, sobre el tiempo restante para la finalización del proyecto, muy pocas veces
existe la intención de mover la fecha de finalización o de reducir el alcance del proyecto. Este
es el punto en el cual, dadas las circunstancias, se comienza desarrollar con apresuramiento.
La atención del Equipo en tales momentos no suele ponerse en evaluar si lo que se cambió o
lo que se realizará es o no totalmente correcto, sino en qué es lo que hay que finalizar con
mayor urgencia. Este error conduce comúnmente a que la necesidad de hacer nuevos
cambios, generando aún mayores retrasos. Cabe destacar que, además de retrasos, la
situación genera también un desgaste en el Equipo.
Muchas veces este factor depende del Scrum Master. Sin embargo, sse implementa de
manera eficiente la Ingeniería de Requisitos los miembros del Equipo podrán confiar en que los
10
Dato obtenido del grupo de investigación Kybele (Carlos)
45
requisitos que se van a desarrollar son los correctos, evitándose de esta forma tener que
corregir en un futuro el sistema a raíz de malos entendidos.
Tomar erróneamente los requisitos erróneos y advertirlo luego de realizado el
desarrollo son dos hechos que nunca deberían suceder según Scrum, ya que el Product Owner
debería estar acompañando el desarrollo del proyecto constantemente. Sin embargo, la
realidad es algo diferente. En general, es prácticamente imposible que el Product Owner esté el
100% del tiempo con el equipo de desarrollo, por lo cual la tarea de comprender cabalmente
los requisitos continua siendo responsabilidad del Scrum Master.
Algunas técnicas para la toma de requisitos que se pueden aplicar son las siguientes:
JAD (Joint Application Development): es una técnica popular que consiste

en incluir a los usuarios como participantes activos en el desarrollo del
software.
Durante las sesiones de JAD, los desarrolladores y los usuarios revisan y
ponen en claro las características de la aplicación. Este tipo de charlas o
encuentros suelen ser muy productivos si durante la sesión se logra evitar que
la conversación se desvíe del tema principal. El objetivo de JAD es definir un
proyecto especifico en diferentes niveles de detalles, diseñar una solución y
monitorear el proyecto hasta que esté terminado. Los participantes son jefes,
líderes de proyectos, usuarios, expertos en sistemas y desarrolladores. De esta
manera, se cuenta con múltiples puntos de vista, lo cual permite hacer un
sistema más específico, con menos probabilidades a fallar a causa de una
mala definición de los requisitos.
Modelado: El Modelado de Sistemas es un importante paso entre el análisis y
el proceso de diseño. Algunos métodos aplican diferentes técnicas de
modelado para describir los requerimientos de los sistemas. Las técnicas más
conocidas son los Modelos de Flujo de Datos, los Modelos de Datos
Semánticos y los Modelos Orientados a Objetos. Aplicar alguna de estas
técnicas puede ayudar a entender mejor los requisitos.
Documentación: El propósito de la Documentación de Requisitos es lograr
que éstos sean comunicados entre los interesados o dueños del proyecto y los
desarrolladores. La Documentación de Requisitos es la línea de base para
evaluar posibles futuros productos y procesos del sistema (documentación de
diseño, testing, verificación y validación de actividades) y para el control de
cambios. Una buena documentación en una metodología ágil debería tener
datos claves del negocio, modelado del mismo (ya que sin este en general es
muy difícil ver la complejidad de la aplicación a desarrollar), y documentación
de código, el cual no lleva mucho tiempo.
46
Validación: El propósito de la Validación de Requisitos es verificar que la

descripción de los mismos resulta aceptable para su implementación. La
entrada de datos para el proceso de validación es la documentación de los
requisitos, estándares organizacionales y el conocimiento organizacional. La
salida es una lista que contiene los problemas reportados con la
documentación de los requisitos y las acciones necesarias para abarcar los
errores reportados.
Las técnicas utilizadas para la validación de requisitos son la revisión de
requisitos y el testing de los mismos.
4.2.1.2 En qué podría mejorar Scrum con IE

La mejora particular que experimentaría Scrum con la aplicación de la Ingeniería de
Requisitos se ve reflejada en varios de los puntos puestos a mejorar, a pesar de que muchos
partidarios de las metodologías ágiles se niegan a aplicar este tipo de procesos alegando que
representan una pérdida de tiempo. En realidad, si se aplica la Ingeniería de Requisitos tal
como es, resultaría demasiado estructurada para la metodología pudiera seguir siendo
considerada ágil.
Sin embargo, aplicarla de manera no tan rígida ni profunda generaría una mejora
fundamental (Requirements Engineering and Agile Software Development, 2003).
El Product Backlog juega un papel muy importante en Scrum. Todos los requisitos y
elementos útiles que aportan valor al proyecto están aquí. Contiene una lista priorizada de
todas las necesidades, funciones, errores y mejoras que hay que realizar o fueron realizadas.
Todo esto se comparar con una lista incompleta y cambiante de requisitos, que contiene
información para el desarrollo y para el futuro de la aplicación también.
Las metodologías ágiles tienen la ventaja que el cliente se encuentra, en general,
participando constantemente en el proyecto. Entonces se puede mejorar la obtención de
requisitos de las siguientes maneras:
Modelado del proyecto: En la Ingeniería de Requisitos se realizan modelos en los
diferentes niveles de análisis y diseño, de manera de realizar una abstracción de la aplicación.
Por lo general, todos estos modelos terminan por ser parte de la documentación del sistema.
Es por eso que modelar de forma un poco más profunda cada iteración resultaría fundamental,
evitando quedarse con el análisis básico del Product Owner para luego ponerse a desarrollar.
Documentación: Para comenzar el proyecto, Scrum necesita cierto nivel de
documentación que exprese de qué se trata cada tarea. Sin embargo, el grado de detalle de
estas descripciones suele ser pobre, permitiendo traslucir una idea de lo que se debía hacer sin
transmitir lo que se hizo y de qué manera.
La documentación se utiliza para compartir conocimiento entre las personas. Por
ejemplo: si se incorpora un nuevo miembro al equipo, probablemente tendrá muchas preguntas
que hacer, la mayoría de las cuales encontrarán respuesta en una buena documentación, sin
47
necesidad de utilizar el valioso tiempo de otros miembros del grupo. Además, la buena
documentación reduce el riesgo de pérdida de información cuando algún integrante del Equipo
deja de ocupar su puesto.
Por lo general, esta clase de problemas se manifiestan en el mediano o el largo plazo.
La necesidad de documentación aparece cuando el cliente consulta acerca de un tema y la
persona que lo desarrolló no se encuentra presente o disponible.
Una documentación significativa en Scrum debe incluir documentación de código (con
herramientas como “Javadoc”), documentación de negocio de las tareas, cambios de requisitos
y modelados realizados. Estas son tareas que no consumen prácticamente nada de tiempo si
se va realizando a medida que se realizan las tareas. Y el resultado final es una documentación
solida y útil para un futuro.
Gestión de cambios: La Ingeniería de Requisitos establece que debería ser posible
rastrear los cambios de requisitos, diseño o documentación, a fin de conocer la razón de estos
cambios. Hacer posible esta trazabilidad en los requerimientos, enriquece mucho el aspecto
relacionado con la documentación y es algo que no demanda mucho tiempo.
Aunque muchas herramientas para la gestión de metodologías ágiles –tales como Jira,
Bugzilla, Version One– ofrecen esta posibilidad, son pocos los Equipos que utilizan estas
ventajas que los programas ofrecen. Sin embargo, éste es un punto en el cual la aplicación una
buena práctica puede llegar a significar una gran diferencia en poco tiempo.
En Scrum, el Product Backlog se maneja por versiones, eliminándose por lo general las
versiones más antiguas. Esto debería dejar de ser así ya que mantener las versiones
superadas permite rastrear los cambios en los requerimientos.
4.2.2 El equipo:
4.2.2.1 El Product Owner

Scrum es una metodología que otorga prioridad y valor al Equipo, por sobre todas las
cosas. Este Equipo debe ser multidisciplinario, sin distinción entre el grupo de desarrolladores,
el grupo de analistas, etc. Por lo tanto, es probable que a cada miembro le toque realizar tareas
diferentes, para algunas de las cuales podría no estar tan preparado.
El Equipo debe mantenerse lo más unido posible. La unificación del Equipo permite que
el proyecto tenga una mejor “salud”, debido a la mayor comunicación que existe entre cada uno
de sus miembros. Esto incluye también al Scrum Master y al Product Owner.
Por definición, Scrum pide que el Product Owner sea un miembro más, que permanece
constantemente con el Equipo. Este mandato no siempre se lleva a la práctica debido a que
esta persona suele tener responsabilidades que dificultan cumplir lo prescripto por Scrum. Y el
hecho de que el Product Owner no se encuentra siempre con su equipo como debería, acarrea
problemas en la definición de requisitos.
48
La solución a este problema reside en entender que lo pedido por Scrum es algo ideal.
Al mismo tiempo, asimilar la idea de que el Product Owner no un miembro del Equipo, si no
alguien que le proporciona soporte y definiciones. Comprenderlo así permitiría tomar los
requisitos con cierta cautela, ya que siempre se asume que, si se presenta un error, el Product
Owner tiene la razón porque se trata de su sistema.
4.2.2.2 Esfuerzos Individuales

Por lo general, al principio cuesta que todos los miembros del Equipo pongan el mismo
esfuerzo. Con frecuencia uno de ellos sobresale en este aspecto y, luego de unos pocos días o
semanas, el resto comienza a seguirlo.
El problema es que algunos individuos terminan de adaptarse y se limitan a realizar lo
que ellos consideran un nivel de esfuerzo “correcto”. En estos casos, el Scrum Master debería
identificarlos y tomar una decisión al respecto, ya que muchas veces también este individuo o
individuos pueden llevar a otras personas a hacer lo mismo, de manera que la desmotivación y
las pocas ganas de trabajar se extienden al resto, la metodología no se aplica de manera
correcta y la tarea no se cumple en los plazos previstos.
Por otro lado, algunos indicios permiten prever cuándo una persona, un grupo de
personas o el equipo no van a “funcionar”. Por ejemplo: si el equipo no se comunica, si hay
poca interacción o retrospectiva en las reuniones diarias, significa que pronto puede
presentarse un problema.
Que existan retrasos es algo posible. Puede ocurrir que una tarea nos lleve un poco
más de tiempo de lo estimado. Sin embargo, existen casos en que una persona demora en
realizar una tarea el triple del tiempo estimado. Esto puede ser un indicio de problema. El
Scrum Master debe detectar rápidamente estos casos e investigar si el problema surgió a raíz
de una complicación al realizar la tarea, si la persona que la llevó o lleva a cabo carece de los
conocimientos necesarios, o si no está participando ni trabajando como corresponde. En este
último caso, es necesario conversar con este miembro del Equipo para averiguar qué le
sucede, ya que una persona que no esté motivada no sirve al grupo.
Situaciones de este tipo se pueden prever si el equipo y el Scrum Master están
antentos. Scrum es eficiente si el Equipo lo es. Y para serlo se necesita un Scrum Master
excelente, que pueda llevar motivado a un Equipo a realizar las tareas.
Situaciones como la descripta –y otras análogas que pueden llegar prsentarse– son
signos que permiten anticipar problemas.
Una buena forma de aprender a gestionar equipos e incorporar pautas acerca de cómo
se aplican, son los que se obtienen del libro “Agile Retrospectives: Making Good Teams Great”
por Esther Derby, Diana Larsen y Ken Schwaber, donde se describen pautas muy útiles, fáciles
de aplciar en todo momento11.
11
Libro enfocado a la motivación del Equipo en proyectos con metodologías ágiles.
49
4.2.3 Desarrollo
Si para el desarrollo de la aplicación se toma como referencia XP, al momento de

desarrollar es posible utilizar las prácticas que ésta implementa.
4.2.3.1 Test Driver Development (TDD)

Test Driver Development es la práctica que consiste en escribir un test automático y,
luego, escribir el código suficiente para que el test resulte “positivo”. A continuación, se
refactoriza el código para mejorar su legibilidad y eliminar duplicaciones (Henrik Kniberg, 2007)
(Beck, 2003). Esto ayuda a mantener el código fuente legible, correcto y no duplicado.
De manera análoga, encontramos en Java la utilidad JUnit. Este tipo de utilidades
permite además, luego de desarrollar más módulos de código para una aplicación, correr todos
los test. De esta manera, sabremos si hay alguna falla que corregir.
Esto acelera los ciclos de desarrollo, compilación y pruebas. Al mismo tiempo, actúa
como una red de seguridad, proporcionando a los desarrolladores la confianza necesaria para
refactorizar y mantener el código limpio y simple mientras el sistema crece.
TDD en código nuevo:
Se hace TDD para todos los desarrollos nuevos, incluso si eso implica que el arranque
del proyecto tardará más tiempo ya que, no obstante, esta práctica traerá beneficios muy
grandes en el futuro.
TDD en código viejo:
Se intenta hacer el TDD sobre la base del código. Cuando hay una base que no tiene
TDD desde el principio, la tarea resulta algo más difícil habida cuenta de que es posible que no
se conozca cómo probar ciertas partes del código, no haya documentación acerca de cómo
hacerlo o cómo se realizaba, o que los creadores de esos módulos no estén más.
Aunque esta tarea resulta muy difícil, finalmente quedará demostrado que valió la pena.
De esta manera cada vez que se desee probar la aplicación, habrá formas de asegurar que su
base está en correcto funcionamiento. Mucho más si se trata un sistema antiguo, para el cual la
base será, seguramente, lo más importante.
4.2.3.2 Pair Programming

En muchos equipos esta modalidad no está muy adaptada. Sin embargo, se ha
demostrado que no se pierde el doble de tiempo para una misma tarea sino que sirve para
ganar conocimiento y resolver las formas de manera más inteligente, generando calidad,
ahorrando esfuerzo, etc.
Algunas conclusiones sacadas de equipos que lo aplicaron (Henrik Kniberg, 2007) son
las siguientes:
La programación por parejas mejora efectivamente la calidad del código.
50
La programación por parejas mejora efectivamente la concentración del Equipo

(por ejemplo, cuando una persona está realizando la tarea y se pregunta si lo
que se está realizando es realmente necesario para este Sprint).
Sorprendentemente, muchos de los desarrolladores que están en totalmente
en contra de la programación por parejas ni siquiera la han probado, pero
comienzan a apreciarla rápidamente una vez que la prueban.
La programación por parejas resulta agotadora y no debería realizarse durante
todo el día.
Es bueno cambiar de parejas frecuentemente. La programación por parejas
mejora efectivamente la distribución de conocimiento entre los miembros del
Equipo, de manera sorprendentemente rápida.
Algunas personas simplemente no se sienten a gusto haciendo programación
por parejas. No obstante, no hay que prescindir de un programador excelente
por el solo hecho de que no se siente a gusto programando por parejas.
La revisión de código es una alternativa aceptable a la programación por
parejas.
El “navegante” (la persona que no usa el teclado) debería tener también un
ordenador propio. No para desarrollar, pero sí para hacer pequeñas tareas
cuando sea necesario, consultar documentación si el “piloto” (quien que usa el
teclado) se atasca, etc.
No es bueno presionar al personal para que realice programación por parejas.
Es mejor animar a las personas y proporcionales las herramientas adecuadas,
permitiéndoles experimentar con esta forma de programación a su propio ritmo.
Por lo tanto, podemos afirmar que la programación por parejas ayuda a mejorar la
calidad, a optimizar los plazos de desarrollo, a aumentar la capacitación acerca del sistema, las
metodologías, prácticas y paradigmas entre los desarrolladores, todo lo cual hace conveniente
su aplicación en el desarrollo ágil de sistemas.
4.2.3.3 Diseño incremental

Esta práctica supone mantener el diseño simple desde el principio y mejorarlo
continuamente, en lugar de pretender que todo funcione desde el principio para entonces
“congelarlo”.
Si, en lugar de plantear un diseño único al principio –lo cual exigirá demorarse en el
análisis de todas las variantes posibles–, se invierte una cantidad razonable de tiempo en
refactorizar y mejorar los diseños existentes, se acortará el plazo de desarrollo del proyecto.
En algunos casos existen ciertos riesgos. Por ejemplo, cuando un diseño inestable está
fuertemente ligado a la aplicación, por lo que la refactorización y mejora del mismo es
prácticamente un proyecto en sí mismo. No obstante, es un esfuerzo que muchas veces vale la
pena.
51
En particular, afirmamos que la mejora continua del diseño es un beneficio secundario

inmediato de la aplicación de TDD.
4.2.3.4 Integración continua

Muchísimos sistema de software cuentan con un sofisticado entorno de integración. Por
esa razón en la actualidad existen sistemas para automatizarlo, tales como Maven o
QuickBuild. Esto resulta extremadamente valioso y ahorra muchísimo tiempo. De esta manera,
se soluciona el típico problema: “–Si en mi maquina funciona… ¿Por qué no funciona en esta
otra?”
Cada vez que alguien chequea algo en el sistema de control de versiones, el servidor
de compilación continua arranca, compila todo desde cero en un servidor compartido y corre
todas las pruebas. Si algo va mal, notifica por correo electrónico a todo el equipo que la
compilación ha fallado, incluyendo información acerca de qué parte exactamente del código
falló la compilación, enlaces a los informes de prueba, etc.
Todos los días el servidor de compilación continua reconstruye el producto desde cero
y envía los binarios o compilados, la documentación, los informes de pruebas, los informes de
cobertura de pruebas, los informes de dependencias, etc., a una URL propia del proyecto de
documentación. Algunos productos también se instalarán automáticamente en un entorno de
pruebas.
Montar un sistema como éste implica un trabajo inicial; sin embargo, este esfuerzo
resulta de gran utilidad para todos los proyectos que se realizarán luego, ya que todos ellos
pueden trabajar conjuntamente, despreocupados respecto de problemas de versiones, de por
qué no funciona en una máquina y en otra sí, etc.
4.2.3.5 Propiedad colectiva del código

Si bien se apoya el concepto de propiedad colectiva del código, no todos los equipos lo
han adoptado aún. Hemos encontrado que la programación por parejas con una rotación
frecuente de las parejas conduce a un nivel elevado de propiedad colectiva del código.
Los equipos que tienen un alto nivel de propiedad colectiva del código han demostrado
ser muy sólidos. Por ejemplo, sus Sprints no fallan simplemente porque una persona clave esté
enferma.
4.2.3.6 Ambiente de trabajo informativo

Todos los equipos tienen acceso a pizarras y espacios vacíos en las paredes, y hacen
buen uso de ellos. En la mayoría de los lugares de trabajo las paredes se ven cubiertas con
toda clase de información acerca del producto y el proyecto. Un problema que esto plantea es
la acumulación de información vieja sobre las paredes. Por eso, para que esta práctica resulte
útil, alguien debe ocuparse de mantener actualizada esta información, haciendo limpieza de la
información vieja y remplazándola por la vigente.
52
No obstante, si bien se promueve el uso de paneles de tareas, pero no todos los

equipos lo han adoptado todavía. (Ver “Cómo distribuimos la Sala del Equipo”.)
4.2.3.7 Estándares de codificación

La definición de estándares de codificación es algo muy útil y siempre conviene
realizarla cuanto antes. Prácticamente no cuesta nada en términos de tiempo: se trata de
comenzar con algo simple, que vaya creciendo con el tiempo. Se debe escribir únicamente
material que no sea obvio y que, dentro de lo posible, esté relacionado con el material
existente.
La mayoría de los programadores tienen su estilo de programación propio y distintivo.
Pequeños detalles como la forma en la que tratan las excepciones, cómo comentan el código,
cuándo devuelven un valor nulo, etc. En algunos casos, estas diferencias no importan; en
otros, sin embargo, pueden conducir a una severa inconsistencia en el diseño del sistema y a
un código difícil de leer. Un estándar de codificación ayuda a que esto no ocurra
invariablemente.
Cada tecnología tiene sus estándares básicos, por lo cual su aplicación depende de
todo el equipo y es necesario ponerse de acuerdo para buscar, adoptar y mantener un
estándar común.
4.2.3.8 Ritmo sostenido

Mucha bibliografía sobre desarrollo ágil de software afirma que las jornadas extendidas
son contraproducentes para el desarrollo de software. Una experiencia que figura en un libro
(Henrik Kniberg, 2007) nos cuenta lo siguiente:
Hace cosa de un año, uno de nuestros equipos (el más grande) estaba
trabajando un número insalubre de horas extra. La calidad de la base de código era
pésima y habían pasado la mayor parte del tiempo “apagando incendios”. El equipo de
pruebas (que también estaba haciendo horas extra) no tenía ninguna posibilidad de
hacer aseguramiento de la calidad en esas condiciones. Nuestros usuarios estaban
enojados y la prensa nos estaba comiendo vivos.
Después de unos meses, conseguimos disminuir las horas de trabajo a un nivel
decente. La gente comenzó a trabajar en horarios normales (excepto durante algunas
crisis de proyecto, a veces). Y, oh sorpresa, la productividad y la calidad mejoraron
notablemente.
Por supuesto, reducir las horas de trabajo no fue en absoluto el único aspecto
que condujo a la mejora, pero todos estamos convencidos de que tuvo mucho que ver.
De esta manera, se puede apreciar que el resultado del trabajo no depende de la

cantidad de horas que se aplique al proyecto, sino la calidad que confiere durante ese tiempo.
53
Si un equipo trabaja muy forzado, bajo mucha presión, sin ver resultados y encontrando cada
vez más problemas, es probable que intente hacer las cosas lo más rápido posible, con calidad
nula, haciendo que la corrección de problemas sea un parche, antes que una corrección bien
hecha. Esto termina generando un código malo y hace también que el ambiente de trabajo no
sea el mejor.
4.2.4 Calidad
Aunque Scrum y XP mencionan que los proyectos tienen que ser de buena calidad,
superiores a lo que el cliente exige, una forma de asegurarnos es aplicar QA.
4.2.4.1 Quality Assurance (QA)

El termino Quality Assurance o QA (Thomas Pyzdek, 2003) (Jeff Tian, 2005) se refiere
a proceso sistemático de producción que provee la seguridad de que un producto es el
adecuado y correcto para lo que se necesita. Consisten en un conjunto de actividades con el
propósito de asegurar que el cliente quedará satisfecho con lo que se realiza o lo que se va a
realizar. Por lo tanto, QA se aplica no sólo al proceso final, cuando el proyecto está terminado,
sino también en la etapa de obtención de los requisitos. Sin embargo, si bien QA mejora la
calidad, su aplicación no garantiza un producto de calidad.
La calidad es un conjunto de propiedades esenciales a un objeto que le dan capacidad
para satisfacer necesidades implícitas o explícitas. La calidad de un producto o servicio es la
percepción que el cliente tiene del mismo; es un juicio del consumidor que asume conformidad
con dicho producto o servicio y con la capacidad del mismo para satisfacer sus necesidades.
Por tanto, debe definirse en el contexto que se esté considerando; por ejemplo, la calidad del
servicio postal, del servicio dental, del un producto con una finalidad, de vida.
En consecuencia, la calidad de un sistema o servicio informático es muy importante y
necesaria, ya se trate de un producto que se vendió o de un recurso para lograr un avance en
una empresa. Se sabe que contratar personal para realizar QA resulta costoso; sin embargo,
este costo no es excesivo si se considera a largo plazo y garantiza una mayor satisfacción del
cliente, además de una menor probabilidad de fracaso del proyecto.
Scrum nada dice acerca de personal para garantizar la calidad en el proyecto, pero
pretende que las cosas se hagan con calidad. La experiencia me ha demostrado que existe
una gran diferencia entre tener y no tener una persona dedicada a QA. Siempre que se trabajó
con personas de QA, aunque sea una sola en el equipo, las cosas parecían terminar de mejor
manera; aunque tal vez se descubrían más errores, el cliente quedó siempre mucho más
satisfecho.
El QA se puede aplicar como una herramienta de ingeniería, de manera que no pueda
existir forma de no aplicarla. De esta forma, el costo de implementar Scrum en términos
económicos sería mayor, pero se podría garantizar mejor el éxito del proyecto, y la mayor
54
satisfacción del cliente. Esto es lo que Scrum plantea en principio: satisfacer al cliente, ofrecerle
un mejor producto antes que documentación. En consecuencia, desde cualquier perspectiva,
aplicar QA en la metodología es lo mejor que se puede hacer.
4.2.4.2 Por qué la calidad no es negociable

La calidad se puede considerar desde dos puntos de vista: calidad interna y calidad
externa (Henrik Kniberg, 2007).
Calidad externa: es lo que perciben los usuarios del sistema. Una interfaz de
usuario lenta y poco intuitiva es un ejemplo de baja calidad externa.
Calidad interna: se refiere a aquellos aspectos que normalmente no son
visibles para el usuario, pero que tienen un fuerte efecto sobre la posibilidad del
mantenimiento del sistema. Incluye aspectos como la consistencia del diseño
del sistema, la cobertura de pruebas, la legibilidad del código, la
refactorización, etc.
En líneas generales, un sistema con alta calidad interna puede, aun así, tener una baja
calidad externa. Pero un sistema con baja calidad interna rara vez tendrá buena calidad
externa ya que resulta difícil construir algo sólido sobre malos cimientos.
La calidad externa se trata como parte del alcance. En algunos casos puede tener
sentido, desde el punto de vista de negocio, liberar una versión del producto que sea lenta y sin
mucha estética visual, y más tarde liberar una versión mejorada. Aun así, se trata de un
aspecto relacionado con el alcance de un proyecto que su dueño debe decidir.
Sin embargo, la calidad interna es algo que no se puede discutir. Es responsabilidad
del Equipo mantener la calidad del sistema bajo toda circunstancia y, simplemente, no es
negociable.
Una gran pregunta suele ser cómo diferenciar la calidad interna de la externa en un
proyecto. Supongamos que el Dueño de Producto aprueba estimaciones de valor de 6 tory
points, pero dice estar seguro de que se podría haber alguna forma rápida para hacerlo en la
mitad del tiempo, si lo piensan mejor. Esto puede convertirse en un gran problema, porque se
pretende las cosas más rápido, en desmedro de la calidad interna. No siempre es así y hay que
hacer un análisis, pero se podrá reducir la estimación si el análisis es correcto.
El sacrificio de la calidad interna es en la práctica una muy mala idea. El tiempo que se
ahorra es mucho menor que el costo, tanto a corto como a largo plazo. Si se permite que una
base de código comience a deteriorarse, resultará muy difícil recuperar su calidad original más
adelante.
Si es muy importante la entrega inmediata del producto, se puede optar por reducir el
alcance del proyecto en lugar de reducir el tiempo de desarrollo.
Una vez que el dueño y el Equipo de desarrollo aprenden que la calidad no es
negociable, se descubren otras formas de reducir plazos, alcance y demás variables para
poder realizar el proyecto en tiempo y con calidad.
55
4.2.5 Diagrama de función de Scrum para tareas
Según el gráfico 2.2.7-1 la metodología no posee por defecto QA, test, aunque se
pueden agregar, al igual que la actualización de tareas, las cuales se deben realizar siempre.
Luego de presentar las modificaciones necesarias en la metodología, se vuelve a definir el
diagrama de función para llevar a cabo las tareas y gestionar la metodología de manera
diferente.
En el gráfico 4.1.6-1 se presenta el nuevo esquema:
Gráfico 4.1.6-1 Scrum enfocado a proyectos informáticos - Autor: Martín Casamayor.
56
4.2.6 Nuevas Reglas
Tal como se dijo, primero se implementarán reglas. Estas reglas servirán para poder
saber cuándo se podrá cambiar los procesos o herramientas de ingeniería de software tratando
de esta manera que siempre se esté aplicando alguna. En caso de no funcionar con las que
traerá por defecto, tener alternativas, tratamientos de problemas generales y demás
eventualidades que puedan suceder.
Cabe destacar que estas reglas están pensadas para lograr un mejor funcionamiento
de la metodología. Como en el caso de las reglas anteriores, Éstas pueden ser modificadas
siempre y cuando haya una razón importante que, de no resolverse, impida el avance del
proyecto.
Las reglas nuevas tienen como objetivo respetar las herramientas de la ingeniera que
se acaban de presentar. También explican cuándo se pueden modificar las mismas en caso
que exista la necesidad. A continuación se presentan las nuevas reglas para el mejoramiento
de Scrum.
4.2.6.1 Las reglas de Scrum (VI): Procesos y herramientas de ingeniería de software

La metodología cuenta con reglas acerca de cómo hacer funcionar, cumplir y
eventualmente modificar los procesos y herramientas con los que cuenta. Estas se deben
respetar según indique cada herramienta o proceso, haciendo que se cumplan tanto las reglas
dictadas a continuación como las propias de cada proceso o herramienta.
La metodología cuenta con procesos y herramientas de ingeniería de software
que son necesarias aplicar. Son las siguientes:
o Ingeniería de Requisitos: Se deberá aplicar Ingeniería de Requisitos
para la etapa de armado del Product Backlog y el Sprint Planning. Se
deberá aplicar siempre.
o Cambios de Requisitos: Se deberá llevar control de los cambios,
aplicando gestión de cambios de requisitos. Al aparecer un cambio de
requisito el Scrum Master deberá evaluar el RIO del mismo. Si tiene un
RIO importante, deberá considerar de congelar el Sprint, ver que
impactos tiene en las tareas que se están desarrollando y volver a
armar un Sprint con estos cambios.
o Pair Programming: En los casos que haya miembros del Equipo con
poca experiencia, los miembros de mayor experiencia deberán trabajar
según el modelo de Pair Programming durante los dos primeros
Sprints, dos veces por semana durante tres hora diarias. De esta
forma, los de menor experiencia adquirirán nuevos conocimiento más
rápidamente.
57
o Test Driven Development (TDD): se deberá aplicar en todo momento

mientras se desarrolle código, ya se trate del desarrollo de un código
nuevo o de la modificación de un código viejo.
o QA: Un miembro del Equipo debe ser especialista en QA. Esto ayudará
a que el cliente quede más satisfecho con lo que se va realizando y a
asegurar la factibilidad del proyecto.
o Documentación: Se deberá preparar la documentación y ésta no
deberá limitarse al código fuente. La documentación se deberá aplicar
en el Product Backlog. Aquí por cada tarea se deberá comentar que
fue lo que se conocía antes de comenzar la tarea, y eventualidades
que sucedan durante la realización de la misma. También se deberá
documentar el código con herramientas como “Javadoc”.
Para poder modificar los procesos o herramientas que existen, es necesario
contar con la aprobación de la mayoría del Equipo, es decir el Scrum Master y
todos sus integrantes. Además de la aprobación del Equipo, debe existir una
lógica de cambio y también determinar cuál es la mejor alternativa. El cambio
de herramientas, por su parte, requiere una experiencia razonable, no sólo
porque no resulta “cómodo”. Si no se cuenta con suficiente experiencia, la
aparente necesidad de cambiar la herramienta puede deberse a que se ignora,
en realidad, cómo aplicarla.
Una vez modificadas, se deberá agregar a las preguntas básicas si se notaron
cambios de metodología y si funciona o no, sin entrar en muchos detalles. En
caso de existir una suma urgencia por el cambio y éste requiera de más tiempo
se organizará una nueva reunión llamada Tools Meeting. En ésta deberán estar
presentes todos los miembros del Equipo y también el Scrum Master. En ella
se debaten qué problemas se plantean con las nuevas herramientas o
procesos que existen en la metodología, si ha habido mejoras. Esta reunión no
deberá durar más de una hora, de forma que se defina rápidamente qué lo
mejor que se puede hacer a continuación.
Una vez decidido el cambio de una metodología, el Scrum Master deberá dar a
conocer a los integrantes del Equipo cómo aplicarla, buscando datos básicos,
mejores prácticas, etc. De esta forma, logrará que todos se informen lo mejor
posible respecto de la metodología nueva.
Si hubo Sprints que no lograron su objetivo y el Equipo se siente
decepcionado, un recurso útil consiste en aplicar nuevas ideas. Cada
integrante es convocado a dar nuevas ideas, comentando su experiencia y
expresando qué le gustaría cambiar. Una vez conocido lo que cada uno piensa,
entre todos elegirán las tres mejores ideas para aplicarlas en el próximo Sprint.
La elección se hará de este modo: que cada integrante expresará cuáles son a
58
su juicio las dos mejores ideas; las seleccionadas serán las que acumulen
mayor puntaje.
Cuando se quieran encontrar formas nuevas de pensar soluciones, suele
resultar productivo cambiar de lugar de la reunión. Ir a nuevos lugares ayuda a
pensar en cosas nuevas. De esta forma pueden aparecer nuevas soluciones.
Agregar a la definición de Done (Terminado) de las tareas, por defecto, Test.
Estos tests son de programación. Una tarea testeada garantiza mayor calidad.
De esta manera, en futuras entregas, sólo será necesario correr los tests para
saber si continúan funcionando de manera adecuada.
59
5 Conclusión
Las metodologías ágiles se están difundiendo día tras día. De esta forma, Scrum
también se vuelve más popular. Muchas personas que nunca utilizaron metodologías ágiles –
mucho menos Scrum– comenzarán a gestionar sus proyectos con estas metodologías, sin
poseer experiencia previa. Esta inexperiencia puede llevar a que el costo de adaptación sea
alto debido a que en principio, probablemente, requiera mucho esfuerzo. También es posible
que se produzcan problemas al momento de gestionarla.
Esto es lo que lleva generalmente a utilizar Scrum adaptando reglas, cometiendo
errores que son comunes y que se afirme que Scrum “es muy buena en gestión pero le hacen
falta mayores herramientas”.
Se prevé que permitirá aumentar la precisión en la estimación de los tiempos y reducir
la probabilidad de problemas con los requisitos, y que las recomendaciones sobre la
documentación y los consejos para superar los problemas serán de gran utilidad. Esto será
más evidente en la cantidad de fracasos en proyectos que aplican a la metodología por primera
vez.
De esta manera, los proyectos llevados a cabo actualmente con Scrum –e inclusive con
XP– podrán aplicar esta mejora para gestionar los proyectos, en la convicción de que si se la
aplica respetando todas las reglas – las que ya poseía y las nuevas–, se podrá gestionar e
implementar un mejor proyecto de software.
60
6 Glosario
Artefacto: Es un producto tangible resultante de un proceso de desarrollo de

software. Ayudan a la descripción de las funciones, la arquitectura y el diseño
de software.
CMMI (Capability Maturity Model Integration): Es un modelo para la mejora y
evaluación de procesos para el desarrollo, mantenimiento y operación de
sistemas de software.
Daily meeting / Daily Scrum Meeting: Reunión diaria que se realiza en Scrum
para ver el estado de trabajo. La dirige el Scrum Master. Tienen que estar
presente todos los miembros del equipo, incluso el Product Owner de ser
posible. Debe durara 15 minutos como máximo. Aquí todos los miembros
deben responder tres preguntas básicas:
o ¿Qué se hizo desde ayer?
o ¿Qué es en lo que vas a trabajar hoy?
o ¿Ha habido algún problema que te haya retrasado o impedido alcanzar
tu objetivo?
Ingeniería de Requisitos: La Ingeniería de Requisitos consiste en un conjunto
de actividades y transformaciones que pretenden comprender las necesidades
de un sistema software y convertir la declaración de estas necesidades en una
descripción completa, precisa y documentada de los requerimientos del
sistema siguiendo un determinado estándar.
JAVA: Lenguaje de programación de tercera generación orientado a objetos.
Fue desarrollado por Sun Microsystems a principio de la década del 90.
Javadoc: Es una utilidad desarrollada para la generación de documentación en
formato HTML a partir del código fuente en JAVA.
JUnit: Test unitarios. Son test que se desarrollan para probar de manera
controlada y por unidades (clases, paquetes de negocio, etc.) el
funcionamiento del código Java.
Product Backlog: Documento de alto nivel para todo el proyecto el cual
contiene las tareas de negocio, funcionalidades deseables, etc. Que se quieren
alcanzar en el proyecto. Cada tarea está estimada en Story Points.
Product Owner: Dueño del proyecto, es quien representa al cliente en Scrum.
QA (Quality assurance): Programa para el monitoreo y evaluación de varios
aspectos de un proyecto o servicio para asegurar estándares de calidad.
Scrum Master: Individuo que en Scrum representa un papel parecido a un líder
de proyecto. Esta encargado de comunicarse principalmente con el Product
Owner, de motivar al equipo y de solucionar cualquier inconveniente que se
presente respecto a información del proyecto.
61
Sprint: Ciclo de trabajo en Scrum. Estos pueden ser de un periodo una a cuatro
semanas por lo general.
Sprint Backlog: Documento detallado a nivel técnico de las tareas a realizar en
el Sprint. Estas están estimadas en horas.
Sprint planning Meeting: Reunión realizada para definir las tareas a llevar a
cabo en el Sprint que va a comenzar.
Sprint review meeting: Reunión realizada al final de cada Sprint para revisar el
trabajo que fue y no completado. Se presenta también lo completado al Product
Owner. Esta presentación se conoce como Demo. Tiempo máximo de la
reunión de 4 horas.
Story Points: Puntaje que se le da a las tareas del Product Backlog. Este
puntaje se obtiene según la formula de RIO (Retorno de inversión).
Procesos de ingeniería / Proceso de la ingeniería:
RIO: Retorno de inversión. En Scrum la fórmula para obtener el retorno de
inversión de una tara de negocio es la siguiente:
Valor Generado / Costo = RIO (Retorno de inversión).
XP (eXtreme Programming): Metodología ágil de desarrollo de software
formulada por Kent Beck en el 1999.
62
7 Bibliografía
(s.f.). Recuperado el 10 de 02 de 2009, de

http://genobraker.spaces.live.com/blog/cns!F45E3DFD1A71CD5A!835.entry
Abrahamsson, P. (2008). Agile Processes in Software Engineering and Extreme

Programming. Página 22: Springer.
Acosta, W. (01 de 07 de 2001). Gestiopolis. Recuperado el 05 de 26 de 2009, de

Gestiopolis: http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/pertcpm.htm
Beck, K. (2003). Test-driven development: by example. Addison-Wesley.
Boehm´s, B. W. (2007). Softwaer Engineering. Willey-Interscience.
Carlos, U. R. (s.f.). Kybele. Recuperado el 26 de 02 de 2009, de Kybele:

http://kybele.escet.urjc.es/Documentos/ISI/Ingenieria%20de%20Requisitos.pdf
Castro, P. M. (s.f.). Metodología de Trabajo Ágil y Eficiente: El método Scrum aplicado

a la Gestión de Proyectos en general. Fundación Antonio Nebrija .
Castro, P. M. PROGRAMA FORMATIVO DE POSTGRADO "Competencias para la

incorporación laboral y profesional. España: Fundación Antonio de Nebrija.
Charvat, J. (2003). Project management methodologies: selecting, implementing, and

supporting methodologies and processes for projects. John Wiley and Sons.
Ciencia y Técnica Administrativa. (s.f.). Recuperado el 26 de Marzo de 2009, de ca:

http://www.cyta.com.ar/ta0502/v5n2a1.htm#1
CM Crossroad. (s.f.). Recuperado el 15 de 04 de 2009, de

http://www.cmcrossroads.com/
Cohn, M. (2004). User stories applied.
Corral, R. (09 de 06 de 2008). Geeks. Recuperado el 11 de 02 de 2009, de Geeks:

http://geeks.ms/blogs/rcorral/archive/2008/06/09/191-c-243-mo-hacer-funcionar-scrum-
191-c-243-mo-saber-si-scrum-est-225-funcionando.aspx
Corral, R. (19 de 11 de 2006). Geeks.ms. Recuperado el 17 de 01 de 2009, de

http://geeks.ms/blogs/rcorral/archive/2006/11/19/las-reglas-de-scrum-i-el-sprint-
planning-meeting.aspx
Covey, S. R. (1989). 7 habitos de la gente altamente efectiva. Paidós Ibérica.
Doug Rosenberg, M. S.-C. (2005). Agile development with ICONIX process: people,
process, and pragmatism. Apress.
Extreme Programming: A gentle Introduction. (s.f.). Obtenido de Extreme

Programming: A gentle Introduction: http://www.extremeprogramming.org/
63
Frauke Paetsch, D. A. (s.f.). Requirements Engineering and Agile Software

Development. Recuperado el 08 de Julio de 2009, de
http://www2.enel.ucalgary.ca/People/eberlein/publications/WETICE_03.pdf
Garreta, J. S. (2003). Ingeniería de proyectos informáticos.
Garrido, R. S. (2009). Scrum and the World Crisis. Scrum Aliance.
Henrik Kniberg, P. d. (2007). Scrum y XP desde las trincheras. Info Q.
Hughes, R. (2008). Agile Data Warehousing. iUniverse.
Hunt, J. (2005). Agile software construction. Springer.
Jeff Tian, C. S. (2005). Software quality engineering.
José H. Canós, P. L. Métodologías Ágiles en el Desarrollo de Software. Universidad

Politécnica de Valencia.
José H. Canós, P. L. Métodologías Ágiles en el Desarrollo de Software. DSIC -

Universidad Politécnica de Valencia.
José Manuel Márquez (Docente de la Universidad de Valladolid), I. L. (27 de 03 de

2008). Daniel’s Blog. Recuperado el 10 de 03 de 2009, de Daniel’s Blog:
http://danielvn7.wordpress.com/category/ingenieria-de-requisitos/
Ken Schwaber, M. B. (2001). Agile Software Development with Scrum.
Ken, S. (2007). The Enterprise and Scrum.
Kent Beck, J. G. (2001). Manifesto For Agile Software Development. Recuperado el 2

de Julio de 2009, de http://agilemanifesto.org/
Larman, C. (2004). Agile and iterative development: a manager's guide. Addison-

Wesley, 2004.
Larman, C. Applying UML and Patterns.
Larsen, E. D. Agile Retrospectives.
N°1. (Marzo-2006). Agile Journal .
(2003). Requirements Engineering and Agile Software Development. IEEE Computer

Society.
Rossberg, J. (2008). Pro Visual Studio Team System Application Lifecycle

Management. Páginas 68 - 70: Apress.
Rossberg, J. (2008). Pro Visual Studio Team System Application Lifecycle

Management. Apress.
Schwaber, K. (2004). Agile Project Management with Scrum.
64
Schwaber, K. (s.f.). SCRUM Development Process. Recuperado el 23 de Mayo de

2009, de http://www.jeffsutherland.com/oopsla/schwapub.pdf
Scrum Alliance. (s.f.). Recuperado el 26 de 02 de 2009, de

http://www.scrumalliance.org/articles/68-what-scrum-can-and-cannot-fix
Thomas Pyzdek, P. A. (2003). Quality Engineering Handbook.
Wikipeadi. (s.f.). Recuperado el 20 de 01 de 2009, de http://es.wikipedia.org/wiki/RUP
Wikipedia. (s.f.). Recuperado el 15 de 12 de 2008, de

http://es.wikipedia.org/wiki/Scrum

http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema

http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente
65
8 Anexo 1
8.1.1 Modelo iterativo e incremental
El modelo iterativo e incremental es un proceso de desarrollo de software creado en

respuesta a las debilidades del modelo tradicional de cascada. Para apoyar el desarrollo de
proyectos por medio de este modelo se han creado frameworks de los cuales los dos más
famosos son RUP (Rationa Unified Process y DSDM (Dynamic Systems Development Method).
El desarrollo incremental e iterativo también es una parte esencial de un tipo de metodología
llamadas metodologías ágiles, a las cuales pertenecen Scrum y Extreme Programming (XP)
entre otros.
La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de
programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha
aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema.
El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea
posible). Los pasos claves en el proceso son comenzar con una implementación simple de los
requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta
que el sistema completo esté implementado. En cada iteración, se realizan cambios en el
diseño y se agregan nuevas funcionalidades y capacidades al sistema.
El proceso en sí mismo consiste de:
Etapa de inicialización.
Etapa de iteración.
Lista de control de proyecto
8.1.1.1 Etapa de inicialización

Se crea una versión del sistema. La meta de esta etapa es crear un producto con el
que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una
muestra de los aspectos claves del problema y proveer una solución lo suficientemente simple
para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración, una lista
de control de proyecto se crea, y esta lista contiene un historial de todas las tareas que
necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas,
y áreas de rediseño de la solución ya existente. Esta lista de control se revisa periódica y
constantemente como resultado de la fase de análisis.
8.1.1.2 9.1.2 Etapa de iteración

Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de
proyecto, y el análisis de la versión más reciente del sistema. La meta del diseño e
implementación de cualquier iteración es ser simple, directa y modular, para poder soportar el
rediseño de la etapa o como una tarea añadida a la lista de control de proyecto. El código
66
puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis
de una iteración se basa en la retroalimentación del usuario y en el análisis de las
funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad,
usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del
proyecto se modifica bajo la luz de los resultados del análisis.
8.1.1.3 Lista de control de proyecto

Las guías primarias que guían la implementación y el análisis incluyen:
Cualquier dificultad en el diseño, codificación y prueba de una modificación

debería apuntar a la necesidad de rediseñar o recodificar.
Las modificaciones deben ajustarse fácilmente a los módulos fáciles de
encontrar y a los aislados. Si no es así, entonces se requiere algún grado de
rediseño.
Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si
dicha modificación no ocurre rápidamente, se debe aplicar algo de rediseño.
Las modificaciones deben ser más fáciles de hacer conforme avanzan las
iteraciones. Si no es así, hay un problema primordial usualmente encontrado
en un diseño débil o en la proliferación excesiva de parches al sistema.
Los parches normalmente deben permanecer solo por una o dos iteraciones.
Se hacen necesarios para evitar el rediseño durante una fase de
implementación.
La implementación existente debe ser analizada frecuentemente para
determinar que tan bien se ajusta a las metas del proyecto.
Las facilidades para analizar el programa deben ser utilizadas cada vez para
ayudar en el análisis de implementaciones parciales.
La opinión del usuario debe ser solicitada y analizada para indicar deficiencias
en la implementación referida por él.
67

Mejora de La Metodologia Scrum-Martin Casamayor

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Mejora de La Metodologia Scrum-Martin Casamayor

Caricato da

Copyright:

Formati disponibili

Universidad de Belgrano

Facultad de Tecnología Informática

Por Martín Alejandro Casamayor

Firma del alumno

ÍNDICE DE FIGURAS Y TABLAS ..................................................................... 5

1.1 Planteamiento y contexto del problema y trabajos relacionados .............................. 7

1.2 Objetivo ............................................................................................................................ 8

1.4 Delimitaciones ................................................................................................................. 8

2 MARCO TEÓRICO .................................................................................... 10

2.1 Metodología ágil ............................................................................................................ 10

2.2 Scrum ............................................................................................................................. 17

3.1 Análisis comparativo entre metodologías .................................................................. 33

3.2 Inconvenientes de Scrum ............................................................................................. 34

3.3 ¿Qué intentamos realizar? ........................................................................................... 36

4.1 ¿Cómo saber si Scrum está funcionando? Puntos claves y débiles de la

4.2 Mejora de la metodología de Scrum ............................................................................ 44

Índice de figuras y tablas

En el inicio de todo proyecto informático es necesario averiguar de qué manera van a

1.1 Planteamiento y contexto del problema y trabajos

Scrum es una metodología de gestión de proyectos relativamente reciente. A pesar de

Buscar y encontrar alternativas para mejorar la implementación de la Metodología ágil

Las recomendaciones que surgen de este trabajo se basan en la experiencia personal

La última delimitación consiste en la tecnología de codificación a emplear para el

2.1 Metodología ágil

2.1.1 El Manifiesto Ágil

Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

2.1.2 Principios: producto, cliente y equipo

El principio de metodología ágil también modifica el concepto de lo que se conoce

2.1.3 Metodología Tradicional versus Metodología Ágil

Metodología Ágil Metodología Tradicional

En qué se basa Basada en heurísticas Basadas en normas

Cambios durante el proyecto Especialmente preparada Cierta resistencia a los cambios.

Quién la impone Impuesta internamente (por Impuesta por un tercero.

Procesos Procesos menos Procesos muchos más

Tipo de contratos existentes No existen contratos Existe un contrato prefijado.

El equipo Grupos pequeños (menos de Grupos grandes y

Artefactos Pocos artefactos. Muchos artefactos.

Roles Pocos roles. Muchos roles.

Diseño y arquitectura Menos énfasis en la La arquitectura del software es

Entregas El cliente ve progresos en El cliente ve solo la versión final.

Definición de requisitos Los requisitos pueden Los requisitos se establecen al

Tabla 2.1.3-1 Metodología ágil vs Metodología Tradicional (José H. Canós P. L.).

Tabla 2.1.3-2 Uso de las metodologías ágiles

Gráfico 2.1.3-1 Uso de las metodologías ágiles

Cascada Espiral Iterativo Scrum

Procesos Requerido Requerido Requerido Planificación y

Producto final Determinado Determinado Determinada Determinada

Costo del Determinado Variable Determinada Determinada

Fecha de Determinado Variable Determinada Determinada

Estudio del En etapa de En la planificación Al final de cada En todo

Cascada Espiral Iterativo Scrum

Flexibilidad y Limitado Limitado Limitado Ilimitado

Transferencia El El entrenamiento es El El equipo

Probabilidad de Baja Media - Baja Media Alta

2.2.1 La historia de Scrum

Scrum es una metodología ágil de gestión de software, que ayuda a administrar,

Gráfico 2.2.3-1 El flujo de trabajo en Scrum

Los componentes y conceptos empleados en Scrum son:

2.2.3.1 Las reuniones

2.2.3.2 Los elementos

2.2.3.3 Los roles o responsabilidades

2.2.3.4 Responsabilidad del producto: El propietario del producto

2.2.3.5 Responsabilidad del desarrollo: El equipo

2.2.3.6 Responsabilidad del funcionamiento de Scrum (Scrum Manager)