Propuesta para La Aplicación de Metodologías Ágiles en La Gestión de Proyectos

INSTITUTO SUPERIOR POLITÉCNICO
“JOSÉ ANTONIO ECHEVERRÍA”
FACULTAD DE INGENIERÍA INFORMÁTICA
Propuesta para la aplicación de metodologías ágiles en la

gestión de proyectos de la DSI-CUJAE.
Presentado por:
Alejandro Carmenates Palenzuela ( acarmenates@ceis.cujae.edu.cu )
Tutores:
MSc. José Angel Franco Navarro

MSc. Yoelys Ronda Amador
CUJAE, Octubre de 2012

La Habana
Índice
INTRODUCCIÓN ................................................................................................................................................................1
CAPÍTULO 1: FUNDAM ENTOS TEÓRICOS ..............................................................................................................4
1.1 Introducción........................................................................................................................................................4
1.2 Metodologías convencionales versus metodologías ágiles ........................................................................4
1.3 Modelo ágil de desarrollo de software ...........................................................................................................6
1.4 El Manifiesto Ágil. Valores y principios .......................................................................................................7
1.5 Algunas prácticas...............................................................................................................................................9
1.5.1 Planificación, Historias de usuario ............................................................................................................9
1.5.2 Programación en pareja (Pair Programming).........................................................................................10
1.5.3 Integración continua (Countinuous integration)....................................................................................10
1.5.4 Refactorización. ..........................................................................................................................................11
1.5.5 Desarrollo dirig ido por pruebas (Test Driven Develop ment). ............................................................11
1.6 Metodologías destacadas................................................................................................................................12
1.6.1 Scru m ............................................................................................................................................................12
1.6.2 eXtreme Programming ...............................................................................................................................15
1.6.3 Lean So ftware Develop ment.....................................................................................................................16
1.6.4 Kanban ..........................................................................................................................................................16
1.6.5 Crystal Methodologies ...............................................................................................................................18
1.6.6 Dynamic Software Development Method ..............................................................................................18
1.6.7 Feature-driven Development ....................................................................................................................18
1.7 Evaluando Metodologías................................................................................................................................19
1.7.1 Framework de Evaluación .........................................................................................................................19
1.7.2 Aplicación del Framework ........................................................................................................................20
1.7.3 Conclusiones de la evaluación..................................................................................................................21
1.8 Scru m y Kanban para la gestión ágil de proyectos ....................................................................................22
1.9 Conclusiones ....................................................................................................................................................23
CAPÍTULO 2: DISEÑO Y EJECUCIÓN DEL EXPERIM ENTO ............................................................................24
2.1 Introducción......................................................................................................................................................24
2.2 Visión global del experimento ......................................................................................................................24
2.3 Objetivos del experimento .............................................................................................................................25
2.4 Contexto del experimento ..............................................................................................................................27
2.4.1 Equipo ...........................................................................................................................................................28
2.4.2 Roles..............................................................................................................................................................29
2.4.3 Herramientas................................................................................................................................................29
2.5 Definición de mediciones...............................................................................................................................29
2.6 Desarrollo utilizando Scru m ..........................................................................................................................32
2.6.1 Pre-Game......................................................................................................................................................32
2.6.2 Sprint 1 .........................................................................................................................................................33
2.6.3 Sprint 2 .........................................................................................................................................................35
2.6.4 Sprint 3 .........................................................................................................................................................37
2.6.5 Sprint 4 .........................................................................................................................................................38
2.6.6 Sprint 5 .........................................................................................................................................................39
2.7 Desarrollo utilizando Kanban........................................................................................................................41
2.7.1 Iteración 1.....................................................................................................................................................41
2.7.2 Iteración 2.....................................................................................................................................................43
2.8 Conclusiones ....................................................................................................................................................44
CAPÍTULO 3: ANÁ LISIS DE RESULTADOS ...........................................................................................................46
3.1 Introducción......................................................................................................................................................46
3.2 Características de los productos durante el desarrollo ..............................................................................46
3.3 Aspectos de agilidad en el desarrollo ...........................................................................................................49
3.4 Calidad en productos obtenidos ....................................................................................................................51
3.5 Esfuerzo de adaptación ...................................................................................................................................52
i
3.6 Satisfacción general del equipo.....................................................................................................................55
3.7 Resumen de análisis de las metodologías Scrum y Kanban.....................................................................56
3.7.1 Semejan zas...................................................................................................................................................56
3.7.2 Diferencias ...................................................................................................................................................57
3.8 Conclusiones ....................................................................................................................................................57
CAPÍTULO 4: DESA RROLLO DEL SISTEMA GESTOR DE CONEXIONES ..................................................59
4.1 Introducción......................................................................................................................................................59
4.2 Gestor de Conexiones .....................................................................................................................................59
4.3 Desarrollo con Scru m .....................................................................................................................................61
4.3.1 Artefactos .....................................................................................................................................................62
4.4 Conclusiones ....................................................................................................................................................69
CONCLUSIONES ..............................................................................................................................................................70
RECOM ENDACIONES....................................................................................................................................................71
REFERENCIAS BIBLIOGRÁFICAS ............................................................................................................................72
ANEXOS ..............................................................................................................................................................................74
Anexo A. Imágenes de los tableros de Scru m y Kanban...................................................................................74
Anexo B. Ejemp lo de tarjeta de historia de usuario ...........................................................................................76
Anexo C. Product Backlog inicial de Estimation Tool .....................................................................................77
Anexo D. Reglas para evaluar las iteraciones .....................................................................................................78
Anexo E. Principales interfaces de usuario de las aplicaciones Estimation Tool y Open Sky. .................79
ii
Índice de Tablas
Tabla 1.1Framework de Evaluación de Metodologías Ágiles .....................................................................................19
Tabla 1.2Aplicación del Framework a Scru m y XP ......................................................................................................21
Tabla 2.1Nivel académico y dedicación del equipo ......................................................................................................28
Tabla 2.2Med iciones del experimento.............................................................................................................................30
Tabla 2.3Síntesis del Product Backlog ............................................................................................................................33
Tabla 2.4Resumen sprint 1 ................................................................................................................................................35
Tabla 2.9Síntesis de la pila de producto..........................................................................................................................42
Tabla 2.10Resumen del desarrollo de Open Sky hasta la semana 4 ...........................................................................43
Tabla 2.11Resumen del desarrollo de Open Sky segunda iteración ...........................................................................44
Tabla 3.1Diferencias entre Scru m y Kanban..................................................................................................................57
Tabla4.1Personas y roles del proyecto ............................................................................................................................62
iii
Índice de Figuras
Figura 3.1Evolución del Product Backlog durante el desarrollo de Estimat ion Tool .............................................46
Figura 3.2Evolución de la pila de producto durante el desarrollo de Open Sky ......................................................47
Figura 3.3Evolución del porcentaje de realización del Product Backlog de Estimation Tool ...............................47
Figura 3.4Evolución del porcentaje de realización de la p ila de producto de Open Sky........................................47
Figura 3.5Evolución del código de Estimat ion Tool ....................................................................................................48
Figura 3.6Evolución del código de Open S ky................................................................................................................48
Figura 3.7Evolución del impacto en las clases de Estimat ion Tool ...........................................................................49
Figura 3.8Evolución del impacto en las clases de Open Sky ......................................................................................49
Figura 3.9Esfuerzo dedicado a Estimat ion Tool en cada sprint ..................................................................................50
Figura 3.10Esfuerzo dedicado a Open Sky en cada iteración .....................................................................................50
Figura 3.11Evolución de la productividad durante el desarrollo de Estimation Tool .............................................51
Figura 3.12Evolución de la productividad durante el desarrollo de Open Sky ........................................................51
Figura 3.13Evolución de la tasa de errores en el producto Estimation Tool ............................................................52
Figura 3.14Evolución de la tasa de errores en el producto Open Sky .......................................................................52
Figura 3.15Distribución del esfuerzo en tareas relacionadas con Scrum ..................................................................53
Figura 3.16Distribución del esfuerzo en tareas relacionadas con Kanban ................................................................53
Figura 3.17Evolución en la calificación de los sprints .................................................................................................54
Figura 3.18Evolución en la calificación de las iteraciones ..........................................................................................54
Figura 3.19Evolución de la satisfacción del equipo y del cliente durante el desarrollo de Estimation Tool ......55
Figura 3.20Evolución de la satisfacción del equipo y del cliente durante el desarrollo de Open Sky .................55
Figura 4.1 Diagrama esquemático de la interfaz de Gestor de Conexiones..............................................................60
Figura 4.2 Diagrama de clases. Gestor de Conexiones.................................................................................................61
Figura 4.3 Product Backlog inicial de Gestor de Conexiones.....................................................................................64
Figura 4.4 Sprint Backlog del Sprint 1 ............................................................................................................................65
Figura 4.5 Sprint Backlog del Sprint 2 ............................................................................................................................66
Figura 4.6 Gráfico de avance del Sprint 1 ......................................................................................................................67
Figura 4.7 Gráfico de avance del Sprint 2 ......................................................................................................................68
Figura A.1: Imagen del tablero de Scru m durante el Sprint 3 .....................................................................................74
Figura A.2: Imagen del tablero Kanban durante el desarrollo ....................................................................................75
Figura A.3: Formu lario para la creación de un nuevo modelo de bloques................................................................79
Figura A.4: Modelo sin estimar con 25181 muestras ...................................................................................................80
Figura A.5: Resultados de estimación .............................................................................................................................81
Figura A.6: Leyenda para los bloques estimados ..........................................................................................................82
Figura A.7: Menú para la generación de muestras aleatorias ......................................................................................83
Figura A.8: Aplicación del cono de restricción al modelo en Open Sky ...................................................................84
Figura A.9: Modelo luego de aplicar algorit mo de Lerch-Grossman en Open Sky ................................................85
iv
RESUMEN
La constante y rápida evolución en la industria de software ha obligado a replantear los

principios sobre los que se sustenta el desarrollo de software convencional. El mercado
actual se caracteriza por el rápido desarrollo de aplicaciones y la reducción de la vida de
los productos. En este entorno inseguro la ventaja competitiva se encuentra en aumentar
la productividad y satisfacer las variantes exigencias del cliente en el menor tiempo
posible. Ante esta situación, cabe reflexionar sobre el grado de adaptación de las
metodologías convencionales a estas circunstancias. La mayoría de los estudios
coinciden en que el carácter regulador y la fuerte dependencia de planificaciones previas
al desarrollo que definen a las metodologías convencionales, implican que resulten
excesivamente pesadas para cubrir las necesidades de un amplio porcentaje del mercado
de software actual. (1)
En los últimos años las metodologías ágiles han irrumpido con fuerza como una tentativa
de despojar al desarrollo de software de las normativas planteadas por las metodologías
convencionales, y son muchas las organizaciones de punta con creciente interés en las
mismas. Teniendo en cuenta estudios recientes que indican que la productividad y calidad
del software aumenta aplicando los principios y valores que rigen las metodologías ágiles,
se decidió realizar un estudio de las metodologías más reconocidas de esta naturaleza,
con el objetivo de comprobar la eficiencia generada con su utilización y extraer prácticas
esenciales para un desarrollo exitoso, aplicándolas en el desarrollo de un proyecto real.
(27)
v
INTRODUCCIÓN
Actualmente el desarrollo de software es una actividad que necesariamente debe ser

guiada por una metodología. Estas imponen un proceso disciplinado con el fin de hacerlo
más predecible y eficiente. La crítica más frecuente a estas metodologías es que son
burocráticas. Hay tanto que hacer para seguir la metodología que el ritmo entero del
desarrollo se retarda.
En el Instituto Superior Politécnico José Antonio Echeverría, la Dirección de Soluciones
Informáticas (DSI) está constituida principalmente por ingenieros recién graduados y un
pequeño número de especialistas de mayor experiencia. Los proyectos abordados por la
DSI se caracterizan por tener arquitecturas bien definidas y conocidas para los
desarrolladores, facilitando el dominio de las herramientas y tecnologías utilizadas, por lo
que son proyectos con alcance bien definido de antemano.
En la DSI se han tenido varias experiencias de desarrollo de software empleando
variantes de RUP (Rational Unified Process) sin embargo el uso de esta metodología en
la práctica no ha mostrado grandes ventajas, y puede decirse que el gran número de
artefactos y actividades implicadas ha derivado en una demora del desarrollo, y
dificultades para el cumplimiento de los cronogramas acordados. Debido a esto, mucha
de la documentación que implica RUP, queda sin actualizar o simplemente no se realiza,
al tener que pasar por alto ciertas actividades. De igual modo, las fases de pruebas no
pueden ser ejecutadas de manera exhaustiva por la falta de tiempo, incrementando así la
posibilidad de que existan errores en los productos finales.
Adicionalmente se hace cada día más usual que los clientes soliciten la ejecución de
procesos ágiles como Scrum, sin que se tenga conocimiento práctico en la DSI del uso de
los mismos.
En aras de solucionar la situación existente, se abordó la opción de aplicar prácticas
ágiles en el proceso de desarrollo. Tras un profundo análisis de la bibliografía disponible,
fueron seleccionadas, específicamente para la gestión de los proyectos, dos metodologías
o herramientas de proceso: Scrum y Kanban, las que serían complementadas por varias
prácticas de naturaleza más ingenieril.
Luego de examinar la situación anterior se puede identificar como problema la siguiente
interrogante:
¿Cuál de las metodologías seleccionadas para la gestión de procesos de desarrollo de
software ágiles resulta más factible para aplicar en la DSI?
1
Teniendo en cuenta el problema planteado con anterioridad y para llevar a cabo la
realización de este trabajo es preciso definir lo que se considera como objeto de estudio y
campo de acción.
El objeto de estudio se centra en el modelo ágil de desarrollo de software.
El campo de acción está orientado a las propuestas metodológicas concretas de Scrum,

Kanban, Extreme Programming (XP), Lean Software Development, y Crystal.
Para dar solución al problema antes identificado se propone como objetivo general:
Evaluar las propuestas metodológicas de desarrollo ágil de Scrum y Kanban, con vistas a
su aplicabilidad práctica en el entorno de proyectos de desarrollo de la Dirección de
Soluciones Informáticas.
Se derivan del objetivo general los siguientes objetivos específicos:
Estudiar el estado del arte en materia de modelos de desarrollo ágiles.

Caracterizar las metodologías en cuestión, Scrum y Kanban.
Realizar una comparación de ambas metodologías, basados en la puesta en
práctica de estas en un experimento.
Desarrollar un proyecto real donde se ponga en práctica los planteamientos ágiles
y la propuesta metodológica seleccionada.
Como valor práctico, el presente trabajo brindará una comparación precisa entre las
metodologías Scrum y Kanban, exponiendo las fortalezas y debilidades de cada una, así
como las ventajas que traería aplicarlas. Además, se expone el uso de una serie de
prácticas ágiles, que al ser incorporadas en el flujo de trabajo, conformarían un proceso
de desarrollo de software con un elevado potencial de éxito, permitiendo culminar los
productos en periodos de tiempo relativamente más cortos que los procesos de
metodologías convencionales, lo que garantizaría la no existencia de retrasos en los
plazos de entrega a los clientes, logrando una mayor satisfacción en estos. El desarrollo
2
de un proyecto concreto bajo los principios y métodos identificados, servirá para validar en
el entorno real existente en la DSI, el uso de métodos ágiles para el desarrollo.
3
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS
1.1 Introducción
Este trabajo se encuentra enmarcado principalmente en el estudio del modelo ágil de

desarrollo de software. En este capítulo se describe en detalle la situación actual de la
investigación en esta área.
1.2 Metodologías convencionales versus metodologías ágiles

Tradicionalmente se ha tendido a desarrollar software a través de metodologías que
dirigían el proceso de desarrollo de manera un tanto rígida que, cada vez más, se
demuestra como una equivocación en las actuales características de dinamismo y
variabilidad del mercado de software. En este entorno inestable, que tiene como factor
inherente el cambio y la evolución rápida y continua, la ventaja competitiva se encuentra
en aumentar la productividad y satisfacer las variantes necesidades del cliente en el
menor tiempo posible para proporcionar un mayor valor al negocio.
Sin embargo, las metodologías convencionales presentan diversos problemas a la hora

de abordar un amplio rango de proyectos, entre los que podemos destacar los siguientes:
Perciben la captura de requisitos del proyecto como una fase previa al desarrollo del
mismo que, una vez completada, debe proporcionar una fotografía exacta de qué desea el
cliente. Se trata de evitar a toda costa que se produzcan cambios en el conjunto de
requisitos inicial, puesto que a medida que avanza el proyecto resulta más costoso
solucionar los errores detectados o introducir modificaciones, y pretenden delegar toda la
responsabilidad económica en el cliente en caso de que estos cambios de requisitos se
produzcan. Por este motivo, se les conoce también como metodologías predictivas. Sin
embargo, el esfuerzo, tanto en coste como en tiempo, que supone hacer una captura
detallada de todos los requisitos de un proyecto al comienzo del mismo es enorme y rara
vez se ve justificado con el resultado obtenido. Además, muchas veces el cliente no
conoce sus propias necesidades con la profundidad suficiente como para definirlas de
forma exacta en un inicio y, a menudo, estas necesidades y sus prioridades varían
durante la vida del proyecto. Establecer mecanismos de control es una de las opciones
existentes para protegerse de estos cambios, aunque frecuentemente provocan la
insatisfacción de los clientes, que perciben el desarrollo del proyecto como algo inflexible
4
que no se adapta a sus necesidades y que si lo hace repercute negativamente en costes
añadidos al presupuesto del proyecto. (28)
Por otro lado, en muchos casos el proceso de desarrollo convencional está oprimido por
excesiva documentación no siempre útil. Un porcentaje elevado del tiempo de desarrollo
de un producto de software se dedica o, desde el punto de vista de las metodologías
ágiles, se malgasta en crear documentación que finalmente no se utiliza y que, por tanto,
no aporta valor al negocio. Además, esta documentación innecesaria entorpece las
labores de mantenimiento de la propia documentación útil lo que provoca que se obvie
esta tarea agudizando, de este modo, el coste en los trabajos de documentación
posteriores. Evidentemente, estas circunstancias no se adaptan a las restricciones de
tiempo del mercado actual.
Otra dificultad añadida al uso de metodologías convencionales es la lentitud del proceso

