Desarrollo Agile

TRABAJO FINAL DE LICENCIATURA EN INFORMÁTICA
DESARROLLO DE SOFTWARE CON

METODOLOGÍAS ÁGILES
Besprosvan, Sol – LU 98258

Licenciatura en Informática
Del Zotto German – LU 102419
Ingeniería en Informática
Ponce, Rodrigo – LU 98313
Ingeniería en Informática
Noviembre 1, 2004
UNIVERSIDAD ARGENTINA DE LA EMPRESA

FACULTAD DE INGENIERÍA Y CIENCIAS EXACTAS
DESARROLLO DE SOFTWARE CON METODOLOGÍAS ÁGILES
Besprosvan Sol, Del Zotto German y Ponce Rodrigo
Resumen
Desde su aparición, el mercado consumidor de software ha ido cambiando en
cuanto a sus requerimientos de tiempos, ámbito de negocios y tecnología que lo soporta. La
producción de software entonces se vio exigida por tiempos de entrega cada vez más cortos e
inamovibles, frecuentes cambios de requerimientos, mayor calidad y mayores desafíos
tecnológicos. Estas exigencias están en constante aumento porque los negocios dependen cada
vez más del software, llegando al punto de requerir una nueva forma de trabajo.
En respuesta, a esta evolución del mercado consumidor, la industria debió
adaptarse y mejorar. Para ello surge la ingeniería de software sustentada en los procesos de
desarrollo que resultan exitosos en otras ingenierías para mitigar los problemas que se
presentan al construir software. Esto provocó la aparición de procesos y metodologías con
fuerte orientación hacia la documentación intensiva y altos niveles de ceremonia en las tareas.
Sin embargo una gran parte de los proyectos no disponen de los recursos
humanos, tecnológicos y económicos para poder afrontar la adopción de las prácticas
tradicionales de la ingeniería de software. Como resultado de esta situación surge el concepto
de metodologías ágiles que permiten llevar adelante el desarrollo de software como una
ingeniería focalizándose en los resultados por sobre el proceso.
Existen múltiples métodos que responden a los principios del desarrollo ágil,
donde se pueden mencionar a SCRUM, XP o RUP Ágil. Cada uno de ellos tiene
características particulares, que permite aplicar el más conveniente para cada situación o
incluso combinarlos. SCRUM se centra en la administración del proyecto y los recursos; XP
se focaliza en la codificación y entregas; RUP Ágil se presenta como una versión simplificada
del Rational Unified Process.
El contexto de la industria de software de la República Argentina se caracteriza
por proyectos de corta o mediana duración con asignación limitada de recursos. Presentando
así un escenario permeable a la aplicación de metodologías ágiles, que permite al desarrollo
de software mantenerse dentro los parámetros de la ingeniería de software, respondiendo
efectivamente a las exigencias del mercado.
Página 2 de 46
Contenidos
Resumen ............................................................................................................. 2
Contenidos .......................................................................................................... 3
Introducción y descripción ................................................................................. 4
La visión ágil del proceso de desarrollo de software ................................ 5
Principios de los Métodos de Desarrollo Ágil.................................................... 6
Desarrollo Iterativo e Incremental............................................................. 7
Desarrollo Evolutivo y Adaptativo ........................................................... 8
Planeamiento guiado por Riesgos y por necesidades del Cliente ............. 9
Análisis Evolutivo de Requerimientos .................................................... 10
Iteraciones de Tiempo Fijo...................................................................... 11
Metodologías Ágiles ......................................................................................... 12
Descripción de los métodos Ágiles elegidos........................................... 12
Scrum ...................................................................................................... 13
Extreme Programming ............................................................................ 16
Rational Unified Process Ágil................................................................. 22
Contrastación entre Ciclo de Vida en Cascada e Iterativo ............................... 27
Requerimientos........................................................................................ 28
Planificación............................................................................................ 29
Diseño...................................................................................................... 31
Construcción............................................................................................ 32
Pruebas .................................................................................................... 32
Puesta en Producción .............................................................................. 33
Introducción a los Métodos Ágiles en proyectos pequeños y grandes ............. 35
Tipos de Proyectos en la Argentina......................................................... 37
Posible aplicación de las metodologías ágiles en el contexto argentino . 38
Desmitificaciones .................................................................................... 39
Conclusiones..................................................................................................... 41
Bibliografía ....................................................................................................... 44
Apéndice A - Manifiesto para el Desarrollo Ágil de Software ........................ 45
Los Principios detrás del Manifiesto para el Desarrollo Ágil de Software ...... 45
Página 3 de 46
Introducción y descripción
Con la conformación de la informática como área de estudio a partir de los
años 50, se ha intentado siempre acercarla a alguna de las ciencias o prácticas existentes en
otros ámbitos. Primero se la aproximó a las ciencias matemáticas dando lugar a los
calculadores científicos, luego estuvo muy próxima de la electrónica con el advenimiento de
los transistores y de las telecomunicaciones cuando surgieron las primeras redes de
computadores.
A mediados de la década de los 80, el desarrollo de software comenzó a tomar
cuerpo como disciplina en sí despegando a la informática de las ciencias y prácticas antes
mencionadas. Ésta nueva orientación, la de la construcción de programas y piezas de software
que manipulan y procesan información, comenzó a estar más relacionada a requerimientos
empresariales de soporte operativo y toma de decisiones y no tanto con problemas de
hardware y/o comunicaciones.
La concepción del desarrollo de software como una práctica industrial de gran
escala trajo consigo problemas que hasta ese momento no habían sido tenidos en cuenta o
carecían de importancia debido a la orientación de la disciplina. La problemática encontrada
se fundamenta con el incumplimiento de plazos y estimaciones de esfuerzos, el aumento
desmedido de los costos fuera de presupuesto y las diferencias encontradas entre el producto
software construido y los requerimientos del cliente.
En la última década, el desarrollo de software ha ido adquiriendo técnicas y
mejores prácticas de otras disciplinas que intentan mitigar los problemas encontrados en el
proceso de construcción de software. Dichas prácticas provienen de ramas de la ingeniería
(principalmente de la industrial y la civil) pero también existen técnicas provenientes de la
medicina, administración de empresas y ciencias sociales.
Todas estas prácticas, sumadas al entendimiento de que el proceso de
construcción de software abarca no sólo la implementación de piezas de software en un
lenguaje de programación o tecnología, sino que incluye también aspectos relacionados con la
gestión de personal, requerimientos, planificación, gestión de presupuestos, riesgos,
contrataciones y acuerdos, etc., conllevan al concepto de Ingeniería de Software.
En el presente trabajo de investigación, intentaremos contrastar dos visiones
existentes que surgieron a partir de la concepción del desarrollo de software como una rama
de la ingeniería.
Página 4 de 46
La visión ágil del proceso de desarrollo de software

Desarrollo de software es el proceso de desarrollar software a través de
fases sucesivas en una forma ordenada. Este proceso incluye no solamente la escritura
del código sino también la preparación de requerimientos y objetivos, el diseño de lo que
será codificado, y la confirmación de que lo desarrollado cumple con los objetivos.
(Anónimo)
Esta definición, universalmente aceptada, es entendida de varias formas. La
más lineal es suponer que las fases se ejecutan en estricto orden, comenzando con la
preparación de los requerimientos y objetivos, luego el diseño del código a escribir y por
último la verificación del cumplimiento de los objetivos.
Para ejecutar este proceso en forma lineal y lograr el éxito se requiere la
capacidad de predecir las fases antes de comenzar con las mismas. La predicción no
alcanza sólo a las tareas de cada fase sino también a ciertos detalles propios del producto a
construir. Muchas metodologías y procesos de desarrollo son definidos en función de
suponer que es posible realizar tal predicción, entonces puede ubicárselos en la categoría
de Proceso Predictivo.
Clements previene acerca de los siguientes aspectos (Clements, 1986):
• Los clientes no siempre están seguros de lo que necesitan
• Experimentan cierta dificultad en especificar lo que desean y conocen
• Muchos detalles de lo que realmente desean aparecen durante la etapa de desarrollo
• Manejar los detalles suele ser demasiado “pesado” para el común de la gente
• A medida que se ve el avance del proyecto el cliente suele cambiar de idea
• Fuerzas externas (competencia, economía) pueden llevar a cambios en los
requerimientos
Tomando en cuenta los aspectos aquí presentados se puede concluir en que la
visión de proceso predictivo de software anteriormente mencionado no es el único que existe.
Existiendo otra visión llamada proceso creativo, la cual plantea el desarrollo de nuevos
productos contemplando circunstancias de requerimientos cambiantes en tiempos cortos.
En el siguiente cuadro comparativo (Larman, 2003) se podrá evidenciar las
diferencias mas importantes de ambas visiones.
Página 5 de 46
Tabla I: Proceso Predictivo vs. Proceso Creativo
Proceso Predictivo Proceso Creativo

Es posible definir especificaciones y Generalmente las especificaciones
luego construir detalladas cambian
Es posible estimar esfuerzo y costos al A medida que se recopilan datos se
comienzo del proceso incrementa la posibilidad de poder planear y
estimar
Es posible identificar, definir y programar A medida que se obtiene feedback sobre
todas las actividades y su orden pequeños pasos se toman decisiones de
cómo seguir
Los cambios inesperados no son comunes Adaptabilidad a los cambios inesperados es
y la tasa de cambios es baja. una norma. La tasa de cambios es alta.
Como se observa, las dos visiones resultan opuestas sobre el mismo proceso.
Siendo este hecho el origen del siguiente interrogante: ¿Como puede la metodología que da
respaldo a este proceso responder a situaciones y problemáticas completamente opuestas? La
respuesta es que existen metodologías distintas para cada concepción del proceso. Es
importante destacar que éste trabajo de investigación se centrará en las metodologías que
conciben el desarrollo de software como un proceso creativo. Debido a esto, a continuación se
analizarán las mejores prácticas que dichas metodologías utilizan y promueven.
Principios de los Métodos de Desarrollo Ágil

Tal como se mencionó anteriormente, se comenzará a analizar las mejores
prácticas que se encuentran en la mayoría de las metodologías que entienden al proceso de
desarrollo como un proceso creativo. Las cuales dan un fuerte sustento teórico y práctico para
alcanzar las metas que ellas persiguen: realizar software sobre escenarios cambiantes y
tiempos cortos.
Las mejores prácticas son:
• Desarrollo Iterativo e Incremental
• Desarrollo Evolutivo y Adaptativo
• Planeamiento manejado por Riesgos y por necesidades del Cliente
Página 6 de 46
• Análisis Evolutivo de Requerimientos

