UNIVERSIDAD GRABRIEL RENE MORENO
Metodología Ágil vs Metodología Tradicional MODULO DE CALIDAD LINDA LUNA TELLEZ
2012
Metodologías ágiles vs tradicionales 1. Historia de las metodologías y de los modelos. Desde el inicio del desarrollo masivo de software [1] se ha querido encontrar las mejores prácticas y distribuir la experiencia obtenida a través de la práctica. Esto se ha hecho tradicionalmente mediante metodologías impulsadas por universidades y grandes empresas de tecnología a través de “metodologías”, como la programación estructurada (1969), SSADM (1980), RAD (1991), RUP y SCRUM (1998) o XP (1999). Además, Además, se s e han generado diferentes ““modelos modelos”” de calidad que identifican actividades del desarrollo determinadas como buenas prácticas (el QUE) pero que no prescriben la manera de realizarlas concretamente (el COMO), de manera que los equipos que los adoptan pueden elegir cuál es la manera de realizar estas prácticas que mejor se adapta a sus contextos y características. Uno de los principales errores que tenemos las personas en general, es el querer aplicar un método de resolución de problemas que una vez usamos exitosamente, exitosament e, para resolver todos los problemas. Cuando analizamos las metodologías ¨candidatas¨ a implantar en nuestros lugares de trabajo, surgen, casi automáticamente, dos tipificaciones de metodologías: las metodologías ágiles versus las metodologías duras (tradicionales). (tradicionales). Podemos mencionar mencionar entre las primeras a XP (Extreme (Extreme Programming, junto a su partner XT- Extreme Testing -) y SCRUM, en tanto que dentro de la segunda categoría una de las más conocidas es CMMI. Revisión de metodologías [1] Antes de resumir algunas metodologías ágiles, vamos a enumerar las principales diferencias respecto de las metodologías tradicionales (“no ágiles”). La Tabla 1 recoge esquemáticamente esquemáticamente estas diferencias que no se refieren sólo al proceso en sí, sino también al contexto de equipo y organización que es más favorable a cada uno de estas filosofías de procesos de desarrollo de software. Metodologías Agiles
Metodologías Tradicionales
Basadas den Heurísticas provenientes Basadas en Normas Provenientes de de prácticas de producción de código Estándares Estándar es seguidos por el entorno de desarrollo Especialmente preparados para Cierta Resistencia a los Cambios. cambios durante el proyecto. Proceso menos controlado, con pocos Proceso mucho más controlado, con principios. numerosas políticas /normas. No existe contrato tradicional o al Existe un contrato prefijado menos es bastante flexible. El cliente es parte del equipo de El cliente cliente interactúa interactúa con el equipo equipo de
desarrollo desarrollo mediante reuniones. Grupos pequeños (<10 integrantes) y Grupos grandes y posiblemente trabajando en el mismo sitio. distribuidos. Pocos roles. Más roles. Menos énfasis en la arquitectura arquitectur a del La arquitectura del software es esencial y software se expresa mediante modelos. Tabla 1. 1. Diferencias entre metodologías ágiles y no ágiles Aunque los creadores e impulsores de las metodologías ágiles más populares coinciden con los principios principios enunciados anteriormente, cada metodología metodología tiene características car acterísticas propias y hace hincapié en algunos aspectos más específicos. A continuación se resumen dichas metodologías ágiles. •
SCRUM. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle.
Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto. Éstas son las verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración. •
Crystal Methodologies Se trata de un conjunto de metodologías para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Alistair Cockburn. Cockburn. El desarrollo de software software se considera un juego juego operativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros). •
Dynamic Systems Development Method(DSDM) Define el marco para desarrollar un
proceso de producción de software. Nace en 1994 con el objetivo el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente i implementación. implementación. Las tres últimas últimas son iterativas, adem a demás ás de existir realimentación a todas las fases. •
Adaptive Software Development7 (ASD) Su impulsor es Jim Highsmith. Sus principales
características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. •
Feature-Driven Development (FDD) Define un proceso proceso iterativo que que consta de 5 pasos. Las
iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del
sistema sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad. Lean Development (LD) Definida por Bob Charette’s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios. •
•
PROGRAMACIÓN EXTREMA ( EXTREME PROGRAMMING , XP)
Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. Los principios y prácticas son de sentido común pero llevadas al extremo, Posteriormente, otras publicaciones de experiencias se han encargado de dicha tarea.. La Tabla 2 compara las distintas aproximaciones ágiles en base a tres parámetros: vista del sistema como algo cambiante, tener en cuenta la colaboración entre los miembros del equipo y características más específicas de la propia metodología como son simplicidad, excelencia técnica, resultados, adaptabilidad, etc. También incorpora como referencia no ágil el Capability Madurity Model (CMM). CMM 1
ASD 5
Crystal 4
DSDM 3
FDD 3
LD 4
SCRUM 5
Sistema algo Cambiante 2 5 5 4 4 4 5 Colaboración Características Metodología (CM) 2 5 5 4 4 4 5 Resultados 1 4 4 3 5 3 5 Simplicidad 2 5 5 3 3 4 4 Adaptabilidad 4 3 3 4 4 4 3 Excelencia Técnica 2 5 5 4 3 3 4 Practicas de Colaboración Media CM 2.2 4.4 4.4 3.6 3.8 3.6 4.2 1.7 4.8 4.5 3.6 3.6 3.9 4.7 Media Total Tabla 2. Ranking de “agilidad” (Los valores más altos representan una mayor agilidad)
XP 5 5 5 5 3 4 5 4.4 4.8
Como se observa en la Tabla 2, todas las metodologías metodologías ágiles tienen una significativa diferencia del índice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP como las más ágiles.
CONCLUSIONES
No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.
Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos que tienen estas características. Una de las cualidades más destacables en una metodología ágil es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos de implantación en un equipo de desarrollo. Esto ha llevado hacia un interés creciente en las metodologías ágiles. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicación, tales como: están dirigidas a equipos pequeños o medianos, el entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboración y la relación contractual son claves), el uso de tecnologías que no tengan un ciclo rápido de realimentación o que no soporten fácilmente el cambio, etc.
REFERENCIAS BIBLIOGRÁFICAS [1]
http://www.willydev.net/descargas/m http://www .willydev.net/descargas/masyxp.pdf asyxp.pdf
CUADRO COMPARATIVO DE LOS MODELOS DE PROCESO DE SOFTWARE [1]
CASCADA
MODELO
Se define como una secuencia de actividades donde la estrategia principal es seguir el proceso del desarrollo de SW hacia checkpoints o mediante entregas calendarizadas
PROCESO
INCREMENTAL
EVOLUTIVO
ESPIRAL
UP
Es una extensión del modelo de cascada. A diferencio del modelo de cascada, que es dirigido por documentos, el modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en áreas de incertidumbre, como requerimientos inestables e incompletos. Al igual que el modelo revolucionario, el modelo de espiral incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Con algunas variantes este es el proceso más importante en la actualidad Es una extensión del modelo de cascada. A diferencio del modelo de cascada, que es dirigido por documentos, el modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en áreas de incertidumbre, como requerimientos inestables e incompletos. Al igual que el modelo revolucionario, el modelo de espiral incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Con algunas variantes este es el proceso más importante en la actualidad Es una extensión al modelo incremental, donde los incrementos de hacen de manera secuencial en lugar de en paralelo; es también conocido como desarrollo rápido de aplicaciones (RAD, Rapid Application Development), que se basa en el uso de prototipo. Es un desarrollo inicial de la arquitectura completa del sistema, seguido de
VENTAJAS
Los documentos técnicos son comprensibles para usuarios y administra dores no técnicos. t écnicos. Cada detalle de los requisitos se conoce de de antemano antes de desarrollar el SW, y los detalles son estables durante el desarrollo. Las pruebas y evaluaciones se realizan eficientemente al final del desarrollo. Las metas se logran mejor cuando se tiene puntos de revisión bien preestablecidos y documentados.
La administración de proyectos es más fácil de lograr en incrementos más pequeños. Es más fácil comprender y probar incrementos de funcionalidad más pequeños. La funcionalidad inicial de desarrolla más temprano, logrando resultados de inversión en menor tiempo. Hay más probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos del SW en el tiempo que si fueran planeados todos a la vez en un mismo periodo.
DESVENTAJAS
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.
Difícil de evaluar el coste total. Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde.
Se entrega temprano parte del sistema, aunque no estén completos todos los requerimientos. Se permite entregar parte del sistema como herramienta para la generación de requerimientos faltantes. Se obtienen beneficios para el sistema mediante entregas iníciales mientras las entregas posteriores están en desarrollo.
Una actividad comienza cuando es entienden los objetivos y riesgos involucrados. Basado en la evaluación de soluciones alternas, se usan las herramientas que mejor reduzcan los riesgos. Todo el personal relacionado debe involucrarse en una revisión que determine cada actividad. El desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos del producto.
Para construir un programa exitoso se deben conocer qué quieren y necesitan los usuarios potenciales.
Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificación de riesgos.
El desarrollo de un producto comercial puede significar un gran esfuerzo durante meses, e
incrementos y versiones parciales del mismo. Cada incremento tiene si propio ciclo de vida. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa se verifica e integra la versión con las demás versiones ya completadas del sistema. Para que la secuencia de desarrollo sea exitosa es esencial definir etapas que no requieran cambiar los resultados anteriores al agregar nuevas
REFERENCIAS BIBLIOGRÁFICAS [1] [2]
http://es.scribd.com/doc/21938147/CUADRO-COMPARATIVO http://www.flickr.com/photos/48425 http://www.flickr.com/photos/48425423@N06/4433 423@N06/4433776469/in 776469/in/photostream /photostream//
incluso años.
