TESINA: USO DE METODOLOGÍAS ÁGLES PARA EL DESARROLLO DE SOFTWARE EN UNA EMPRESA DE DESARROLLO DE SOFTWARE EN CIUDAD JUÁREZ

1. USO DE METODOLOGÍAS ÁGLES PARA EL DESARROLLO DE SOFTWARE EN
UNA EMPRESA DE DESARROLLO DE SOFTWARE EN CIUDAD JUÁREZ
TRABAJO ESCRITO:
ESTUDIO DE CASO
QUE COMO REQUISITO PARCIAL PARA OBTENER EL GRADO DE
MAESTRÍA EN SISTEMAS DE INFORMACIÓN
PRESENTA:
JOSÉ ANTONIO SANDOVAL ACOSTA
212157
Ciudad Juárez, Chih., abril de 2009

2. Los que suscriben, ASESOR de la Materia de Sistemas de Información y ASESOR
de Metodología respectivamente, hacen CONSTAR que el TRABAJO ESCRITO
orientado a un TRABAJO DE INVESTIGACION denominado:
USO DE METODOLOGÍAS ÁGLES PARA EL DESARROLLO DE SOFTWARE EN
UNA EMPRESA DE DESARROLLO DE SOFTWARE EN CIUDAD JUÁREZ
Elaborada por el pasante de la Maestría en Sistemas de Información:
JOSÉ ANTONIO SANDOVAL ACOSTA
Reúne los términos exigidos por el Reglamento General de Estudios de Posgrado y
por el Reglamento Interior de la Facultad de Contaduría y Administración, por lo que
se aprueba como requisito para la tramitación del examen de grado correspondiente.
Se extiende la presente a los diecisiete días del mes de abril de dos mil nueve.
Asesor de la Materia Asesor de Metodología
M .A. P. Ana María Gallo Sánchez M.S.I. René Arroyo Ávila
Catedráticos Revisores
M.A. César Pacheco M.A. Mercedes Ogaz Alamillo

3. AGRADECIMIENTOS
A dios por permitirme llegar a este punto en mi desarrollo profesional y académico.
Agradezco especialmente a las personas que colaboraron con este trabajo,
asesorándome, respondiendo mis preguntas, y contribuyendo con un poco de su
conocimiento para enriquecer el mío.
i

4. DEDICATORIA
Dedico este trabajo a aquellas personas que han colaborado con mi formación
académica y mi desarrollo profesional, ya que con este trabajo, obtengo un logro
muy importante en mi vida profesional y en mis aspiraciones personales.
ii

5. RESUMEN
Objetivo: Describir el uso de metodologías ágiles en una empresa de desarrollo de
software en Ciudad Juárez, Chihuahua.
Metodología: La investigación fue de carácter no experimental ya que no se
manipuló la variable. La población de interés fueron todos los equipos de desarrollo
que pertenecientes a la empresa de desarrollo de software. El marco muestral
comprendió 3 equipos de desarrollo de software de dicha empresa, conformados por
4 personas cada uno La unidad de análisis estuvo enfocada a aquellos equipos de
desarrollo de la empresa que lleven proyectos manejados (con gerencia). La variable
evaluada fue el uso de metodologías ágiles en el proceso de desarrollo de software.
Los indicadores fueron: Tiempo de Respuesta al cliente; Resultados de la revisión de
producto; Resultados de los métricos de calidad. El tipo de muestreo aplicado fue
total, toda la población. La recolección de los datos se llevó a cabo a través del
cuestionario, el cual se envió por correo electrónico a cada uno de los integrantes de
los equipos de desarrollo de software.
Resultados: Los principales resultados indican que el uso de una metodología ágil
para el desarrollo de software mejora los tiempos de entrega así como la
productividad, y ayuda a reducir costos en el proceso de desarrollo de software.
Palabras clave (Metodologías ágiles, desarrollo de software).
iii

6. ÍNDICE GENERAL
Página
Agradecimientos i
Dedicatoria ii
Resumen iii
Índice de Cuadros v
Índice de Gráficas vi
Índice de Figuras vii
Introducción 1
Antecedentes 2
Marco Teórico 4
Breve Introducción a las Metodologías de Desarrollo 4
El Manifiesto Ágil 6
Programación Extrema (XP) 11
Metodología Scrum 14
Otras Metodologías Ágiles 17
Metodologías Tradicionales 18
La metodología RUP 18
Codificar y corregir (Code-and-Fix) 20
Microsoft Solution Framework (MSF) 21
Modelo en cascada 22
Desarrollo evolutivo 24
Desarrollo incremental 26
Desarrollo en espiral 28
Cuando Usar Metodologías Ágiles 32
Ventajas de las Metodologías Ágiles 33
Problemas Comunes a los Métodos Ágiles 34
Justificación 36
Objetivo 37
Metodología 38
1.- Lugar y tiempo 38
2.- Carácter 38
3.- Diseño 38
4.- Población de interés 38
5.- Unidad de análisis 38
6.- Variable 38
7.- Indicadores 39
8.- Recolección de datos 39
9.- Análisis de la información 39
10.- Interpretación de resultados 39
Resultados y Discusión 40
Conclusiones y Recomendaciones 55
Literatura citada 56
Anexos 58
iv

7. ÍNDICE DE CUADROS
Cuadro
número
Título Página
1 Metodologías ágiles más conocidas para el desarrollo de
software 9
2 Diferencias entre metodologías tradicionales y ágiles 29
3 Diferencias por etapas y enfoque metodológico 31
v

8. ÍNDICE DE GRÁFICAS
Gráfica
número
Título Página
1 Nivel de Participación 41
2 Roles desempeñados por los encuestados 42
3 Nivel de conocimiento/participación 43
4 Tiempo de uso de Metodologías Ágiles 44
5 Tamaño del área de trabajo 45
6 Conocimientos sobre la empresa 46
7 Porcentaje de proyectos con metodologías ágiles 47
8 Tiempo de uso de Metodologías Ágiles por la empresa 48
9 Localidades que usan Metodologías Ágiles 49
10 Razones para adoptar Metodologías Ágiles 50
11 Metodologías Ágiles más conocidas 51
12 Barreras para adoptar las Metodologías Ágiles 52
13 Porcentaje de proyectos exitosos usando Metodologías Ágiles 53
14 Estimación de beneficios obtenidos 54
vi

9. ÍNDICE DE FIGURAS
Figura
número
Título Página
1 Metodología XP (eXtreme Programing) 11
2 Flujo de trabajo de la metodología XP 13
3 Ciclo de la metodología Scrum 16
4 Rational Unified Process (RUP) 19
5 Partes que componen la Metodología MSF 21
6 Iteraciones en el Modelo en Cascada 24
7 Descripción del Modelo de Desarrollo Evolutivo 25
8 Flujo General del Modelo de Desarrollo Iterativo Incremental 27
9 Flujo del Modelo de desarrollo en Espiral 29
vii

10. INTRODUCCIÓN
Actualmente existen dos enfoques para realizar el desarrollo de software dentro de la
industria de tecnologías de información, las metodologías tradicionales y las
metodologías ágiles para el desarrollo de software. En la empresa de desarrollo
de software en Ciudad Juárez se utilizan ambos enfoques en sus equipos de
trabajo y desarrollo de software.
Existen 3 equipos de desarrollo de software, dos de ellos hacen uso de una
metodología de software ágil, mientras que el tercer equipo utiliza una
metodología más rígida y estricta que requiere de autorizaciones adicionales,
revisiones tanto en diseño como en cambios realizados y tiene una estructura de
desarrollo que toma más tiempo llevar los cambios al usuario final.
La intención de esta investigación es describir el uso de metodologías ágiles para el
desarrollo de software dentro de dicha empresa y realizar una redacción
explicativa de los beneficios obtenidos con su uso. No se pretende modificar los
actuales métodos de trabajo ya que estos han demostrado tener gran eficacia
para la empresa.
1

11. ANTECEDENTES
La empresa de desarrollo de software de ciudad Juárez, Chihuahua con la que se
trabajó, es una empresa de Servicios de Tesorería y Seguridad de Valores (TSS
Treasury & Securities Services) genera más de $ 8 mil millones en ingresos anuales
y es un líder mundial en custodia, préstamo de valores, fondos y administración, así
como en servicios de tesorería. Servicios de Tesorería y de Valores apoya las
necesidades de los clientes institucionales en todo el mundo y es uno de los tres
principales proveedores en sus dos negocios: Servicios de Tesorería (TS Treasury
Services) y Servicios de Valores Mundiales (WSS Worldwide Securities Services).
En 2005, dicha empresa adquirió a otra, líder mundial en el comercio proveedor de
soluciones de gestión de ayudar a los clientes reducir el riesgo, mejorar el
cumplimiento y racionalizar el flujo de los envíos internacionales. Ahora conocido
como Global Trade Services, la entidad combinada se integra la información utilizada
para la gestión financiera y la actividad física la cadena de suministro.
La empresa, ayuda a los clientes a gestionar mejor su integridad física y financiera
con las cadenas de suministro de una completa gama integrada de soluciones de
comercio y logística. Como el único banco con el de extremo a extremo la capacidad
de la cadena de suministro, que agregan valor tanto al importador y exportador de
partes de las transacciones. Dicha empresa ayuda a facilitar la financiación, reducir
el riesgo comercial, gestión de relaciones de la cadena de suministro, mejorar el
cumplimiento y racionalizar los flujos comerciales.
La empresa proporciona el servicio administrado de las operaciones (GTS Global
Trade Services), garantizando la optimización de impuestos, garantizando las
operaciones en tiempo; para ello, esta área está conformada por diferentes
departamentos: dirección general, evaluación de proyectos, operación, soporte
usuario, análisis y diseño, desarrollo, calidad, centro de datos.
2