• Iteraciones de Tiempo Fijo
Desarrollo Iterativo e Incremental

Cuando se desarrolla en forma iterativa e incremental, el sistema se libera para
producción en forma repetitiva y continua con funcionalidad ampliada. Las iteraciones son
planificadas con una duración pequeña, respecto del total del proyecto, permitiendo así
diseñar, construir y probar en pequeñas cantidades. Este es un proceso en forma de espiral
(Bohem, 1988).
Las entregas incrementales suelen ser confundidas con desarrollo iterativo,
pero mientras que el desarrollo iterativo implica ciclos que se repiten, al final de cada ciclo no
necesariamente se obtiene una versión del sistema que será entregado.
El concepto de evolutivo es debido al énfasis en obtener realimentación acerca
del último entregable y así orientar el contenido de la próxima entrega. De esta manera se
puede lograr que ciertas necesidades o requerimientos, difíciles de predecir, mediante la
información resultante del contacto con entregas previas, se puedan descubrir con mayor
facilidad. Cuando se trata de entregas evolutivas, la planificación de las siguientes iteraciones
se basan en el resultado de las anteriores, en cambio en las entregas incrementales la
planificación es previa y no considera la información resultante de las entregas previas
(Larman, 2003).
Este tipo de planificación en iteraciones provoca la necesidad de decidir no
solamente qué tareas deberán encararse y desarrollarse sino también en que momento. El
retrabajo es la tarea de adaptar, corregir, ampliar o generalizar algo con el fin de cumplir con
los requerimientos actuales. El retrabajo es entonces algo a tener en cuenta, y se debe lograr
que la mayor parte se desarrolle durante las primeras iteraciones, en un proyecto saludable se
puede observar una marcada disminución del retrabajo conforme al avance del mismo. El
foco de los primeros incrementos debería centrarse entonces no solamente sobre
especificaciones sino también en la construcción de software. También es importante atacar
problemas difíciles como la integración incluso en iteraciones tempranas, de otra forma
podría ocurrir que el perfil de dificultad del proyecto en un cierto punto cambie abruptamente
y no se pueda cumplir con las entregas o bien éstas ya no muestren incremento y/o evolución
(Kruchten, 2000).
Página 7 de 46
Figura 1: Comparación del riesgo a lo largo del tiempo según el ciclo de vida
Desarrollo Evolutivo y Adaptativo

El desarrollo evolutivo implica que los requerimientos, la planificación, las
estimaciones y la solución evolucionan y son refinadas a lo largo de las iteraciones, en vez de
ser completamente definidas y en especificaciones detalladas antes de comenzar la iteración
de desarrollo (Larman, 2003).
En los métodos evolutivos, los requerimientos y el diseño van evolucionando a
lo largo de las diferentes iteraciones debido a que no tiene sentido especificar detalladamente
requerimientos al inicio del proyecto si su implementación se estima que será realiza al final.
Ante un cambio en el contexto o el negocio, el requerimiento puede cambiar
considerablemente y todo aquello que se había detallado puede no tener más sentido.
El desarrollo adaptativo implica que los elementos generados durante el
proceso de desarrollo se van adaptando en respuesta al feedback del trabajo realizado en una
iteración anterior. El feedback puede ser de los usuarios, testers, el equipo de desarrollo, etc.
(Larman, 2003). El hecho de que sea adaptativo refuerza aún más el concepto de que el
trabajo se va guiando por el feedback recibido en una etapa anterior.
La ventaja principal de los métodos que utilizan desarrollo adaptativo es que
todos los elementos (plan, requerimientos, análisis, diseño, implementación, etc.) se basan en
Página 8 de 46
lo que el cliente o usuario percibe y transmite como necesario. Los métodos adaptativos están
muy relacionados a la práctica de planificación guiada por el cliente.
Planeamiento guiado por Riesgos y por necesidades del Cliente

Hasta ahora se ha mencionado que el desarrollo de software se realizará de
forma iterativa, incremental y/o evolutiva según el método que se aplique. Pero no se ha dicho
nada acerca de como seleccionar los requerimientos que se planearán en cada iteración o cual
será el concepto que prime al momento de tomar las decisiones. Es en esto que se basan las
practicas de Risk Driven y Client Driven Planning.
Risk Driven Planning o Planeamiento Dirigido por los Riesgos es una práctica
que indica que al momento de elegir los requerimientos, se analizarán o implementarán
primero, aquellos que mayores riegos signifiquen. Para ello se deberá poder generar un
ranking de los requerimientos en función del riesgo.
Es fundamental entender qué es un riesgo. Riesgo es todo aquello que
signifique un gran esfuerzo técnico o que refiera a una actividad incierta o nunca realizada o
que se posea poca especificación o signifique un tema políticamente problemático o
demasiado novedoso.
En función de estos conceptos se realizará una tabla como la Tabla II, ubicando
en las primeras iteraciones los requerimientos que mayores riesgos signifiquen. De esta
manera, el proyecto estará más controlado y en caso de que algunos de los riesgos mayores (la
escala es ascendente según el nivel de riesgo, desde el 0 al 3) generen alguna contingencia o
desplazamiento en los tiempos o costos, esto podrá ser visto en el principio del proyecto y no
en etapas posteriores.
Tabla II: Modelo de Ponderación de Requerimientos
Requerimiento Tipo Impacto en la Arquitectura Riesgo

Proceso de Pago con Tarjeta de Crédito escenario 3 3
Generación de la Interfaz Grafica feature 2 0
Proceso de Venta Telefónico escenario 3 2
Página 9 de 46
Con un concepto similar al anterior Client Driven Planning o planeamiento

dirigido por el cliente implica que la elección de qué requerimientos se incluirá en la próxima
iteración, será una decisión que el cliente tome. Ya que es quien percibe el valor del negocio
que dichos requerimientos agregan. Es importante destacar que el cliente debe ser
correctamente recomendado en función de un orden factible de implementación.
Análisis Evolutivo de Requerimientos

Siguiendo los lineamientos planteados por las practicas de desarrollo iterativo y
evolutivo, el análisis evolutivo de requerimientos hace hincapié en cómo se va a ir realizando
el relevamiento y análisis de los requerimientos del sistema.
Esta práctica se basa fundamentalmente en que solo el 20% de los
requerimientos impactan realmente en la arquitectura (Larman, 2003). Es por ello que dichos
requerimientos deben poder descubrirse y ser tenidos en cuenta para las primeras iteraciones.
Completándose en el resto de las iteraciones todos los requerimientos que el sistema debe
cumplimentar.
Para ello se debe recordar que en cada iteración se dan todas las actividades del
desarrollo de software: requerimientos, análisis, diseño, programación y pruebas. Volviendo a
las bases del proceso creativo de desarrollo donde una de las premisas más importantes es que
gran parte de los requerimientos pueden cambiar, no seria óptimo analizarlos y especificarlos
con gran nivel de detalle al principio del proyecto. Es por ello que esta práctica se encuentra
acompañada por la de desarrollo iterativo y evolutivo, planteando en conjunto que el análisis
profundo de los temas que incluye ese incremento se realice en el momento en que el
proyecto esté centrado en los mismos y no antes.
Una de las formas para implementar esta práctica es realizando Workshops de
Requerimientos. Estos son encuentros donde durante dos o tres días el equipo o los
representantes de este junto con el cliente definen los requerimientos. Es muy importante
tener en cuenta que en el primer encuentro, que se realiza al principio del proyecto, la misión
de este workshop es especificar los requerimientos dándole un nombre lo mas identificatorio
posible y un impacto sobre los riegos que éstos significan. De esta manera podrán elegir los
requerimientos de la primera iteración y así sucesivamente para las siguientes. Una vez que la
iteración comienza, se realizará otro workshop para analizar en detalle los requerimientos
propios de la iteración.
Página 10 de 46
Básicamente esta practica lo que permite es no analizar requerimientos que

posiblemente nunca se implementen o sufran tantas modificaciones que el análisis deba
realizarse nuevamente al momento de implementarlos.
Iteraciones de Tiempo Fijo

En las Iteraciones de Tiempo Fijo se asigna una fecha inamovible para la
finalización de cada iteración, en algunos casos puede utilizarse esta práctica para todo el
proyecto. Esta práctica posibilita que el proyecto avance de forma previsible y estable. Si se
advierte la imposibilidad de cumplir con los objetivos de la iteración dentro del tiempo
asignada a la misma, la acción a aplicar es diferir esos objetivos a futuras iteraciones en lugar
de cambiar la fecha de finalización (Larman, 2003).
Si bien las iteraciones tienen una duración determinada y fija, no
necesariamente todas las iteraciones tendrán la misma duración. Dependiendo de la
metodología aplicada, la elección de la duración de las iteraciones será libre, puede estar
sugerida o incluso determinada.
No debe ser asociado el concepto de fechas fijas con tiempos reducidos ni
tampoco con cantidades de trabajo que obliguen a los miembros del equipo a dedicar más
tiempo del correspondiente para poder alcanzar los objetivos.
Cockburn explica que Las Iteraciones de Tiempo Fijo garantizan que el equipo
tenga el tiempo y claridad mental para desarrollar software que funciona, mediante esta frase
relaciona la forma de planificar el trabajo con la manera en que se manejan las solicitudes de
cambio. Debido a que los cambios de fecha no son aceptados, cualquier modificación a la
planificación deberá ser realizada sobre futuras iteraciones, por lo tanto el equipo se
mantendrá concentrado en el cumplimiento en el mismo tiempo y de los mismos objetivos
que fueron fijados y acordados al comienzo de la iteración. (Cockburn, 2001)
El efecto de tener un tiempo fijo determinado para las iteraciones es la
desaparición del variable tiempo o duración del proyecto. Debido a que los ajustes de
planificación deberán ser realizados sobre el alcance del proyecto, la cantidad de recursos
asignados o la calidad final. Generalmente no es posible afectar a la calidad y el alcance del
proyecto no suele ser negociable pero en ciertos contextos, donde los requerimientos son
evolutivos, los objetivos se redefinen en cada planificación.
Página 11 de 46
Metodologías Ágiles
Tal como dice Alistair Cockburn: Ser ágil no es sino declarar maniobrabilidad
frente a los cambios de los requerimientos, la tecnología y entender los cambios de situación.
Ser ágil es también una declaración de prioridades en un proyecto. Eso es ser ágil.
(Cockburn, 2001)
Con esta visión de agilidad, muchos grandes desarrolladores o lideres de
proyectos comenzaron a delinear y establecer distintos métodos que podían diferenciarse entre
si por las implementaciones pero que su hilo conductor siempre respondía a este concepto.
Finalmente en el año 2001, en Utah EE.UU. todos los representantes fueron invitados a un
taller de dos días en Snowbird. Martin Fowler cuenta: Todos estábamos conscientes del hecho
de que había mucho en común, y este reconocimiento era mucho mayor que las diferencias
entre los procesos. Además de un contacto útil entre los líderes de procesos, había también la
idea de emitir una declaración conjunta - una llamada a las armas en favor de más procesos
de software ágiles (Fowler, 2000).
Y justamente lo que obtuvieron fue una declaración de los principios y valores
comunes de los procesos ágiles llamada Manifiesto Ágil (Apéndice A). Martin Fowler
continúa diciendo: El manifiesto fue sólo eso, una publicación que actuó como un punto de
partida para aquellos que compartían estas ideas básicas. Uno de los frutos del esfuerzo fue
la creación de un cuerpo más longevo, la Alianza Ágil. La Alianza Ágil es una organización
sin fines de lucro que busca promover el conocimiento y la discusión de todos los métodos
ágiles. (Fowler, 2000).
Las metodologías ágiles son métodos que contribuyen y dan soporte al proceso
creativo de software. En todos los casos adoptan el Manifiesto y los principios Ágiles como
pilares de los mismos.
Descripción de los métodos Ágiles elegidos

