Metodologías tradicionales
Las metodologías tradicionales son denominadas, a veces, de forma peyorativa, como metodologías pesadas.
Centran su atención en llevar una documentación exhaustiva de todo el proyecto y en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.
Otra de las características importantes dentro de este enfoque, son los altos costes al implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es volátil.
Las metodologías tradicionales (formales) se focalizan en la documentación, planificación y procesos (plantillas, técnicas de administración, revisiones, etc.)
METODOLOGÍAS ÁGILES
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”.
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 el éxito o fracaso del
mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información
dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí
mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y
según esto ajusta su comportamiento.
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 el éxito o fracaso del
mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información
dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí
mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y
según esto ajusta su comportamiento.
· SCRUM5 [16]. 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, entre ellas destaca la reunión diaria de 15 minutos
del equipo de desarrollo para coordinación e integración.
· Crystal Methodologies6 [5].
Se trata de un conjunto de metodologías para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo y la reducción
al máximo del número de artefactos producidos. Han sido desarrolladas por
Alistair Cockburn. El desarrollo de software se considera un juego cooperativo
de invención y comunicación, limitado por los recursos a utilizar. El equipo de
desarrollo es un factor clave, por lo que se deben invertir esfuerzos en
mejorar sus habilidades y destrezas, así como tener políticas de trabajo en
equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose
una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal
Orange (25 a 50 miembros).
· Dynamic Systems Development
Method7 (DSDM) [17]. Define el marco para desarrollar un proceso de producción
de software. Nace en 1994 con el objetivo de crear una metodología RAD
unificada. Sus principales características son: es un proceso iterativo e
incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco
fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y
construcción, y finalmente implementación. Las tres últimas son iterativas,
además de existir realimentación a todas las fases.
· Adaptive Software Development8 (ASD) [9]. 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 Development9
(FDD) [3]. Define un proceso iterativo que consta de 5 pasos. Las iteraciones
son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación
del sistema partiendo de una lista de características que debe reunir el software.
Sus impulsores son Jeff De Luca y Peter Coad.
· Lean Development10 (LD) [15]. 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.
(2006 ) METODOLOGÍAS Y CICLOS DE VIDA, recuperado de URL http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.PDF
Canos, Joseh. Letelier, Patricio. Penades Ma. Carmen , Métodologías Ágiles en el Desarrollo de Software, Articulo recuperado de http://noqualityinside.com.ar/nqi/nqifiles/XP_Agil.pdf
No hay comentarios:
Publicar un comentario