12. Como antecedente podemos mencionar que esta empresa está a la vanguardia en
operaciones aduaneras hoy en día a nivel internacional, contando con la ventaja
competitiva de brindar un sistema maduro y muy confiable, que le ha permitido
brindar servicios administrados a firmas fuertes en varios regímenes aduaneros
como son Deposito Fiscal, Maquiladora, Recinto Fiscalizado.
El área de servicios administrados en México cuenta aproximadamente con 110
personas para llevar la operación completa de las diferentes cuentas. Cada uno de
los miembros tiene actividades especificas que contribuyen en el cumplimiento de la
tarea final, que es llevar la operación al día del cliente, garantizando tiempo, fechas
de cumplimiento, recuperación de saldos a favor, monitoreo de vencimientos, etc.
La empresa de desarrollo de software en Ciudad Juárez tiene su centro de
desarrollo de software para México, cuenta con una amplia cartera de clientes que
hacen uso de sus productos.
La empresa ofrece 3 principales productos de software a sus clientes, estos son
Sistema de Trámite Aduanero (STA), Sistema Automatizado Aduanero Integral (SAAI
M3) y Deposito Fiscal (DF). Cuenta con 3 equipos de desarrollo en ciudad Juárez,
cada uno encabezado por un líder.
Actualmente la empresa hace uso de diferentes métodos de desarrollo, estos
dependen del equipo de desarrollo y el producto que desarrollan, siendo uno de los
equipos el que utiliza una metodología rígida para el desarrollo y dos equipos mas
hacen uso de métodos más ágiles y menos documentación.
3

13. MARCO TEÓRICO
Breve Introducción a las Metodologías de Desarrollo
Dentro del desarrollo de software y la altiva necesidad de que los proyectos lleguen
al éxito y obtener un producto de gran valor para nuestros clientes, generan grandes
cambios en las metodologías adaptadas por los equipos para cumplir sus objetivos,
puesto que, unas se adaptan mejor que otras, al contexto del proyecto brindando
mejores ventajas.
Es por eso de la importancia de una metodología robusta que ajustada en un equipo
cumpla con sus metas, y satisfaga mas allá de la las necesidades definidas al inicio
del proyecto.
El éxito del producto depende en gran parte de la metodología escogida por el
equipo, ya sea tradicional o ágil, donde los equipos maximicen su potencial y
aumenten la calidad del producto con los recursos y tiempo establecidos.
Muchos de los proyectos de software fracasan antes de entrar a la fase de
desarrollo, debido a una mala planeación o al exceso de ésta. El 71 % de todos los
proyectos de IT no se cumplen o experimentan problemas de fecha de entrega o
presupuesto (The Standish Group, 2001).
Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de
mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse
la concepción y fundamentos de metodologías existentes en otras áreas y adaptarlas
al desarrollo de software. Esta nueva etapa de adaptación contenía el desarrollo
dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente
en el campo del software.
4

14. Las metodologías tradicionales concentran su atención en llevar una documentación
exhaustiva de todo proyecto y centran su atención en cumplir en un plan de proyecto,
definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las
características importantes dentro de este enfoque tenemos los altos costos al
implementar y al no ofrecer una buena solución para proyectos donde el entorno es
volátil. Las metodologías tradicionales o formales se enfocan en documentación,
planificación y procesos (plantillas técnicas de administración, revisiones, etc.)
(Figueroa y Solís, 2008).
Las metodologías tradicionales presentan ciertos problemas tales como:
 Fases de obtención de requerimientos, análisis y diseño muy costosas en
cuanto a tiempo y recursos.
 Muchos niveles de aprobación, lo cual lleva comúnmente al retraso en las
fechas de entrega.
 Una vez que se llega a la fase de desarrollo es muy difícil para el equipo el
entender un sistema tan complejo al ser tan amplia el área que se abarca.
En el otro lado están las metodologías ágiles, las cuales se han incorporado muy
bien a un mundo de requerimientos cambiantes, y estas nos muestran ciertas
ventajas sobre los métodos tradicionales, tales como:
 Buena respuesta a los cambios durante la fase de desarrollo, lo cual es cada
vez más común en los proyectos.
 Entrega continua y rápida de secciones funcionales del sistema.
 Involucramiento del cliente.
 Eliminación del trabajo innecesario.
 Mayor atención a la parte técnica y de diseño.
 Mejora continua de los procesos y equipos de desarrollo (Highsmith, 2002).
5

15. Las metodologías ágiles presentan un nuevo enfoque que nace como respuesta a los
problemas de las metodologías tradicionales y se basa en aspectos puntuales, el
retrasar las decisiones y la planificación adaptativa; permitiendo potencia aún más en
el desarrollo de software a gran escala. El resultado es un Manifiesto Ágil cuyas
principales ideas son:
 Los individuos y las iteraciones entre ellos son más importantes que las
herramientas y los procesos empelados.
 Es más importante crear un producto de software que funcione que escribir
documentación exhaustiva.
 La colaboración con el cliente debe prevalecer sobre la negociación de
contratos.
 La capacidad de respuesta ante un cambio es más importante que el
seguimiento estricto de un plan (Pires, 2001).
El Manifiesto Ágil
En febrero 11 – 13 de 2001 en las montañas Wasatch en Utah, 17 personas se
reunieron para platicar, esquiar y relajarse. Lo que surgió de esa reunión fue la
Alianza de Desarrollo de Software Ágil, todos los miembros de la alianza firmaron el
llamado Manifiesto Ágil el cual tiene como texto: “Estamos poniendo al descubierto
nuevas y mejores maneras de desarrollar software, haciéndolo y ayudando a otros a
que lo hagan. A través de este trabajo hemos llegado a valorar: Los individuos y la
interacción sobre los procesos y herramientas; El software que funciona sobre la
documentación abarcadora; la colaboración con el cliente sobre negociación de
contratos; Responder al cambio sobre seguir un plan; Eso es, aunque hay valor en
las partes de la derecha, nosotros valoramos mas los de la izquierda”.
6

16. Principios del Manifiesto:
 La prioridad es satisfacer al cliente mediante tempranas y continuas entregas
de software que le aporte un valor.
 Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.
 Entregar frecuentemente software que funcione desde un par de semanas
hasta un par de meses, con el menor intervalo de tiempo posible entre
entregas.
 La gente del negocio y los desarrolladores deben de trabajar juntos a lo largo
del proyecto.
 Construir el proyecto en torno a individuos motivados. Darles el entorno el
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
 El dialogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
 El software que funciona es la medida principal de progreso.
 Los procesos ágiles promueven un desarrollo sostenible. Los promotores
desarrolladores y usuarios deberían ser capaces de mantener una paz
constante.
 La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
 La simplicidad es esencial.
 Las mejores arquitecturas, requisitos y diseños surgen de los equipos
organizados por sí mismos.
 En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más
efectivo y según esto ajusta su comportamiento (Abrahamsson y Ronkainen,
2002).
7

17. El movimiento ágil no es anti-metodológico menciona Fowler, se requiere restaurar
credibilidad en la palabra. También se requiere restaurar un balance: adoptar el
modelado, pero no precisamente para archivarlo en un polvoso repositorio
corporativo. Adoptar documentación, pero no para desperdiciar grandes cantidades
de papel en la creación de tomos que nunca sean mantenidos o raramente usados
(Fowler, 2001).
Los creadores de dicho Manifiesto son: Kent Beck (Extreme Programming), Mike
Beedle, Arie van Bennekum (Dynamics Solutions Delivery Model), Alistair Cockburn
(Cystal), Ward Cunningham (Extreme Programming), Martin Fowler (Extreme
Programming), James Grenning (Extreme Programming), Jim Highsmith (Agile
Spreadsheet Development), Andrew Hunt (Pragmatic Programming), Ron Jeffries
(Extreme Programming), Jon CERN (Feature Driven Development), Brian Marick,
Robert C. Martin (Extreme Programming), Steve Mellor, Ken Schwaber (Scrum), Jeff
Sutherland (Scrum), Dave Thomas (Pragmatic Programming).
En la comunidad de la ingeniería del software, se está viviendo con intensidad un
debate abierto entre los partidarios de las metodologías tradicionales y aquellos que
apoyan las ideas emanadas del Manifiesto Ágil.
Por un lado, para muchos equipos de desarrollo el uso de metodologías tradicionales
les resulta muy lejano a su forma de trabajo actual; considerando las dificultades de
su introducción e inversión asociada en términos de formación y compra de
herramientas. Por otro, las características de los proyectos para los cuales las
metodologías agiles han sido especialmente pensadas se ajustan a un amplio rango
de proyectos de desarrollo de software; aquellos en los cuales los equipos de
desarrollo son pequeños, con plazos reducidos, requisitos volátiles, basados en
nuevas tecnologías, etc. (Abrahamsson y Ronkainen, op cit).
8