Los métodos ágiles que se analizarán en este trabajo son:
• Scrum
• XP
• RUP Ágil
Página 12 de 46
Scrum
Scrum nace en Hardvard en el año 1986 de la mano de Ikujiro Nonaka y
Hirotaka Takeuchi quienes escriben The New Product Development Game (Harvard Business
Review 86116:137-146, 1986) y luego elabora The Knowledge Creating Company (Oxford
University Press, 1995) referido al desarrollo ágil de software. En ambos libros, refieren a las
técnicas de manejo usadas para el desarrollo de software en proyectos que poseen un entorno
caótico.
En el año 2001 es redactado el Manifiesto Ágil, documento en el cual Jeff
Sutherland, Ken Schwaber, y Mike Beedle se basaron para reforzar los conceptos ya
exhibidos por Nonaka y Takeuchi. Agregando finalmente las reglas y artefactos al método
planteado para llegar finalmente a lo que hoy se conocen como Scrum.
Scrum es un método ágil que trabaja con ciclos iterativos e incrementales tanto
para el desarrollo de un software como para el manejo de cualquier equipo o proyecto.
Su nombre es tomado del Rugby y es por ello que el espíritu de Scrum es la
visión del desarrollo de Software como un Juego de Equipo. Donde el Líder del Proyecto es
considerado un Coach y en el equipo el compromiso es una de las claves.
Dentro de los métodos ágiles Scrum es el único que presenta todos sus ciclos
de igual tiempo de duración: 30 días. Los mismos se denominan Sprints, que en los términos
del Rugby significa “Jugada”. Es por ello que este método dividirá la complejidad del
proyecto o partido en las distintas Jugadas.
Scrum es un método muy sencillo pero tiene reglas y roles muy claros. El
primer rol es el de Product Owner. Este rol será ocupado por el cliente o aquella persona que
el cliente designe a trabajar con el resto del equipo. La característica más importante es que el
Product Owner será quien pueda establecer las prioridades en una lista de requerimientos a
realizar.
De esta forma se puede evidenciar que Scrum es un método fuertemente
basado en Client Driven Planning. Ya que será el cliente quien guiará acerca de qué
requerimiento implementar primero.
El segundo rol es el del Scrum Master. Este es el rol más importante de este
método, ya que se trata del Líder de Proyecto, el cual debe desempeñarse como un Coach. Su
perfil estará conformado por un cincuenta por ciento técnico ya que debe poder guiar o
solucionar problemas de esta índole. Sin significar que deba controlar el código de sus
Página 13 de 46
desarrolladores, sino muy por el contrario debe confiar en lo que estos realicen. Será además
quien deba mantener el foco de cada Sprint en el Sprint Goal o misión de cada incremento.
Será el encargado de llevar adelante cada reunión y completar o actualizar cada uno de los
documentos que el método posee.
Los dos roles siguientes son los del equipo de desarrollo y el resto de los
stakeholders involucrados en el Proyecto. Las diferencias se pueden encontrar en las
responsabilidades que tendrán. Ambos perfiles serán muy tenidos en cuenta
fundamentalmente al momento de priorizar los requerimientos. Ya que al adoptar la practica
de Client Driven Planning es muy importante tener en cuenta la factibilidad técnica y
cualquier otro aspecto que afecte la correcta implementación de dichos requerimientos.
El ciclo de vida de Scrum esta compuesto por tres áreas: Pre-Game (Pre-
Juego), Game (Juego) y Post-Game (Post-Juego). Encontrando dentro de cada etapa las
siguientes tareas, características y funciones.
Tabla III: Ciclo de Vida del Método Scrum

Pre-Juego Juego Post-Juego
Staging
Planeamiento (Ordenamiento) Desarrollo Release
Propósito Establecer la Identificar más Implementar un Puesta en
visión y requerimientos y sistema por medio Producción del
expectativas. priorizarlos para la de iteraciones Sistema
primera iteración. incrementales y
evolutivas de 30
días(Sprints)
Actividades Escribir la Planeamientos y Reuniones de Documentación
misión, el exploración de los Planeamiento de final
Presupuesto requerimientos Sprint.
inicial, el Definiciones de los
Product Sprint Backlog.
Backlog inicial Reuniones Diarias
y algunos ítems de Scrum y
de estimación Revisiones de los
Sprints
Si se analiza la Tabla III se encontrará terminología propia del método, tal

como Product Backlog, Sprint Backlog. Ambas palabras refieren a documentos o entregables
que posee este método. Tal como dice Alistair Cockburn ser ágil es priorizar (Cockburn,
2001). Los backlogs son justamente listas priorizadas de los requerimientos que se deben
llevar a cabo en cada momento del proyecto. El Product Backlog es la lista priorizada de
Página 14 de 46
todos los requerimientos que el proyecto completo debe abarcar. Siendo el Sprint Backlog la
lista priorizada de todos los requerimientos que es Sprint debe cumplir.
Scrum posee además una serie de reuniones o encuentros definidos en los
cuales se podrán definir, especificar y actualizar estos Backlogs.
El momento donde se formaliza la actividad de reconocimiento de
requerimientos para un Sprint recibe el nombre de Sprint Planning Meeting o reunión de
Planeamiento del Sprint. En ella se reúne todo el equipo, los stakeholders y el cliente y se
define el Sprint Backlog y el Sprint Goal. Siendo este último una oración que resume el
espíritu de lo que se quiere lograr en esa iteración.
Otra de las reuniones características de este Método son las Daily Scrum
Meetings o reuniones diarias de Scrum, donde todo el equipo se reúne y el ScrumMaster
pregunta a cada uno de ellos: ¿Que hiciste ayer? ¿Qué harás hoy? ¿Qué dificultades tuviste?
Estas tres preguntas serán las que le permitirán de forma diaria saber como esta avanzando el
proyecto y que dificultades han surgido. Pudiendo con esta información el Scrum Master
actualizar el Sprint Backlog y una lista de dificultades encontradas. En esta lista quedarán
documentados los inconvenientes que el equipo ha tenido para cada requerimiento del
Backlog.
Es importante destacar que la Daily Scrum Meeting se realiza cada día del
proyecto en el mismo horario y lugar. Teniendo en cuenta que su duración no debe exceder
los 20 minutos. Es por ello que se plantea que se haga lejos de cualquier maquina de café o
sitio de recreación y preferentemente se lleve a cabo de pie.
La última de estas reuniones es la Sprint Review Meeting donde el
ScrumMaster durante 4 horas realiza la demostración de lo realizado durante ese Sprint.
Página 15 de 46
Figura 2: Visión Gráfica del Método Scrum
Extreme Programming
XP es el método ágil de desarrollo iterativo e incremental más reconocido y
practicado debido a su simplicidad y a la claridad de sus prácticas.
Como lo define su creador Kent Beck, XP es un método iterativo e incremental
que hace hincapié en la satisfacción del cliente mediante la creación rápida de software de
gran valor, técnicas de desarrollo útiles y sostenibles, y flexibilidad en respuesta a los
cambios.
Como la palabra programming lo indica, provee explícitamente métodos a los
desarrolladores que les permiten responder ante requerimientos de cambio con mayor
confiabilidad, aún en una etapa avanzada del proyecto, y aún así producir código de calidad.
(Larman, 2003)
Otra definición, es la de Ron Jeffries, pupilo de Beck: Extreme Programming
es una disciplina de desarrollo de software basada en los valores de simplicidad,
comunicación, realimentación y coraje. Funciona reuniendo a todo el equipo junto utilizando
Página 16 de 46
de prácticas simples, con suficiente realimentación que permita que el equipo entienda el
estado actual y pueda ajustar las prácticas a cada situación particular. (Jeffries, 2001)
La palabra extreme se debe a que sus creadores tomaron ciertas prácticas ya
conocidas en la industria del software y las llevaron al extremo. Larman hace una buena
síntesis de las mismas (Larman, 2003):
• Realizar pruebas (Testing) es muy útil, por lo cual se aconseja realizar pruebas
unitarias para casi todos los bloques de código fuente y pruebas de aceptación para
funcionalidad del sistema.
• Las revisiones de código son muy buenas, por lo cual se aconseja realizar
revisiones en todo momento y durante todo el proyecto.
• La integración frecuente del código es también útil, por lo cual se aconseja
automatizar el proceso de integración para que funcione 24 x 7 en una máquina
dedicada a realizar builds.
• Las iteraciones cortas y su realimentación temprana son esenciales. Se aconseja
realizar iteraciones de entre una y tres semanas.
• Que el cliente esté involucrado es muy importante. Se aconseja mantener al cliente
próximo al equipo durante todo el proyecto, incluso en el mismo lugar físico.
• La comunicación es crucial, se aconseja sentar a todo el equipo junto, incluyendo
al cliente e involucrar a todo el equipo en la planificación, correcciones y
evaluación del avance del proyecto.
Prácticas
XP se basa en 12 prácticas básicas que ayudan a que el equipo de desarrollo
mantenga el rumbo en forma disciplinada a medida que va tomando requerimientos
cambiantes. Estas prácticas no son todas novedosas sino que existían con anterioridad y lo
novedoso fue juntarlas y hacer que fueran interdependientes.
Las prácticas pueden ser clasificadas en tres niveles de generalidad. El primer
nivel está relacionado al proyecto como proceso y a la relación con el cliente y el equipo. El
segundo nivel se identifica con prácticas asociadas únicamente al equipo. Por último, el tercer
nivel especifica técnicas de programación.
Página 17 de 46
Figura 3: Prácticas de Extreme Programming
1) Talleres de Planificación (Planning Game)