de desarrollo. Es difícil para los desarrolladores entender un sistema com plejo en su
globalidad lo que provoca que las diferentes etapas del ciclo de vida convencional
transcurran lentamente. Dividir el trabajo en módulos abordables ayuda a minimizar los
fallos y, por tanto, el coste de desarrollo. Además, permite liberar funcionalidad
progresivamente, según indiquen los estudios de las necesidades del mercado que
aportan mayor beneficio a la organización. En la feroz competencia del mercado vigente,
en la que los productos quedan obsoletos rápidamente, se pide básicamente rapidez,
calidad y reducción de costes, pero para asumir estos retos, es necesario tener agilidad y
flexibilidad. (2)
Asimismo, las metodologías convencionales tienden a acumular los riesgos y dificultades

que surgen en el desarrollo del producto al final del proyecto, repercutiendo en retrasos en
la entrega de productos o influyendo en la incorrecta ejecución de las últimas fases del
ciclo de vida.
En contraposición a las metodologías convencionales, las metodologías ágiles aparecen

como alternativa atractiva para adaptarse a este entorno. Estas son apropiadas cuando
los requisitos son emergentes y cambian rápidamente. De este modo, presentan diversas
ventajas en el contexto actual (5):
Capacidad de respuesta a cambios a lo largo del desarrollo ya que no los perciben

como un lastre sino como una oportunidad para mejorar el sistema e incrementar
5
la satisfacción del cliente, considerando la gestión de cambios como un aspecto
característico del propio proceso de desarrollo de software.
Entrega continúa y en plazos breves de software funcional lo que permite al cliente
verificar el desarrollo del proyecto, ir disfrutando de la funcionalidad del producto
progresivamente y comprobando si satisface sus necesidades, mejorando de esta
forma su satisfacción. Además, el desarrollo en ciclos de corta duración favorece
que los riesgos y dificultades se repartan a lo largo del desarrollo del producto,
principalmente al comienzo del mismo y permite ir aprendiendo de estos riesgos y
dificultades.
Trabajo conjunto entre el cliente y el equipo de desarrollo con una comunicación
directa que pretende mitigar malentendidos, que constituyen una de las principales
fuentes de errores en productos de software, y exceso de documentación
improductiva.
Importancia de la simplicidad, eliminando el trabajo innecesario que no aporta
valor al negocio.
Atención continua a la excelencia técnica y al buen diseño para mantener una alta
calidad de los productos.
Mejora continua de los procesos y el equipo de desarrollo, entendiendo que el
éxito depende de tres factores: éxito técnico, éxito personal y éxito organizacional.
1.3 Modelo ágil de desarrollo de software

Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería del
software que están acaparando gran interés y controversia. A mediados de los años 90
comenzó a forjarse una definición moderna de desarrollo ágil del software como una
reacción contra las metodologías utilizadas hasta el momento, consideradas
excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de
planificaciones detalladas previas al desarrollo. En el año 2001 miembros destacados de
la comunidad software, incluyendo algunos de los creadores o impulsores de las
metodologías en software, se reunieron y adoptaron el nombre de “Metodologías ágiles”
para denominar a esta nueva corriente de desarrollo. Poco después, algunos de estos
miembros formaron la conocida como “Alianza Ágil”, una organización sin ánimo de lucro
que promueve el desarrollo ágil de aplicaciones. Desde ese momento hasta la actualidad
las metodologías ágiles han ido adquiriendo gran auge dentro de la industria de software y
6
las organizaciones de punta comienzan a apostar por este nuevo enfoque para desarrollar
sus productos. (4)
1.4 El Manifiesto Ágil. Valores y principios

Continuamente estamos utilizando el concepto de agilidad para definir estas
metodologías, pero ¿qué significa ser ágil desde una perspectiva software? Basados en el
consenso de varias definiciones contemporáneas, Qumer y Henderson-Sellers ofrecieron
la siguiente definición de agilidad:“La agilidad es un comportamiento persistente o
habilidad, de entidad sensible, que presenta flexibilidad para adaptarse a cambios,
esperados o inesperados, rápidamente; persigue la duración más corta en tiempo; usa
instrumentos económicos, simples y de calidad en un ambiente dinámico; y utiliza los
conocimientos y experiencia previos para aprender tanto del entorno interno como del
externo.”(1)
Por tanto, el desarrollo ágil no especifica unos procesos o métodos que seguir, aunque
bien es cierto que han aparecido algunas prácticas asociadas a este movimiento. El
desarrollo ágil es más bien una filosofía de desarrollo de software. El punto de partida se
establece en las ideas emanadas del Manifiesto Ágil, un documento que resume la
filosofía ágil estableciendo cuatro valores y doce principios. (5)
Según el Manifiesto se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas. La gente es el principal factor de éxito de un proceso software. Este primer
valor expresa que es preferible utilizar un proceso indocumentado con buenas
interacciones personales que un proceso documentado con interacciones hostiles. Se
considera que no se debe pretender construir primero el entorno y esperar que el equipo
se adapte automáticamente sino al revés, construir primero el equipo y que éste configure
su propio entorno. El talento, la habilidad, la capacidad de comunicación y de tratar con
personas son características fundamentales para los miembros de un equipo ágil. (5)
Desarrollar software que funcione por encima de una completa documentación. Este valor
es utilizado por muchos detractores de las metodologías ágiles que argumentan que éstas
son la excusa perfecta para aquellos que pretenden evitar las tareas menos gratificantes
del desarrollo de software como las tareas de documentación. Sin embargo, el propósito
de este valor es acentuar la supremacía del producto por encima de la documentación. El
7
objetivo de todo desarrollador es obtener un producto que funcione y cumpla las
necesidades del cliente y la documentación es un artefacto que utiliza para cumplir su
objetivo. Por tanto, no se trata de no documentar sino de documentar aquello que sea
necesario para tomar de forma inmediata una decisión importante. Los documentos deben
ser cortos y centrarse en lo fundamental. Dado que el código es el valor principal que se
obtiene del desarrollo se enfatiza en seguir ciertos estándares de programación para
mantener el código legible y documentado. (5)
La colaboración con el cliente por encima de la negociación contractual. Se propone una

interacción continua entre el cliente y el equipo de desarrollo de tal forma que el cliente
forme un tándem con el equipo de desarrollo. Se pretende no diferenciar entre las figuras
cliente y equipo de desarrollo sino que se apuesta por un solo equipo persiguiendo un
objetivo común. (5)
Responder a los cambios más que seguir estrictamente un plan. Planificar el trabajo a
realizar es muy útil y las metodologías ágiles consideran actividades específicas de
planificación a corto plazo. No obstante, adaptarse a los cambios es vital en la industria de
software actual y, por tanto, también consideran mecanismos para tratar los cambios de
prioridades. La regla es “planificar es útil. Seguir un plan es útil hasta que el plan se
distancia de la situación actual. Pender de un plan desactualizado es caminar por un
callejón sin salida”. (5)
Para cumplir estos valores se siguen doce principios que establecen algunas diferencias
entre un desarrollo ágil y uno convencional (5):
1. La prioridad es satisfacer al cliente mediantes tempranas y continuas entregas de

software que le aporten valor.
2. Dar la bienvenida a los cambios de requisitos. Se capturan los cambios para que el
cliente tenga una ventaja competitiva.
3. Liberar software que funcione frecuentemente, desde un par de semanas a un par de

meses, con el menor intervalo de tiempo posible entre entregas.
4. Los miembros del negocio y los desarrolladores deben trabajar juntos diariamente a lo
largo del proyecto.
8
5. Construir el proyecto en torno a individuos motivados. Darles el entorno y apoyo que
necesiten y confiar en ellos para conseguir finalizar el trabajo.
6. 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.
7. El software que funciona es la principal medida de progreso.
8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
10. La simplicidad es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos que se auto
organizan.
12. En intervalos regulares el equipo debe reflexionar sobre cómo ser más efectivo y
según estas reflexiones ajustar su comportamiento.
Estos principios marcan el ciclo de vida de un desarrollo ágil, así como las prácticas y
procesos a utilizar.
1.5 Algunas prácticas

Aunque el movimiento ágil está sustentado por valores y principios para el desarrollo de
productos de software, la mayoría de estas metodologías tienen asociadas un conjunto de
prácticas, en muchos casos comunes, que buscan la agilidad en el desarrollo. Entre las
más relevantes están: planificación, programación en parejas (Pair Programming),
integración continua, refactorización y desarrollo dirigido por pruebas (Test Driven
Development).
1.5.1 Planificación, Historias de usuario

Mientras que las metodologías convencionales centran la ingeniería de requisitos en
habilidades de predicción basándose en férreas planificaciones previas al desarrollo, las
metodologías ágiles perciben la gestión de cambios como un aspecto inherente al
proceso de desarrollo de software, considerando planificaciones continuas, más flexibles y
en cortos plazos, que respondan mejor a los cambios en las necesidades del cliente.
9
Con el objetivo de disminuir el coste que supone la etapa de planificación en las
metodologías convencionales, las ágiles simplifican las tareas de gestión y
documentación de las necesidades del sistema. Apuestan por involucrar de una forma
más intensa al cliente a lo largo de todo el proceso de desarrollo, de forma que, la
comunicación directa y frecuente retroalimentación son las prácticas más importantes
para la planificación y especificación de requisitos en estas metodologías. (8)
En este proceso de definición de las necesidades del sistema que guiará el desarrollo, se
utilizan las llamadas historias de usuario para detallar, en un lenguaje cercano al cliente,
la funcionalidad que debe satisfacer el sistema. Las historias de usuario se descomponen
en tareas que deberán ser realizadas para cumplir con la funcionalidad que se solicita.
Nótese que la estimación de tiempo no es una restricción fija, simplemente constituye una
aproximación inicial. Se considera que las historias de usuario deben cumplir seis
características: independientes, negociables, valorables, estimables, pequeñas y
comprobables. (2)
1.5.2 Programación en pareja (Pair Programming)

Una de las prácticas más utilizadas en metodologías ágiles, sobre todo en sistemas de
alta complejidad, es la programación en parejas, que establece que la producción de
código se realice con trabajo en parejas de programadores. El utilizar Pair Programming
en un proyecto no implica que todas las líneas de código sean escritas por una pareja, ya
que mientras una persona está escribiendo el código, la otra puede estar verificando
errores, pensando en alternativas mejores, identificando casos de prueba, pensando en
aspectos de diseño, etc. El objetivo principal de esta técnica es disminuir la tasa de
errores, mejorar el diseño y aspectos como la satisfacción de los programadores. No
obstante, algunos estudios indican que se trata de una técnica intensa y estresante para
los propios programadores, aunque admiten que acelera el proceso de desarrollo. (3)
Otro detalle a tener en cuenta es las habilidades y capacidades de los miembros de la

pareja. Si existe una diferencia importante entre ellos, puede llegar a ser una práctica
frustrante para ambos. En este caso concreto, el Pair Programming ha de ser visto como
una técnica de aprendizaje. (3)
1.5.3 Integración continua (Countinuous integration)

La integración continua pretende mitigar la complejidad que el proceso de integración
suele tener asociada en las metodologías convencionales, superando, en determinadas
10
circunstancias, la propia complejidad de la codificación. El objetivo es integrar cada
cambio introducido, de tal forma que pequeñas piezas de código s ean integradas de
forma continua, ya que se parte de la base de que cuanto más se espere para integrar
más costoso e impredecible se vuelve el proceso. Así, el sistema puede llegar a ser
integrado y construido varias veces en un mismo día.
Para que esta práctica sea viable es imprescindible disponer de una batería de test,
preferiblemente automatizados, de tal forma, que una vez que el nuevo código está
integrado con el resto del sistema se ejecute toda la batería de pruebas. Si son pasados
todos los test del sistema, se procede a la siguiente tarea. En caso contrario, aunque no
falle el nuevo módulo que se quiere introducir en el sistema, se ha de regresar a la versión
anterior, pues ésta ya había pasado la batería de pruebas. (4)
1.5.4 Refactorización.
Actividad constante en los desarrollos ágiles cuyo objetivo es mejorar el diseño de un
sistema sin influir en su funcionalidad. Se pretende reestructurar el código para eliminar
duplicaciones, mejorar su legibilidad, simplificarlo y hacerlo más flexible de forma que se
faciliten los posteriores cambios. Recordemos que el código que funciona es el principal
aporte de valor para las metodologías ágiles, por encima de la documentación, por lo que
se enfatiza en que éste sea legible y permita la comunicación entre desarrolladores. (3)
1.5.5 Desarrollo dirigido por pruebas (Test Driven Development).

Al utilizar esta práctica la producción de código está dirigida por las pruebas.
Concretamente, se trata de escribir las pruebas que validarán el sistema antes de
comenzar a construirlo, idealmente que sea el propio cliente quien las escriba. De esta
forma, ante cada modificación del sistema la batería completa de pruebas es ejecutada.
Esta práctica constituye, por tanto, la primera línea para garantizar la calidad del producto,
pues ésta se considera en términos de la correcta funcionalidad que se le ofrece al
cliente. Entre las ventajas que aporta el desarrollo dirigido por pruebas podemos destacar
que disminuye el tiempo dedicado a solucionar errores y genera un sentimiento de
confianza de éxito del proyecto en el equipo. (4)
No obstante, el hecho de que aspectos tan importantes como la cohesión o el

acoplamiento de los módulos pase a un segundo plano en el desarrollo a favor de la
funcionalidad, implica la necesidad de realizar constantes etapas de refactorización que
permitan mantener la calidad del código.
11
Como se puede apreciar, a pesar de la reciente aplicación de las metodologías ágiles la
mayoría de las prácticas propuestas no son novedosas sino que de alguna manera ya
habían sido propuestas en ingeniería del software. El mérito de las metodologías ágiles es
proponer una aplicación conjunta, equilibrada y efectiva de forma que se complementen
con ideas desde la perspectiva del negocio, los valores humanos y el trabajo. (4)
1.6 Metodologías destacadas

A continuación se describen brevemente algunas de las metodologías más populares,
teniendo en cuenta que han sido expuestas en conferencia por Martín Salías, arquitecto
de software miembro de la Alianza Ágil y también han sido tratadas en artículos
publicados por Martin Fowler, igualmente miembro de la Alianza Ágil y co-autor del
Manifiesto Ágil. (5)
1.6.1 Scrum
Scrum es el término que describe una forma para desarrollar productos iniciada en Japón.
No se trata de un concepto nuevo, sino que ya en 1987 Ikujiro Nonaka y Hirotaka
Takeuchi acuñaron este término, una estrategia utilizada en rugby en la que todos los
integrantes del equipo actúan juntos para avanzar la pelota y ganar el partido, para
denominar un nuevo tipo de proceso de desarrollo de productos. Escogieron este nombre
por las similitudes que consideraban que existían entre el juego del rugby y el tipo de
proceso que proponían: adaptable, rápido, auto-organizable y con pocos descansos. (6)
Scrum es un proceso para la gestión y control del producto que trata de eliminar la
complejidad en estas áreas para centrarse en la construcción de software que satisfaga
las necesidades del negocio. Es simple y escalable, ya que no establece prácticas de
ingeniería del software sino que se aplica o combina, fácilmente, con otras prácticas
ingenieriles, metodologías de desarrollo o estándares ya existentes en la organización. (6)
Scrum se concentra, principalmente, a nivel de las personas y equipo de desarrollo que

construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de
forma eficiente obteniendo productos complejos y sofisticados. Podríamos entender
Scrum como un tipo de ingeniería social que pretende conseguir la satisfacción de todos
los que participan en el desarrollo, fomentando la cooperación a través de la auto-
organización. De esta forma se favorece la franqueza entre el equipo y la visibilidad del
producto. Pretende que no haya problemas ocultos u obstáculos que puedan poner en
peligro el proyecto. Los equipos se guían por su conocimiento y experiencia más que por
12
planes de proyecto formalmente definidos. La planificación detallada se realiza sobre
cortos espacios de tiempo lo que permite una constante retroalimentación que
proporciona inspecciones simples y un ciclo de vida adaptable. Así, el desarrollo de
productos se produce de forma incremental y con un control empírico del proceso que
permite la mejora continua. (7)
Cualquier desarrollo de software parte siempre de un mismo problema: conocer las