18. Estas metodologías están especialmente orientadas para proyectos que necesitan de
una solución a la medida, con una elevada simplificación sin dejar de lado el
aseguramiento de la calidad del producto. Las metodologías giles se centran en el
factor humano y el producto software; es decir, ellas le dan mayor valor al individuo,
a la colaboración del cliente y al desarrollo incremental del software con iteraciones
muy cortas. En el cuadro 1 se muestran las metodologías ágiles más comunes.
Cuadro 1. Metodologías ágiles más conocidas para el desarrollo de software.
Metodología Creación Tipo de Modelo Característica
Adaptative Software
(ASD)
Highsmith 2000 Practicas + Ciclo de
vida
Inspirado en Sistemas
adaptativos complejos
Agile Modeling (AM) Ambler 2002 Metodología basada
en la práctica
Suministra modelado ágil a
otros métodos
Crystal Methods (CM) Cockburn 1998 Familia de
Metodologías
Énfasis en modelado de
ciclos
Agile RUP
(dX)
Booch, Martin,
Newkirk 1998
Framework
/ Disciplina
XP “al revés” con artefactos
de RUP
Dynamic Solutions
Delivery Model
(DSDM)
Stapleton 1997 Framework / Modelo
de ciclo de vida
Creado por 16 expertos en
RAD
Evolutionary Project
Management
(Evo)
Gilb 1976 Framework adaptativo Primer método ágil existente
Extreme
Programming
(Xp)
Beck 1999 Disciplina en prácticas
de Ingeniería
Método ágil radical
Feature-driven
development
(FDD)
De Luca & Coad 1998
Palmer & Felsing
2002
Metodología Método Ágil de diseño y
construcción
Lean Development
(LD)
Charette 2001,
Mary & Tom
Poppendieck
“Forma de Pensar” –
Modelo logístico
Metodología basada en
procesos productivos
Microsoft Solutions
Framework
(MSF)
Microsoft 1994 Lineamientos,
Disciplinas, prácticas
Framework de desarrollo de
soluciones
Rapid Development
(RAD)
McConnell 1996 Survey de técnicas y
modelos
Selección de mejores
prácticas, no métodos
Racional Unified
Process
(RUP)
Krutchen 1996 Proceso Unificado método (¿ágil?) con
modelado
Scrum Sutherland 1994 –
Schwaber 1995
Proceso (Software de
management)
Complemento de otros
método, ágiles o no
Fuente (Reynoso, 2005)
9

19. A diferencia de los enfoques más tradicionales, las metodologías ágiles se centran
en la generación de liberaciones en las primeras etapas de productos de trabajo
utilizando principalmente técnicas de colaboración, como por ejemplo, programación
par, refactorización y tener clientes trabajando en el lugar como parte del equipo de
miembros. Los programadores utilizan estas liberaciones que son productos de
trabajo, no prototipos para demostrar las características y funciones a los
contratantes que están relacionados con su utilización, comercialización y apoyo
(Cockburn, 2001).
En los proyectos de desarrollo de software más tradicionales, el ciclo de vida
(simplificado) es análisis, Desarrollo, Pruebas; primero obteniendo todos los
requerimientos conocidos para el producto completo, después desarrollando todos
los elementos de software, después probando que el producto completo está listo
para entregarse. En el desarrollo de software ágil, el ciclo es análisis, desarrollo,
pruebas, análisis, desarrollo, pruebas; y así sucesivamente… de manera que se
haga cada paso para cada característica, una característica a la vez. Las ventajas de
este proceso iterativo en el desarrollo de software son
 Reduce Riesgos: clarifica la visibilidad de que esta terminado en fecha a
través del proyecto.
 Incrementa el valor: entregando algunos beneficios tempranamente; siendo
capaz de liberar un producto, en lugar de esperar a que todas las
características estén listas.
 Más flexibilidad/agilidad: se puede elegir el cambiar de dirección o adaptarse a
las siguientes iteraciones basadas en el software que se está usando
actualmente.
 Mejor administración de costos (Waters, 2007).
10

20. A continuación se muestra una de las metodologías ágiles más comunes y sobre la
cual muchos autores han escrito una gran cantidad de artículos.
Programación Extrema (XP)
La Programación Extrema (XP) es una metodología ágil que ha ganado creciente
aceptación y reconocimiento en la comunidad del software. XP promueve una
disciplina de desarrollo de software basada en principios de simplicidad,
comunicación, realimentación y coraje. Está diseñada para el uso con equipos
pequeños que necesitan desarrollar software rápidamente en un ambiente de
continuos cambios de requerimientos.
La metodología XP utiliza prácticas efectivas como Refactoring, Programación en
Pares, e Integración Continua. Cada práctica proporciona una importante ventaja
para el ciclo de desarrollo. Por ejemplo, Refactoring proporciona un cambio gradual
del código fuente hacia un diseño más adaptable. La Programación en Pares permite
a dos programadores compartir sus pensamientos y conocimientos técnicos frente a
una pantalla en común. Finalmente, la Integración Continua asegura que exista
siempre un sistema corriendo en el que se ejecuten todas las pruebas con éxito
(Beck, 1999). La figura 1 muestra la descripción de la metodología XP.
Figura 1: Metodología XP (eXtreme Programing)
Fuente (Beck, op cit).
11

21. Características de la metodología XP, esta se basa en:
 Pruebas Unitarias: se basa en las pruebas realizadas a los principales
procesos, de tal manera que adelantándonos en algo hacia el futuro, podamos
hacer pruebas de las fallas que pudieran ocurrir. Es como si nos
adelantáramos a obtener los posibles errores.
 Re-fabricación: se basa en la reutilización de código, para lo cual se crean
patrones o modelos estándares, siendo más flexible al cambio.
 Programación en pares: una particularidad de esta metodología es que
propone la programación en pares, la cual consiste en que dos
desarrolladores participen en un proyecto en una misma estación de trabajo.
Cada miembro lleva a cabo la acción que el otro no está haciendo en ese
momento. Es como el chofer y el copiloto: mientras uno conduce, el otro
consulta el mapa.
La metodología XP propone algunas formas de trabajar:
 Empieza en pequeño y añade funcionalidad con retroalimentación continua
 El manejo del cambio se convierte en parte sustantiva del proceso
 El costo del cambio no depende de la fase o etapa
 No introduce funcionalidades antes que sean necesarias
 El cliente o el usuario se convierte en miembro del equipo
Derechos del cliente dentro de la metodología XP:
 Decidir que se implementa
 Saber el estado real y el progreso del proyecto
 Añadir, cambiar o quitar requerimientos en cualquier momento
 Obtener lo máximo de cada semana de trabajo
 Obtener un sistema funcionando cada tres o cuatro meses
12

22. Derechos del desarrollador en la metodología XP:
 Decidir cómo se implementan los procesos
 Crear el sistema con la mejor calidad posible
 Pedir al cliente en cualquier momento aclaraciones de los requerimientos
 Estimar el esfuerzo para implementar el sistema
 Cambiar los requerimientos en base a nuevos descubrimientos
Lo fundamental en este tipo de metodología es:
 La comunicación, entre los usuarios y los desarrolladores
 La simplicidad, al desarrollar y codificar los módulos del sistema
 La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y
los usuarios finales (Wells, 2003).
El funcionamiento de la metodología XP puede ser resumido por medio del esquema
descrito en la figura 2.
Figura 2: Flujo de trabajo de la metodología XP.
Fuente (Wells, op cit)
13
Plan de entregas
con Historias de Usuario
El cliente selecciona la
lista de historias para la
iteración/mini-entrega
Reunión de Planificación
de Entregas
Escribir código y pruebas de módulos
Refactorizar la iteración previa
Pruebas de
Aceptación
Entregas pequeñas al
cliente
¿Pruebas de
aceptación OK?
Mantenerse iterando para
pasar las pruebas de
aceptación:
• Pruebas de sistema (Bugs)
• Pruebas de módulos
• Pruebas de usuario
Aprobación del
cliente