En éstos talleres, que pueden ser por versión entregable o por iteración, se
definen los alcances a desarrollar en base a requerimientos relevados que se especifican y
estiman durante el taller. Los requerimientos se especifican utilizando escenarios (Story
Cards) que son escritos junto al cliente y estimadas por el equipo de desarrollo durante el
taller.
En el caso del taller por versión entregable, se define el alcance de la próxima
versión a entregar al cliente teniendo en cuenta aquella funcionalidad que más valor le aporte
al cliente en ese momento. El cliente selecciona los escenarios a cubrir en la siguiente versión
del software teniendo en cuenta la fecha de finalización (time boxed).
Si el taller es por iteración, el objetivo del mismo es especificar los escenarios
de la siguiente iteración (no mayor a tres semanas de duración). El equipo de desarrollo
estima cada escenario definiendo las tareas necesarias para su implementación y cada
integrante selecciona las tareas que desarrollará durante la iteración.
Página 18 de 46
2) Entregas frecuentes y pequeñas (Small Releases)

XP es un método iterativo e incremental por lo cual las entregas se llevan a
cabo a cada fin de iteración (ya sean entregas internas o externas al equipo de desarrollo). Las
iteraciones no deben durar más de tres semanas para poder obtener una realimentación rápida
de parte del cliente y así definir cuál es el estado actual del proyecto y cuál será la
funcionalidad a implementar en la siguiente iteración. (Larman, 2003)
3) Todo el equipo junto (Whole Team)

Debido a que XP lleva la comunicación dentro del equipo y para con el cliente
al extremo, una de las prácticas es contar con el cliente y el equipo de desarrollo en la misma
sala. Incluso, se tiende a que los puestos de trabajo estén en el centro de la sala y o contra las
paredes para favorecer la comunicación cara a cara.
Otra característica es que suele no haber oficinas para el líder del proyecto o el
cliente. Esto es debido a que XP trata a todos los integrantes del equipo (incluido el cliente)
por igual.
4) Integración Continua (Continuous Integration)

XP lleva al extremo el concepto de creatividad en el proceso de desarrollo.
Aquellas tareas que no son consideradas creativas, como el proceso de pruebas de software y
la generación de versiones entregables que incluyen compilación y linquedición, son
automatizadas utilizando herramientas y máquinas dedicadas a dicho propósito.
Estos procesos automatizados se ejecutan en forma continua y en modalidad 24
x 7 para permitir contar en todo momento con software productivo, integrado y libre de
errores.
5) Diseño Simple (Simple Design)

Una de las características más sobresalientes de XP es su apoyo a la
simplicidad en todas sus prácticas, principalmente en el diseño. Debido a que las iteraciones
son cortas y los requerimientos se definen a medida que avanza el proyecto, se tiende a
realizar diseños bien simples pero robustos sin pensar demasiado a futuro o en la reutilización
de componentes.
Página 19 de 46
6) Refactoring
Debido que durante una iteración, se realiza automáticamente y en forma
continua una integración del código, es esencial que cada vez que se rediseñe o se modifique
un bloque de código el mismo continúe funcionando igual o mejor que antes del cambio.
Para que esto sea posible, se utiliza la práctica de Refactoring que permite
modificar un bloque de código de tal modo de que sea más claro o robusto pero sin impactar
en su funcionalidad. Esta práctica define reglas que hay que tener en cuenta a la hora de la
modificación y técnicas para realizar los cambios de manera correcta. Algunas herramientas
de desarrollo actuales ya poseen asistentes que permiten realizar refactoring sobre bloques de
código de manera correcta. (Fowler et al., 1999)
7) Metáfora del sistema (Metaphor)

Una de las prácticas menos utilizadas es la de crear una metáfora del sistema o
de cada uno de sus subsistemas si el sistema es muy grande. La metáfora consiste en definir
una frase que describa el objetivo del sistema y permite que el equipo posea rápidamente una
visión completa del sistema más allá de la iteración actual.
8) Mantener un paso sostenible (Sustainable Pace)

Las metodologías ágiles están fuertemente centradas en las personas y XP no
es la excepción. Una de sus prácticas más comúnmente utilizada es la de mantener un paso
sostenible a lo largo del proyecto.
Que el paso sea sostenible significa que la carga de trabajo para el equipo debe
ser coherente y uniforme (si bien pueden haber picos de trabajo, no debería ser la norma). Se
suelen trabajar semanas de 40-45 horas y una de las reglas más conocidas es que no puede
haber dos semanas seguidas con jornadas mayores a 10 horas. La principal razón de esta
práctica es que XP se centra en la calidad del código escrito o modificado. Si el equipo está
exhausto, la calidad decae considerablemente. (Larman, 2003)
Página 20 de 46
9) Programación por Parejas (Pair Programming)

Esta práctica es la más radical de XP y la más cuestionada por aquellos que
adoptan XP por primera vez. Todo el código productivo es creado por dos programadores en
una única computadora; ellos rotan periódicamente al mando de los dispositivos de entrada.
Los pares cambian frecuentemente, para diferentes tareas. El que observa realiza revisión de
código en línea y talvez medita más ampliamente que aquel que está escribiendo
considerando posibles pruebas. (Larman, 2003)
10) Propiedad colectiva del código (Collective Ownership)

En un proyecto XP, el líder del equipo no designa las tareas de los integrantes,
sino que cada uno de ellos elige cuáles son las tareas a las cuales se compromete en cada
iteración y el líder coordina los esfuerzos para que se cumpla el objetivo.
Esta forma de trabajo del equipo lleva a que un miembro tome parte de un
código en una iteración y luego otro integrante la vuelva a tomar en otra iteración donde
ambos tienen que poder modificarlo o realizar Refactoring en forma totalmente independiente
del dueño anterior del código.
Larman define está práctica de la siguiente manera: Cada par de
programadores puede mejorar cualquier bloque de código, y XP promueve que todo el
equipo es colectivamente responsable por todo el código generado. Esto permite solucionar
cuellos de botella asociados a requerimientos de cambio en un modelo de propiedad
individual del código. (Larman, 2003)
11) Estándares de codificación (Code Standards)

Debido a la fuerte utilización de prácticas como programación por parejas,
propiedad colectiva del código, refactoring permanente e integración continua, es esencial
utilizar claros estándares de codificación que definan reglas precisas de cómo debe generarse
y modificarse código.
12) Pruebas (Customer Tests, Test-Driven Development)

Código limpio y que funciona es el lema de Ron Jeffries, uno de los
precursores del desarrollo guiado por pruebas (Test-Driven Development o TDD). Existen
Página 21 de 46
muchos factores que nos alejan del código limpio, y más aún del código que funciona. Lo que
promueve el TDD como solución para estas fuerzas es guiar el desarrollo por pruebas
automatizadas que se ejecutan periódicamente a lo largo de casi todo el código generado.
(Beck, 2002)
El TDD es más que una práctica, es un estilo de programación cuyo lema es:
Escribir nuevo código sólo si una prueba automatizada ha fallado. Esto implica que antes de
escribir cualquier bloque de código, se debe generar un código de prueba que será ejecutado
para probar el código aún no escrito. Al ejecutar la prueba, y debido a que no existe código a
ser probado por la prueba, la prueba fallará y eso llevará a escribir el nuevo código. Una vez
escrito se vuelven a repetir los pasos hasta que la prueba sea exitosa. Estos pasos se realizan
con un máximo de 15-20 minutos entre pasos. (Beck, 2002)
La automatización de la ejecución de las pruebas generadas se lleva a cabo
mediante la utilización de herramientas. Esto es consistente con la práctica de integración
continua permitiendo que en todo momento exista código integrado y libre de errores.
Rational Unified Process Ágil

El Rational Unified Process (RUP) es un proceso de ingeniería de software que
provee un enfoque disciplinado para la asignación de tareas y responsabilidades dentro de la
organización de desarrollo de software. Su objetivo es asegurar la producción de software de
alta calidad que cumpla con las necesidades de los usuarios finales, dentro de un presupuesto
y agenda predecibles (Kruchten, 1999).
El RUP es un producto desarrollado y mantenido por Rational Software Corp.,
adquirida en el año 2003 por IBM. El desarrollo y evolución del RUP se origina en el trabajo
conjunto de los equipos de Rational con sus clientes, asociados de negocios y consultores
especializados. Está sometido a una constante actualización proveniente de experiencias
recientes y la evolución de mejores prácticas.
La búsqueda de la productividad del equipo es uno de los puntos que se
resaltan en el RUP, esto se hace mediante la provisión de una base de conocimiento común
acerca del proceso de desarrollo, todos los miembros de la organización están contemplados
en el mismo proceso, sin importar la metodología que aplique para llevar adelante las tareas
correspondiente a la disciplina bajo la cual se encuentran albergadas sus responsabilidades.
Página 22 de 46
Las actividades definidas en el RUP producen y mantienen modelos, este

concepto va más allá de la definición de documentación. Por modelo se entiende a una
representación rica del software que se está desarrollando.
El RUP está concebido como un marco de trabajo abierto, sin embargo no es
un marco de trabajo vacío, sino que esta compuesto por contenido que define los roles,
actividades y artefactos que están organizados en disciplinas y apoyados por guías.
Actualmente cuenta con nueve disciplinas, más de cuarenta roles, cientos de artefactos y miles
de páginas de guías.
Figura 4: Componentes que conforman el RUP
La concepción del RUP es que pueda ser ajustado y configurado para ser
aplicable en proyectos de diferentes tamaños, dominios de aplicación, tecnología y contexto.
Precisamente esta característica es el que posibilita crear una versión “ágil” del RUP, como se
ha realizado en otros casos como RUP para e-business, RUP para proyectos pequeños o para
implementaciones de tecnologías en particular como J2EE, Java, .NET y otras.
Página 23 de 46
La agilidad del RUP radica en su flexibilidad para ser adaptado al nivel de