necesidades de los clientes. Scrum, al igual que el resto de las metodologías ágiles,
pretende no centrar las tareas de desarrollo en un conjunto de requisitos formalmente
definidos sino que aboga por la incorporación del cliente como un miembro más del
equipo. De este modo, no se considera el proceso de definición de requisitos como un fin
dentro del desarrollo del proyecto, sino que los requisitos aparecen implícitamente dentro
del contenido de las denominadas historias de usuario. (2)
Las historias de usuario son el elemento base que utiliza Scrum para describir las
características que el usuario espera que tenga el software que se va a desarrollar. Por lo
tanto, pueden incorporar tanto cuestiones relacionadas con las funciones del sistema
como con cualquier otro aspecto del mismo (restricciones, rendimiento, etc.). Las historias
de usuario se presentan desde la perspectiva del usuario. Así, no se describen utilizando
una terminología técnica sino que se escriben utilizando un lenguaje cercano al dominio
de la aplicación que se está desarrollando de forma que sea comprensible por los clientes
y por los desarrolladores. Las historias de usuario se construyen bajo un mismo esqueleto
que centra el foco de las características del producto. (8)
Primero se determina quién propone la historia de usuario.

Luego se describe la característica que se cubre con la historia de usuario.
Finalmente se especifica la razón por la que dicha característica es necesaria.
El proceso comienza con la fase de Pre-game, en la que se realiza de forma conjunta con
el cliente una definición sencilla y clara de las características que debe tener el sistema
que vaya a ser desarrollado, definiendo las historias de usuario que van a guiar el proceso
de desarrollo. El resultado de esta fase de Pre-game es lo que se denomina en Scrum
“Product Backlog”, que contiene una lista de todas las historias de usuario priorizadas así
como de las tareas que se deben llevar a cabo para la realización del proyecto. (7)
13
Una vez identificadas y priorizadas las historias de usuario del Product Backlog, se realiza
la separación de historias de usuario en etapas de corta duración (no más de 30 días)
denominadas Sprint. Para cada sprint se realiza una reunión de planificación de lo que se
va a llevar a cabo en ese sprint y se establece la fecha de finalización del mismo. El
objetivo es mover aquellas historias de usuario con mayor prioridad para el cliente al
denominado “Sprint Backlog”, que contiene el conjunto de tareas a desarrollar en ese
sprint, incluyendo diseño, desarrollo, pruebas, integración, etc. Las historias de usuario se
congelan en el Sprint Backlog de forma que durante dicho periodo no puedan producirse
cambios sobre los aspectos que se encuentran en fase de desarrollo. (7)
De forma iterativa, todos los días que dure el sprint, se realiza una reunión operativa,
informal y ágil con el equipo de desarrollo, de un máximo de quince minutos, en la que a
cada integrante del equipo se le hacen tres preguntas:
¿Qué tareas ha hecho desde la última reunión? Es decir, tareas realizadas en un

día.
¿Qué tareas realizará hoy?
¿Qué ayuda necesita para poder realizar este trabajo? Es decir, identificación de
obstáculos o riesgos que impiden o pueden impedir el normal avance.
Una vez finalizado el sprint se debería obtener parte del producto, un entregable o algo
que se pueda mostrar y que enseñe los avances acometidos en el Sprint. En este punto
se procede a una fase de revisión del proyecto para mostrar dichos avances e incorporar,
si fuera necesario, nuevas historias de usuario al Product Backlog. Para mantener la
calidad del producto se establece que una historia de usuario está 100% completa si
supera los test unitarios, pasa las pruebas de aceptación, supera los test adicionales para
mantener la calidad del producto, el código está construido e integrado satisfactoriamente,
está basado en un diseño construido sin duplicaciones, el código es claro, estructurado y
autodocumentado y, por supuesto, es aceptado por el cliente. (7)
Además, tras la realización de cada sprint se lleva a cabo una reunión retrospectiva que
permite aprender de los conocimientos y experiencias adquiridas hasta el momento y
mejorar de forma continua el proceso de desarrollo. Se revisará con el equipo los
objetivos marcados inicialmente en el Sprint Backlog concluido, se aplicarán los cambios y
ajustes si son necesarios, y se marcarán los aspectos positivos y los aspectos negativos
del sprint, que servirán de retroalimentación para el siguiente. Los elementos que servirán
14
de entrada y guiarán la planificación de un nuevo sprint serán el Product Backlog, las
capacidades o habilidades del equipo, las condiciones que en ese momento se den del
negocio, el avance tecnológico que se haya podido producir y el incremento que se
pretenda hacer al producto que se está desarrollando. De esta forma, en contraposición
con las metodologías convencionales, el proceso de desarrollo adquiere flexibilidad,
agilidad y capacidad para adaptarse a su entorno. (7)
La efectividad de la metodología para la gestión de proyectos se basa en un conjunto de

valores fundamentales que deben seguir todos los integrantes del equipo, principios sobre
los que reposan el resto de prácticas: compromiso, esmero, franqueza, respeto y valor.
Los miembros del equipo deben estar dispuestos a comprometerse con el objetivo de
cada sprint y del proyecto en general. Scrum proporciona al equipo toda la autoridad que
necesiten para obtener a cambio su compromiso. El equipo se tiene que comprometer a
hacer su trabajo. Cada miembro debe concentrar todos sus esfuerzos y habilidades en
cumplir con el trabajo que se han comprometido a realizar sin desviarse en otros
aspectos, realizando todas sus labores con esmero. Todos los aspectos del proyecto son
visibles para todo el equipo por lo que un valor fundamental es también la franqueza.
Además, los miembros del equipo están avalados por sus conocimientos y experiencias,
el respeto es un valor fundamental con cada uno de ellos. Finalmente, cada miembro del
equipo tiene que tener el coraje suficiente para comprometerse, actuar, ser transparente
en el desarrollo y respetar y hacer que le respeten. (7)
1.6.2 eXtreme Programming

También conocida como XP, es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo software. Aspectos como el trabajo
en equipo, el aprendizaje de los desarrolladores y propiciar un buen clima de trabajo son
pilares en esta metodología. Oficialmente fue creada en 1999 por Kent Beck, con la
publicación de su libro Extreme Programming Explained. (9)
XP se centra en la continua retroalimentación entre el cliente y el equipo de desarrollo, la

comunicación fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. Se define como una metodología
especialmente adecuada para proyectos con requisitos muy cambiantes e imprecisos,
donde existe un alto riesgo técnico. Como metodología pragmática, recoge las que
considera mejores prácticas para el desarrollo software, cuya aplicación disciplinada
15
pretende disminuir la curva exponencial del costo del cambio a lo largo del proyecto. Se
trata de doce prácticas: el juego de la planificación, entregas pequeñas, metáfora, diseño
simple, pruebas, refactorización, programación en parejas, propiedad colectiva del código,
integración continua, 40 horas por semana, cliente in-situ y estándares de programación.
(9)
Una posterior revisión de la metodología clasificó las prácticas en primarias, aquellas que
según Beck proporcionan una mejora inmediata independientemente de la metodología
que se esté siguiendo, y secundarias, que implican una mayor dificultad si no se tiene
experiencia en las prácticas primarias. Siguiendo esta clasificación, las prácticas primarias
consideradas fueron la adecuación del lugar de trabajo, sentarse juntos, entorno de
trabajo informativo, sentimiento de equipo, trabajo enérgico, programación en parejas,
historias de usuarios, iteraciones cortas, integración continua, pruebas primero, diseño
incremental y refactorización. El conjunto de prácticas secundarias quedó compuesto por
la involucración del cliente, continuidad del equipo, equipos retractiles, código compartido
y alcance del contrato negociado. (10)
1.6.3 Lean Software Development

Es una metodología dirigida especialmente al desarrollo de sistemas cuyas características
varían constantemente. Fue definida por Bob Charette’s a partir de su experiencia en
proyectos industriales, constituyendo una adaptación para el desarrollo de software de las
lecciones aprendidas en la industria, en particular, en el sistema japonés de producción de
automóviles Toyota. La metodología establece que todo cambio en el desarrollo de
software conlleva riesgos, pero si se manejan adecuadamente pueden convertirse en
oportunidades que mejoren la productividad del cliente. Consta de siete principios
dirigidos a gestionar los cambios: eliminación de todo aquello que no aporte valor al
negocio, conocimiento incremental, toma de decisiones tan tarde como sea posible,
deliberar funcionalidad tan pronto como sea posible, poder del equipo, construcción
incremental del producto y perspectiva global del proyecto. (11)
1.6.4 Kanban
Kanban, surgida a partir del pensamiento lean, se basa en una idea muy simple: el trabajo
en curso (Work In Progress, WIP) debería limitarse, y sólo deberíamos empezar con algo
nuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra
función posterior de la cadena. El Kanban (tarjeta señalizadora) implica que se genera
16
una señal visual para indicar que hay nuevos bloques de trabajo que pueden ser
comenzados porque el trabajo en curso actual no alcanza el máximo acordado. (12)
Kanban es una aproximación a la introducción de cambios en un ciclo de vida de

desarrollo de software, o metodología de gestión de proyectos ya existentes. El principio
de Kanban es comenzar con lo que se esté haciendo ahora mismo, comprender el
proceso actual mediante la realización de un mapa del flujo de valor y entonces acordar
los límites de trabajo en curso (WIP) para cada fase del proceso. A continuación se
comienza a hacer fluir el trabajo a través del sistema, a medida que se van generando las
señales Kanban. (12)
Dado que el WIP está limitado en un sistema Kanban, cualquier elemento que se bloquea
por cualquier razón tiende a atascar el sistema. Si un número suficiente de elementos se
bloquean, todo el proceso se detiene. Esto tiene el efecto de que todo el equipo y la
organización se concentran en resolver el problema, desbloqueando estos elementos
para permitir la restauración del flujo productivo. (12)
Kanban usa un mecanismo de control visual para hacer seguimiento del trabajo, conforme
este viaja a través del flujo de valor. Típicamente, se usa un panel o pizarra con notas
adhesivas o un panel electrónico de tarjetas. Las mejores prácticas apuntan
probablemente al uso de ambos. La transparencia que esto genera contribuye también al
cambio cultural. Las metodologías ágiles han obtenido buenos resultados proporcionando
transparencia respecto al trabajo en curso y completado, así como en el reporte de
métricas como la velocidad (cantidad de trabajo realizado en una iteración). Kanban sin
embargo va un paso más allá y proporciona transparencia al proceso y su flujo. Kanban
expone los cuellos de botella, colas, variabilidad y desperdicios. Todas las cosas que
impactan al rendimiento de la organización en términos de la cantidad de trabajo
entregado y el ciclo de tiempo requerido para entregarlo. Kanban proporciona a los
miembros del equipo y a las partes interesadas visibilidad sobre los efectos de sus
acciones o falta de acción y promueve la discusión sobre las posibles mejoras, con lo que
los equipos comienzan rápidamente a implementar mejoras en su proceso. (25)
Como resultado, Kanban propicia la evolución incremental de los procesos existentes, una
evolución que generalmente está alineada con los valores del “Agilismo”. Kanban no pide
una revolución radical de la forma en la que las personas trabajan, sino que sugiere un
17
cambio gradual. Es un cambio que surge del entendimiento y el consenso entre todos los
trabajadores y sus colaboradores. (12)
1.6.5 Crystal Methodologies

Es un conjunto de metodologías ágiles para equipos de diferentes tamaños y con distintas
características de criticidad. Fue propulsada por uno de los padres del Manifiesto Ágil,
Alistair Cockburn, que consideraba que la metodología debe adaptarse a las personas
que componen el equipo utilizando políticas diferentes para equipos diferentes. Estas
políticas dependerán del tamaño del equipo, estableciéndose una clasificación por
colores: Crystal Clear (3 a 8 miembros), Crystal Yellow (10 a 20 miembros), Crystal
Orange (25 a 50 miembros), Crystal Red (50 a 100 miembros) y Crystal Blue (para más
de 100 miembros). Por ejemplo, Crystal Clear, la metodología más ligera de este
conjunto, está dirigida a la comunicación de equipos pequeños que desarrollan software
cuya criticidad no es elevada. Tiene asociadas siete características: liberación frecuente
de funcionalidad, mejora reflexiva, comunicación osmótica, seguridad personal, atención,
fácil acceso para usuarios expertos y requisitos para el entorno técnico. (13)
1.6.6 Dynamic Software Development Method

Método de desarrollo dinámico de software, por sus siglas en inglés (DSDM), puede
considerarse un marco para el proceso de producción de software, más que una
metodología. Nació en 1994 con el objetivo de crear una metodología RAD (Rapid
Application Development) unificada. Divide el proyecto en tres fases: pre-proyecto, ciclo
de vida del proyecto y post-proyecto especificando de forma rigurosa la arquitectura y
gestión del proyecto. Así, propone cinco fases en el desarrollo del proyecto: estudio de la
viabilidad y estudio del negocio que constituyen la etapa de pre-proyecto; y, de forma
iterativa, modelado funcional, diseño y construcción y finalmente implementación, además
de una adecuada retroalimentación a todas las fases. Sus principales características son
interacción con el usuario, poder del equipo de desarrollo, liberaciones frecuentes de
funcionalidad, regirse siguiendo las necesidades del negocio, desarrollo iterativo e
incremental, adaptación a los cambios reversibles, fijar el nivel de alcance al comienzo del
proyecto, pruebas durante todo el desarrollo y efectiva comunicación. (14)
1.6.7 Feature-driven Development

Esta metodología, ideada por Jeff De Luca y Peter Coad, combina el desarrollo dirigido
por modelos con el desarrollo ágil. Se centra en el diseño de un modelo inicial, cuyo
18
desarrollo será dividido en función a las características que debe cumplir el software e,
iterativamente, se diseñará cada una de estas características. Por tanto, cada iteración
consta de dos partes, diseño e implementación de cada característica. Este tipo de
metodología está dirigido al desarrollo de aplicaciones con un alto grado de criticidad. (15)
1.7 Evaluando Metodologías

Una vez decididos a probar el modelo ágil aparece la duda. ¿Qué metodología aplicar,
cual será más eficiente, más ágil? Con idea de esclarecernos al respecto, a continuación
se expondrán los resultados obtenidos de la aplicación de un framework para evaluación
de metodologías ágiles, a dos de las más populares: Scrum Y XP.
1.7.1 Framework de Evaluación

El framework de evaluación propuesto mide de qué manera las metodologías ágiles
cumplen con los postulados del Manifiesto Ágil descritos en secciones previas. Provee
mediciones para los cuatro postulados, los que fueron expresados como la valoración de
dos atributos. La medida de cada postulado se define como la suma de las medidas de
los atributos relacionados. (16)
El framework, los atributos y sus medidas se presentan en la tabla 1.1.
Tabla 1.1Framework de Evaluación de Metodologías Ágiles
P1 Valorar al individuo y las interacciones del equipo por sobre el proceso y las herramientas
P1.1 Valorar al individuo y las interacciones P1.2 Valorar el proceso y las herramientas
Valor Descripción Valor Descripción
0 No define roles para individuos -5 Define actividades, entregables,

herramientas de desarrollo y de gestión
1 Clara definición de roles para individuos -3 Define actividades, entregables y
herramientas de desarrollo
2 Clara definición de roles y responsabilidades -2 Define actividades y entregables
3 Clara definición de roles, responsabilidades y -1 Define actividades para cada iteración

conocimientos técnicos
5 Clara definición de roles, responsabilidades, 0 Define actividades para el proyecto pero no
conocimientos técnicos e interacciones entre a nivel de cada iteración
miembros del equipo de trabajo
P2 Valorar el desarrollo de software que funcione por sobre una documentación exhaustiva
P2.1 Valorar desarrollo de software que funcione P2.2 Valorar documentación exhaustiva
0 Generar entregable al finalizar el proyecto -5 Requiere documentación detallada al

comienzo del proyecto
3 Generar entregable con testing satisfactorio al -2 Requiere solo documentación necesaria al
finalizar cada iteración comienzo de cada iteración
5 Generar entregable con testing satisfactorio e 0 No requiere documentación para comenzar
integrado con el resto de las funciones al a implementar la funcionalidad incluida en
finalizar cada iteración una iteración
19
P3 Valorar la colaboración con el cliente por sobre la negociación contractual
P3.1 Valorar la colaboración con el cliente P3.2 Valorar la negociación contractual
0 Cliente colabora a demanda del equipo -5 Existe contratación detallada al inicio y no

se aceptan cambios
3 Cliente es parte del equipo, responde consultas -2 La contratación exige contemplar cambios
y planifica las iteraciones durante el proyecto
5 Cliente es parte del equipo, responde consultas, 0 El contrato por la construcción del producto
planifica iteraciones, y colabora en la escritura no aporta valor al producto.
de requerimientos y pruebas
P4 Valorar la respuesta al cambio por sobre el seguimiento de un plan
P4.1 Valorar la respuesta al cambio P4.2 Valorar el seguimiento de un plan
0 No prevé incorporar cambios durante la -5 Define un plan detallado al inicio del

ejecución del proyecto Proyecto
1 Prevé introducir sólo cambios de alta prioridad -3 Define un plan detallado de iteraciones, no
acepta cambios durante una iteración
4 Permite la evolución y el cambio, pero no es -2 Define un plan detallado para cada
recomendable en la iteración en curso iteración, que puede ser modificado
5 Permite introducir cambios en la iteración en 0 No define planificación alguna
curso
P1 Valorar al individuo y las interacciones del equipo por sobre el proceso y las herramientas
1.7.2 Aplicación del Framework

