Metodologías ágiles: qué son y para qué sirven

Framework

Se aplica un framework de evaluación

para las metodologías ágiles de desarrollo, porque permite evaluar si las metodologías ágiles satisfacen los principios básicos definidos, su

utilización es recomendada al momento de decidir una metodología a adoptar.

Es una Evaluación de Metodologías Ágiles

¿Qué es?

Básicamente con la colaboración de usuarios

de software durante el proceso de desarrollo de un producto la facilidad que

ofrecen para de adaptar el producto a cambios en requerimientos.

¿Cómo funciona?

Estos procesos, denominados

tradicionales, han demostrado ser efectivos en proyectos de gran tamaño,

particularmente en lo que respecta a la administración de recursos a utilizar y

a la planificación de los tiempos de desarrollo. Sin embargo, el enfoque

propuesto por estos métodos no resulta el más adecuado para el desarrollo de

proyectos donde los requerimientos del sistema son muy cambiantes, se pide

reducir drásticamente los tiempos de desarrollo y al mismo tiempo producir un

producto de alta calidad. Como alternativa a los métodos tradicionales de

desarrollo, surgen las Metodologías Ágiles, (The Agile Alliance), dedicada a

promover los conceptos relacionados con el desarrollo ágil de software y ayudar

a las organizaciones a adoptar dichos conceptos, manteniendo prácticas

esenciales de las metodologías tradicionales, las metodologías ágiles se

centran en otras dimensiones del proyecto.

Manifiesto Ágil

¿Para qué sirve?

Los procesos

Metodologías Ágiles de Desarrollo

Surgen

El Manifiesto Ágil incluye cuatro postulados y una serie de

principios asociados.

Dynamic Systems

Development Method (DSDM). - Cumple con las características generales de

definir un proceso iterativo e incremental. Propone cinco etapas de desarrollo:

Estudio de Viabilidad, Estudio del Negocio, Modelado Funcional, Diseño y

Construcción, e Implementación. La iteración se produce en las tres últimas

etapas, sin embargo, prevé retro-alimentación en todas.

1) Valorar al individuo y a las interacciones del equipo de

desarrollo por encima del proceso y las herramientas. Tres premisas sustentan

este principio: a) los integrantes del equipo son el factor principal de éxito

de un proyecto; b) es más importante construir el equipo de trabajo que

construir el entorno; y c) es mejor crear el equipo y que éste configure el

entorno en base a sus propias necesidades.

2) Valorar el desarrollo de software que funcione por sobre

una documentación exhaustiva. El principio se basa en la premisa que los

documentos no pueden sustituir ni ofrecer el valor agregado que se logra con la

comunicación directa entre las personas a través de la interacción con los

prototipos. Se debe reducir al mínimo indispensable el uso de documentación que

genera trabajo y que no aporta un valor directo al producto.

3) Valorar la

colaboración con el cliente por sobre la negociación contractual. En el

desarrollo ágil el cliente se integra y colabora con el equipo de trabajo como

un integrante más. El contrato en sí no aporta valor al producto, es sólo un formalismo

que establece líneas de responsabilidad entre las partes.

4) Valorar la respuesta al cambio por sobre el seguimiento

de un plan. La evolución rápida y continua deben ser factores inherentes al

proceso de desarrollo. Se debe valorar la capacidad de respuesta ante los

cambios por sobre la capacidad de seguimiento y aseguramiento de planes

pre-establecidos.

Feature-Driven Development (FDD). -Define un proceso iterativo, con iteraciones cortas de dos semanas como máximo. El ciclo de vida consta de cinco pasos: a) Desarrollo de un modelo global, b) Construcción de una lista de funcionalidades, c) Planeación por funcionalidad, d) Diseño por funcionalidad y e) Construcción por funcionalidad.