rigurosidad y ceremonia que el proyecto requiera, esto le confiere a este proceso la
característica de ser aplicable a un amplio espectro de proyectos.
La tarea de agilizar al RUP consta de seleccionar aquellos roles, actividades y
artefactos que serán utilizados en el proyecto al que será aplicado, esta actividad es parte de la
disciplina Ambiente y deber ser llevada a cabo por el Ingeniero de Procesos, uno de los roles
definidos en el RUP. Esta tarea se realiza durante el armado del caso de desarrollo
(Development Case).
La selección de los artefactos está seguida por la ubicación de los mismos en el
tiempo, es decir indicando en que iteración serán producidos. Por ser un proceso que se basa
en iteraciones iterativas e incrementales, es necesario indicar en que iteración se comienza y
en que iteraciones se refinan.
La siguiente es una descripción realizada por Craig Larman (Larman, 2003)
acerca de las fases en que se divide el ciclo de vida de un desarrollo en el RUP:
• Concepción (Inception): es una iteración de corta duración donde se realiza la
captura en detalle de los requerimientos que tendrán influencia sobre la
arquitectura. Se debe lograr un borrador del documento de visión, el caso de
negocio, el alcance y la planificación de la fase de elaboración.
• Elaboración: compuesto por iteraciones de corta duración, se desarrollan y
prueban los elementos fundamentales de la arquitectura. No solo se realiza
análisis y diseño sino que también se programa. La característica evolutiva de las
iteraciones permite que al final de la fase se obtenga una versión estabilizada de
los requerimientos y el núcleo del sistema.
• Construcción: en iteraciones de corta duración, sobre la sólida base del sistema
que se elaboró en la fase anterior se construye el resto del sistema. Se atienden los
cambios en requerimientos que surjan y se realizan pruebas, y ajustes al
desempeño.
• Transición: en sistema es finalmente puesto en producción, durante varias
iteraciones se liberan sistemas candidatos. La puesta en marcha se realiza en
varios aspectos entre otros en como entrenamiento, conversión de datos,
ejecuciones en paralelo con sistemas previos.
Página 24 de 46
Figura 5: Esfuerzo de cada disciplina a lo largo de las fases del ciclo de vida
El RUP se basa expresamente en las siguientes seis mejores prácticas,

desarrollar iterativamente, modelar visualmente, administrar requerimientos, controlar los
cambios, verificar la calidad continuamente, usar arquitecturas basadas en componentes, sin
embargo Kruchten hace hincapié en recordar que los siguientes principios también son
básicos pero habitualmente no son observados e incluso olvidados (Kruchten, 2001):
Desarrollar solo lo necesario; poner foco en los resultados no en como se
alcanzan los mismos; minimizar la cantidad de trabajo en papel; ser flexible; aprender de los
errores; revisar los riesgos regularmente; establecer criterios objetivos y mensurables para el
progreso; automatizar las tareas tediosas, intensivas y susceptibles a errores; usar equipos
pequeños y poderosos; tener un plan.
Al considerar las prácticas mencionadas anteriormente en el caso de desarrollo
se obtendrá la versión ágil del RUP, de todos modos Kruchten menciona los siguientes
elementos como esenciales:
La visión: representada en el documento de visión, el cual se comienza durante
la fase de concepción y se refina en la elaboración. Será la guía general y define el alcance.
• Un plan: describiendo como se organizará el proyecto, en forma detallada
únicamente para las iteraciones próximas.
Página 25 de 46
• Criterios de éxito: por ejemplo el caso de negocio, permite enfocar cada iteración
para alcanzar los hitos correspondientes.
• Un diseño: representando al sistema que está siendo construido, tanto lo ya
realizado como lo que aún está por construirse.
• Una lista de riesgos: siendo un proceso guiado por riesgos, es importante llevar un
registro cuidados de los mismos y atender a ellos.
• Una lista de defectos u otros tipos de solicitudes de cambio: son esenciales para la
planificación de las siguientes iteraciones.
Larman propone una configuración más explícita del proceso y describe los
artefactos a producir en cada disciplina (Larman, 2003):
• Administración de Requerimientos: se requiere el documento de visión,
especificaciones suplementarias y el modelo de casos de uso.
• Diseño: se producen el modelo de diseño, el modelo de datos y una versión corta
del documento de arquitectura del software.
• Pruebas: un documento con el plan de pruebas, describiendo los objetivos y
métodos con que se probará.
• Administración del Proyecto: el plan de desarrollo, con los hitos y recursos a
aplicar; el plan de las iteraciones, se genera previo a cada iteración y tiene el
detalle de la iteración; lista de riesgos, indicando la gravedad y como mitigarlos.
• Administración de Configuraciones y Cambios: el caso de desarrollo, precisamente
un documento que describe como se configura el proceso para este proyecto;
solicitud de cambio, el estándar que será utilizado durante el proyecto.
También llamado Modelo Clásico o Modelo Lineal Secuencial, es
el paradigma más antiguo y más extensamente utilizado en la Ingeniería del
Software.
Página 26 de 46
Contrastación entre Ciclo de Vida en Cascada e Iterativo

Sugiere un enfoque sistemático, secuencial, del desarrollo del
software que comienza en un nivel de sistemas y progresa con el análisis,
diseño, codificación, pruebas y mantenimiento.
Los conceptos básicos en los cuales se fundamenta son:
• Planear un proyecto antes de embarcarse en él.
• Definir el comportamiento externo deseado del sistema antes de
diseñar su arquitectura interna.
• Documentar los resultados de cada actividad.
• Diseñar un sistema antes de codificarlo.
• Testear un sistema después de construirlo.
Figura 6: Ciclo de Vida en Cascada
Página 27 de 46
Figura 7: Ciclo de Vida Iterativo
Requerimientos
El modelo en cascada requiere como uno de sus principales componentes el
relevamiento exhaustivo de todos los requerimientos funcionales y no funcionales que el
sistema va a comprender.
Para poder realizar esta tarea por lo general se suelen utilizar las prácticas de la
Ingeniería de Requerimientos. La cual plantea el proceso de requerimientos con las siguientes
actividades: elicitación, especificación y validación.
La elicitación tiene como propósito hacer del analista un experto en el dominio.
Para ello realizará entrevistas, prototipos y reuso de conocimiento anterior. Utilizará literatura
sobre el tema, software existente y similar para el caso en cuestión, estándares internacionales
de la industria y consultará con especialistas en el área.
La especificación requiere del análisis y asimilación de los conocimientos
obtenidos en la elicitación conjuntamente con la síntesis y organización de los conceptos. Los
cuales se evidenciarán mediante modelos orientados al usuario y a los desarrolladores que
permitan lograr un acuerdo entre las partes y sirvan de guías para la construcción del sistema.
Por último, la validación busca que los modelos realizados en la etapa de
especificación sean realmente consistentes.
Estas actividades se realizarán mediante diversas técnicas, tales como Léxico
Extendido del Lenguaje y escenarios, casos de uso, análisis de formularios, entre otros.
Las ventajas del modelo en casada con respecto a los requerimientos es que al
tratarse de una de las actividades más importantes, el esfuerzo que se le dedicará para poder
Página 28 de 46
realizar las etapas antes mencionadas será muy importante. Contando con recursos
especializados en la materia que trabajarán exhaustivamente con el cliente para identificar
todos los requisitos necesarios para el sistema. Esto hará que a principios del proyecto se
cuente con una documentación muy clara de todo aquello que la aplicación debe cumplir.
Las desventajas de este modelo ya se han mencionado cuando se realizó el
cuadro comparativo entre las visiones de software como proceso predictivo y proceso
creativo. Donde se mencionaban los siguientes aspectos:
Es muy difícil que el cliente exponga los requisitos de forma completa al
principio del proyecto. Siendo que el modelo en cascada asume que esto sucede.
En proyectos de mediano y largo plazo es normal que los requerimientos
cambien parcial o completamente produciendo que el tiempo y costos invertidos en ellos no
se puedan recuperar. Además, dada la naturaleza lineal de este ciclo de vida, a los proyectos le
suele costar mucho adaptarse a estos cambios.
En contraposición con esto, las metodologías ágiles que poseen la visión del
proceso de desarrollo de software como un proceso creativo utilizan para el análisis de
requerimientos las prácticas de análisis evolutivo de requerimientos. Donde la principal
ventaja está dada en que los requerimientos solo se analizarán en forma exhaustiva dentro de
la iteración donde este requisito será implementado. Optimizando el esfuerzo de análisis de
los mismos, ya que solo se tendrá en cuenta requerimientos que se implementarán en ese
momento. Permitiendo además al equipo focalizarse por completo en los requisitos que hayan
sido elegidos para esa iteración.
Planificación
La planificación tal vez sea la disciplina más cuestionada en las metodologías
ágiles. Sin embargo la crítica suele aparecer por la gran diferencia respecto de la planificación
tradicional y no por falta de efectividad de la planificación ágil.
El enfoque clásico, que supone la secuencialidad de las actividades, facilita la
planificación ya que la misma es realizada en base a poca información y generalmente de
origen teórico. Otro aspecto importante en este tipo de planificación es su semejanza con la
planificación que se realiza en otras ingenierías, por lo tanto la experiencia previa,
herramientas y las métricas suelen ser conocidas. El resultado de este proceso de
planificación intensivo como primer actividad del desarrollo, es un plan detallado para el resto
del ciclo de vida. El nivel de detalle utilizado suele imponer fechas de comienzo para las
Página 29 de 46
tareas, responsables y duración; es común encontrar duraciones medidas en días e incluso