La aplicación del framework se muestra en la Tabla 1.2 y se explica a continuación.
Postulado P1: Scrum y XP obtienen 5 en el atributo P1.1, ya que ambas
metodologías valoran al individuo, definen roles y responsabilidades y reconocen
la importancia y promueven la capacitación de los integrantes del equipo. Scrum
obtiene -3 en el atributo P1.2 ya que define actividades, entregables y
herramientas de desarrollo; mientras que XP obtiene -2 por que solo define
actividades y entregables.
Conclusión: Scrum obtiene 2 puntos y XP 3. Scrum obtiene un menor valor ya que la
metodología define herramientas para el desarrollo. XP satisface P1 mejor que Scrum.
Postulado P2. Scrum obtiene 3 puntos y XP 5 en el atributo P2.1. La diferencia
radica en que XP también considera la integración parcial del software al finalizar
cada iteración. Ambas metodologías se evalúan con un valor -2 para el atributo
P2.2 ya que ambas sólo requieren documentación para la iteración planificada.
Scrum y XP obtienen un valor positivo para el principio P2, superando XP a Scrum
por 1 punto.
Conclusión: XP satisface P2 mejor que Scrum, ya que requiere que los incrementos
entregados sean integrados en forma continua con el resto de la funciones.
20
Postulado P3. Ambas metodologías obtienen el mejor valor en ambos atributos, 5
puntos para P3.1 y 0 punto para P3.2. Ambas consideran al cliente como un
miembro del equipo, que colabora desde la planificación de las iteraciones hasta la
escritura de requerimientos y pruebas funcionales. Ninguna de ellas utiliza la
relación contractual para agregar valor al producto.
Conclusión: Ambas satisfacen P3 de manera óptima.
Postulado P4. En el atributo P4.1 Scrum obtiene un valor 4 ya que si bien permite
introducir cambios, no se recomiendan en el sprint en curso. De ser prioritario el
cambio en el sprint en curso, se debe estimar nuevamente el esfuerzo requerido y
si es necesario, quitar tareas del sprint ya planificado. XP obtiene el m áximo valor
debido a que los cambios se pueden incorporar durante la iteración. Debido a que
un enfoque similar sucede con la planificación, Scrum obtiene un valor de -3 y XP -
2.
Conclusión: XP obtiene 3 puntos y Scrum 1. XP satisface P4 mejor que Scrum.
Tabla 1.2Aplicación del Framework a S crum y XP
Postulados
Metodología P1 P2 P3 P4
P1.1 P1.2 Total P2.1 P2.2 Total P3.1 P3.2 Total P4.1 P4.2 Total
Scrum 5 -3 2 3 -2 2 5 0 5 4 -3 1
XP 5 -2 3 5 -2 3 5 0 5 5 -2 3
1.7.3 Conclusiones de la evaluación

El framework aplicado define un método de evaluación cuantitativo para evaluar de qué
manera las metodologías ágiles cumplen con los postulados del Manifiesto Ágil. En base
a la evaluación se puede concluir que XP satisface los postulados ágiles mejor que
Scrum. Sin embargo, existen trabajos que comparan metodologías ágiles
cualitativamente. En (17), se define una lista de palabras claves y se evalúan varias
metodologías en base a dicha lista. Las palabras claves incluyen: estado de des arrollo del
método, puntos importantes, características especiales, adopción y el grado de soporte de
la metodología para las actividades tradicionales del proceso de desarrollo. Iacovelli y
Souveyet(18) definen un framework de evaluación en base a cuatro atributos de alto nivel:
capacidad de agilidad, uso, aplicabilidad, y proceso y productos. Strode (19) define un
framework de comparación que incluye los siguientes atributos: filosofía de la
metodología, modelos, técnicas, herramientas, entregables, práctica y el grado de
adaptabilidad a una situación.
21
Debido a lo variable de los resultados de aplicar estos frameworks, se puede concluir que
ninguna metodología satisface totalmente los principios del Manifiesto Ágil, y que para
acercarse a este propósito, debería conformarse una metodología combinando aspectos
de varias.
1.8 Scrum y Kanban para la gestión ágil de proyectos

La selección de Scrum y Kanban como metodologías a probar en el contexto del presente
trabajo estuvo basada, principalmente, en el hecho de que ambas definen un marco para
la gestión de proyectos, a diferencia de otras metodologías ágiles como XP y la familia de
las Crystal, que proponen prácticas de carácter ingenieril, sin una manera clara de
gestionar los proyectos.
Primeramente fue seleccionada Scrum, debido a su alto grado de popularidad a nivel

mundial, y el buen criterio que ha despertado entre sus usuarios, tal es el caso de
empresas como Yahoo y Google, promotoras de las metodologías ágiles. Yahoo, por
ejemplo, desde hace varios años utiliza con éxito metodologías ágiles, concretamente
Scrum, habiendo publicado algunas de sus experiencias en la web (20). En una encuesta
realizada en Estados Unidos por CM Crossroads en 2006 (21), se evidenció Scrum como
una de las tres metodologías ágiles más utilizadas, en la encuesta Ágil 2011 realizada por
VersionOne, resulto ser Scrum la metodología más usada (22), lo que sumado al
creciente interés entre los clientes de software porque sus proyectos sean desarrollados
utilizando Scrum, no dejó lugar a la duda en cuanto a su elección.
De otro lado, la decisión de optar por Kanban como alternativa ante Scrum se debió a la
similitud observada inicialmente entre ambas metodologías, y las buenas opiniones de
equipos que la utilizaban, por ejemplo en (23) el autor describe la recuperación
experimentada durante el desarrollo de un proyecto luego de haber aplicado Kanban. En
(24), se hace referencia al uso de Kanban como parte de la mejora de proceso buscada
por un equipo que empleaba Scrum, mientras en (25) se expone su utilización como guía
para tareas referidas a pedidos de cambio, arreglos de defectos, mantenimiento de
aplicaciones productivas y todo aquello que no llega a una iteración de Scrum. Además, la
encuesta Ágil 2011 realizada por VersionOne, mostró un aumento de un 6% en la
utilización de Kanban respecto a la última encuesta (22).
22
1.9 Conclusiones
Tras una profunda revisión del estado de la investigación en este campo, se puede
concluir que las metodologías ágiles son sin duda uno de los temas destacados en la
ingeniería de software actualmente, que están acaparando gran interés por parte de los
investigadores. Aunque algunas críticas argumentan que no son más que viejo vino
presentado en botellas nuevas (26), otros estudios muestran que el desarrollo de
productos en entornos ágiles es muy diferente al desarrollo convencional, como ejemplo
en (27) se comparó la productividad de dos proyectos similares. Un equipo utilizó una
metodología tradicional y el otro XP, obteniendo como resultado que, en general, el
equipo XP obtuvo una productividad 42% mayor que la del equipo tradicional. La
utilización de metodologías ágiles es un tema que tiene sus detractores pero a la vez tiene
muchos seguidores, por tanto, se necesitan estudios que indaguen en el valor que
acarrearía su uso.
De otro lado, no existe una metodología ágil ideal, es conveniente tomar características
de las diferentes metodologías y combinarlas, obteniendo un paquete más completo que
sirva como base al equipo de desarrollo, que luego deberá hacer los ajustes necesarios
para lograr un rendimiento óptimo en su forma de trabajar.
Tras analizar las metodologías ágiles más populares se puede concluir que las candidatas
a ser aplicadas son Scrum y Kanban, por brindar un marco para la gestión de proyectos
además de la flexibilidad necesaria para el desarrollo en contextos variables.
23
CAPÍTULO 2: DISEÑO Y EJECUCIÓN DEL EXPERIMENTO
2.1 Introducción
En este capítulo se presenta el experimento que da base a esta investigación,

especificando claramente las áreas de interés para el mismo, así como las mediciones
que serán realizadas con objetivo de evaluar el experimento. Con el propósito de facilitar
la comprensión del estudio, se brindará una descripción general del mismo, para luego
exponerlo detalladamente.
2.2 Visión global del experimento
El experimento se centra en el desarrollo de dos aplicaciones con características

similares, Estimation Tool y Open Sky, las que serán realizadas utilizando las
metodologías Scrum y Kanban respectivamente. Las aplicaciones representan pequeños
sistemas que a pesar de no interactuar con ningún otro ni emplear bases de datos,
implementan estructuras de datos bastante complejas y representaciones de gráficos 3D.
Las características de Estimation Tool y Open Sky no son propias de los sistemas que
comúnmente desarrolla la DSI, aunque podría hacerse una analogía con módulos de
sistemas desarrollados por la DSI, así como con las características del equipo de
desarrollo.
Ambas aplicaciones están relacionadas con la estimación de recursos minerales, labor

que básicamente funciona de la siguiente manera:
Una vez escogida el área a estimar, se realizan excavaciones puntuales en zonas

aleatorias, con el objetivo de tomar muestras de diferentes sitios y a distintos niveles de
profundidad en el terreno, muestras que luego son utilizadas por los métodos de
estimación practicados. Para el trabajo computacional en este tema, los terrenos son
expresados mediante modelos de bloques, ya que estos permiten la representación del
terreno por niveles, así como poder ubicar las muestras de manera precisa.
Estimation Tool consiste en una herramienta para realizar pruebas prácticas que permitan
analizar y compararla estimación de recursos minerales mediante los algoritmos del
inverso de la distancia y el kriging ordinario, los que constituyen algoritmos muy utilizados
24
en la estimación minera. La aplicación debe proporcionar la posibilidad de seleccionar el
tipo de variograma a utilizar (esférico, gaussiano, exponencial) e indicar los valores de
meseta, rango y efecto pepita (estos son parámetros de entrada para los algoritmos de
estimación de recursos minerales). Además, debe permitir la definición de un modelo de
bloques de cualquier tamaño, la generación e inserción de muestras en este, así como
salvar y cargar todos los datos referentes a un modelo específico, útil en el trabajo y
experimentación con datos reales. Todas las opciones brindadas por la aplicación deben
efectuarse estableciendo una interactividad visual con el usuario, de manera que se
puedan apreciar en todo momento los cambios y operaciones realizadas sobre el modelo.
Open Sky consiste en una herramienta de soporte para el diseño de minas a cielo abierto.
La misma debe permitir la creación de un modelo de bloques personalizado, al que luego
se le aplicará un cono de restricción óptimo, dando origen al diseño de la mina, que debe
ser representado gráficamente, al igual que todos los cambios que en este ocurran. La
herramienta permitirá además, cargar los valores netos para cada bloque del modelo, es
decir, el valor ya estimado de cada bloque, utilizando esto como dato para la aplicación
del algoritmo de Lerch-Grossman, el que determina los mejores bloques para la
extracción de mineral. Finalmente la herramienta deberá reducir el modelo al conjunto de
bloques que fueron seleccionados por el algoritmo.
Una vez culminadas las aplicaciones, serán analizadas las métricas obtenidas durante el
proceso de desarrollo, con la intención de realizar una comparación profunda del
desempeño logrado con las metodologías utilizadas, Scrum y Kanban.
2.3 Objetivos del experimento
Los objetivos perseguidos con este experimento siguen principalmente seis líneas de
interés: características de los productos desarrollados con una y otra metodología durante
el período de desarrollo, aspectos de gestión en el equipo de desarrollo al utilizar las
metodologías Scrum y Kanban, calidad del producto obtenido, esfuerzo de adaptación de
cada metodología, satisfacción del cliente y de los desarrolladores durante y tras la
ejecución del proyecto, y por último, análisis de las metodologías tras la experiencia
alcanzada en la investigación.
Características de los productos durante el desarrollo
25
Resulta necesario analizar la evolución del producto a lo largo del desarrollo y la
integración continua que será utilizada como práctica referente al movimiento
ágil, tomando en cuenta lo siguiente:
-¿Cómo han evolucionado las líneas de código a lo largo del proyecto?
- ¿Cómo han evolucionado las clases del producto a lo largo del desarrollo?
- ¿Cuántas nuevas han aparecido? ¿Cuántas han cambiado? ¿Cuántas se han

eliminado?
Aspectos de agilidad en el equipo de desarrollo

El principal motivo de este estudio es el interés por aumentar la productividad,
reducir notablemente los tiempos de desarrollo y adaptarse a las variabilidades
del proceso. Por tanto, es de interés estudiar aspectos relacionados con la
gestión del equipo durante el experimento, específicamente en lo relacionado a
las cuestiones siguientes:
- ¿Se ha sido ágil?
- ¿Se han cumplido los objetivos previstos?
- ¿Hemos sido capaces de adaptarnos a los cambios e imprevistos que han

surgido a lo largo del desarrollo?
Calidad del producto final

Por otro lado, la aplicación de metodologías ágiles supone gran empeño en
obtener productos de calidad mediante la continua interacción con el cliente,
atención a la calidad técnica y al buen diseño. En este sentido estudiaremos:
- ¿Se ha obtenido un producto de calidad?
- ¿Cómo se ha comportado la identificación de defectos durante el desarrollo?
- ¿Cuán ágiles hemos sido para dar solución a los defectos detectados?
Esfuerzo de adaptación de las metodologías

Resulta importante analizar el esfuerzo que ha supuesto el desarrollo con las
metodologías Scrum y Kanban, así como el resto de las prácticas ágiles
utilizadas, para miembros que no estaban familiarizados con las metodologías
ágiles.
26
- ¿Cuán grande es el esfuerzo de familiarización con las metodologías Scrum y
Kanban?
- ¿Cuánto tiempo demora el equipo en adaptarse, basado en aspectos tales

como el cumplimiento de objetivos, la satisfacción personal y el hábito en las
prácticas ágiles?
Satisfacción del cliente y de los desarrolladores

Dado que ni Scrum ni Kanban establecen prácticas ingenieriles, sino que se
pueden concebir como una nueva cultura de desarrollo de software, es de interés
conocer las apreciaciones que estas despiertan, tanto en el cliente como en el
equipo de desarrollo, aunque vale aclarar que en este caso el cliente forma parte
del equipo de desarrollo.
- ¿Satisfacen las metodologías al cliente?
- ¿Satisfacen al equipo de desarrollo?
Análisis de las metodologías Scrum y Kanban

Una vez realizado el experimento, apoyándonos en la experiencia adquirida en el
mismo, se examinarán las metodologías ágiles y las prácticas propuestas desde
una perspectiva más ingenieril.
-¿Cuáles son las ventajas de estas metodologías?
- ¿Qué problemas presentan las metodologías?
2.4 Contexto del experimento
Definir el contexto es una labor extremadamente importante que permite garantizar que la
descripción es lo suficientemente específica para que otros investigadores puedan utilizar
los resultados obtenidos, haciendo posible la replicación del estudio, así como la
generalización de las conclusiones.
A continuación se describen los factores contextuales que impactan en la realización del

experimento.
27
2.4.1 Equipo
El desarrollo de las aplicaciones, Estimation Tool y Open Sky, es llevado a cabo por un
equipo conformado por cinco personas, de las cuales dos contaban con algunas
experiencias previas trabajando en el dominio al que pertenecen las aplicaciones.
A continuación la tabla 2.1 muestra el grado académico y el nivel de dedicación de los

integrantes del equipo.
Tabla 2.1Nivel académico y dedicación del equipo
Aspecto Característica Integrantes

Nivel Académico Estudiante Ingeniería Informática 5to Año 3
Estudiante Ciencias de la Computación 5to Año 1
Estudiante Ciencias de la Computación 4to Año 1
Dedicación de Integrantes Tiempo Completo 2
Tiempo Parcial 2
Soporte 1
Es válido destacar que el desarrollo tiene lugar en un contexto universitario,

concretamente las aplicaciones desarrolladas se enmarcan en una de las líneas del
centro GEYSED de la facultad 6 de la Universidad de las Ciencias Informáticas (UCI) y
que además, estas sirven como soporte a dos trabajos de diploma de estudiantes de
dicha universidad.
Teniendo en cuenta que un factor crítico en las metodologías ágiles, en términos de

calidad y productividad, es la experiencia del equipo en la industria de software y,
concretamente, en desarrollo ágil, así como su experiencia en el dominio de desarrollo,
resulta válido aclarar que ningún miembro del equipo cuenta con años de experiencia en
estas áreas. Previo al experimento, un solo integrante contaba con conocimiento teórico
en metodologías de desarrollo ágil, aunque en la práctica nunca había experimentado con
ninguna de ellas. No obstante, algunos integrantes del equipo están acostumbrados a
trabajar en pareja, por lo que la técnica de pair-programming se puede considerar
utilizada con anterioridad.
Debido a que el equipo de desarrollo está conformado por estudiantes de varias

universidades, fue necesario establecer una sede para el trabajo conjunto. Aprovechando
la cercanía entre las viviendas de los integrantes, fue seleccionada la que mejores
condiciones brindaba para el trabajo en grupo, aunque el equipo se reunía en su totalidad,
regularmente, de dos a tres días por semana, en función del grado de interacción que
28
requiriera la tarea a realizar. En cuanto a las reuniones con el cliente, estas tenían lugar
cada vez que se reunía el equipo, pues como ya se ha mencionado, el cliente formaba
parte del mismo.
2.4.2 Roles
A pesar de tratarse de un equipo bien reducido utilizando metodologías ágiles, lo que