23. Metodología Scrum
Esta es, después de la metodología XP, la metodología ágil mejor conocida y la que
otros métodos ágiles recomiendan como complemento, aunque su porción del
mercado (3% según el Cutter Consortium) es más modesta que el ruido que hace.
Scrum es una metodología para el desarrollo ágil de productos, expuesta, en el
artículo The New Product Development Game [Harvard Business Review Ene-Feb
1986 en el que ponen de manifiesto que:
 El mercado competitivo de los productos tecnológicos, además de los
conceptos básicos de calidad, coste y diferenciación, exige también rapidez y
flexibilidad.
 Los nuevos productos representan cada vez un porcentaje más importante en
el volumen de negocio de las empresas.
 El mercado exige ciclos de desarrollo más cortos (Takeuchi y Nonaka, 1986).
El método Scrum no está concebido como método independiente, sino que se
promueve como complemento de otras metodologías, incluyendo XP. Como método,
Scrum enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos,
implementación y demás cuestiones técnicas; de allí su deliberada insuficiencia y su
complementariedad. Scrum se define como un proceso de administración y control
que implementa técnicas de control de procesos; se lo puede considerar un conjunto
de patrones organizacionales.
Los valores de la metodología Scrum son:
 Equipos auto-dirigidos y auto-organizados. No hay gerente que decida, ni
otros títulos que “miembros del equipo” o “cerdos”; la excepción es el Scrum
Master que debe ser 50% programador y que resuelve problemas, pero no
manda. Los observadores externos se llaman “gallinas”; pueden observar,
pero no interferir ni opinar.
14

24.  Una vez elegida una tarea, no se agrega trabajo extra. En caso que se
agregue algo, se recomienda quitar alguna otra cosa.
 Encuentros diarios con las tres preguntas indicadas en la figura. Se realizan
siempre en el mismo lugar, en círculo. El encuentro diario impide caer en el
dilema señalado por Fred Brooks: “¿Cómo es que un proyecto puede
atrasarse un año?: Un día a la vez”.
 Iteraciones de treinta días; se admite que sean más frecuentes.
 Demostración a participantes externos al fin de cada iteración.
 Al principio de cada iteración, planeamiento adaptativo guiado por el cliente
(Schwaber y Beedle, 2001).
El nombre de los miembros del equipo y los externos se deriva de una típica fábula
agilista: un cerdo y una gallina discutían qué nombre ponerle a un nuevo restaurant;
la gallina propuso “Jamón y Huevos”. “No, gracias”, respondió el cerdo, “Yo estaré
comprometido, pero tú sólo involucrada”.
La metodología Scrum define seis roles:
1. El Scrum Master: Interactúa con el cliente y el equipo. Es responsable de
asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas,
valores y reglas de Scrum y que progrese según lo previsto. Coordina los
encuentros diarios, formula las tres preguntas canónicas y se encarga de
eliminar eventuales obstáculos. Debe ser miembro del equipo y trabajar a la
par.
2. Propietario del Proyecto: Es el responsable oficial del proyecto, gestión,
control y visibilidad de la lista de acumulación o lista de retraso del producto
(product backlog). Es elegido por el Scrum Master, el cliente y los ejecutivos a
cargo. Toma las decisiones finales de las tareas asignadas al registro y
convierte sus elementos en rasgos a desarrollar.
3. Equipo de Scrum: Tiene autoridad para reorganizarse y definir las acciones
necesarias o sugerir remoción de impedimentos.
4. Cliente: Participa en las tareas relacionadas con los elementos del registro.
15

25. 5. Administración: Está a cargo de las decisiones fundamentales y participa en la
definición de los objetivos y requerimientos. Por ejemplo, selecciona al Dueño
del Producto, evalúa el progreso y reduce el registro de acumulación junto con
el Scrum Master.
6. Usuario: La dimensión del equipo total de Scrum no debería ser superior a
diez ingenieros. El número ideal es siete, más o menos dos, una cifra
canónica en ciencia cognitiva [Mil56]. Si hay más, lo más recomendable es
formar varios equipos. No hay una técnica oficial para coordinar equipos
múltiples, pero se han documentado experiencias de hasta 800 miembros,
divididos en Scrums de Scrum, definiendo un equipo central que se encarga
de la coordinación, las pruebas cruzadas y la rotación de los miembros
(Schwaber y Beedle, op cit).
La figura 3 describe el ciclo de la metodología Scrum:
Figura 3: Ciclo de la metodología Scrum
16
Creación
del
Concepto
Prueba de
Aceptación
Diseño Código Prueba de
Unidad
Prueba de
Integración
Prueba del
Sistema
Especific.
Requerim.
Pre-Juego
Juego
Post-Juego
Planteamiento
Lista de
retraso
de
product
o
Lista de
retraso
de
Srpint
Diseño de Alto
Nivel/Arquitectura
Sprint
Análisis &
Diseño
Codificación Prueba Entrega
Release
Intermedi
o
Integración,
prueba de
sistema
Producto
final,
documentos

26. Fuente (Schwaber y Beedle, op cit).
Otras Metodologías Ágiles
Aunque los creadores e impulsores de las metodologías ágiles más populares han
suscrito el manifiesto ágil y coinciden con los principios enunciados anteriormente,
cada metodología tiene características propias y hace hincapié en algunos aspectos
más específicos. A continuación se resumen otras metodologías ágiles. La mayoría
de ellas ya estaban siendo utilizadas con éxito en proyectos reales pero les faltaba
una mayor difusión y reconocimiento.
 Crystal Methodologies: Se trata de un conjunto de metodologías para el
desarrollo de software caracterizadas por estar centradas en las personas que
componen el equipo y la reducción al máximo del número de artefactos
producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de
software se considera un juego cooperativo de invención y comunicación,
limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave,
por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas,
así como tener políticas de trabajo en equipo definidas. Estas políticas
dependerán del tamaño del equipo, estableciéndose una clasificación por
colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50
miembros) (Cockbun, 2001).
 Dynamic Systems Development Method (DSDM): Define el marco para
desarrollar un proceso de producción de software. Nace en 1994 con el
objetivo de crear una metodología RAD unificada. Sus principales
características son: es un proceso iterativo e incremental y el equipo de
desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad,
estudio del negocio, modelado funcional, diseño y construcción, y finalmente
implementación. Las tres últimas son iterativas, además de existir
realimentación a todas las fases (Fowler, 2001).
 Adaptive Software Development (ASD): Su impulsor es Jim Highsmith. Sus
principales características son: iterativo, orientado a los componentes
17

27. software más que a las tareas y tolerante a los cambios. El ciclo de vida que
propone tiene tres fases esenciales: especulación, colaboración y aprendizaje.
En la primera de ellas se inicia el proyecto y se planifican las características
del software; en la segunda desarrollan las características y finalmente en la
tercera se revisa su calidad, y se entrega al cliente. La revisión de los
componentes sirve para aprender de los errores y volver a iniciar el ciclo de
desarrollo (Highsmith y Orr, 2000).
 Feature -Driven Development (FDD): Define un proceso iterativo que consta
de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las
fases de diseño e implementación del sistema partiendo de una lista de
características que debe reunir el software. Sus impulsores son Jeff De Luca y
Peter Coad (Fowler y Beck, 1999)
 Lean Development (LD): Definida por Bob Charettes a partir de su experiencia
en proyectos con la industria japonesa del automóvil en los años 80 y utilizada
en numerosos proyectos de telecomunicaciones en Europa. En LD, los
cambios se consideran riesgos, pero si se manejan adecuadamente se
pueden convertir en oportunidades que mejoren la productividad del cliente.
Su principal característica es introducir un mecanismo para implementar
dichos cambios (Poppendieck, 2003).
Metodologías Tradicionales
Las metodologías tradicionales (formales) se focalizan en documentación,
planificación y procesos. (Plantillas, técnicas de administración, revisiones, etc.), a
continuación se detalla RUP uno de los métodos más usados dentro de los métodos
tradicionales.
La metodología RUP es un proceso formal, Provee un acercamiento disciplinado
para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su
objetivo es asegurar la producción de software de alta calidad que satisfaga los
requerimientos de los usuarios finales (respetando cronograma y presupuesto). Fue
desarrollado por Rational Software, y está integrado con toda la suite Rational de
18

28. herramientas. Puede ser adaptado y extendido para satisfacer las necesidades de la
organización que lo adopte. (Customización). Es guiado por casos de uso y centrado
en la arquitectura, y utiliza UML como lenguaje de notación (Figueroa y Solís, op
cit). En la figura 4 podemos ver las fases de la metodología RUP:
Figura 4: Rational Unified Process (RUP).
Fuente (Figueroa y Solís, op cit).
Fases: Las cuatro fases del ciclo de vida de la metodología RUP son:
 Concepción
 Elaboración
 Construcción
 Transición
Ventajas de la metodología RUP:
 Evaluación en cada fase que permite cambios de objetivos
 Funciona bien en proyectos de innovación.
 Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de
desarrollar el software.
 Seguimiento detallado en cada una de las fases.
19

29. Desventajas de la metodología RUP:
 La evaluación de riesgos es compleja
 Excesiva flexibilidad para algunos proyectos
 Estamos poniendo a nuestro cliente en una situación que puede ser muy
incómoda para él.
 Nuestro cliente deberá ser capaz de describir y entender a un gran nivel de
detalle para poder acordar un alcance del proyecto con él (Figueroa y Solís,
op cit).
Codificar y corregir (Code-and-Fix)
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene
dos pasos:
 Escribir código.
 Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos,
diseño, validación, y mantenimiento.
Este modelo tiene tres problemas principales:
 Después de un número de correcciones, el código puede tener una muy mala
estructura, hace que los arreglos sean muy costosos.
 Frecuentemente, aún el software bien diseñado, no se ajusta a las
necesidades del usuario, por lo que es rechazado o su reconstrucción es muy
cara.
 El código es difícil de reparar por su pobre preparación para probar y modificar
(Boehm, 2002).
20

30. Microsoft Solution Framework (MSF)
Esta es una metodología flexible e interrelacionada con una serie de conceptos,
modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión
de proyectos tecnológicos.
MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano
las elecciones tecnológicas, como se muestra en la figura 5.
Figura 5: Partes que componen la Metodología MSF.
Fuente (Microsoft, 2004)
MSF tiene las siguientes características:
 Adaptable: es parecido a un compás, usado en cualquier parte como un mapa,
del cual su uso es limitado a un específico lugar.
 Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así
como también, proyectos que requieren 50 personas a más.
21

31.  Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
 Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones
basadas sobre cualquier tecnología.
MSF se compone de varios modelos encargados de planificar las diferentes partes
implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,
Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de
Diseño de Proceso y finalmente el modelo de Aplicación (Microsoft, op cit)
Modelo en cascada
El primer modelo de desarrollo de software que se publicó se derivó de otros
procesos de ingeniería. Éste toma las actividades fundamentales del proceso de
especificación, desarrollo, validación y evolución y las representa como fases
separadas del proceso.
El modelo en cascada consta de las siguientes fases:
 Definición de los requisitos: Los servicios, restricciones y objetivos son
establecidos con los usuarios del sistema. Se busca hacer esta definición en
detalle.
 Diseño de software: Se particiona el sistema en sistemas de software o
hardware. Se establece la arquitectura total del sistema. Se identifican y
describen las abstracciones y relaciones de los componentes del sistema.
 Implementación y pruebas unitarias: Construcción de los módulos y unidades
de software. Se realizan pruebas de cada unidad.
 Integración y pruebas del sistema: Se integran todas las unidades. Se prueban
en conjunto. Se entrega el conjunto probado al cliente.
 Operación y mantenimiento: Generalmente es la fase más larga. El sistema es
puesto en marcha y se realiza la corrección de errores descubiertos. Se
realizan mejoras de implementación. Se identifican nuevos requisitos
 Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte
de un sistema mayor el trabajo comienza estableciendo los requisitos de todos
22

32. los elementos del sistema y luego asignando algún subconjunto de estos
requisitos al software.
 Análisis de los requisitos del software: el proceso de recopilación de los
requisitos se centra e intensifica especialmente en el software. El ingeniero de
software (Analistas) debe comprender el ámbito de la información del
software, así como la función, el rendimiento y las interfaces requeridas.
 Diseño: el diseño del software se enfoca en cuatro atributos distintos del
programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño traduce
los requisitos en una representación del software con la calidad requerida
antes de que comience la codificación.
 Codificación: el diseño debe traducirse en una forma legible para la maquina.
El paso de codificación realiza esta tarea. Si el diseño se realiza de una
manera detallada la codificación puede realizarse mecánicamente.
 Prueba: una vez que se ha generado el código comienza la prueba del
programa. La prueba se centra en la lógica interna del software, y en las
funciones externas, realizando pruebas que aseguren que la entrada definida
produce los resultados que realmente se requieren.
 Mantenimiento: el software sufrirá cambios después de que se entrega al
cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que
el software deba adaptarse a cambios del entorno externo (sistema operativo
o dispositivos periféricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento (Pressman, 1997).
Cada fase tiene como resultado documentos que deben ser aprobados por el
usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se
incluye la corrección de los problemas encontrados en fases previas.
En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción
entre las distintas fases de desarrollo. Algunos problemas que se observan en el
modelo de cascada son:
23

33.  Las iteraciones son costosas e implican rehacer trabajo debido a la producción
y aprobación de documentos.
 Aunque son pocas iteraciones, es normal congelar parte del desarrollo y
continuar con las siguientes fases.
 Los problemas se dejan para su posterior resolución, lo que lleva a que estos
sean ignorados o corregidos de una forma poco elegante.
 Existe una alta probabilidad de que el software no cumpla con los requisitos
del usuario por el largo tiempo de entrega del producto.
 Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es
difícil responder a cambios en los requisitos.
La interacción entre fases del Modelo en Cascada puede observarse en la figura 6.
Figura 6: Iteraciones en el Modelo en Cascada
Fuente (Bennington, 1956).
Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza
como parte de proyectos grandes.
Desarrollo evolutivo
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
24

34. La idea detrás de este modelo es el desarrollo de una implantación del sistema
inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se
desarrolle el sistema adecuado.
Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario,
ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada
iteración.
En la figura 7 se observa cómo las actividades concurrentes: especificación,
desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar
al producto final.
Figura 7: Descripción del Modelo de Desarrollo Evolutivo
Fuente (Pressman, op cit)
Existen dos tipos de desarrollo evolutivo:
 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario
los requisitos hasta llegar a un sistema final. El desarrollo comienza con las
partes que se tiene más claras. El sistema evoluciona conforme se añaden
nuevas características propuestas por el usuario.
25
Bosquejo de la
Descripción.
Actividades
Concurrentes
Especificación
Desarrollo
Validación
Versión
Inicial
Versiones
Intermedias
Versión
Final

35.  Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario
y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no están claros para el
usuario y se utiliza un prototipo para experimentar con ellos. El prototipo
ayuda a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo están:
 La especificación puede desarrollarse de forma creciente.
 Los usuarios y desarrolladores logran un mejor entendimiento del sistema.
Esto se refleja en una mejora de la calidad del software.
 Es más efectivo que el modelo de cascada, ya que cumple con las
necesidades inmediatas del cliente.
Desde una perspectiva de ingeniería y administración se identifican los siguientes
problemas:
 Proceso no Visible: Los administradores necesitan entregas para medir el
progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir
documentos que reflejen cada versión del sistema.
 Sistemas pobremente estructurados: Los cambios continuos pueden ser
perjudiciales para la estructura del software haciendo costoso el
mantenimiento.
 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan
herramientas que pueden ser incompatibles con otras o que poca gente sabe
utilizar (Pressman, op cit).
Desarrollo incremental
Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la
repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la
toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Es
una combinación del Modelo de Cascada y Modelo Evolutivo.
26

36. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para
retrasar las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o
evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a
implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es
dudoso, evolutivo (Mills y O´Neill, 1980).
En la figura 8 podemos observar el flujo general del Modelo de Desarrollo Iterativo
Incremental.
Figura 8: Flujo General del Modelo de Desarrollo Iterativo Incremental
Fuente (Mills y O´Neill, op cit).
Entre las ventajas del modelo incremental se encuentran:
 Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema.
Pueden empezar a usarlo desde el primer incremento.
 Los clientes pueden aclarar los requisitos que no tengan claros conforme ven
las entregas del sistema.
 Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede
distribuir en cada incremento.
 Las partes más importantes del sistema son entregadas primero, por lo cual
se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
27
Definición del bosquejo
de requisitos
Asignar requisitos a los
elementos
Diseñar la arquitectura
del sistema
Validar
incrementos
Integrar
incrementos
Desarrollar incrementos
del sistema
Validar
sistema
Sistema completo
Sistema
Final

37.  Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000
líneas).
 Cada incremento debe aumentar la funcionalidad.
 Es difícil establecer las correspondencias de los requisitos contra los
incrementos.
 Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Desarrollo en espiral
El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue
propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar
de una serie de actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones
del proceso y del producto. Se realiza un diseño detallado del plan
administrativo. Se identifican los riesgos y se elaboran estrategias alternativas
dependiendo de estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada
riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de
requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la
evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales,
evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente
fase del proyecto.
Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo,
esta es una actividad importante en la administración del proyecto.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones
se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos
28

38. contra las alternativas. Se evalúan los riesgos con actividades como análisis
detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica
la siguiente fase (Boehm, 1988).
La figura 9 muestra el flujo del Modelo de Desarrollo en Espiral:
Figura 9: Flujo del Modelo de desarrollo en Espiral
Fuente (Boehm, op cit).
Cuadro 2: Diferencias entre metodologías tradicionales y ágiles:
Metodologías Tradicionales Metodologías Ágiles
Basados en normas provenientes de
estándares seguidos por el entorno de
desarrollo. Cierta resistencia a los cambios
Basada en heurísticas provenientes de
prácticas de producción de código.
Especialmente preparadas para cambios
durante el proyecto.
Impuestas externamente. Proceso mucho Impuestas internamente (por el propio
29

39. más controlado, con numerosas
políticas/normas.
equipo). Proceso menos controlado, con
pocos principios.
El cliente interactúa con el equipo de
desarrollo mediante reuniones. Más
artefactos.
El cliente es parte del equipo de desarrollo.
Pocos artefactos.
Más roles. Grupos grandes y posiblemente
distribuidos.
Pocos roles. Grupos pequeños (<10
integrantes) y trabajando en el mismo sitio.
La arquitectura del software esencial y se
expresa mediante modelos. Existe un
contrato prefijado.
Menos énfasis en la arquitectura del
software. No existe contrato tradicional o es
bastante flexible.
Fuente (Boehm, op cit).
De acuerdo con el cuadro 2 se puede observar que las metodologías de desarrollo
ágiles son más orientadas a procesos de desarrollo de software de pocas semanas
de desarrollo y con bajos niveles de formalización requeridos. A continuación se
describen con mayor nivel de especificación las principales semejanzas y diferencias
de las metodologías ágiles y las tradicionales:
 Prácticas de desarrollo: En las metodologías de desarrollo ágil se procura
realizar los procesos de software de acuerdo a las prácticas que le han dado
resultados al grupo. En las tradicionales se desarrolla de acuerdo a las
normas sugeridas por los estándares de desarrollo.
 Adaptación al cambio: En las metodologías ágiles por la misma capacidad de
reacción son más adaptables a los cambios por el contrario las tradicionales
por el nivel de formalidad en la fase de requerimientos son más resistentes al
cambio.
 Control: Por su capacidad de adaptación el proceso se hace menos controlado
que en las metodologías tradicionales que ejercen mayor control en el proceso
por su nivel de formalización.
 Documentación: En las metodologías ágiles no se hace énfasis en la