horas.
La visión ágil de la planificación debe acompañar al carácter iterativo del ciclo
de vida del desarrollo de software. En este caso no es suficiente con una única planificación al
inicio, y tampoco es posible realizar un plan detallado ya que no se conocen los
requerimientos, los cuales se conciben evolutivos. Si bien existen técnicas y herramientas
muy distintas para realizar las planificación, las metodologías coinciden en la necesidad de
contar con objetivos precisos, priorizados y medibles. Respecto a la asignación de tiempos y
responsabilidades el común denominador es acuerdo y colaboración por parte de todo el
equipo.
En el modelo en cascada, es posible realizar un seguimiento del plan
identificando los retrasos y responsables. Sin embargo al momento la ejecución del plan no es
posible realizar un nuevo plan, por lo tanto para corregir los retrasos, se deben tomar medidas
correctivas que puedan reencausar el proyecto. Otro punto a tener en cuenta es la propagación
de los cambios, retrasos, reasignaciones o cualquier otra alteración al plan, ya que la
secuencialidad con que está construido el plan hace que la gran mayoría de las actividades se
encuentren enlazadas entre sí. Enfoques más modernos tienden a aceptar ciertos cambios al
plan, pero la naturaleza secuencial de todo el proceso es un impedimento para la ejecución de
las nuevas tareas. Por ejemplo, si es necesario reanalizar requerimientos para incorporar un
cambio durante la etapa de construcción el analista deberá intervenir, pero es probable que el
mismo no esté disponible ya que ha sido asignado a otro proyecto debido a que la etapa de
análisis de requerimientos concluyo mucho tiempo atrás.
En la planificación ágil los planes se realizan para cada iteración, las tareas a
controlar son menos en cantidad y la dependencia entre tareas es acotada. Cada iteración
puede pensarse como un compartimiento estanco, por lo tanto los retrasos, cambios o
reasignaciones en las tareas no escapan de esa iteración. Con iteraciones cuya duración no es
extensa los objetivos tampoco lo son, con lo cual los retrasos se descubren tempranamente y
las medidas correctivas se incorporan de forma natural y sin mayor impacto en la próxima
iteración.
La dificultad de la planificación en las metodologías ágiles reside en ofrecer al
cliente una predicción acerca del proyecto completo. La planificación detallada al comienzo
predice el proyecto completo, sin embargo la ejecución del plan difícilmente se cumpla.
Página 30 de 46
Diseño
En el modelo cascada, la etapa de diseño se centra en realizar especificaciones
técnicas detalladas a respecto de cómo se va a construir la solución a implementar en la etapa
de construcción. Para dicho propósito, se utilizan herramientas tales como la Carta de
Estructura, los Árboles de Decisión, Tablas de Decisión y los Diagramas de Transición de
Estados que permiten definir claramente las entradas y salidas de cada una de las piezas de
software que serán construidas en la siguiente etapa.
El diseño del modelo en cascada consta de un conjunto de tareas que se
corresponden con aquellas definidas en la etapa de planificación y que deben permitir diseñar
la construcción de una solución a los requerimientos especificados en la etapa de análisis de
requerimientos. En el plan se definieron los entregables, esfuerzo y fechas de inicio y fin de
cada una de las tareas.
Por otro lado, el diseño ágil se basa en los principios de los métodos iterativos
e incrementales donde las tareas de diseño pueden variar en cada iteración y no siguen un plan
detallado global sino que se van ajustando y redefiniendo según el conjunto de requerimientos
a implementar en cada iteración y el feedback recolectado.
En las primeras iteraciones, el diseño ágil se centra principalmente en definir
las piezas de software fundamentales que conforman el esqueleto del sistema. A dicho
conjunto se lo denomina arquitectura del sistema y comprende no sólo especificaciones sino
también ejecutables que permiten verificar que la arquitectura funciona. En la definición de la
arquitectura, se toman los requerimientos que mayor impacto pueden tener en la estructura
base del sistema a construir o que mayor riesgo significan.
Tomando como base ésta arquitectura se continúa diseñando las distintas
piezas de software que irán conformando el sistema y que serán especificadas en cada
iteración a medida que el proyecto avanza y se estipulan los requerimientos a implementar en
cada una de ellas. Algunas buenas prácticas son la utilización de patrones de diseño,
definición de responsabilidades de clases mediante patrones GRASP y modelado visual
mediante de diagramas de clases y paquetes de UML.
Cabe destacar que el diseño ágil promueve la reutilización de componentes, la
simplicidad de las especificaciones y minimizar el re-trabajo a la hora de definir un diseño.
Página 31 de 46
Construcción
La práctica de construcción o implementación contempla diferentes tareas
entre las que se incluyen la codificación en un lenguaje de programación, la esquematización
de repositorios de datos y la creación de documentos y/o entregables.
En un modelo en cascada, la construcción se plantea únicamente como la
traducción de las especificaciones de diseño a un lenguaje de programación. Dichas
especificaciones están absolutamente detalladas y cualquier cambio propuesto en la
construcción será considerado un error de diseño que deberá ser analizado y corregido antes
de proseguir con la construcción.
En un modelo ágil, la construcción posee mayor libertad de acción ya que el
diseño ágil no llega hasta un nivel exhaustivo de detalle sino que deja para la etapa de
construcción algunas consideraciones técnicas muy específicas. Un cambio propuesto en la
construcción de una especificación de diseño o inclusive de una construcción de una iteración
anterior será visto como un refactoring.
Pruebas
Esta disciplina tiene por objetivo determinar si el resultado del desarrollo
satisface el objetivo último del sistema a construir, tal como lo percibe el cliente.
El proceso tradicional contempla toda una etapa de pruebas en forma previa a
la puesta en marcha. Este concepto de pruebas está asociado a la verificación del
cumplimiento de objetivos, sin esforzarse en el aseguramiento. De un plan detallado, basado
en un proceso específico se espera que sus resultados sean asegurados por el proceso en sí
mismo. La dificultad radica en lograr la coincidencia de los objetivos definidos al comienzo
con los objetivos al final del proceso de desarrollo.
El desarrollo basado en metodologías ágiles promueve que las pruebas estén
presentes durante prácticamente todas las actividades de todas las disciplinas. Por eso se
verifica constantemente lo que se construye. En cada iteración los requerimientos que se
analizan se prueban al diseñar, el diseño se prueba al construir, lo construido se prueba contra
lo requerido, los entregables se verifican respecto de los objetivos del plan correspondiente. Y
el resultado de la iteración se entrega al cliente para su escrutinio, lo que el cliente informa
acerca de los resultados se tiene en cuenta para las siguientes iteraciones.
Página 32 de 46
Probar en forma tardía provoca que, al descubrirse errores, el costo de la

corrección de los mismos sea varios órdenes de magnitud mayor a salvar esos errores al poco
tiempo de haberse producido. Si se aplican técnicas como iteraciones de tiempo fijo y
requerimientos evolutivos; la corrección de un error no ocurrirá, en el tiempo, más allá de la
siguiente iteración, lo que significa que es conocido el tiempo de vida de un error por lo cual
puede conocerse el costo de reparación del mismo. Esto es posible porque al final de cada
iteración se realizan las pruebas necesarias y porque los requerimientos evolutivos exigen que
el cliente informe acerca de su impresión sobre los resultados.
Otras ventajas de las pruebas en un entorno de desarrollo bajo metodologías
ágiles es la proximidad entre la definición de los requerimientos y las pruebas para verificar el
cumplimiento de los mismos. El escaso tiempo que transcurre entre estas dos tareas aseguran
que se conozcan con precisión las pruebas a realizar y así el objetivo de las mismas puede ser
alcanzado, es decir asegurar que el cliente obtenga lo que solicitó. Bajo el proceso lineal las
pruebas generalmente se realizan en base a requerimientos que fueron realizados mucho
tiempo atrás y la característica no iterativa del proceso suele ocultar los cambios que sufrieron
los requerimientos, el diseño y la construcción, o al menos implican un esfuerzo mucho
mayor en reconstruir esta historia de cambios; bajo estas condiciones tal vez las pruebas no
estén asegurando cumplimiento con las expectativas del cliente.
Puesta en Producción
La puesta en producción es una disciplina de alto impacto, en especial para el
cliente, donde se afectan recursos operativos de la organización que utilizará el sistema
desarrollado. Esta disciplina implica múltiples tareas, muchas de ellas se relacionan poco con
la construcción de software, como puede ser la creación de manuales de usuario o el
entrenamiento de los mismos.
Según la cascada de disciplinas propuesta por el modelo tradicional esta puesta
en producción sucede luego de las pruebas y antes del contacto del usuario con el sistema.
Entonces se podría concluir que no hay pruebas sobre la puesta en producción, se la supone
libre de errores y por otra parte significaría que el usuario no conoce al sistema por lo cual se
dificulta que la aceptación de las pruebas tenga realmente valor. En la realidad práctica no
ocurre de esta manera, por lo tanto el proceso lineal no se cumple exactamente de la forma en
que está definido.
Página 33 de 46
Las metodologías ágiles exigen puestas en producción sucesivas, en muchos

casos no son específicamente versiones de producción, pero sí versiones que se ejecutan. Esto
anticipa desafíos particulares que cada tecnología puede presentar. El descubrir las
dificultades en forma previa a los momentos de exposición con el cliente es muy ventajoso.
Concebir la puesta en producción como parte de cada iteración promueve a la
automatización de la misma y facilita luego las tareas de mantenimiento durante todo el ciclo
de vida del software más allá del desarrollo del mismo. Por este mismo motivo se realizan
pruebas sobre el proceso de puesta en producción lo que asegura la posibilidad de repetición.
Página 34 de 46
Introducción a los Métodos Ágiles en proyectos pequeños y grandes

Para explicar el efecto de las metodologías en los grupos de desarrollo, Alistar
Cockburn desarrolló una curva donde relaciona los conceptos de tamaño del problema y peso
de la metodología para grandes y pequeños grupos de trabajo. El fin que desea alcanzar con
esta gráfica, es demostrar que en equipos pequeños de trabajo, las prácticas que se adopten
para conformar la metodología del equipo no deben ser demasiadas. Ya que sino el peso de
las mismas hará que el grupo se sienta demasiado oprimido por ellas. Logrando el efecto
contrario al que se buscó (Cockburn, 2002).
Problem Size
large team
small team
Methodology Weight
Figura 8: Gráfico del Peso de la Metodología
El gráfico ilustra como añadiendo más elementos a la metodología inicialmente

ayuda pero luego puede llegar hasta disminuir notoriamente el progreso del proyecto.
La línea punteada muestra como un equipo pequeño, utilizando una
metodología mínima, puede atacar satisfactoriamente problemas de ciertos tamaños. Añadir
unos pocos elementos bien seleccionados a la metodología les permite trabajar más
efectivamente y atacar problemas más grandes.
A medida que continuamos añadiendo elementos a la metodología, se
incrementa la carga burocrática sobre el equipo y siendo éste aun pequeño, empieza a perder
más energía en cultivar la propia metodología que en resolver el problema. El tamaño del
problema que pueden afrontar satisfactoriamente disminuye.
Página 35 de 46
La curva es parecida en los equipos grandes (línea continua), pero no tan

abrupta. Los grandes equipos necesitan mayor coordinación para funcionar de manera óptima
y tienen, a medida que crecen, más gente cultivando la metodología. Eventualmente, incluso
los grandes equipos empiezan a perder productividad cuando el tamaño de la metodología
crece y resuelven los grandes problemas menos satisfactoriamente.
La Figura 9, conocida como la Escala de Cockburn, muestra una forma de
caracterizar proyectos. El eje horizontal representa el número de gente que se necesita
coordinar comenzando por 1 a la izquierda hasta 1000 a la derecha. La idea es que los
proyectos necesitan más elementos de coordinación para sus metodologías a medida que el
número de gente involucrada se incrementa.
El eje vertical representa el daño potencial causado por defectos no detectados
en el sistema, desde la pérdida del confort hasta la pérdida de la vida. La idea es que los
proyectos necesitan más elementos de validación a medida que el daño potencial se
incrementa.
. . . Prioritized for Legal Liability