propicia un trabajo muy colaborativo donde todos los miembros ayudan en todas las fases
del desarrollo, se pueden diferenciar varios roles y miembros liderando diferentes tareas:
tareas de gestión del proyecto, tareas de especificación de historias de usuario, tareas de
diseño, tareas de desarrollo y tareas de pruebas. Varios miembros del equipo
desempeñaron más de una función dentro del contexto del proyecto. Finalmente, cabe
destacar que, uno de los integrantes dedicó sus esfuerzos exclusivamente a las tareas de
pruebas, aunque fue apoyado en momentos por una segunda persona.
2.4.3 Herramientas
Los métodos de desarrollo ágil centran su atención principalmente en la comunicación

“cara a cara” y en los resultados, más que en la generación de documentación, por eso,
muchos de sus procesos pueden llevarse a cabo prácticamente sin herramientas. Esta
búsqueda de simplicidad no ha impedido que aparezcan en el mercado aplicaciones
específicas para trabajar con metodologías ágiles, que prometen facilitar la realización de
algunas tareas. Debido a los elevados requisitos de las principales de estas aplicaciones,
se decidió utilizar como herramientas para la gestión, solamente una pizarra y papel.
2.5 Definición de mediciones
El objetivo principal del plan de mediciones desarrollado para la evaluación del

experimento, es disponer de datos objetivos y consistentes que nos permitan obtener
conclusiones basadas en hechos y no en simples intuiciones. Dada la naturaleza de la
investigación, se procuró que el proceso de recogida de las mediciones fuera lo más
ligero posible, de forma tal que no obstruyera las actividades del equipo ágil.
Para establecer el conjunto de mediciones a recoger, se han considerado las típicas

medidas para este tipo de estudios como los defectos encontrados en los productos, la
satisfacción de los implicados en el proceso (28), la experiencia del equipo (29)y medidas
especialmente indicadas para experimentos sobre metodologías ágiles (30).
29
Las entidades de interés para dar respuesta a las cuestiones planteadas como objetivos
del experimento y que, por tanto, serán medidas en él, se pueden identificar como:
- Las entradas o recursos con los que cuenta el equipo para el desarrollo del
experimento, dado que influyen en los resultados.
- Los productos obtenidos, específicamente la evolución de estos a medida que

avanza el experimento y se consolida la aplicación de la metodología, y la calidad
de estos productos obtenidos.
- Las actividades que conforman el proceso de desarrollo y la productividad del

mismo.
La tabla 2.2muestra, a modo de resumen, el conjunto de mediciones a recoger.
Tabla 2.2Mediciones del experimento
Entidad de interés Medición

Entradas o recursos Experiencia del equipo
Esfuerzo dedicado al proyecto
Productos obtenidos Defectos en cada iteración* (Sprint en el caso de Scrum)
Defectos en productos entregados
Cantidad de líneas de código del producto por iteración*
Clases impactadas por cada historia de usuario
Proceso % de realización de la pila de producto* (Product Backlog)
Cantidad de iteraciones hasta completar una historia de
usuario
Satisfacción en cada iteración*
Satisfacción global con la metodología
A continuación se describe detalladamente cada una de estas mediciones
Experiencia del equipo. Al inicio del experimento se medirá de cada uno de los
miembros del equipo, los siguientes factores: grado académico, experiencia en desarrollo
de software, experiencia en gestión de proyectos, experiencia en el lenguaje de
programación a utilizar (C++), y experiencia en desarrollo ágil y programación en parejas
(pair-programming). Además será de interés medir el grado de conocimiento sobre el
dominio de las aplicaciones a desarrollar, es decir, la estimación de recursos minerales.
La experiencia será medida en años o, en su defecto, en meses. Los niveles de
conocimiento podrán tomar los valores alto, medio o bajo.
30
Esfuerzo dedicado al proyecto. Resulta importante registrar el tiempo, las horas o
minutos, que se dedican a realizar cualquier actividad relacionada con el desarrollo de las
aplicaciones en cuestión. Estas mediciones servirán para analizar los objetivos obtenidos
durante el proceso respecto al esfuerzo dedicado al mismo. Además permitirá dar
seguimiento al proceso de aprendizaje de la metodología y la posible influencia del
esfuerzo dedicado a cada aspecto de la misma.
Defectos en cada iteración. Con objetivo de evaluar la calidad del producto, al concluir
cada iteración se medirán el número de defectos del mismo, así como la importancia de
estos defectos. De cada defecto se recogerá una descripción y una estimación de su
importancia (alta, media o baja). Esta tarea será ejecutada por la persona encargada de
hacer las pruebas.
Defectos en productos entregados. Igualmente, resulta útil conocer los defectos

encontrados por el cliente cuando ya se ha entregado el producto. El hecho de que el
cliente forme parte del equipo, facilitará la toma de esta medición. La información a
recoger será similar a la de la métrica anterior, sin embargo, en este caso el encargado de
tomar la medida será el cliente.
Número de líneas de código del producto por iteración. Al finalizar cada iteración, se
anotarán el número de líneas de código del producto hasta ese momento, con el propósito
de valorar la evolución del producto.
Clases impactadas por cada historia de usuario. Con intención similar ala métrica
anterior, serán medidas las clases que sufren algún cambio durante la evolución del
producto. Esta medición se tomará en función de la historia de usuario que esté siendo
desarrollada. Se indicará el identificador de la historia de usuario y el nombre de la clase
que está siendo impactada, especificando el tipo de impacto sufrido (clase nueva, clase
modificada o clase eliminada).
Porcentaje de realización dela pila de producto. Para medir la productividad al utilizar

las metodologías de desarrollo ágil Scrum y Kanban, se evaluará el porcentaje de
realización de la pila de producto. Esta medida será tomada al finalizar cada iteración y se
calculará como se muestra a continuación:
- Número total de elementos de la pila de producto (TEP)
- Número de elementos realizados dela pila de producto (ERP)
31
- Elemento dela pila de producto (EP)
% realización pila =
pi: peso del elemento de la pila, ya que existen elementos priorizados respecto a
otros.
Número de iteraciones hasta completar una historia de usuario. Como puede suceder
que una historia de usuario no se complete en la iteración planificada, representando así
una demora, se medirán estos retrasos contabilizando el número de iteraciones que se
dedican a cada historia de usuario, ya que idealmente estas deberían ser definidas de
forma que fuese posible desarrollarlas en una única iteración. Esta medida será recogida
indicando la iteración en que se incorpora la historia de usuario y la iteración en que
finalmente es concluida.
Satisfacción en cada iteración. Finalmente, dado el enfoque de las metodologías ágiles

como una nueva filosofía de desarrollo, resulta muy importante conocer la opinión, tanto
de los integrantes del equipo como del cliente con esta nueva forma de trabajo. Así al
finalizar cada iteración deberán brindar una breve descripción con reflexiones personales
sobre la metodología seguida y valorar su grado de satisfacción (valor comprendido entre
0, satisfacción mínima, y 10, satisfacción máxima). Al finalizar el proyecto se analizará, de
forma similar, la satisfacción global de la metodología.
2.6 Desarrollo utilizando Scrum
En esta sección se describe el desarrollo de la aplicación Estimation Tool, con la

utilización de la metodología Scrum. El desarrollo consta de 5sprints, con una duración
promedio de dos semanas cada uno. Se describirán los hechos más destacables de cada
uno de los sprints, así como la influencia y resultado de las prácticas ágiles utilizadas y de
cada uno de los elementos para la gestión del proyecto propuestos por Scrum.
2.6.1 Pre-Game
La fase de pre-game significa el comienzo del proyecto y tiene el objetivo de descubrir las
necesidades que debía satisfacer el sistema que iba a ser desarrollado. Se destinaron
32
unos días a esta primera fase, en la que utilizando la ayuda y documentación aportada
por el cliente, se realizó una primera definición sencilla y clara de las características que
debía cumplir el sistema a desarrollar. Como resultado se obtuvo el Product Backlog o pila
de producto de Scrum, artefacto que contiene las historias de usuario a alto nivel que
guiarán el proceso de desarrollo y que a medida que avancen los sprints, serán
descompuestas en un nivel mayor de detalle.
La tabla 2.3 muestra, en síntesis, el Product Backlog obtenido, especificando quién

propone la historia de usuario y por qué lo hace.
Tabla 2.3S íntesis del Product Backlog
Estimation Tool Product Backlog

ID Definición Propone Motivación
HIS-1 Crear modelo de bloques Cliente Representar el terreno a estimar
HIS-2 Visualizar el modelo Cliente Brindar una representación 3D del
modelo de bloques y las acciones
sobre él
HIS-3 Gestionar muestras Cliente, Agregar muestras al modelo creado
desarrollador
HIS-4 Estimar recursos minerales en Cliente Ofrecer la estimación de recursos
el modelo en el modelo, mediante los
algoritmos del inverso de la
distancia y el Kriging ordinario
HIS-5 Guardar y cargar modelo Desarrollador Facilitar el trabajo con diferentes
desde archivo modelos, así como la exportación e
importación de datos.
2.6.2 Sprint 1
Como establece Scrum, inicialmente se realizó la reunión de planificación del primer

sprint. El objetivo de esta reunión fue seleccionar las historias de usuario del Product
Backlog a cumplir en este sprint para comenzar a desarrollar el producto. La prioridad del
cliente era disponer de la estructura para la creación del modelo de bloques, así como
poder insertar muestras en este.
Para la planificación de este sprint se descompusieron las historias de usuario implicadas,

HIS-1 y HIS-3 respectivamente, en tareas que habría que realizar para completar dichas
historias de usuario. La falta de conocimiento en el dominio a desarrollar complicó la
estimación del tiempo necesario para efectuar cada tarea. Finalmente, el equipo acordó
basándose en intuiciones y dando prioridad a las opiniones de aquellos miembros con un
mayor conocimiento respecto al tema, que el Sprint Backlog del sprint 1 estuviera
33
constituido por la historia HIS-1 solamente y que además, el equipo profundizara un poco
en el dominio de la aplicación.
El desarrollo siguió el orden lógico de las tareas establecidas en la planificación,

comenzando por una familiarización con el dominio de aplicación. Con el avance del
sprint comenzaron a aparecer complicaciones en la parte del diseño para seleccionar la
estructura de datos espaciales óptima para el modelo, causadas principalmente por la
falta de conocimiento de los desarrolladores. El continuo contacto con el cliente y los
aportes del mismo, ayudaron en gran medida a mitigar estas complicaciones. Sin
embargo, el hecho de que estas dificultades no fuesen consideradas en la planificación
del sprint, propició la aparición de retrasos.
Siguiendo la metodología, aunque una adaptación de esta, regularmente se realizaron

reuniones en las que cada miembro del equipo describía el estado del trabajo que tenía
asignado. Se confirmó el beneficio de estas reuniones para detectar y solucionar
problemas de forma rápida. No obstante, la falta de hábito en realizar este tipo de
reuniones propició que la mayoría se prolongaran más de lo previsto.
Durante la reunión de revisión del sprint se evidenciaron los retrasos ocurridos. Si bien se
mostraron al cliente algunos avances en tareas de diseño e implementación, no se logró
concluir la historia de usuario prevista, con lo cual los resultados en relación a la
planificación establecida fueron negativos.
Tras la reunión de revisión se llevó a cabo la reunión retrospectiva, en la que fueron

tratadas las dificultades a las que nos enfrentamos durante el primer sprint, principalmente
motivadas por la falta de conocimiento en el dominio del producto. El mayor problema de
este sprint fue la dificultad para definir la historia de usuario y realizar la estimación de
tiempo para esta. Concretamente, la definición se realizó a alto nivel, provocando una
estimación de tiempo imprecisa. Por otro lado, se desconocía cuánto trabajo se podría
realizar en un sprint y se sobrestimó las posibilidades, especialmente en el coste de
familiarización con el dominio de la aplicación.
En compensación, la metodología aportó aspectos positivos al desarrollo. Se favoreció la

toma de decisiones durante el desarrollo pues la responsabilidad se distribuyó entre todo
el grupo. Aunque no se lograron cumplir los tiempos, las tareas avanzaron de forma
34
rápida y segura. La práctica de pair-programming resultó positiva pues el código obtenido,
a pesar de no ser mucho, mostró gran calidad.
No obstante, el resultado de la retrospectiva fue negativo. La tabla 2.4 muestra un

resumen del desarrollo del sprint.
Tabla 2.4Resumen sprint 1
Elemento Valor
Duración 14 días en los que el equipo se reunió en su totalidad en 8 ocasiones
Objetivo Implementar la estructura para crear un modelo de bloques que represente
el terreno
Desarrollo Número de clases: 6 Líneas de código: 755
Objetivos Aunque se han producido avances en conocimiento del dominio del
logrados producto y en diseño e implementación, no se ha logrado completar la
historia de usuario planificada. Los avances más significativos se han
producido en la selección e implementación de la estructura de datos
espaciales que servirá de base al modelo de bloques, siendo esta un Octree.
Puntuación -10
retrospectiva
2.6.3 Sprint 2
Con el objetivo de mejorar los resultados obtenidos en el sprint 1 dio comienzo el sprint 2.
Durante la reunión de planificación el equipo centró su empeño en definir las historias de
usuario con un mayor nivel de detalle para realizar una planificación realista de acuerdo a
los recursos disponibles. El hecho de que en el sprint anterior se profundizase en el
dominio de la aplicación repercutió positivamente en este sentido. El objetivo propuesto
para este sprint fue completar la historia de usuario HIS-1, pendiente del sprint pasado.
Dicha historia de usuario fue descompuesta en un nivel mayor de detalle considerando los
elementos de interés del modelo de bloques. De este modo, aparecieron algunas historias
de usuario nuevas, constituyendo un subconjunto de la HIS-1. El equipo en su totalidad
estuvo de acuerdo en que era posible cumplir estas nuevas historias de usuario durante el
sprint, quedando el Sprint Backlog constituido por dichas historias.
El trabajo en este sprint avanzó a buen ritmo ajustándose bastante a la planificación

realizada. Las labores de diseño, implementación y pruebas se sucedían rápidamente,
con una colaboración activa del cliente. El crecimiento del código y el número de clases
impactadas en este sprint fue significativo. Sin embargo, surgieron algunas limitaciones en
35
la parte de pruebas, pues fueron realizadas manualmente debido a la falta de experiencia
en esta tarea.
De otro lado, comenzó a corregirse el problema de la prolongación, cuando tenían lugar,

de las reuniones diarias del equipo. Se detectó que no estaban siendo usadas
correctamente, porque se trataban en ellas aspectos que se apartaban de su propósito.
La principal causa de la demora en las reuniones se encontraba en el intento de
solucionar los problemas que se presentaban en el desarrollo. Se decidió que los
problemas que aparecieran en el proyecto fuesen mencionados en las reuniones pero si
la solución a dicho problema requería un tiempo prolongado, fuese en reuniones con las
personas implicadas en las que se plantease dicha solución, evitando así, que el resto del
equipo dedicase un tiempo excesivo a algo que no era de su total competencia. Una vez
encontrada la solución se exponía, en la siguiente reunión, al resto del equipo para que
todos tuviesen un conocimiento global del avance del proyecto.
En la reunión de revisión del sprint se constataron los avances y el buen funcionamiento

en el desarrollo del proyecto. Como establecen las metodologías ágiles, la mejor prueba
de avance es mostrar código que funciona y para esta reunión se contaba con el trabajo
previsto totalmente operativo, es decir el modelo de bloques estaba listo.
La satisfacción tanto del cliente como del equipo aumentó notablemente durante este
segundo sprint, quedando reflejado en la reunión retrospectiva del mismo. En esta reunión
la mayor parte de aspectos tratados fueron positivos. Se valoró muy positivamente la
exactitud de la planificación del sprint, teniendo un gran avance en la definición de las
historias de usuario, principalmente por el incremento del conocimiento sobre el dominio
de desarrollo. Durante este sprint la motivación y comunicación entre el grupo de trabajo
se vio muy reforzada.
Como aspecto negativo se puede señalar el hecho de no haber congelado del todo el
Sprint Backlog, tal y como establece Scrum, pues a lo largo del sprint se añadieron
algunas variaciones del cliente, que no fueron contempladas en la planificación, aunque
estaban íntimamente relacionadas con el trabajo del mismo.
La tabla 2.5 muestra un resumen del desarrollo en este sprint.
36
Elemento Valor
Objetivo Diseñar e implementar las clases para representar el modelo de bloques
con sus atributos.
Implementar algoritmo de subdivisión espacial para la creación del modelo
de bloques.
Objetivos Se han cumplido los objetivos del sprint, culminando finalmente la historia
logrados de usuario HIS-1, pendiente del sprint anterior.
Puntuación +20
retrospectiva
2.6.4 Sprint 3
En este punto, el modelo de bloques ya estaba listo para ser usado, resultaba necesario
poder crear muestras e introducirlas al modelo para llevar a cabo la estimación del mismo.
La planificación de este sprint contó con dos líneas de trabajo. De un lado, la realización
de la historia de usuario HIS-3, que debía crear la funcionalidad de insertar una muestra
especificando sus parámetros y además la generación e inserción en el modelo de un
número dado de muestras aleatorias. De otro lado, se decidió subdividir la historia de
usuario HIS-4 de acuerdo a los algoritmos a implementar, incluyéndose en este sprint la
implementación del inverso de la distancia.
El desarrollo del trabajo fue similar al del sprint 2, considerando prácticamente las mismas
características. Se constató un decremento en el número de líneas y de clases del
producto debido a que se comprobó que algunas de las clases de bibliotecas de terceros
que habían sido adaptadas en el sprint pasado fuesen erróneas, es decir, no se
necesitaban para conseguir la funcionalidad.
En la reunión de revisión del sprint se mostraron los avances del mismo. Se había
completado gran parte del trabajo previsto, señal del perfeccionamiento en la planificación
del sprint. La historia de usuario HIS-3 había sido completada y se tenía,
aproximadamente, un 70% de la implementación del algoritmo de estimación. Además, se
presentaron algunos retrasos en el caso particular de las pruebas, causados por el hecho
de que eran realizadas manualmente, debido a la falta de experiencia en esta labor.
En la reunión retrospectiva se comprobó que gracias al buen análisis realizado del punto
de partida, la planificación fue más realista, aunque se concluyó que el trabajo era mejor
37
sin planificaciones tan ajustadas. Por otro lado, la motivación y el compromiso del equipo
habían decaído un poco y fueron propuestos como puntos a mejorar. Cabe destacar que
las reuniones en este sprint comenzaban a acortarse en duración, manteniendo los
resultados conseguidos en las mismas, clara muestra de que se estaba consiguiendo una
adecuada adaptación de la metodología. La tabla 2.6 muestra un resumen del desarrollo
del sprint 3.
Elemento Valor
Objetivo Implementar funcionalidad que permita agregar muestras al modelo de
bloques.
Implementar algoritmo de estimación usando el método del inverso de la
distancia.
%Objetivos Gestión de muestras(HIS-3): 100%
logrados Estimación mediante inverso de la distancia: 70%
Puntuación +10
retrospectiva
2.6.5 Sprint 4
En la reunión de planificación se establecieron objetivos primarios claramente

