Metodologías Ágiles

Revisión del 23:10 6 nov 2010 de Nmcabrera uci (discusión | contribuciones) (Página creada con 'El desarrollo de Software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas{{Definición|Nombre=Metodologías Ágiles|imagen=|concepto=}}<br>metodol...')
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)

El desarrollo de Software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas

Metodologías Ágiles
Información sobre la plantilla


metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos
aquellas propuestas más tradicionales que se centran especialmente en el control del proceso,
estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las
herramientas y notaciones que se usarán. Estas propuestas han demo strado ser efectivas y necesarias en
un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible
mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones,
basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo
más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra
aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto
software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la
colaboración con el cliente y al des arrollo incremental del software con iteraciones muy cortas . Este
enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige
reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías
ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre
sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las
Metodologías tradicionales.


Introduccion


En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas
pretendieron ser las "balas de plata" para el éxito en el desarrollo de software, sin embargo, las
expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante elemento, la
metodología de desarrollo, había sido postergado. De nada sirven buenas notaciones y
herramientas si no se proveen directivas para su aplicación. Así, esta década ha comenzado con
un creciente interés en metodologías de desarrollo. Hasta hace poco el proceso de desarrollo
llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición
de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este
esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y
necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se
exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más
adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy
cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero
manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con
estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a
prescindir del “buen hacer” de la Ingeniería del software, asumiendo el riesgo que ello conlleva.
En este escenario , las metodologías ágiles emergen como una posible respuesta para llenar ese
vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las
metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada
simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad
del producto.


Historia


En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado
al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su
objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar
software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las
actividades desarrolladas.
Tras esta reunión se creó The Agile Alliance3 , una organización, sin ánimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las
organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto
Ágil, un documento que resume la filosofía “ágil”.


Manifiesto Ágil


Según el Manifiesto se valora:
• Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de éxito de un proyecto software. Es más
importante construir un buen equipo que construir el entorno. Muchas veces se comete el
error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es
mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus
necesidades.
• Desarrollar software que funciona más que conseguir una buena documentación. La
regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata
para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo
fundamental.
• La colaboración con el cliente más que la negociación de un contrato. Se propone que
exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración
entre ambos será la que marque la marcha del proyecto y asegure su éxito.
• Responder a los cambios más que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, etc.) determina también e l éxito o fracaso del
mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.


Fuentes


*[1]
*[2]