documentación ni en los artefactos a diferencia de las metodologías
tradicionales.
 Equipo de trabajo: En las metodologías ágiles existen bajo número de
participantes y roles, por el contrario las metodologías tradicionales sugieren
los roles que proporcionan las normas.
30

40. En el cuadro 3 se hace una comparativa entre cada una de las etapas más comunes
en el desarrollo de software y los enfoques que hay entre las metodologías
tradicionales y ágiles.
Cuadro 3: Diferencias por etapas y enfoque metodológico:
Modelos Rigurosos Etapa Modelos Ágiles
Planificación predictiva y
“aislada”
Análisis de requerimientos
Planificación
Planificación adaptativa:
entregas frecuentes +
colaboración del cliente
Diseño flexible y extensible +
modelos + documentación
exhaustiva
Desarrollo individual con
roles y responsabilidades
estrictas
Diseño
Codificación
Diseño simple: documentación
mínima + focalizado en la
comunicación
Transferencia de
conocimiento: programación
en pares + conocimiento
colectivo
Actividades de control:
orientado a los hitos +
gestión miniproyectos
Pruebas
Puesta en producción
Liderazgo-colaboración:
empoderamiento + auto-
organización
Fuente (Boehm, op cit).
Las metodologías tradicionales no se adaptan a las nuevas necesidades o
expectativas que tienen los usuarios hoy en día, en parte que los métodos usados no
son flexibles ante la posibilidad de la exigencia de nuevos requerimientos. Estos
cambios generalmente implican altos costos, demanda de tiempo y la
reestructuración total del proyecto que se esté llevando; en contraparte, los métodos
ágiles permiten un desarrollo iterativo y adaptable que permite la integración de
nuevas funcionalidades a lo largo del desarrollo del proyecto; para que tanto el
cliente como el desarrollador queden satisfechos porque el producto final tiene una
calidad adecuada.
Un proceso es ágil cuando el desarrollo de software es:
31

41.  Incremental. Entregas pequeñas de software, con ciclos rápidos.
 Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con
una cercana comunicación.
 Sencillo. El método en sí mismo es simple, fácil de aprender y modificar.
 Está bien documentado y es adaptable. Permite realizar cambios de último
momento).
Sus elementos claves son:
 Poca documentación
 Simplicidad
 Análisis como una actividad constante
 Diseño evolutivo
 Integraciones
 Pruebas diarias (Canós, Letelier, 2006).
Cuando Usar Metodologías Ágiles
No existe una metodología universal para hacer frente con éxito a cualquier proyecto
de desarrollo de software. Toda metodología debe ser adaptada al contexto del
proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema).
Históricamente, las metodologías tradicionales han intentado abordar la mayor
cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable
para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy
cambiantes.
Las metodologías ágiles ofrecen una solución casi adecuada para una gran cantidad
de proyectos. Sin embargo existen métodos más generales y con mejores resultados
que otros. Saber qué reglas y metodologías aplicar en cada caso es más importante
y útil que seguir ciegamente siempre las mismas.
32

42. Las propias prácticas de los métodos ágiles limitan o descartan su uso en algunos
proyectos. A continuación se detallan algunos casos donde no conviene usar
métodos ágiles.
 Aplicaciones distribuidas. Las pruebas unitarias son complicadas de aplicar
entre componentes. Sería necesario construir una arquitectura de pruebas
para probar directamente los componentes, que podría ser tan complicada
como el sistema que se desea construir.
 Aplicaciones que requieren seguir un diseño estricto. Por ejemplo: sistemas
operativos, software de telecomunicaciones.
 Aplicaciones que requieren una documentación exhaustiva. Por ejemplo:
sistemas militares, médicos o industriales.
 Aplicaciones basadas fundamentalmente en interfaces gráficas de usuario: No
es fácil aplicar pruebas unitarias a las interfaces gráficas.
 Aplicaciones con código heredado. Habría que reescribir todo el código
heredado siguiendo los principios ágiles.
 Proyectos muy grandes. La comunicación entre los miembros del equipo es
difícil de conseguir.
 Aplicaciones donde la escalabilidad o la eficacia sean importantes. La
escalabilidad o la eficacia no son características que se pueden añadir durante
el proceso del desarrollo del software o que puedan obtenerse refactorizando:
deben considerarse desde un principio (Canós, Letelier, op cit).
Ventajas de las Metodologías Ágiles
Las metodologías ágiles presentan diversas ventajas como:
 Rápida respuesta a cambios de requisitos a lo largo del desarrollo.
 Entrega continua y en plazos cortos de software funcional.
 Trabajo conjunto entre el cliente y el equipo de desarrollo.
 Minimiza los costos frente a cambios.
 Importancia de la simplicidad, al eliminar el trabajo innecesario.
 Atención continua a la excelencia técnica y al buen diseño.
33

43.  Mejora continua de los procesos y el equipo de desarrollo.
 Evita malentendidos de requerimientos entre el cliente y el equipo.
 El equipo de desarrollo no malgasta el tiempo y dinero del cliente
desarrollando soluciones innecesariamente generales y complejas que en
realidad no son un requisito del cliente.
 Cada componente del producto final ha sido probado y satisface los
requerimientos (Canós, Letelier, op cit).
Problemas Comunes de las Metodologías Ágiles
Como en cualquiera otra metodología, también hay desventajas y problemas que
surgen a la hora de implementarlas:
 Falta de documentación del diseño. El código no puede tomarse como una
documentación. En sistemas de tamaño grande se necesitar leer los cientos o
miles de páginas del listado de código fuente.
 Problemas derivados de la comunicación oral. Este tipo de comunicación
resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas
ambigüedades.
 Falta de calidad. Probar el código de forma constante no genera productos de
calidad, sólo revela falta de análisis y diseño.
 Fuerte dependencia de las personas. Como se evita en lo posible la
documentación y los diseños convencionales, los proyectos ágiles dependen
críticamente de las personas.
 Falta de procesos de revisión del código. Con métodos como el PSP o TSP se
han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La
programación en parejas tiene resultados del 20 al 40%, que no es mucho
frente al 10 y el 25% de un programador.
 Falta de reusabilidad. La falta de documentación hacen difícil que se pueda
reutilizar el código ágil.
34

44.  Sobre costos y retrasos derivados de la refactorización continua. Para un
sistema de ciertas proporciones, los costos y retrasos derivados de la
refactorización no pueden despreciarse.
 Restricciones en cuanto a tamaño de los proyectos abordables.
 Rigidez. Algunos métodos ágiles son muy rígidos: deben cumplirse muchas
reglas de una forma estricta para garantizar el éxito del proyecto. Por ejemplo
XP exige en realidad mucho esfuerzo, concentración y orden.
 Cambios. Los modelos de datos son “pesados” y no pueden cambiarse así
como así solo porque el cliente que ira a incorporar más funciones al sistema.
 Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil
fracasa no hay documentación o hay muy poca; lo mismo ocurre con el
diseño. La comprensión del sistema se queda en las mentes de los
desarrolladores (Canós, Letelier, op cit).
35

45. JUSTIFICACIÓN
La metodología que actualmente usa la empresa le ha dado buenos resultados, pero
se usa de manera muy estricta a todos los proyectos. Aunque hay algunos grupos
que ya han adoptado practicas de metodologías ágiles, además, requiere de un gran
número de formatos y documentos que deben ser llenados, documentados y
aprobados por muchos niveles, esto ha hecho que en algunos proyectos la respuesta
al cambio sea lenta, y requiera de bastante tiempo para que un cambio pueda ser
aprobado. También, es cada vez más común un atraso significativo en las fases de
desarrollo.
Las metodologías ágiles proponen una solución ligera al problema del exceso de
pasos para llevar a cabo una tarea, aunque se ha denominado que es aplicable por
lo regular para equipos pequeños, esta se puede llevar a la práctica sin problema en
desarrollo de sistemas grandes
36

46. OBJETIVO
Describir el uso de metodologías ágiles en una empresa de desarrollo de software en
Ciudad Juárez, Chihuahua.
37

47. METODOLOGÍA
1. Lugar y Tiempo
El trabajo se llevó a cabo entre los meses de enero y abril de 2009 en una
empresa de desarrollo de software de Ciudad Juárez.
2. Carácter
La investigación fue de carácter no experimental ya que no se manipuló la
variable.
3. Diseño
El diseño de la investigación fue de tipo transeccional descriptivo, ya que la
recolección de los datos se realizó en un momento único en el tiempo y se incluyó
una sola variable.
4. Población de Interés
Todos los equipos de desarrollo que pertenezcan a la empresa de desarrollo de
software en Ciudad Juárez.
5. Unidad de análisis.
La unidad de análisis estuvo orientada hacia aquellos equipos de desarrollo de la
empresa que sean proyectos manejados (con gerencia) y estén usando métricas
en sus entregas.
6. Variable
La variable que se midió en el proceso fue el uso de metodologías ágiles en el
proceso de desarrollo de software.
38