(defects cause loss of...)
Prioritized for Productivity & Tolerance

Criticality
Life
(L)
L6 L20 L40 L100 L200 L500 L1000
Essential
money
(E) E6 E20 E40 E100 E200 E500 E1000
Discretionary
money
(D) D6 D20 D40 D100 D200 D500 D1000
Comfort
(C)
C6 C20 C40 C100 C200 C500 C1000
1-6 - 20 - 40 - 100 - 200

- 500 - 1,000
Number of people involved +20%
Figura 9: Escala de Cockburn
Cada caja de la cuadrícula identifica un conjunto de proyectos que podrían

plausiblemente utilizar la misma combinación de políticas de coordinación y validación. La
Página 36 de 46
etiqueta en la caja indica el máximo daño y la carga comunes a esos proyectos (esto es, D40
se refiere a proyectos con entre 20 y 40 personas y potencial pérdida de dinero discrecional).
Los proyectos que encajan en diferentes cajas deberían utilizar diferentes políticas.
(Cockburn, 2002)
Tipos de Proyectos en la Argentina

El 18 de agosto del 2004 el Senado de la Nación sancionó la Ley de Promoción
de la Industria del Software. Dicha ley generó muchísima expectativa en la CICOMRA
(Cámara de Informática y Comunicaciones de la Republica Argentina). Creyendo que esto va
a permitir que la industria del software de nuestro país pueda generar mayores proyectos y por
consiguiente incrementar el número de empleos (CICOMRA 2004).
Esto se realiza en función de la relación costo-beneficio que surge a partir de la
devaluación. La cual coloca a la Argentina en una posición por demás competitiva.
Ahora bien, si se toma en cuenta ésta posibilidad, en conjunto con los
proyectos que se están sucediendo dentro del país se puede inferir que responden a las
siguientes características:
• Grandes proyectos en organizaciones pequeñas resultan en proyectos pequeños,
con mucho apoyo gerencial pero con escaso apoyo técnico. Estos proyectos deben
presentar resultados operacionales concretos, de otra manera la organización
sufrirá fuertemente las consecuencias.
• Pequeños proyectos en organizaciones grandes, a los cuales se les exige mucho
desde el punto de vista metodológico y de procesos, pero sobre el cual no se hace
hincapié en el resultado final ni en la eficiencia del mismo, esto se debe a que
tienen poco impacto en la organización. De este tipo de proyectos se exige que se
realice todo de acuerdo a un proceso determinado para mantenerse dentro de las
normas y procedimientos de la organización.
• Múltiples proyectos pequeños y similares que se presentan en simultáneo, como
pueden ser las adaptaciones o puesta en funcionamiento de paquetes de software o
bien nuevas versiones de productos. Aquí lo que más se espera del proyecto es que
se termine en el tiempo prefijado.
Página 37 de 46
• En organizaciones multinacionales, la versión local de un proyecto que a nivel

global es de un gran tamaño suele ser similar pero a una escala muy pequeña;
resultan en proyecto sencillos de llevar adelante pero con estándares
metodológicos de alta exigencia.
Estas características son a su vez las que se encuentran dentro de la Escala de
Cockburn como proyectos de tipo C6 y D6.
Posible aplicación de las metodologías ágiles en el contexto argentino

Generalmente resulta muy difícil establecer o elegir un método que cubra todas
las expectativas en cuanto a una metodología y que además su aplicación no genere el efecto
“pesado” al cual Cockburn se refería con su curva de Peso de la Metodología.
Es por ello, que una buena forma de comenzar a aplicar estas metodologías es
analizando el grupo y el proyecto en el que uno se encuentra. Eligiendo aquellas prácticas
generales o propias de un método que se adecuan al contexto.
Dentro de esas prácticas, consideramos que hay un nivel básico o primario que
debe considerarse para aplicar en una primera fase. Este nivel incluye las siguientes prácticas,
características y herramientas.
Prácticas generales
• Desarrollo iterativo e incremental
• Planeamiento adaptativo
• Análisis de requerimientos evolutivos
• Iteraciones timeboxed
• Simplicidad
Características tomadas de métodos particulares

• Comunicación y trabajo en equipo. El líder deberá tener características
técnicas y de liderazgo de equipos basada en el concepto de
ScrumMaster.
• Evitar ownerships de código u otros elementos.
Página 38 de 46
• Onsite Customer o al menos cliente consultable telefónicamente

durante todo el proyecto.
• Construir sobre seguro (arquitectura / tecnología / innovación)
• Medición de resultados en función de piezas de software entregadas.
Herramientas recomendadas
Product Backlog
Iteration Backlog
Desmitificaciones
Si bien todas las prácticas de los métodos ágiles están en consonancia con los
principios fundamentales, la aplicabilidad de muchas de ellas no resulta sencilla. Esto se debe
principalmente a las características de los proyectos locales y a la idiosincrasia del equipo de
desarrollo.
Un ejemplo concreto es el de Programación en Parejas (Pair Programming)
donde las personas trabajan de a pares en la misma máquina durante todo el proyecto. El
hecho de trabajar de esta forma requiere una fuerte predisposición y conducta del equipo de
desarrollo a aceptar comentarios y correcciones por parte de su par durante todo el día laboral.
Hay que tener también en cuenta la cultura de la organización; si el objetivo principal de la
misma no es el desarrollo de software, tal vez existan políticas, procedimientos o normas que
se contraponen con esta forma de trabajo.
Otro caso es el de Desarrollo Guiado por Pruebas (Test Driven Development o
TDD) en el cual es imprescindible que el equipo de desarrollo posea una fuerte capacitación
en las herramientas y técnicas de TDD; no resulta tan intuitivo programar casos de prueba, es
por ellos que se requiere un importante conocimiento funcional por parte de cada integrante
del equipo. Por último, es clave para el éxito de la aplicación de la técnica el contar con
suficiente experiencia en la misma para poder implementar todos los casos posibles de prueba
para cada pieza de software a construir.
La técnica de Entregas Diarias (Daily Build) dentro de la práctica de
Integración Continua también puede llevar a conflictos durante su implementación.
Generalmente, el hecho de tener que realizar entregas todos los días, conlleva a la necesidad
Página 39 de 46
de disponer de un ambiente muy automatizado o personal dedicado a la tarea de integración.

Por otro lado, el equipo deberá poseer gran disciplina para poder realizar diariamente las
pruebas necesarias que permiten la integración continua del software. Para cada tecnología o
ambiente de desarrollo deberán definirse los procesos y la forma de implementación de esta
técnica.
Página 40 de 46
Conclusiones
Desde el principio de este trabajo de investigación se intentó mostrar la
diferencia que presenta la ingeniería de software por sobre las otras ingenierías.
Comprendiendo que el proceso de desarrollo de software no puede asemejarse directamente a
la producción masiva de productos. Ya que el contexto donde se desarrolla conjuntamente con
el producto resultante es distinto debido a su carácter creativo y la dificultad que presenta al
momento de captar los requerimientos y características que el mismo debe cumplir.
Uno de los puntos que se intentó mostrar es como hacer llegar la ingeniería de
software a aquellos proyectos de corto plazo y recursos limitados. Donde la aplicación de las
tareas que comprenden las metodologías tradicionales requiere una dedicación de recursos
que compite con el cumplimiento del objetivo principal: construir y entregar software
funcional que cumple con los requerimientos al momento que el cliente lo necesite.
Las metodologías ágiles son una opción para aquellos equipos de desarrollo
que desean construir software bajo este contexto pero sin dejar de cumplir con la ingeniería de
software. La característica diferencial es la priorización de los resultados por sobre la
documentación intensiva, ya que promulgan realizar sólo lo necesario en forma simple
permitiendo cumplir con los objetivos y adaptarse a los cambios.
Es posible planificar el proyecto, estandarizar los procedimientos, y organizar
el equipo aplicando una metodología ágil. La forma en que se realiza esto es mediante el
seguimiento de ciertos principios y la aplicación de ciertas prácticas. Ágil no significa hacerlo
improvisadamente sino hacer solo aquello que produzca resultados.
Los métodos propuestos son de reciente aparición, todos se ajustan a los
principios, pero muchos de ellos con enfoques distintos. Esto ofrece un amplio espectro de
alternativas para atacar un mismo problema, no existiendo una receta única. El origen de estos
métodos es la práctica del desarrollo de software, por lo tanto no resulta difícil de
implementarlas a otros equipos que también realizan desarrollos. Adherir a algún método es
formalizar prácticas que tal vez ya se hacen naturalmente en esos equipos.
En el contexto, de los proyectos de software de la Argentina, la aplicación de
estas metodologías puede contribuir a elevar el nivel de organización, calidad y productividad
de la industria, manteniendo niveles competitivos por no exigir gran cantidad de recursos.
En el caso de Scrum, las dos características más relevantes de este método son
el manejo de backlogs, y las reuniones diarias del equipo. Dichas prácticas aplicadas al
Página 41 de 46
desarrollo de software actual estarían resolviendo alguna de las problemáticas que hoy en día
encontramos como frecuentes errores o necesidades de los proyectos argentinos.
El primero de ellos es la falta de comunicación en el equipo de desarrollo, lo
que genera muchas veces que el líder del proyecto no conozca de ciertos riesgos o trabas que
se están presentando en el correcto desempeño de las tareas de los miembros del equipo.
Ocasionando desvíos en los tiempos y costos del proyecto que podrían haber sido evitados
simplemente incorporando mayor comunicación entre los integrantes. Siendo esto uno de los
motivos más importantes para realizar las reuniones diarias de equipo, las cuales les permiten
tanto a los integrantes como al líder conocer día a día cómo se desarrollan las tareas y con que
dificultades se han encontrado.
El segundo inconveniente suele ser la falta de actualización en los estados de
avances de los proyectos conjuntamente con el desconocimiento puntual de las tareas a lograr
en el corto y mediano plazo. El cual surge por lo general de no poseer un documento que
contenga dichas tareas con un nivel de avance constante del mismo. Esto genera que no se
pueda analizar continuamente el estado del proyecto detectando en forma temprana desvíos
que permitan tomar acciones correctivas para logar los objetivos planteados. Además de no
poder focalizar al equipo de desarrollo únicamente en las tareas que se deben realizar para
lograr las metas planteadas para esa etapa del proyecto. Esto es fácilmente solucionable con la
aplicación del Sprint Backlog, el cual contendrá los objetivos a lograr para dicha etapa del
proyecto siendo actualizado diariamente por el ScrumMaster en las Daily Scrum Meetings.
Ambas prácticas resultan sumamente simples y no generan mayor carga de
trabajo en los equipo de desarrollo. Pero la aplicación de las mismas, traerían muchos
beneficios en dos de los aspectos más importantes y conflictivos de los proyectos de
desarrollo de software que son: tener más control acerca del cumplimiento de los tiempos y
costos estipulados y poseer un estado actualizado durante todo el proyecto.
En el caso de Extreme Programming o XP, el contexto socio-económico de la
Argentina limita la aplicación de muchas de sus prácticas como ser programación por parejas,
donde no es común que un cliente acepte tener dos desarrolladores por máquina, o la práctica
de integración continua, donde se requiere de un ambiente de software y hardware dedicado a
la generación de builds.
Otras prácticas son más aplicables localmente, como ser las de talleres de
programación, entregas frecuentes y la definición de estándares de codificación. Estas
prácticas ayudan a mitigar los riesgos existentes en proyectos pequeños, donde se requiere de
Página 42 de 46
una muy acertada estimación de tiempos o esfuerzo de las tareas y contar con un equipo de
trabajo bien sincronizado e interdisciplinario. Las entregas frecuentes posibilitan obtener
feedback temprano por parte del cliente minimizando el riesgo de una mala interpretación e
los requerimientos por parte del equipo.
Para el caso de RUP Ágil las condiciones son algo distintas, aquí no se trata de
tareas sumamente sencillas, pero que son simples de aplicar en organizaciones que tengan en
marcha otros proyectos bajo RUP. Utilizar un pequeño subconjunto de RUP cuando el
proyecto sea de las características mencionadas en este trabajo puede ser cumplido sin
mayores exigencias.
Como se ve en los ejemplos, utilizar metodologías ágiles no representa grandes
esfuerzos, deben tenerse en cuenta ciertas situaciones comunes que afectan a los proyectos en
la Argentina.
En primer lugar considerando la disponibilidad y costos de capacitación,
consultoría y mentoring acerca de metodologías ágiles que lamentablemente en la Argentina
no contamos, al menos en forma amplia, con oferta de cursos y servicios de consultoría que
puedan utilizarse para acompañar a la incorporación del equipo.
En segundo lugar con respecto a la experiencia y capacitación donde una de las
formas de adopción de alguno de estos métodos es mediante la incorporación de personal con
experiencia en otros proyectos donde se haya utilizado. En este caso en la Argentina será
difícil encontrar este tipo de características por los motivos expresados anteriormente.
Igualmente en el caso particular de RUP es fundamental tener en cuenta que
empresas donde ya se cuente con esta metodología es sumamente sencillo adaptarlo para
utilizar la versión de RUP Ágil que le permitirá mantener dicha metodología y sus estándares
de calidad a proyectos más pequeños en los cuales no se creía poder llegar a aplicarla.
Es por ello que podemos concluir finalmente en que en el contexto de los
proyectos de software de la Argentina, la aplicación de las metodologías ágiles puede
contribuir notoriamente a elevar el nivel de organización, calidad y productividad de la
industria, manteniendo niveles competitivos por no exigir gran cantidad de recursos.
Página 43 de 46
Bibliografía
Beck, Kent. Test-Driven Development by Example. Addison Wesley – Noviembre 2002
Boehm, Barry W. A Spiral Model of Software Development and Enhancement. IEEE