Programación Extrema (XP). -Define un proceso iterativo e incremental con pruebas unitarias continuas y entregas frecuentes. El cliente o un representante del cliente son integrados al equipo de desarrollo. Recomienda que el desarrollo de las funciones del producto sea realizado por dos personas en el mismo puesto, programación por pares. Antes de incorporar nueva funcionalidad, se deben corregir todos los defectos encontrados. Constantemente, se llevan a cabo pruebas de regresión a fin de detectar los posibles errores.

Cristal Methodologies. - Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por la valoración a las personas que componen el equipo de trabajo y la reducción al máximo del número de artefactos producidos. Enfatiza en esfuerzos para mejorar las habilidades de los integrantes del equipo y para definir políticas de trabajo en equipo. Las políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo, Crystal Clear corresponde a equipos con 3 a 8 integrantes y Crystal Orange en equipos con 25 a 50 integrantes.

Adaptive Software Development (ASD). -Es un proceso iterativo, tolerante a cambios y orientado a los componentes de software. Define tres etapas para el ciclo de vida: a) Especulación=se inicia el proyecto y se planifican las características del software; b) Colaboración=se desarrolla el producto; y c) Aprendizaje=se revisa la calidad del producto y se entrega al cliente. La revisión tiene como objetivo aprender de los errores cometidos y volver a iniciar el ciclo de desarrollo.

Scrum. -

Indicada para proyectos con alto ratio de cambio de requerimientos, su

principal característica es la definición de sprints, cada una de las

iteraciones del proceso con una duración máxima de 30 días. El resultado de

cada sprint es un incremento ejecutable que se muestra al cliente. Otra

característica importante son las reuniones diarias que se llevan a cabo a lo

largo del proyecto. Dichas reuniones no requieren más de 15 minutos del equipo

de desarrollo y su objetivo son la coordinación e integración del producto a

entregar.

La metodología respeta el ciclo de

vida evolutivo y la entrega incremental. Al comienzo del proyecto, se

identifican los requerimientos funcionales y no funcionales y se conforma una

lista de los mismos llamada product backlog. El product backlog constituye el

artefacto base para medir el avance del proyecto. Las iteraciones, denominadas

sprints entregan partes del producto llamadas builds. Cada iteración comienza

con una planificación adaptativa guiada por el cliente y culmina con una

demostración del build al cliente. Cada sprint puede durar como máximo 30 días.

En cada sprint, el equipo de desarrollo selecciona del product backlog un

conjunto de ítems de mayor prioridad que se convierte en el objetivo a

desarrollar. La metodología propone las siguientes tres fases: 1) Fase de

Planeamiento, es subdividida en: a) Planeación, y b) Diseño Arquitectónico, 2)

Fase de Desarrollo, 3) Fase de Finalización, incluye integración, testing y

documentación. La metodología propone la creación de equipos de trabajo

auto-dirigidos y auto-organizados, aconsejando equipos pequeños que maximizan

la comunicación entre sus integrantes, se identifican roles como el Scrum

Master, responsable de asegurar que el proyecto se ejecute en base a las

prácticas, valores y reglas de Scrum; el Dueño del Producto, responsable del

proyecto, administra, controla y mantiene y publica el product backlog; los miembros

del equipo, tienen la autoridad para decidir acerca de las acciones a realizar

y organizarlas de tal manera de alcanzar los objetivos de cada sprint, y el cliente,

participa de las tareas relacionadas con la lista de requerimientos del

producto a desarrollar, aporta ideas, sugerencias y nuevas necesidades. Scrum

prevee las siguientes prácticas: o Reunión de Planeamiento del Sprint, organizada

por el Scrum Master, se divide en dos etapas. En la primera etapa se reúnen los

clientes, el dueño del producto y los miembros del equipo para decidir sobre

los objetivos y funcionalidad del nuevo sprint. La segunda etapa de la reunión

se realiza entre el Scrum Master y el equipo de trabajo y se concentra en cómo

el incremento del producto será implementado durante el proceso. Los

requerimientos son seleccionados por el equipo de trabajo, en conjunto con el

Scrum Master y el propietario del producto en la reunión de planeamiento del