alcanzables, y objetivos secundarios. Como objetivo primario fueron comprendidas las
historias de usuario HIS-4, conformadas por la implementación de los dos algoritmos de
estimación y HIS-5, dedicada a implementar métodos para guardar y cargar desde
archivo. Como objetivo secundario para este sprint se consideró el comenzar la
implementación de la historia HIS-2, relacionada con la representación gráfica del modelo.
La implementación avanzó de forma ágil. Simultáneamente se concluía el trabajo

pendiente del sprint anterior, ya que formaba parte de las prioridades del sprint en curso.
Sin embargo, hubo tareas que no se realizaron adecuadamente, algunos integrantes
incumplieron los compromisos hechos durante la planificación, principalmente en la parte
de pruebas.
A pesar de esta situación, los objetivos primarios alcanzados para este sprint fueron
excelentes. Al finalizar el sprint, las historias HIS-4 y HIS-5 estaban completas y se había
completado un 60% de las tareas planificadas de HIS-2.
38
La aplicación de Scrum fue clave para el éxito de este sprint, ya que una porción del
equipo debió atender a sus obligaciones docentes. El contradictorio valor de objetivos
alcanzados respecto a recursos disponibles puede explicarse por la ágil respuesta del
grupo, incrementando los esfuerzos de los integrantes comprometidos para suplir los de
aquellos que colaboraban de una forma menos activa. Sin esta ágil respuesta en la
distribución de tareas el resultado de este sprint hubiese sido muy negativo.
En la reunión retrospectiva se identificaron los problemas acontecidos. La mayoría eran

de seguimiento de la metodología más que técnicos. El cumplimiento de objetivos y la
sensación de progreso, así como la productividad al usar pair-programming, fueron los
aspectos positivos detectados. La ausencia de un espíritu de grupo, de motivación y de
compromiso, fueron los principales obstáculos del sprint. Los objetivos se cumplían pero a
costa del sobreesfuerzo de un subconjunto del equipo.
Elemento Valor
Objetivo Concluir implementación del algoritmo de estimación usando el método
del inverso de la distancia.
Implementar algoritmo de estimación usando el método del Kriging
ordinario.
Implementar métodos para salvar y cargar modelos desde ficheros.
Comenzar implementación para visualizar los modelos de bloques en 3D.
%Objetivos Implementar ambos métodos de estimación (HIS-4): 100%
logrados Guardar y cargar desde fichero (HIS-5): 100%
Visualizar modelo (HIS-2): 60%
Puntuación -40
retrospectiva
2.6.6 Sprint 5
El sprint 5 constituyó el fin del experimento con Scrum. El hecho de haber tocado fondo
respecto a los principios y valores que guían la metodología en el sprint anterior, resultó
muy positivo para este quinto sprint. El equipo estaba consciente del sobreesfuerzo que
supuso para algunos miembros lograr cumplir objetivos en el sprint anterior, y dispuesto a
mejorar y cambiar aquellos aspectos que les habían llevado a esa situación.
39
Este sprint se dedicó exclusivamente a concluir la historia de usuario HIS-2, referida a la
representación 3D del modelo de bloques, que era el único elemento pendiente en el
Product Backlog.
El desarrollo, con un comportamiento por parte del grupo similar al del sprint 2, transcurrió
con normalidad. Una vez completado el visualizador 3D, se llevó a cabo una
refactorización del código de la aplicación para mejorarlo y hacerlo más legible. Después
de la refactorización se realizaron pruebas de validación al sistema para comprobar el
correcto funcionamiento del mismo.
Los resultados obtenidos en el sprint fueron muy buenos. La planificación propuesta fue
cumplida sobradamente, realizando además una etapa de refactorización que no había
sido considerada en un principio.
En la reunión retrospectiva de este sprint la mayor parte de los aspectos tratados

volvieron a ser positivos. El hecho de que los objetivos marcados para el producto
hubiesen sido cubiertos, brindó gran satisfacción al cliente. Las prácticas ágiles como
pair-programming y la refactorización también resultaron muy positivas.
Elemento Valor
Objetivo Concluir implementación de función para representar los modelos de
bloques en 3D.
%Objetivos Visualizar modelo (HIS-2): 100%
logrados Código refactorizado
Puntuación +20
retrospectiva
40
2.7 Desarrollo utilizando Kanban
Este acápite del documento describe el desarrollo de la aplicación Open Sky dividido en
dos iteraciones y guiado por los planteamientos de Kanban. Dichos planteamientos no
prescriben iteraciones de tiempo fijo, se debe elegir el momento de hacer la planificación,
la mejora de procesos, y la entrega, actividades que el equipo decidió ejecutar bajo
demanda y dirigido por eventos. Es decir, se haría una reunión de planificación cada vez
que se agotaran las tareas previstas. Se lanzaría una entrega cuando hubiese un conjunto
mínimo de características comercializables listo para entregar. Se haría una reunión para
tratar problemas de calidad siempre que apareciera un mismo problema por segunda vez.
Además se haría una retrospectiva más profunda cada cuatro semanas.
Se describirán los hechos más destacables ocurridos durante el desarrollo, así como la
influencia y resultado de las prácticas ágiles utilizadas y de los elementos para la gestión
del proyecto propuestos por Kanban.
2.7.1 Iteración 1
Dado que lo único que prescribe Kanban es que el flujo de trabajo debe ser visual, y que
el trabajo en curso debe estar limitado, resulta muy importante decidir las columnas a
manejar en el tablero, así como los límites para cada una, con tal de crear un flujo suave a
través del sistema y minimizar el tiempo de entrega. Inicialmente se decidió conformar el
tablero con las siguientes columnas:
- Pila de producto. Contiene las historias de usuario sin analizar.
- Listo para desarrollo. Muestra las historias de usuario priorizadas, con el nivel
de detalle necesario para su desarrollo. Se limita a cinco elementos
simultáneamente.
- En curso. Columna que se subdivide en dos, por un lado la columna

desarrollo que contiene elementos en los que se está trabajando, con un
máximo de dos a la vez, y la columna pruebas, que limitada a un elemento,
muestra los componentes que están siendo probados.
- Terminado. Agrupa las historias de usuario completadas.
41
Durante unos días, ayudados significativamente por el cliente, se trabajó para obtener una
primera definición de las características que debía cumplir el sistema a desarrollar. Como
resultado se obtuvo la pila de producto, conformada por las historias de usuario que
guiarán el proceso de desarrollo.
La tabla 2.9 muestra, en síntesis, la pila de producto obtenida, especificando quién

propone la historia de usuario y por qué lo hace.
Tabla 2.9S íntesis de la pila de producto
Pila de producto de Open Sky

ID Definición Propone Motivación
HIS-1 Crear modelo de bloques Cliente Representar el terreno
HIS-2 Visualizar el modelo Cliente Brindar una representación 3D del
modelo y sus atributos
HIS-3 Crear cono de restricción Cliente Representar el diseño de una mina,
con un aprovechamiento óptimo del
terreno
HIS-4 Cargar valores netos Cliente Incluir en cada bloque la estimación
de cuanto recurso contiene
HIS-5 Acotar modelo aplicando Cliente Reducir el modelo a los bloques de
algoritmo de Lerch-Grossman mayor provecho según el algoritmo
de Lerch-Grossman
Inicialmente se realizó una reunión de planificación con el objetivo de organizar y detallar

las historias de usuario de la pila de acorde a las prioridades del cliente. El hecho de que
el equipo contara con conocimientos sobre el dominio de la aplicación y experiencias en
este trabajo, facilitó bastante la planificación.
El desarrollo fluyó cómodamente, siguiendo el orden lógico de las tareas establecidas en

la planificación, comenzando por la obtención de la estructura para el modelo de bloques.
Aprovechando la existencia del código necesario para el trabajo con el modelo de
bloques, la historia de usuario HIS-1 fue rápidamente completada, pues solo hubo que
hacer una pequeña adaptación de código ya existente y probado. Igual sucedió con la
historia HIS-2, completando así en menos de diez días, una buena parte del proyecto,
aunque en gran medida esta rapidez se debió al desarrollo previo de Estimation Tool.
Transcurridos veinte días desde el inicio del proyecto se había logrado completar también
la historia de usuario HIS-4, encargada de cargar valores estimados por otra herramienta,
42
hacia cada bloque del modelo. La utilización de pair-programming influía positivamente en
la rapidez y calidad con que se escribía el código.
Con el avance del proyecto comenzaron a aparecer complicaciones para diseñar un

algoritmo que definiera el cono óptimo para un modelo dado, causadas principalmente por
lo complicado de combinar la geometría del cono con la estructura del modelo de bloques.
Estos problemas trajeron consigo la aparición de un cuello de botella en el proceso de
desarrollo, que evidenciado por el tablero Kanban, movilizó rápidamente al equipo en pos
de encontrar una solución. Finalmente, se dispuso de una biblioteca de apoyo para el
trabajo con la geometría del cono, lo que ayudó en gran medida a resolver las dificultades.
Cumpliendo lo acordado se realizó una reunión retrospectiva al concluir la cuarta semana,

donde se comprobó que gracias a la experiencia en el dominio de la aplicación, la
planificación resultó bastante sencilla y realista a la vez. Se constató la eficiencia para
reaccionar ante los problemas por parte de Kanban, así como su capacidad de adaptación
a los cambios surgidos, permitiendo incorporar nuevas historias de usuario al desarrollo
en cualquier momento. Como aspecto negativo se advirtió la falta de conocimiento
general acerca del proyecto, debido a la celebración de pocas reuniones con el equipo en
su totalidad, acordándose aumentar el número de actividades de esta índole.
La tabla 2.10 muestra un resumen del desarrollo del proyecto hasta la cuarta semana.
Tabla 2.10Resumen del desarrollo de Open S ky hasta la semana 4
Elemento Valor
%Completado 62% completado, basado en las estimaciones por puntos de historia.
pila de productos
Lead Time La media fue de 6 días.
(tiempo de
entrega)
Desarrollo Número de clases: 17 (12 adaptadas) Líneas de código: 1173
%Tareas en curso Crear cono de restricciones (HIS-3): 80%
Puntuación +20
retrospectiva
2.7.2 Iteración 2
La segunda iteración constituyó la última del experimento dado. El trabajo pendiente era
concluir la historia de usuario HIS-3, con un 80% de completamiento hasta el momento, y
HIS-5, que fue analizada nuevamente para lograr mayor nivel de detalle en sus tareas.
43
Como resultado de este análisis se subdividió HIS-5 en dos nuevas historias más
pequeñas, HIS-6 que seleccionaría los mejores bloques según el algoritmo de Lerch-
Grossman y HIS-7 que simplemente acotaría el modelo, eliminando de la estructura de
datos los bloques obviados por HIS-6.
El desarrollo transcurrió sin contratiempos mayores, confirmando la buena labor en la

planificación y especificación de las historias de usuario, además de corroborar el valor
positivo de reunir a todo el equipo al menos 3 veces por semana. Transcurridas tres
semanas de la segunda iteración se había completado el producto, dedicando la cuarta
semana a pruebas solamente, período en el que se puso de manifiesto nuevamente la
efectividad de utilizar pair-programming, y de efectuar pruebas a medida que se
desarrolla, pues no se detectaron defectos en el software.
Tabla 2.11Resumen del desarrollo de Open S ky segunda iteración
Elemento Valor
%Completado 100% Completado.
pila de productos
Lead Time La media fue de 9 días.
(tiempo de
entrega)
Desarrollo Número de clases: 20 (12 adaptadas) Líneas de código: 1256
Puntuación +15
retrospectiva
2.8 Conclusiones
A modo de conclusión parcial del capítulo se puede decir que se detallaron los procesos
de desarrollo de los sistemas Estimation Tool y Open Sky, los que fueron guiados por los
patrones que imponen Scrum y Kanban respectivamente. Ambas aplicaciones se
completaron en su totalidad permitiendo hacer un análisis del rendimiento del equipo al
utilizar cada metodología. Se observó una mayor organización al desarrollar con Scrum,
pues el hecho de que Kanban permite más libertades combinado con la heterogeneidad
institucional de los integrantes del equipo de desarrollo, propició un pequeño relajamiento
al emplear Kanban.
44
Finalmente los resultados de ambos desarrollos fueron positivos, pues los conocimientos
adquiridos por el equipo respecto al dominio de las aplicaciones durante la utilización de
Scrum, facilitaron el poder lidiar con los problemas surgidos durante el segundo
desarrollo. Se obtuvieron dos aplicaciones de calidad en el tiempo acordado, cumpliendo
con las expectativas del cliente.
45
CAPÍTULO 3: ANÁLISIS DE RESULTADOS
3.1 Introducción
En este capítulo se realiza el análisis del experimento que da base al estudio, con el
objetivo de dar respuesta a las cuestiones que guían la investigación y valorar el
desarrollo delos productos aplicando metodologías ágiles como Scrum y Kanban.
3.2 Características de los productos durante el desarrollo
En esta sección se analiza la evolución de los productos, Estimation Tool y Open Sky,
durante el desarrollo hasta constituir los productos finales. Tratándose de dos procesos de
integración continua a pequeña escala, a través de los cuales, mediante historias de
usuario, se fueron incorporando funcionalidades. La figura 3.1 muestra gráficamente la
evolución del Product Backlog que guiaba el desarrollo de Estimation Tool, mientras la
figura 3.2 presenta la evolución de la pila de producto de Open Sky.
Figura 3.1Evolución del Product Backlog durante el desarrollo de Estimation Tool
46
Figura 3.2Evolución de la pila de producto durante el desarrollo de Open S ky
El área de color rojo refleja el número de funcionalidades a implementar en las sucesivas

iteraciones. Durante ambos desarrollos se observa un incremento en esta cifra, debido al
hecho de que a medida que avanzaban los proyectos el nivel de detalle con el que se
veían los componentes fue mayor. El área azul muestra la integración de funcionalidad en
los productos a lo largo del desarrollo, conforme se daban por concluidas las historias de
usuario.
En ambos proyectos el porcentaje final de realización de la pila de producto fue del 100%,
aunque con evoluciones distintas. Las figuras 3.3 y 3.4 muestran la evolución de estos
porcentajes a medida que avanzaba el desarrollo.
Figura 3.3Evolución del porcentaje de realización Figura 3.4Evolución del porcentaje de realización de
del Product Backlog de Estimation Tool la pila de producto de Open S ky
47
Claramente se observa una evolución estable del producto en ambos casos, debida, en
gran medida, a la aplicación de la integración continua como práctica ágil, pues al
conformar el producto con integraciones pequeñas, la evolución ha sido progresiva y sin
grandes problemas.
La evolución en líneas de código, tanto para el producto Estimation Tool como para Open
Sky, puede verse en las figuras 3.5 y 3.6, respectivamente. Del mismo modo las figuras
3.7 y 3.8 muestran la evolución en clases impactadas durante el desarrollo para ambos
productos. Cabe destacar la notable diferencia existente entre los dos productos. La
evolución de Estimation Tool mostró inestabilidad al principio del desarrollo, debido a que
al comienzo la falta de conocimiento sobre el dominio de la aplicación ocasionó que se
manipularan más clases de las que era necesario manipular. En Open Sky el incremento
de líneas de código al igual que las clases impactadas se comportó de forma normal.
Figura 3.5Evolución del código de Estimation Tool Figura 3.6Evolución del código de Open S ky
48
Figura 3.7Evolución del impacto en las clases de Figura 3.8Evolución del impacto en las clases de
Estimation Tool Open S ky
Podemos concluir que la experiencia adquirida por el equipo durante el desarrollo de este
experimento, tanto en las prácticas como en el dominio de las aplicaciones, ha sido crucial
en el volumen de funcionalidad integrada.
3.3 Aspectos de agilidad en el desarrollo
En esta sección se analizará la evolución de la productividad en las distintas iteraciones