48. 7. Indicadores
Variable: Uso de las metodologías ágiles.
Indicadores: Tiempo de Respuesta al cliente; Resultados de la revisión de
producto; Resultados de los métricas de calidad.
8. Recolección de datos
El instrumento que se utilizo para la recolección de datos fue un cuestionario que
se realizó al gerente del área de desarrollo de software relacionada, así como al
personal de cada uno de los equipos de desarrollo. Dicho cuestionario se agrega
como anexo 1.
9. Análisis de la información
La información obtenida en la entrevista se comparo con la obtenida en
cuestionarios y de esta manera se determinó el uso de la metodología ágil
dentro de la empresa. La información se presenta en forma de gráficas y
diagramas de proceso los cuales proporciono la empresa para mejor
comprensión de los procesos que llevan a cabo los empleados que desarrollan
software.
10. Interpretación de resultados
Se realizó una redacción explicativa de cómo se lleva a cabo el proceso de
desarrollo de software. Se presentaron graficas y diagramas de proceso que
muestran los porcentajes de uso de las metodologías ágiles dentro de la
empresa, el conocimiento que los empleados tienen al respecto y también los
procesos que el personal lleva a cabo durante el desarrollo de software.
39

49. RESULTADOS
Se realizó un cuestionario al personal de la empresa de desarrollo de software en
Ciudad Juárez, el cual está dividido en tres secciones, que son, preguntas sobre los
participantes, preguntas sobre la organización y preguntas sobre la transición e
implementación de las metodologías ágiles. Las primeras 4 gráficas del cuestionario
son acerca del acercamiento que los encuestados han tenido hacia las metodologías
ágiles, las gráficas 5, 6, 7, 8 y 9 son acerca de la organización donde labora el
personal encuestado, y las últimas 5 (10, 11, 12 ,13 y 14) son acerca de la transición
e implementación de las metodologías ágiles en la organización.
En las primeras 4 gráficas podemos ver que el personal ha participado muy poco en
este tipo de encuestas, han usado muy poco las metodologías ágiles aun cuando la
mayoría de los encuestados son desarrolladores de software.
En las gráficas 5, 6, 7, 8 y 9 podemos ver que el personal labora en grupos de
tamaño medio, considerando un máximo 20 personas, el personal tiene poco
conocimiento acerca de quienes usan metodologías ágiles dentro de la empresa, así
mismo de la cantidad de proyectos que se están usando bajo el esquema de
metodologías ágiles. La mayor parte del personal desconoce por cuanto tiempo han
usado metodologías ágiles en esta empresa, además no tienen la certeza de cuantas
localidades de la empresa utilizan metodologías ágiles.
En las últimas 5 gráficas (10, 11, 12, 13 y 14) podemos ver que el personal desea el
cambio a las metodologías ágiles entre otras cosas para mejorar, calidad,
productividad y el proceso de mantenimiento del software. Las principales barreras
que el personal ve para la implementación de una metodología ágil son la falta de
experiencia y la cultura organizacional. A pesar de este desconocimiento el personal
piensa que un alto porcentaje de proyectos usando estas metodologías es exitoso y
ha ayudado a reducir los defectos en el desarrollo de software y al incremento de la
productividad
40

50. Nivel de participación: en esta gráfica podemos ver el nivel de participación en
encuestas anteriores del personal de la empresa de desarrollo de software de Ciudad
Juárez acerca del desarrollo de software usando metodologías ágiles.
Gráfica 1: Nivel de participación
41

51. En este cuadro podemos ver los roles que desempeña el personal encuestado en la
empresa de desarrollo de software de Ciudad Juárez. Esta pregunta no se
representa con gráfica de pastel ya que los encuestados podían contestar más de
una opción (o todas si así aplicaba su caso) por lo que se representa con una gráfica
en barras y porcentajes.
Gráfica 2: Roles desempeñados por los encuestados
42

52. Nivel de conocimiento/participación del personal encuestado de la empresa de
desarrollo de software de Ciudad Juárez sobre metodologías ágiles.
Gráfica 3: Nivel de Conocimiento/Participación
43

53. Tiempo que el personal de la empresa de desarrollo de software de Ciudad Juárez
ha usado las metodologías ágiles sin importar si ha sido por razones laborales o
personales.
Gráfica 4: Tiempo de uso de Metodologías Ágiles
44

54. Tamaño del área o grupo donde el personal encuestado labora.
Gráfica 5: Tamaño del área de trabajo
45

55. Conocimiento sobre la distribución del personal que usa metodologías ágiles en la
empresa de desarrollo de software de Ciudad Juárez.
Gráfica 6: Conocimientos sobre la empresa
46

56. Porcentaje de proyectos que se desarrollan en la empresa de desarrollo de software
de Ciudad Juárez usando metodologías de desarrollo ágiles.
Gráfica 7: Porcentaje de proyectos con metodologías ágiles
47

57. Tiempo durante el cual la empresa de desarrollo de software de Ciudad Juárez ha
estado haciendo uso de metodologías ágiles para el desarrollo de software.
Gráfica 8: Tiempo de uso de Metodologías Ágiles por la empresa
48

58. Número de localidades de la compañía que están haciendo uso de las metodologías
ágiles para el desarrollo de software.
Gráfica 9: Localidades que usan Metodologías Ágiles
49

59. Principales razones para adoptar el uso de metodologías ágiles para el desarrollo de
software en la empresa de desarrollo de software de Ciudad Juárez. Esta pregunta
se representa en grafica de barras y porcentajes ya que el personal encuestado
podía responder más de una opción (o todas si aplicaba el caso).
Gráfica 10: Razones para adoptar Metodologías Ágiles
50

60. Metodologías ágiles para el desarrollo de software que más conoce el personal
encuestado en la empresa de desarrollo de software de Ciudad Juárez.
Gráfica 11: Metodologías Ágiles más conocidas
51

61. Barreras/obstáculos que enfrenta el personal de la empresa de desarrollo de
software de Ciudad Juárez para adoptar en un futuro las metodologías ágiles para el
desarrollo de software. Esta pregunta no se representa con una grafica de pastel ya
que el personal encuestado podía responder más de una opción (o todas si aplicaba
en su caso) por lo que se representa con barras y porcentajes.
Gráfica 12: Barreras para adoptar las Metodologías Ágiles
52

62. Porcentaje de proyectos que el personal encuestado considera que han sido exitosos
usando metodologías ágiles en la empresa de desarrollo de software de Ciudad
Juárez.
Gráfica 13: Porcentaje de proyectos exitosos usando Metodologías Ágiles
53

63. Estimación en porcentaje sobre cuáles son los beneficios que se han obtenido en la
organización con el uso de metodologías ágiles en la empresa de desarrollo de
software de Ciudad Juárez. En este recuadro se toman en cuenta los porcentajes de
aquellos encuestados que respondieron esta pregunta, los que no respondieron
fueron excluidos.
Gráfica 14: Estimación de beneficios obtenidos
Beneficio Porcentaje estimado
Incremento en productividad 42%
Mejora en tiempos de entrega 36%
Reducción de defectos en el software 52%
Reducción de costos 28%
54

64. CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
El uso de una metodología ágil permite a la empresa de desarrollo de software de
Ciudad Juárez desarrollar software de manera más rápida y segura, y a la vez
reducir el costo de desarrollo.
Existe el conocimiento básico sobre metodologías ágiles de desarrollo de software
aún cuando no se ha identificado una metodología en particular. La empresa tiene
implementado un método que facilita atender las necesidades inmediatas de clientes
demandantes de cambios en sus sistemas.
RECOMENDACIONES
Aunque la empresa cuenta con experiencia en el desarrollo de software utilizando
una metodología ágil, el personal tiene poco conocimiento de esto y no identifica a
ciencia cierta la metodología utilizada, se recomienda lo siguiente:
1. Identificar la metodología utilizada e informar al personal de la empresa cual
es la metodología así como los pasos y procesos que esta implica.
2. Capacitar al personal de desarrollo que forma parte de los dos equipos que
utilizan metodología ágil en el desarrollo de software para que tengan mejor
conocimiento del tema, eso permitirá madurar el proceso de desarrollo
mediante metodologías ágiles.
3. Definir adecuadamente los roles que se requieren en el modelo seleccionado
4. Dar mayor importancia al desarrollo de software por medio del uso de una
metodología ágil y formalizar su uso.
55

65. LITERATURA CITADA
Abrahamsson, P., Ronkainen, J. 2002. Agile software development methods
Review and analysis.. VTT Publications.
Beck, K. 1999. Extreme programming explained: Embrace Change. Reading, Mass.,
Addison-Wesley.
Boehm, B. 2002. Get Ready For the Agile Methods, With Care. Computer.
Boehm, B. 1988. A Spiral Model of Software Development and Enhancement.
Bennington, B. 1956. Agile Requirements Methods.
http://www.therationaledge.com/content/agilerequirements.
Canós, J., Letelier, P. 2006. Metodologías Ágiles para el Desarrollo de Softaware.
Universidad Politécnica de Valencia.
http://www.willydev.net/descargas/prev/TodoAgil.pdf
Cockburn, A. 2001. Agile Software Development.. Addison-Wesley.
Cockburn, A. 2001. Agile software development: the people factor, Computer,
November 2001, IEEE.
Figueroa, G., Solis, C. 2008. Metodologías Tradicionales vs. Metodologías Ágiles.
Universidad Técnica Particular de Loja
Fowler, M. 2001. Planning Extreme Programming, Addison-Wesley Professional, 1st
edition.
Fowler, M., Beck, K. 1999. Refactoring: Improving the Design of Existing Code..
Addison-Wesley.
Highsmith, J. 2002. Agile software development ecosystems, Addison-Wesley,
Boston.
Highsmith, J., Orr, K. 2000. Adaptive Software Development: A Collaborative
Approach to Managing Complex Systems. Dorset House.
Microsoft, 2004. Microsoft Solution Framewordk Ver. 3.0.
http://www.microsoft.com/DownLoads/details.aspx?FamilyID=a71ac896-
1d28-45a4-880c-8b0cc8265c63&displaylang=en
Mills, H., O´Neill, D. 1980. The Management of Software Engineering, IBM Systems
Pires, Donald. 2001. Manifiesto Ágil, Uniersidad de California en Los Ángeles UCLA,
(en línea), disponible en http://www.manifiestoagile.com
56