sprint. Cuando todos los ítems del sprint se completan, se entrega una nueva

iteración del sistema, dirigida por el Scrum Master. Se organizan básicamente

para mantener una revisión constante del avance del proyecto. Los integrantes

responden a tres preguntas: 1) ¿Qué se ha logrado completar desde la última

reunión?, 2) ¿Qué obstáculos o problemas se han detectado ?, y 3) ¿Qué

funciones del backlog planea completar para la próxima reunión?, el equipo de

trabajo y el Scrum Master presentan los resultados del sprint al cliente, se

analizarán y se aplicarán los ajustes y cambios necesarios cuando corresponda,

se destacarán los aspectos positivos y se tratará de cambiar aquellos aspectos

negativos, para no repetirlos en el siguiente sprint.

El éxito de la metodología se basa

en potenciar las relaciones interpersonales, promoviendo el trabajo en equipo,

el aprendizaje de los desarrolladores, y un ambiente de trabajo cordial. Los

cinco principios básicos de XP incluyen: 1) Simplicidad; 2) Comunicación; 3)

Retro-alimentación; 4) Coraje; y 5) Respeto. Los desarrolladores no pueden

realizar cambios que hagan que las pruebas existentes fallen o que demore el

trabajo de compañeros, y hacia el trabajo, los miembros del equipo tienen como

principal objetivo lograr un producto de alta calidad con un diseño óptimo. El

proceso de desarrollo consiste de tres etapas: 1) Interacción con el cliente, el

cliente interactúa permanentemente con el equipo de trabajo. Se elimina así la

fase inicial de recolección de requerimientos, y éstos se van incorporando de

manera ordenada a lo largo del desarrollo. La metodología propone utilizar la

técnica de Historias de Usuario mediante la cual el usuario especifica los

requerimientos funcionales y no funcionales del producto. 2) Planificación del

Proyecto, el equipo de trabajo estima el esfuerzo requerido para la

implementación de las Historias de Usuario. Cada historia debe ser implementada

en un período de una a tres semanas. Aquellas historias que requieran más

tiempo se sub-dividen tratando de que resulten atómicas y puedan realizarse

dentro del plazo máximo. 3) Diseño y Desarrollo de Pruebas, la implementación

está conducida por las pruebas unitarias. Cada vez que se quiere implementar

una función, primero se debe definir el test y luego el código para que lo

satisfaga. Una vez que el código cumple el test exitosamente, se amplía y se

continúa. XP fomenta la programación por pares, donde el desarrollo es

realizado por una pareja de programadores. Las parejas tienen que ir cambiando

de manera periódica, para que el conocimiento sea adquirido por todo el grupo

de desarrollo. Los integrantes del equipo incluyen el Programador, encargado de

escribir pruebas unitarias y producir el código; el Cliente, escribe Historias

de Usuario y pruebas funcionales; el Tester, es el responsable de las pruebas,

ayuda al cliente a escribir las pruebas funcionales, las ejecuta, informa los

resultados al resto del equipo y mantiene la herramienta de soporte que se

utiliza para llevar a cabo las pruebas; el Encargado de Seguimiento (tracker), proporciona

retro-alimentación al equipo, verifica el grado de acierto de las estimaciones

y controla el avance del proyecto; Entrenador (coach), es responsable del

proceso en su totalidad, guía al equipo de manera que se respeten las prácticas

XP y que el proceso se ejecute correctamente; El Consultor, es un miembro

externo al equipo con conocimientos específicos en algún tema, necesario para

resolver problemas que surjan durante el proyecto; y el Gestor (big boss), es

el vínculo entre el cliente y los desarrolladores, ayuda a que el equipo

trabaje efectivamente. Su principal tarea es la coordinación. XP define las

siguientes prácticas: Juego de Planificación, o Refactorización o Programación

por pares, o Integración continua, o Cliente in-situ, el cliente debe estar

presente y disponible todo el tiempo.

A detalle

A detalle