Computer, Vol. 21, No. 5, 1988.
Clements P. A Rational Design Process: How and why to Fake It. IEEE Transactions on
Software Engineering. Feb. 1986.
Cockburn, Alistair. Agile Software Development. Addison-Wesley. Diciembre 2001.
Cockburn, Alistair. Learning From Agile Software Development. Octubre 2002. Artículo de
Crosstalk - The journal of Defense Software Engineering.
http://www.stsc.hill.af.mil/crosstalk/2002/10/cockburn.html
Control Chaos. About Scrum 2004. http://www.controlchaos.com/about/
Fowler, Martin et al. Refactoring: Improving the Design of Existing Code. Addison Wesley
- Junio 1999
Fowler, Martin. The New Methodology. Julio 2000 – Abril 2003.

http://www.martinfowler.com/articles/newMethodology.html
Jeffries, Ron. What is Extreme Programming?. Artículo publicado en el sitio

XProgramming.com en Noviembre, 2001.
http://www.xprogramming.com/xpmag/whatisxp.htm
Kruchten, Philippe. From Waterfall to Iterative Lifecycle – A tough transition for project
managers. Rational Software Corporation White Paper, 2000.
Kruchten, Philippe. Agility with the RUP. Artículo publicado en Cutter IT Journal Vol. 14
Nro. 12, Diciembre 2001.
Kruchten, Philippe. Rational Unified Process, an Introduction, Third Edition. Addison-

Wesley, 2003.
Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison Wesley, 2003.
Página 44 de 46
Apéndice A - Manifiesto para el Desarrollo Ágil de Software

• Individuos e interacciones sobre procesos y herramientas
• Software que funcione sobre documentación intensiva
• Colaboración del cliente sobre negociación y contratos
• Respuesta frente al cambio sobre el seguimiento de un plan
No es que no se reconozca el valor de los elementos en el lado de la derecha, pero hay mucho
más en los de la izquierda
Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
Los Principios detrás del Manifiesto para el Desarrollo Ágil de Software

Nosotros seguimos estos principios:
• Nuestra prioridad más alta es el satisfacer a nuestros clientes mediante entrega
temprana y continua de software que funciona.
• Vemos bien los cambios de los requerimientos, incluso si éstos vienen durante el
desarrollo. El proceso de desarrollo ágil implora el cambio para que el cliente tenga
una ventaja competitiva.
• Entregar software que funciona frecuentemente, desde unas semanas a unos meses,
prefiriendo una ventana de tiempo más corta.
• La gente de negocio y los desarrolladores tienen que trabajar juntos día a día a lo largo
de un proyecto.
• Haz proyectos con individuos motivados. Dadles el entorno y soporte que necesitan y
confiad en que puedan acabar el trabajo.
• El método más eficiente y efectivo de pasar información en un equipo de desarrollo es
en una conversación cara a cara.
• Software que funciona es la forma primaria de calcular el progreso.
Página 45 de 46
• Los procesos ágiles promueven un desarrollo sustancial. Los sponsors, desarrolladores

y los usuarios deben ser capaces de mantener una velocidad constante
indefinidamente.
• Atención continua a la excelencia técnica y buen diseño mejora la agilidad.
• Simplicidad -- el arte de maximizar la cantidad de trabajo no hecho -- es esencial.
• Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto-
gestionados.
• A intervalos regulares, el equipo hace una reflexión de como ser más efectivos y
ajusta y mejora su comportamiento de acorde al resultado.
Página 46 de 46

Desarrollo Agile

Cargado por

Copyright:

Formatos disponibles

Desarrollo Agile

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

Desarrollo Agile

Cargado por

Copyright:

Formatos disponibles

TRABAJO FINAL DE LICENCIATURA EN INFORMÁTICA

DESARROLLO DE SOFTWARE CON

Besprosvan, Sol – LU 98258

UNIVERSIDAD ARGENTINA DE LA EMPRESA

La visión ágil del proceso de desarrollo de software

Tabla I: Proceso Predictivo vs. Proceso Creativo

Proceso Predictivo Proceso Creativo

Principios de los Métodos de Desarrollo Ágil

• Análisis Evolutivo de Requerimientos

Desarrollo Iterativo e Incremental

Desarrollo Evolutivo y Adaptativo

Planeamiento guiado por Riesgos y por necesidades del Cliente

Tabla II: Modelo de Ponderación de Requerimientos

Requerimiento Tipo Impacto en la Arquitectura Riesgo

Con un concepto similar al anterior Client Driven Planning o planeamiento

Análisis Evolutivo de Requerimientos

Básicamente esta practica lo que permite es no analizar requerimientos que

Iteraciones de Tiempo Fijo

Descripción de los métodos Ágiles elegidos

Tabla III: Ciclo de Vida del Método Scrum

Si se analiza la Tabla III se encontrará terminología propia del método, tal

Figura 2: Visión Gráfica del Método Scrum

Figura 3: Prácticas de Extreme Programming

1) Talleres de Planificación (Planning Game)

2) Entregas frecuentes y pequeñas (Small Releases)

3) Todo el equipo junto (Whole Team)

4) Integración Continua (Continuous Integration)

5) Diseño Simple (Simple Design)

7) Metáfora del sistema (Metaphor)

8) Mantener un paso sostenible (Sustainable Pace)

9) Programación por Parejas (Pair Programming)

10) Propiedad colectiva del código (Collective Ownership)

11) Estándares de codificación (Code Standards)

12) Pruebas (Customer Tests, Test-Driven Development)

Rational Unified Process Ágil

Las actividades definidas en el RUP producen y mantienen modelos, este

Figura 4: Componentes que conforman el RUP

La agilidad del RUP radica en su flexibilidad para ser adaptado al nivel de

El RUP se basa expresamente en las siguientes seis mejores prácticas,

Contrastación entre Ciclo de Vida en Cascada e Iterativo

Figura 6: Ciclo de Vida en Cascada

Figura 7: Ciclo de Vida Iterativo

tareas, responsables y duración; es común encontrar duraciones medidas en días e incluso

Probar en forma tardía provoca que, al descubrirse errores, el costo de la

Las metodologías ágiles exigen puestas en producción sucesivas, en muchos

Introducción a los Métodos Ágiles en proyectos pequeños y grandes

El gráfico ilustra como añadiendo más elementos a la metodología inicialmente

La curva es parecida en los equipos grandes (línea continua), pero no tan

. . . Prioritized for Legal Liability

Prioritized for Productivity & Tolerance

1-6 - 20 - 40 - 100 - 200

Cada caja de la cuadrícula identifica un conjunto de proyectos que podrían

Tipos de Proyectos en la Argentina

• En organizaciones multinacionales, la versión local de un proyecto que a nivel

Posible aplicación de las metodologías ágiles en el contexto argentino

Características tomadas de métodos particulares

• Onsite Customer o al menos cliente consultable telefónicamente

de disponer de un ambiente muy automatizado o personal dedicado a la tarea de integración.

Beck, Kent. Test-Driven Development by Example. Addison Wesley – Noviembre 2002