66. Poppendieck M., Poppendieck T. 2003. Lean Software Development: An Agile
Toolkit for Software Development Managers. Addison Wesley.
Pressman, R. 1997. Software Engineering - A Practitioner's Approach, McGraw Hill.
Reynoso C. 2005. Métodos ágiles en el desarrollo de software.
http://www.microsoft.com/spanish/msdn/latam/mediacenter/webcast/architect.a
spx (15 Nov 2005)
Schwaber K., Beedle M. 2001. Agile Software Development with SCRUM.. Prentice
Hall.
Takeuchi, H., Nanoka, I. 1986. The new product development game. Harvard
Business Review Jan/Feb.
The Standish Group. 2001. Fallas en los desarrollos de Sistemas de IT.
Waters, K. 2007. How do you eat an elephant?
http://www.agilealliance.org/article/articles_by_category/5 (25 Marzo
2007).
Wells, D. 2003. Proceedings of Extreme Programming and Agile Methods XP/Agile
Universe.
57

67. ANEXOS
Anexo 1: Cuestionario aplicado al personal y gerentes de JPMorgan Chase.
La siguiente encuesta tiene como objetivo determinar en nivel de uso de las
metodologías ágiles para el desarrollo de software dentro de la empresa. A
continuación se describe brevemente las metodologías ágiles así como las
tradicionales.
Las metodologías tradicionales concentran su atención en llevar una documentación
exhaustiva de todo proyecto y centran su atención en cumplir en un plan de proyecto,
definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las
características importantes dentro de este enfoque tenemos los altos costos al
implementar y al no ofrecer una buena solución para proyectos donde el entorno es
volátil. Las metodologías tradicionales o formales se enfocan en documentación,
planificación y procesos (plantillas técnicas de administración, revisiones, etc.)
Las metodologías tradicionales presentan ciertos problemas tales como:
 Fases de obtención de requerimientos, análisis y diseño muy costosas en cuanto a
tiempo y recursos.
 Muchos niveles de aprobación, lo cual lleva comúnmente al retraso en las fechas
de entrega.
 Una vez que se llega a la fase de desarrollo es muy difícil para el equipo el
entender un sistema tan complejo al ser tan amplia el área que se abarca.
En el otro lado están las metodologías ágiles, las cuales se han incorporado muy
bien a un mundo de requerimientos cambiantes, y estas nos muestran ciertas
ventajas sobre los métodos tradicionales, tales como:
 Buena respuesta a los cambios durante la fase de desarrollo, lo cual es cada vez
más común en los proyectos.
 Entrega continua y rápida de secciones funcionales del sistema.
 Involucramiento del cliente.
 Eliminación del trabajo innecesario.
58

68.  Mayor atención a la parte técnica y de diseño.
 Mejora continua de los procesos y equipos de desarrollo
Las metodologías agiles presentan un nuevo enfoque que nace como respuesta a los
problemas de las metodologías tradicionales y se basa en aspectos puntuales, el
retrasar las decisiones y la planificación adaptativa; permitiendo potencia aún más en
el desarrollo de software a gran escala. El resultado es un Manifiesto Ágil cuyas
principales ideas son:
 Los individuos y las iteraciones entre ellos son más importantes que las
herramientas y los procesos empelados.
 Es más importante crear un producto de software que funcione que escribir
documentación exhaustiva.
 La colaboración con el cliente debe prevalecer sobre la negociación de contratos.
Por favor lea cuidadosamente las siguientes preguntas y responda subrayando la(s)
respuesta(s) convenientes en cada pregunta(s), en alguna de ellas es posible
seleccionar más de una respuesta. En caso de responder este cuestionario por
medio de archivo electrónico favor de marcar en negrita las respuestas.
Nombre:
Correo Electrónico: Empresa:
Preguntas sobre los participantes
¿Has tomado parte antes en una encuesta sobre metodologías de desarrollo?
a) Si
b) Primera vez
c) No
d) No recuerdo
59

69. 2 ¿Cuál de los siguientes roles describe mejor tu actual posición en la compañía?
- Administrador de proyectos
- Desarrollador/programador
- Jefe de desarrollo
- Consultor
- Arquitecto de software
- QA/pruebas/tester
- IT Staff/soporte
3 ¿Cuál de las siguientes situaciones describe mejor tu nivel actual de
conocimiento/participación en Metodologías Ágiles?
- Líder de equipo de desarrollo que usa metodologías ágiles
- Formo parte de un equipo de desarrollo que hace uso de metodologías ágiles
- Estoy considerando introducir metodologías ágiles en mi actual equipo
- He formado parte de equipos de trabajo que hacen uso de metodologías
ágiles
- He escuchado acerca de las metodologías ágiles, conozco muy poco al
respecto
4 ¿Por cuánto tiempo has hecho uso personalmente de las metodologías ágiles sin
importar si en el orden personal o laboral?
a) Nunca
60

70. b) 6 meses
c) Hasta 1 año
d) Entre 1 y 2 años
e) Entre 2 y 5 años
f) Más de 5 años
Preguntas sobre la organización
5 ¿Qué tan grande es la empresa de software a la que perteneces? Incluyendo
personal relacionado en cualquier aspecto al desarrollo de software.
a) <5 personas
b) Entre 5 y 20 personas
c) Entre 21 y 50 personas
d) Más de 50 personas
6 ¿Actualmente la empresa tiene personal distribuido (que forma parte de los
equipos de desarrollo que usan metodologías ágiles) en localidades diferentes?
a) Si
b) No
7 ¿Qué porcentaje de los proyectos de tu empresa se desarrollan haciendo uso de
metodologías ágiles?
a) <20%
b) Entre 20 y 40%
61

71. c) Entre 40 y 60%
d) Entre 60 y 80%
e) Entre 80 y 100%
8 ¿Por cuánto tiempo tu empresa ha estado haciendo uso de metodologías ágiles en
sus proyectos?
a) Nunca
b) 6 meses
c) Hasta 1 año
d) Entre 1 y 2 años
e) Entre 2 y 5 años
f) Más de 5 años
9 ¿Cuántas localidades distintas están haciendo uso de metodologías ágiles en la
compañía?
a) 1
b) 2
c) 3
d) Más de 3
e) Desconozco
Preguntas sobre la transición e implementación
10 ¿Cuál es la principal razón para adoptar metodologías ágiles dentro de la
empresa? En esta pregunta puedes seleccionar más de una opción.
- Mejorar la habilidad en el manejo de cambios
62

72. - Incrementar productividad
- Mejorar calidad en el software
- Mejorar la relación entre TI y negocios
- Reducir riesgos de negocio
- Mejorar o aumentar la disciplina de desarrollo
- Mejorar el proceso de mantenimiento y cambios de software
- Mejorar el quipo de trabajo
11 ¿Qué metodologías ágiles conoces mas? En esta pregunta puedes seleccionar
más de una opción.
a) Scrum
b) XP
c) RUP
d) Otras: ¿Cuáles?
12 ¿Cuáles son las barreras/obstáculos para adoptar en un futuro las metodologías
ágiles en tu actual organización? En esta pregunta puedes seleccionar más de una
opción.
- Cultura organizacional
- Resistencia al cambio en la organización
- Falta de experiencia con metodologías ágiles entre el personal
- Apoyo de los niveles más altos de la organización
63

73. - Proyectos demasiado complejos
- Falta de colaboración por parte de los clientes
- Desconfianza en los resultados de las metodologías ágiles
- Tiempo de transición muy largo
- Limitantes en presupuestos financieros
13 ¿Qué porcentaje de proyectos desarrollados con metodologías ágiles has sido
exitosos en su organización?
a) < 10%
b) Entre 10 y 30%
c) Entre 30 y 60%
d) Entre 60 y 90%
e) Cercano al 100%
f) 100%
14 Por favor intente estimar cuales son los beneficios que ha obtenido la
organización con el uso de metodologías ágiles (responder todos los incisos).
Beneficio Porcentaje estimado
Incremento en productividad
Mejora en tiempos de entrega
Reducción de defectos en el software
Reducción de costos
Anexo 2: Planeación de actividades para los equipos de desarrollo que usan
metodología ágil.
64

74. Anexo 3: Flujo del proceso de control de cambios para los equipos que trabajan
usando la metodología ágil de desarrollo.
65

75. Anexo 4: Flujo del proceso de desarrollo de sistemas para los equipos que utilizan
metodologías ágiles.
66

76. Anexo 5: Flujo del Proceso de Pruebas.
67

77. Anexo 6: Flujo del Análisis y Diseño de sistemas
68

78. 69