que se han desarrollado hasta conseguir los productos finales, con el objetivo de dar
respuesta a cómo evoluciona la agilidad en el desarrollo al utilizar metodologías ágiles
como Scrum y Kanban.
Para el estudio de la productividad en ambos productos, esta se ha medido en cuanto a

objetivos alcanzados de la pila de producto, en cada iteración, respecto al esfuerzo
invertido en el mismo. Las figuras 3.9 y 3.10 visualizan gráficamente el esfuerzo destinado
a los proyectos Estimation Tool y Open Sky respectivamente en cada iteración, medido en
horas.
49
Figura 3.9Esfuerzo dedicado a Estimation Tool en Figura 3.10Esfuerzo dedicado a Open S ky en cada
cada sprint iteración
El descenso de motivación y la aparición de otras responsabilidades propias del contexto

universitario en el que se desarrolla el experimento, propició que algunos miembros del
equipo incumplieran su compromiso y, consecuentemente, el esfuerzo dedicado al
desarrollo resultara variable, con un decremento hacia los finales. Por otro lado, la
agilidad alcanzada por el grupo con el transcurso del tiempo, explica que se cumplieran
los objetivos con una destinación menor de recursos.
Una vez conocidos los valores de esfuerzo dedicado al proyecto y considerando el

porcentaje de realización de la pila de productos en cada iteración que aparece en las
figuras 3.3 y 3.4, se ha calculado el valor de la productividad en cada iteración del modo
que se indica a continuación:
Productividad (Ix) =
Las figuras 3.11 y 3.12 muestran los resultados obtenidos para Estimation Tool y Open
Sky respectivamente.
50
Figura 3.12Evolución de la productividad durante el
Figura 3.11Evolución de la productividad durante el desarrollo de Open S ky
desarrollo de Estimation Tool
De manera general las gráficas muestran que con el transcurso del desarrollo aumenta la
productividad en el proceso, es decir, se cumplen más objetivos y se es más ágil. En el
caso específico de Estimation Tool, inicialmente el equipo mostró un rendimiento bajo,
causado fundamentalmente por el desconocimiento del dominio a desarrollar y la poca
experiencia en el uso de metodologías ágiles, teniendo que dedicar gran parte del
esfuerzo a conocer la metodología y habituarse a ella.
3.4 Calidad en productos obtenidos
Uno de los aspectos que mayor satisfacción ha aportado tanto al cliente como al equipo
de desarrollo es la calidad de los productos obtenidos.
Durante el desarrollo de Estimation Tool y Open Sky, un integrante del equipo se dedicó
exclusivamente a realizar las pruebas de validación de los productos. No obstante, los
aspectos a probar resultaban tan obvios que ya habían sido probados por los propios
desarrolladores, obteniendo ventaja de la utilización de pair-programming. Gracias a un
trabajo incisivo en este aspecto, no se encontraron defectos en las distintas entregas de
los productos a los clientes.
La tasa de defectos encontrados durante las fases de pruebas en Estimation Tool y Open
Sky sigue la distribución que aparece en las figuras 3.13 y 3.14 respectivamente.
51
Figura 3.14Evolución de la tasa de errores en el
Figura 3.13Evolución de la tasa de errores en el producto Open S ky
producto Estimation Tool
El número de defectos encontrados es muy bajo, constatando el hecho de que dos

personas dedicadas al desarrollo simultáneamente favorece la obtención de productos de
calidad.
3.5 Esfuerzo de adaptación
Adaptarse a los nuevos hábitos establecidos por las metodologías Scrum y Kanban, es un
elemento cuya complejidad radica en el propio factor humano. La variación del esfuerzo
empleado en tareas vinculadas con aspectos metodológicos tales como la preparación y
realización de reuniones a lo largo del experimento, constituye una métrica que nos puede
dar una idea de esta situación. Las figuras 3.15y 3.16 muestran gráficamente esta
evolución.
52
Figura 3.15Distribución del esfuerzo en tareas Figura 3.16Distribución del esfuerzo en tareas
relacionadas con S crum relacionadas con Kanban
En el desarrollo de Estimation Tool, durante los primeros sprints la motivación del equipo
propicio que todas las tareas relacionadas con Scrum fueran llevadas a cabo, aunque la
falta de adaptación a la metodología hizo que consumieran un tiempo considerablemente
mayor al establecido teóricamente. A medida que avanzaba el desarrollo, el tiempo
dedicado a este tipo de tareas se fue estabilizando.
De otro lado, el desarrollo de Open Sky se caracterizó por una dedicación mucho menor a
las tareas relacionadas con la metodología Kanban, debido a la experiencia adquirida con
el uso de Scrum.
Otro elemento interesante resulta la puntuación con la que fue calificada cada iteración,
pues nos proporciona información sobre el grado de adaptación del equipo a la
metodología, ya que las reuniones retrospectivas se centraban principalmente en
aspectos metodológicos.
53
Figura 3.18Evolución en la calificación de las
Figura 3.17Evolución en la calificación de los sprints iteraciones
En la figura 3.17 se muestra como tras un periodo de adaptación a la metodología Scrum,

el equipo comienza a adquirir progresivamente hábitos ágiles. No obstante, cuando
parecía lograda la adaptación, hubo un periodo de desmotivación y ruptura de
compromisos que provocó que muchos de los hábitos adquiridos fuesen prácticamente
olvidados. Luego de este periodo, el equipo comenzó a restablecer prácticas de desarrollo
ágil y a adaptar los aspectos teóricos aprendidos a sus condiciones de desarrollo.
La figura 3.18 presenta la estabilidad mantenida durante el desarrollo con Kanban,

causada por su semejanza con Scrum, habiendo obtenido experiencias de esta última con
antelación.
54
3.6 Satisfacción general del equipo
La satisfacción final fue positiva para todos los miembros del equipo incluido el cliente.
Las medidas de satisfacción han sido recogidas al finalizar cada iteración, cuando los
integrantes del proyecto debían valorar el grado con que se había ajustado la iteración a
sus necesidades, considerando tanto el resultado desde la perspectiva del producto como
sus sensaciones respecto a la metodología, otorgando a cada iteración un valor
comprendido entre 0 y 10.
Las figuras 3.19 y 3.20 muestran una media de la satisfacción del equipo a lo largo del
desarrollo junto a la satisfacción desde el punto de vista del cliente, para los productos
Estimation Tool y Open Sky respectivamente.
Figura 3.19Evolución de la satisfacción del equipo y Figura 3.20Evolución de la satisfacción del equipo y
del cliente durante el desarrollo de Estimation Tool del cliente durante el desarrollo de Open S ky
La satisfacción del cliente en ambos casos, se ha ido incrementando a medida que

avanzaba el desarrollo, debido principalmente al cumplimiento de objetivos. Dicha
satisfacción refleja el agrado del cliente con la calidad del producto obtenido.
La evolución de la satisfacción del equipo en el caso de Estimation Tool, ha pasado por

diferentes etapas. La poca experiencia del grupo influyó en que el comienzo fuese
complicado. Indudablemente, la satisfacción de la mayor parte de los integrantes en este
punto se vio socavada por la fase de planificación. No obstante, se valoró positivamente la
interacción entre el equipo. A medida que aumentó el conocimiento, la experiencia en la
55
metodología y en el dominio del producto a desarrollar, se observó un aumento en la
satisfacción del equipo.
Finalmente, el desarrollo tanto con Scrum como con Kanban resultó muy satisfactorio
para los miembros del equipo.
3.7 Resumen de análisis de las metodologías Scrum y Kanban
En esta sección se expresa, a grandes rasgos, las principales semejanzas y diferencias

existentes entre las dos metodologías.
3.7.1 Semejanzas
Ambos emplean sistemas de planificación pull. El equipo elige cuándo y cuánto

trabajo acometer.
Ambos establecen límites para el trabajo en curso. Scrum lo limita por iteración,
mientras Kanban lo hace por los estados en el flujo de trabajo.
En ambos la visibilidad del proceso es la base para su mejora.
Ambos tienen como objetivo la entrega temprana y frecuente de software.
Ambos trabajan con equipos auto-organizados.
Ambos necesitan la división del trabajo en tareas.
Ambos revisan y mejoran de forma continua el plan del producto en base a datos
empíricos como la velocidad y el tiempo de entrega.
56
3.7.2 Diferencias
Tabla 3.1Diferencias entre Scrum y Kanban
Scrum Kanban
Las iteraciones deben ser de tiempo fijo. El tiempo fijo en las iteraciones es opcional. La
cadencia puede variaren función del plan del
producto y la mejora del proceso. Pueden estar
marcadas por la previsión de los eventos en lugar
de tener un tiempo pre-fijado.
Se emplea una limitación del trabajo en curso La limitación del trabajo en curso es directa,
indirecta (por sprint). marcada por el estado del trabajo dentro del flujo.
Deben emplearse gráficos Burndown. No se prescriben diagramas de seguimiento
concretos.
Se deben realizar estimaciones. Las estimaciones son opcionales.
No se pueden añadir tareas en medio de una Siempre que haya capacidad disponible, se pueden
iteración. añadir tareas.
Prescribe 3 roles: Product Owner, Scrum Master No hay roles prescritos.
y Scrum Team.
En cada sprint se limpia el tablero de El tablero Kanban es persistente.
seguimiento.
La pila del producto debe estar priorizada. La priorización es opcional.
La métrica por defecto para la planificación y la La métrica por defecto para la planificación y la
mejora del proceso es la Velocidad del equipo. mejora del proceso es el Lead Time (tiempo de
entrega o tiempo medio que tarda una petición en
salir del ciclo).
3.8 Conclusiones
Aunque los análisis realizados muestran un desarrollo más estable en todos los sentidos
con la metodología Kanban, se presume que sea producto de haber llegado a esa etapa
del experimento con la experiencia adquirida previamente en el uso de la metodología
Scrum, además, el hecho de que las iteraciones con Kanban fueran más largas
complejiza aún más la comparación en este sentido. Ambas metodologías demostraron
capacidad de adaptación ante los cambios surgidos en el proceso de ejecución del
proyecto, ostentando Kanban el liderazgo en velocidad de respuesta a las exigencias
emergentes del cliente, al ser más flexible en cuanto a cambios en el trabajo en curso
durante una iteración. De igual manera se constató que al emplear la metodología
Kanban, el equipo dispuso de más libertades para organizar y llevar a cabo el trabajo,
57
necesario para equipos cuyos integrantes se encuentran geográficamente dispersos,
mientras Scrum mostró un mayor rigor en la gestión, haciéndola ideal para equipos con
alto grado de profesionalismo y capacidad de contacto diario.
58
CAPÍTULO 4: DESARROLLO DEL SISTEMA GESTOR DE CONEXIONES
4.1 Introducción
Este capítulo describe la implementación de la metodología de trabajo Scrum para la

gestión del desarrollo del proyecto Gestor de Conexiones. Incluye junto con la descripción
de este ciclo de vida iterativo e incremental, los artefactos o documentos con los que se
gestionan las tareas de desarrollo, así como una descripción del proyecto.
4.2 Gestor de Conexiones
El sistema Gestor de Conexiones constituye un proyecto real de la Dirección de

Soluciones Informáticas (DSI) en colaboración con la Facultad de Ingeniería Informática
del Instituto Superior Politécnico José Antonio Echeverría. El proyecto comprende la
creación de una aplicación destinada a la plataforma Android1, siguiendo el propósito de
experimentar en el ámbito de una nueva línea de productos en los que pretende
incursionar la DSI, relacionados con aplicaciones para teléfonos móviles.
Gestor de Conexiones tiene como objetivo controlar las conexiones disponibles en el

dispositivo con el propósito de priorizar el uso de redes Wi-Fi2 sobre 3G3. La aplicación
debe ser capaz de utilizar el gestor Wi-Fi nativo del equipo para mostrar el listado de
redes disponibles y una descripción de estas, permitiendo conectarse a una nueva red o a
una previamente configurada, haciendo uso de diferentes protocolos de seguridad. En el
diseño de la aplicación deben considerarse ciertas exigencias del cliente, referidas a la
interfaz gráfica.
La figura 4.1 muestra un diagrama esquemático de la interfaz de la aplicación y algunas

funcionalidades.
1
Sistema operativo para dispositivos móviles basado en Linux.
2
Redes inalámbricas de área local que cumplen con estándares 802.11.
3
Redes de telefonía móvil que brindan servicios asociados con la tercera generación de este tipo de redes.
59
Figura 4.1 Diagrama esquemático de la interfaz de Gestor de Conexiones.
60
La figura 4.2 consiste en un diagrama de clases cuyo objetivo es brindar una visión más
clara de la estructura de la aplicación, desde un punto de vista ingenieril.
Figura 4.2 Diagrama de clases. Gestor de Conexiones
La clase GestorConexiones es la interfaz gráfica principal de la aplicación y se puede

considerar como núcleo, que junto con las clases ListaRedesWiFi, Preferencias y
Configuraciones, constituyen especializaciones de la clase Activity perteneciente al
framework de desarrollo de Android. La clase XMLConfig se encarga de hacer persistir
las configuraciones de la aplicación en un fichero XML. Tanto la clase GestorConexiones
como ListaRedesWiFi hacen uso de la clase WifiManager del framework de Android
para controlar lo relacionado con el uso de las redes WiFi.
61
Desarrollo con Scrum
La principal razón del uso de un ciclo de desarrollo de tipo Scrum para la ejecución de
este proyecto es la petición por parte del cliente de que así fuera, sumado a la previsible
inestabilidad de requisitos, ya que:
Es posible que el sistema incorpore más funcionalidades de las inicialmente

identificadas.
Es posible que durante la ejecución del proyecto se altere el orden en que se

desean recibir los módulos o historias de usuario terminadas.
Para el cliente resulta difícil precisar cuál será la dimensión completa del sistema,
y su crecimiento puede continuarse en el tiempo, suspenderse o detenerse.
La tabla 4.1 muestra las personas que componen el equipo de desarrollo y sus
respectivos roles.
Tabla4.1Personas y roles del proyecto
Persona Contacto Roles

Alejandro Carmenates acarmenates@ceis.cujae.edu.cu Scrum Manager / Programador
Ernesto Menéndez emenendez@tesla.cujae.edu.cu Product Owner / Programador
4.2.1 Artefactos
En esta sección se enumeran los artefactos utilizados, y se exponen algunos de los más
importantes. Para la confección de los artefactos de gestión y monitorización del proceso
de desarrollo fue empleada una plantilla con características dinámicas, capaz de crear y
mantener actualizada las gráficas de avance según transcurre el desarrollo.
Documentos:
o Pila de producto o Product Backlog

o Pila de sprint o Sprint Backlog
Sprint.
Incremento.
Gráficas para registro y seguimiento del desarrollo:
o Gráfica de avance o Burn Down.

62
Comunicación:
o Reunión de inicio de sprint.

o Reunión técnica semanal.
o Reunión de cierre de sprint y retrospectiva.
Pila de producto
Es el equivalente a los requisitos del sistema en esta metodología. El Product Owner debe
encargarse de su correcta gestión durante todo el proyecto, pidiendo el asesoramiento
que pueda necesitar para su redacción y gestión al Scrum Manager de este proyecto.
Responsabilidades del Product Owner:

Registro y mantenimiento en la lista de pila del producto de las historias
de usuario que definen el sistema.
o Incorporación / eliminación /modificaciones de las historias o de
su orden de prioridad.
o Comunicar los cambios al Scrum Manager para la pronta
gestión de estos.
Responsabilidades del Scrum Manager

Supervisión de la pila de producto, y comunicación con el Product
Owner.
La figura 4.3 muestra las historias de usuario que fueron inicialmente identificadas durante
la planificación.
63
Figura 4.3 Product Backlog inicial de Gestor de Conexiones
64
Pila de Sprint
Es el documento de registro de los requisitos detallados o tareas que va a desarrollar el

equipo en cada iteración.
Las figura 4.4 y 4.5 muestran las respectivas pilas de los sprints 1 y 2, habiendo
transcurrido once días de desarrollo en ambos casos.
Figura 4.4 Sprint Backlog del S print 1
65
Figura 4.5 Sprint Backlog del S print 2
Sprint
Cada una de las iteraciones del ciclo de vida iterativo de Scrum, cuya duración se
determinó fuera de 15 días para el proyecto Gestor de Conexiones.
Incremento
Parte del sistema que se produce en un sprint y se entrega al gestor del producto
completamente terminada y operativa.
Gráfica de avance (Burn Down)
Gráfico que muestra el estado de avance del trabajo del sprint en curso. Sería actualizado
por el Scrum Manager al menos cada tres días en este caso.
Las figuras 4.6 y 4.7 muestran los respectivos gráficos de los sprints 1 y 2 al terminar las
iteraciones.
66
Figura 4.6 Gráfico de avance del S print 1
El grafico correspondiente al Sprint 1 muestra un pronto progreso en las labores

planificadas, manteniendo incluso un sobrecumplimiento la mayor parte del tiempo. Ya en
el final de la iteración, la ausencia de recursos (dispositivo real con sistema Android,
infraestructura de red Wi-Fi) necesarios para probar el incremento de funcionalidad del
sistema, propició el incumplimiento del plan del sprint, situación que se repetiría durante el
Sprint 2 como muestra su respectivo gráfico de avance.
67
Figura 4.7 Gráfico de avance del S print 2
Reunión de incio de sprint
Reunión para determinar las funcionalidades o historias de usuario que se van a incluir en
el próximo incremento. El Product Owner debe exponer y explicarlas historias que
necesita para la próxima iteración y las posibles restricciones de fechas que pudiera tener.
Las tareas serán auto-asignadas, llegando a un compromiso por parte de cada
desarrollador.
68
Reunión técnica semanal
Reunión semanal de corta duración para brindar una visión actualizada del estado del
sprint a todo el equipo, como forma de suplir la ausencia de reuniones diarias. Cada
persona deberá brindar:
Comunicación individual del trabajo realizado hasta el momento.
Actualización individual del trabajo pendiente.
Notificación de necesidades o impedimentos para realizar las tareas asignadas.
Por último se actualizará el gráfico de avance (Burn Down) para reflejar el estado de
avance del sprint.
Reunión de cierre de sprint y retrospectiva.
Reunión para probar y entregar el incremento al Product Owner, y hacer un análisis sobre
el desempeño del equipo, proponiendo de ser posible, elementos capaces de mejorar el
proceso.
4.3 Conclusiones
El desarrollo del sistema Gestor de Conexiones demostró la efectividad del uso de Scrum
como metodología, ya que a pesar de contar solo con dos desarrolladores se avanzó
rápidamente durante los dos sprints terminados, llegando a completar el 75% del proyecto
antes de que fuera cancelado el proyecto.
El progreso durante cada sprint fue evidente, aunque en ambos casos quedaron tareas
sin concluir debido a la falta de recursos para probar el correcto funcionamiento del
sistema. Gracias al uso de Scrum el equipo pudo planificar de manera eficiente el trabajo,
asignando las tareas en correspondencia con la capacidad de cada integrante. Aunque la
comunicación con el cliente fue muy pobre, se puede destacar que entre los integrantes
del equipo la información fluyo de forma rápida y se respetó el criterio de cada
desarrollador.
69
CONCLUSIONES
El análisis de los resultados presentados nos lleva a pensar que las metodologías ágiles
propician la optimización progresiva de los procesos de desarrollo de software, y que
proporcionalmente hacen crecer la productividad del equipo, enfatizando en la calidad del
producto lo que deriva en satisfacción tanto para el cliente como para los desarrolladores.
Como conclusiones del presente trabajo se arribó a:
- La similitud entre las metodologías Scrum y Kanban, propicia que puedan ser
utilizadas indistintamente con resultados positivos, a pesar de resultar Kanban un
tanto más flexible.
- Se obtuvo una descripción detallada de la realización de un experimento

comparativo entre las metodologías Scrum y Kanban, el cual demostró que
independientemente de la metodología utilizada:
o La utilización de pair-programming como práctica ágil, influye en gran medida

en la rápida obtención de código limpio y eficiente.
o La definición detallada de las historias de usuario y el método de estimación

colaborativa basado en la experiencia, conducen a una planificación realista,
siendo una labor sobre la que influye mucho el conocimiento respecto al
dominio de la aplicación a desarrollar y de las tecnologías/arquitectura a
emplear.
- Se desarrolló el sistema Gestor de Conexiones (Representativo de una línea de

productos próxima a iniciarse en la DSI) completando el 75% de su totalidad antes
de ser detenido por el cliente. Haberlo desarrollado con resultados positivos
ayuda a demostrar la aplicabilidad de los métodos ágiles en las condiciones de la
DSI.
70
RECOMENDACIONES
Existen algunos aspectos que se desprenden de este trabajo investigativo en los cuales
sería útil seguir profundizando y otros que se recomiendan tener en cuenta como son:
- Evaluar herramientas de soporte a la gestión de proyectos ágiles, como

VersionOne, Ice Scrum y Xplanner, que prometen facilitar el proceso de desarrollo.
- Probar la utilización de servidores de compilación para labores de integración

continua, como QuickBuild y Hudson.
- Profundizar en el estudio de los procesos automatizados de pruebas propuestos

por las metodologías ágiles, así como en la utilización de Desarrollo Guiado por
Pruebas (TDD).
71
REFERENCIAS BIBLIOGRÁFICAS
1. Qumer, A. y Henderson-Sellers, B.An evaluation of the degree of agility in six agile methods and its
applicability for method engineering. 2007.
2. Cao, L. y Ramesh, B.Agile Requirements Engineering Practices: An Empirical Study. 2008. págs. 60-67.
3. Robinson, H. y Sharp, L.The social side of technical practices in eXtreme Programming and Agile
Processes in Software Engineering. Berlin : s.n., 2005. págs. 139-147.
4. Canós, J. H., Letelier, P. y Penadés, M. C. Metodologías Ágiles en el Desarrollo Software. VIII Jornada
de Ingeniería de Software y Bases de Datos. 2003.
5. Fowler, M. The New Methodology. [En línea] 2005. [Citado el: 16 de octubre de 2011.]
http://martinfowler.com/articles/newMethodology.html.
6. Takeuchi, H. y Nonaka, I.The New Product Development Game. 1986. págs. 137-146.
7. Schwaber, K. y Beedle, M.Agile Software Development with Scrum. s.l. : Conchango, ISBN:
0130676349., 2006.
8. Cohen, M.User Stories Applied for Agile Software Development. s.l. : The Addison-Wesley Signature
Series, ISBN: 0321205685, 2004.
9. Beck, K. y Andres, C.Extreme Programming Explained: Embrace Change. Boston : Addison Wesley
Professional, 2004.
10. XP. Extreme Programming. [En línea] [Citado el: 21 de Noviembre de 2011.]
http://www.extremeprogramming.org.
11. Poppendieck, M. y Poppendieck, T.Lean Software Development - An Agile Toolkit for Software
Development Managers. Boston : Addison-Wesley, ISBN 0-321-15078-3., 2003.
12. Kniberg, H y Skarin, M.Kanban and Scrum making the most of both. s.l. : C4Media Inc, ISBN: 978-0-
557-13832-6., 2010.
13. Cockburn, A.Crystal Clear: A Human-Powered Methodology for Small Teams. s.l. : Addison-Wesley,
ISBN 0-201-69947-8, 2004.
14. Stapleton, J.DSDM: Business Focused Development. s.l. : Pearson Education, ISBN 978-0321112248,
2003.
15. Palmer, S. R. y Felsing, J. M.A Practical Guide to Feature-Driven Development. Upper Saddle River,
NJ : Prentice Hall, ISBN 0-13-067615-2., 2002.
16. MendesCalo, K, Estevez, E y Fillottrani, P.Un Framework para Evaluación de Metodologías Ágiles.
Bahía Blanca, Argentina : Departamento de Ciencias e Ingeniería de la Computación, Universidad Nacional
del Sur, 2010. Informe de Investigación.
17. Abrahansson, P., y otros.Agile Software Development Methods. s.l. : VTT Publications 478, 2002.
18. Iacovelli, A. y Souveyet, C. Framework for Agile Methods Classification. Workshop on Model Driven
Informat. Systems Eng.: Enterprise, User and System Models. 2008.
19. Strode, D. E.The Agile Methods: An Analytical Comparison of Five Agile Methods and an Investigation
of Their Target Environment. Palmerstin North, Nueva Zelanda : Massey University, 2005. MSc Thesis in
Information Systems.
20. Mackie, K.Lessons From a Yahoo Scrum Rollout. 2008.
21. CM Crossroads. CM Crossroads. [En línea] 2006. http://www.cmcrossroads.com/h.html.
22. VersionOne Team. Version One 3rd Annual State Of Agile. Version One. [En línea] 2011.
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf.
23. Mazán, Manuel. Aplicando Kanban para Recuperar un Proyecto Caótico. SG Buzz. [En línea] SG #35.
Agilidad, 2012. http://sg.com.mx/.
24. Fernández, A. D. y Amodeo Rubio, E. J.Un caso real con equipos de trabajo en remoto. s.l. : Agile
Spain CAS2010. Ser Ágil en España, 2007.
25. Blatter, Claudia. Kanban vs. Scrum. Dos Ideas. [En línea] 2009.
http://www.dosideas.com/noticias/metodologias/555-kanban-vs-scrum.html.
26. Merisalo-Rantanen, H., Tuunanen, T. y Rossi, M.Is Exreme Programming Just Old Wine in New
Bottles: A Comparison of Two Cases. 2005. págs. 41-61.
27. Capiluppi, A., y otros.An empirical study of the evolution of an agile-developed software system. 2007.
págs. 511-518.
72
28. Endres, A. y Rombach, D.A Handbook of Software and Systems Engineering, Empirical Observations,
Laws and Theories. Fraunhofer : Institut Experimentelles Software Engineering. Ed. Pearson Addison
Wesley, 2003.
29. Williams, Laurie A., Layman, Lucas y Krebs, William.Extreme Programming Evaluation Framework
for Object-Oriented Languages Version 1.4. s.l. : NCSU Computer Science TR-2004-18, 2004.
30. Hartmann, D. y Dymond, R.Appropiate Agile Measurement: Using Metrics and Diagnostics to Deliver
Business Value. s.l. : Proceedings of AGILE 2006 Conference (AGILE’06), 2006.
31. Alfaro, Marco Antonio.Estimación de Recursos Mineros. 2007.
32. Godoy, Marcelo .Estimación de Recursos. 2009.
33. Ogayar, Carlos Javier.Optimización de Algoritmos Geométricos Básicos Mediante el Uso de
Recubrimientos Simpliciales. 2006.
34. ScrumAlliance. ScrumAlliance. [En línea] 2003. [Citado el: 7 de diciembre de 2011.]
http://www.scrumalliance.org.
35. Jacobson, Ivar, Booch, Grady y Rumbaugh, James.El Proceso Unificado de Desarrollo de Software.
s.l. : Addison Wesley, 2000.
36. Ambler, Scott W. Agile Modeling and the Rational Unified Process (RUP). [En línea] [Citado el: 15 de
enero de 2012.] http://www.agilemodeling.com/.
37. —. The Agile Unified Process (AUP). [En línea] [Citado el: 15 de enero de 2012.]
http://www.ambysoft.com/.
38. Schwaber, K.Agile Project Management with Scrum. 2004.
39. Cockburn, A.Selecting a Project's Methology, Humans and Technology. s.l. : IEEE SOFTWARE, 2000.
40. González Castellanos, Roberto A.Metodología de la Investigación Científica para las Ciencias
Técnicas. s.l. : Universidad de Matanzas, 2003.
41. Kniberg, Henrik. Scrum y XP desde las trincheras, Cómo hacemos Scrum. s.l. : C4Media Inc, ISBN:
978-1-4303-2264-1, 2007.
42. Estévez, Elmidio.Apuntes sobre estimación de recursos y reservas. 2009.
43. Palacio, J. Flexibilidad con SCRUM. [En línea] 2007.
http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf.
44. Palacio, J. y Ruata, C. Scrum Manager: Gestión de proyectos. [En línea] 2009.
http://www.scrummanager.net/files/sm_proyecto.pdf.
73
ANEXOS
Anexo A. Imágenes de los tableros de Scrum y Kanban, tomadas

durante los procesos de desarrollo de las aplicaciones
experimentales.
Figura A.1: Imagen del tablero de S crum durante el S print 3
74
Figura A.2: Imagen del tablero Kanban durante el desarrollo
75
Anexo B. Ejemplo de tarjeta de historia de usuario
HIS-1: Crear modelo de bloques. rev 2.0

Importancia:200 Estimación: 70 pts
Tareas:
- Seleccionar e implementar estructura de datos espacial óptima para el caso.
- Diseñar e implementar clases que permitan representar el modelo de bloques y
sus atributos.
- Implementar algoritmo de subdivisión espacial para la creación del modelo de
bloques.
Notas:
- Debe ser implementado utilizando Octree como estructura de datos.
Comprobar: Pruebas manuales al código.
76
Anexo C. Product Backlog inicial de Estimation Tool
Product Backlog Estimation Tool. Rev 1.0

ID Historia de usuario Prioridad (Cliente) Puntos de historia
estimados
HIS-1 Crear modelo de bloques 200 70
HIS-2 Visualizar modelo 80 20
HIS-3 Gestionar muestras 150 16
HIS-4 Estimar recursos minerales 150 80
HIS-5 Guardar y cargar modelo 100 16
77
Anexo D. Reglas para evaluar las iteraciones

Los elementos realizados correctamente sumarán 5 puntos.
Un elemento realizado correctamente en una iteración que se realiza
incorrectamente en otra posterior restará 10 puntos.
Un elemento realizado correctamente en una iteración anterior que deba mejorarse
en la iteración actual restará 7 puntos.
Elementos positivos que se mantengan de una iteración ala siguiente sumarán 3
puntos.
Un elemento mejorable sumará 7 puntos si se mejora en la siguiente iteración y
restará 5 puntos si no se logra mejorar.
Un elemento que se pueda mejorar y se convierta en un error en la iteración
siguiente restará 7 puntos.
Cada error cometido restará 5 puntos.
Cada error corregido sumará 10 puntos.
Cada error no corregido restará 5 puntos.
Cada error corregido pero que se deba mejorar sumará 7 puntos.
78
Anexo E. Principales interfaces de usuario de las aplicaciones
Estimation Tool y Open Sky.
Figura A.3: Formulario para la creación de un nuevo modelo de bloques
79
Figura A.4: Modelo sin estimar con 25181 muestras
80
Figura A.5: Resultados de estimación
81
Figura A.6: Leyenda para los bloques estimados
82
Figura A.7: Menú para la generación de muestras aleatorias
83
Figura A.8: Aplicación del cono de restricción al modelo en Open S ky
84
Figura A.9: Modelo luego de aplicar algoritmo de Lerch-Grossman en Open S ky
85

Propuesta para La Aplicación de Metodologías Ágiles en La Gestión de Proyectos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Propuesta para La Aplicación de Metodologías Ágiles en La Gestión de Proyectos

Cargado por

Copyright:

Formatos disponibles

INSTITUTO SUPERIOR POLITÉCNICO

“JOSÉ ANTONIO ECHEVERRÍA”

FACULTAD DE INGENIERÍA INFORMÁTICA

Propuesta para la aplicación de metodologías ágiles en la

Alejandro Carmenates Palenzuela ( acarmenates@ceis.cujae.edu.cu )

MSc. José Angel Franco Navarro

CUJAE, Octubre de 2012

La constante y rápida evolución en la industria de software ha obligado a replantear los

Actualmente el desarrollo de software es una actividad que necesariamente debe ser

El objeto de estudio se centra en el modelo ágil de desarrollo de software.

El campo de acción está orientado a las propuestas metodológicas concretas de Scrum,

Se derivan del objetivo general los siguientes objetivos específicos:

Estudiar el estado del arte en materia de modelos de desarrollo ágiles.

Este trabajo se encuentra enmarcado principalmente en el estudio del modelo ágil de

1.2 Metodologías convencionales versus metodologías ágiles

Sin embargo, las metodologías convencionales presentan diversos problemas a la hora

Otra dificultad añadida al uso de metodologías convencionales es la lentitud del proceso

Asimismo, las metodologías convencionales tienden a acumular los riesgos y dificultades

En contraposición a las metodologías convencionales, las metodologías ágiles aparecen

Capacidad de respuesta a cambios a lo largo del desarrollo ya que no los perciben

1.3 Modelo ágil de desarrollo de software

1.4 El Manifiesto Ágil. Valores y principios

Según el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

La colaboración con el cliente por encima de la negociación contractual. Se propone una

1. La prioridad es satisfacer al cliente mediantes tempranas y continuas entregas de

3. Liberar software que funcione frecuentemente, desde un par de semanas a un par de

7. El software que funciona es la principal medida de progreso.

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

9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

10. La simplicidad es esencial.

1.5 Algunas prácticas

1.5.1 Planificación, Historias de usuario

1.5.2 Programación en pareja (Pair Programming)

Otro detalle a tener en cuenta es las habilidades y capacidades de los miembros de la

1.5.3 Integración continua (Countinuous integration)

1.5.5 Desarrollo dirigido por pruebas (Test Driven Development).

No obstante, el hecho de que aspectos tan importantes como la cohesión o el

1.6 Metodologías destacadas

Scrum se concentra, principalmente, a nivel de las personas y equipo de desarrollo que

Cualquier desarrollo de software parte siempre de un mismo problema: conocer las

Primero se determina quién propone la historia de usuario.

¿Qué tareas ha hecho desde la última reunión? Es decir, tareas realizadas en un

La efectividad de la metodología para la gestión de proyectos se basa en un conjunto de

1.6.2 eXtreme Programming

XP se centra en la continua retroalimentación entre el cliente y el equipo de desarrollo, la

1.6.3 Lean Software Development

Kanban es una aproximación a la introducción de cambios en un ciclo de vida de

1.6.5 Crystal Methodologies

1.6.6 Dynamic Software Development Method

1.6.7 Feature-driven Development

1.7 Evaluando Metodologías

1.7.1 Framework de Evaluación

Tabla 1.1Framework de Evaluación de Metodologías Ágiles

Valor Descripción Valor Descripción

0 No define roles para individuos -5 Define actividades, entregables,

3 Clara definición de roles, responsabilidades y -1 Define actividades para cada iteración

Valor Descripción Valor Descripción

0 Generar entregable al finalizar el proyecto -5 Requiere documentación detallada al

Valor Descripción Valor Descripción

0 Cliente colabora a demanda del equipo -5 Existe contratación detallada al inicio y no

P4.1 Valorar la respuesta al cambio P4.2 Valorar el seguimiento de un plan

Valor Descripción Valor Descripción