Modelado Agil

AM es un conjunto de valores, principios y prácticas para el modelado , que se pueden aplicar en forma efectiva y ligera en un Proyecto desarrollo de software. Adaptándose de pleno a metodología como XP o SCRUM inclusive a RUP, en deesarrollo de proyectos de sistemas, con el objetivo de que estos realmente satisfagan sus necesidades.

Características

1. Satisface su propósito.
2. Es inteligible.
3. Es suficientemente preciso.
4. Es suficientemente consistente.
5. Es suficientemente detallado.
6. Aporta valor positivo.
7. Es lo más simple posible.

¿Que es y que no es AM?

1. AM es una actitud, no un proceso prescriptivo.
2. AM es un complemento a los métodos existentes, no es una metodología completa.
3. AM es una manera efectiva de trabajar en conjunto para alcanzar las necesidades de las partes interesadas en el proyecto.
4. AM es efectivo, y se trata sobre ser efectivo.
5. AM es algo que funciona en la práctica, no es una teoría académica.
6. AM no es una bala de plata.
7. AM es para el desarrollador promedio, más no es un sustituto de la gente competente.
8. AM no es un ataque a la documentación, de hecho AM aconseja la creación de documentos que tengan valor.
9. AM no es un ataque a las herramientas CASE.
10. AM no es para todos.

Objetivos de AM

1. Definir y mostrar como poner en práctica una colección de valores, principios y prácticas que conlleven a un modelado ligero efectivo.
2. Explorar la aplicación de técnicas de modelado en proyectos de software a través de un enfoque ágil, tal como XP, DSDM o SCRUM.
3. Explorar el como mejorar el modelado bajo procesos prescriptivos, tales como el Proceso Rational Unificado (RUP).

Los Valores de AM

• Comunicación.
• Coraje.
• Retroalimentación.
• Humildad.
• Simplicidad.

Los Valores de la Alianza Ágil

Además de los valores antes mencionados, la metodología de Modelado Ágil ha adoptado también los valores de la Alianza Ágil (AA) definidos en su manifiesto. Los valores de la AA:
1. Individuos e interacciones más que procesos y herramientas.
2. Software operante más que documentaciones completas.
3. Colaboración con el cliente más que negociaciones contractuales.
4. Respuesta al cambio más que apegarse a una rigurosa planificación.

Prácticas centrales de AM

Participación activa de todos aquellos que soportan el proyecto.

• Aplicar los artefactos correctos. Propiedad colectiva.
• Considerar la puesta a prueba del sistema.
• Crear varios modelos en paralelo.
• Crear contenidos simples.
• Representar los modelos de manera simple.
• Presentar los modelos públicamente.
• Iterar a otros artefactos.
• Modelar en pequeños incrementos.
• Modelas con otros.
• Demuéstrelo con código.
• Use las herramientas más simples.

Principios centrales de AM

• Asumir simplicidad.
• Bienvenido el cambio.
• Permitir el siguiente esfuerzo es el objetivo secundario.
• Cambio incremental.
• Maximizar la inversión de las partes interesadas en el proyecto.
• Modelar con un propósito.
• Múltiples modelos.
• Trabajo de calidad.
• Rápida retroalimentación.
• El software es el objetivo primario.
• Viaje con poco equipaje

Vivencias - Programación Extrema

Recuerdo que hace ya algún tiempo en el 2000 para ser exactos fue cuando por primera vez escuche de XP hasta ese entonces la curricula profesional “de línea”, en la universidad donde estudie como en otras del medio por no decir todas, solo se ocupo de aquellas metodología que hoy conocemos como tradicionales (RUP ). Quizá por que nadie hasta ese entonces tuvo el coraje (por cierto un valor de las metodologías ágiles), de abrirse mas en la investigación y explorar estas nuevas prácticas de desarrollo de software. Ignoro la verdad si en alguna universidad de mi querido Trujillo incluyan dentro de su curricula el estudio e investigación de metodologias ágiles como XP. Bueno el punto es que desde que lei acerca de XP me sorprendí por que a primera impresión se trataría de una nueva metodología mas no es así, si no mas bien es una nueva forma de desarrollar proyectos de sistemas, XP reúne muchas prácticas de las metodologías tradicionales. Lo curioso del caso es que de cierta forma y sin saberlo en la universidad realizábamos una de las prácticas que promueve XP “pair programming ”, muchas veces por que el número de alumnos doblábamos en número a las pcs en nuestro queridos COM1…COM8 y bueno pues de una manera casi obligados, nos teníamos que sentar de a dos y la pasábamos bien durante las 8 horas pedagógicas de laboratorio sin aburrirnos programando los ejercicios que nuestros queridos profesores nos los proponían, otra forma de programación en pares era cuando hacíamos los proyectos en casa, de MANUPRO (matemática numérica y programación), ORGARCO(organización de archivos), como olvidar TECPRO(técnicas de programación) y los proyectos de PROINFO (Proyectos Informáticos I II y III) y bueno en mi caso recuerdo que hasta ese entonces los que no teníamos pcs formábamos grupo con los que si tenían, aquellas horas de programación nos agrupábamos y nos sentábamos de a dos y aprendíamos o explicábamos lo que unos sabíamos y otros no claro cuando íbamos a la casa de Lizardo era por lo general para tomar el café que su mamá nos preparaba, y en la casa de Antonio para comer los juanes que sus viejos le enviaban de Amazonas. Tanto recuerdo ya me estoy saliendo del tema.

Bueno como verán de cierta forma realizábamos una de las practicas de XP (programación por pares).
Esta es una de las practicas más criticadas a XP. Lo cierto es que con Esta práctica se desarrolla nuevas costumbres y actitudes de programar. por ejemplo:

• Cuando estás programando con alguien más frente a la misma pc, es muy difícil distraerte en otras cosas como por ejemplo leer emails, atender el messenger, etc. (a no ser que no te importe que tu pareja se entere de tus asuntos personales).

• Se practica mejor la puntualidad como manera de respeto a tu pareja.

• Se introducen menos errores en el código.

• Cuando uno de los dos se cansa o se estanco con algo, el otro continua programando y no se detiene la generación de código.

• Se aprovechan las áreas de experiencia de cada persona y se intercambia el conocimiento. Por ejemplo: Si tu pareja domina CSS, haces que el/ella haga la hoja CSS muy rápidamente mientras tu observas y aprendes.
• Mientras programas tu pareja puede estar repasando las tareas que se están programando.

Así que antes de terminar mis estudios en la universidad convencí a uno de mis compañeros para profundizarnos en el tema así que luego de investigar proyectos en la vida real con uso de XP lo propusimos como tema principal para nuestra tesis de grado como resultado final de nuestra investigación proponemos un marco de trabajo en cuanto a modelado de un proyecto durante el ciclo de vida de XP, exactamente llevamos los principios y valores de Agile Modeling (Modelado Agil) a XP.

RAD

Seguramente muchos de nosotros hemos oido hablar de este tema,pero que es RAD(Rapid Application Development),Desarrollo Rápido de APlicaciones o Desarrollo Agil de Software (Metodologías Livianas). Bueno es un paradigma que aparece haciendo frente a las metodologías tradicionales("pesadas"), que se caracterizan por hacer uso de procesos basados en la planeación exhaustiva del problema esperando que el resultado en cada proceso sea determinante y predecible. La experiencia nos demuestra que vivimos en continuos cambios, y que como consecuencia de las caracaterísticas del software los resultados de los procesos no son siempre predecibles y otra cosa muy importantes es que se hace muy dificil predecir los resultados desde el comienzo del proyecto. Las metodologías ágiles por lo contrario basan sus fundamentos en la adaptabilidad de los procesos mediante el uso de ciertas prácticas como las entregas funcionales,documentar lo necesario, se considera que lo más importante es el código antes que documentar. Las metodologías ágiles no estan en contra, como se endiende muchas veces,de las metodologías tradicionales más bien por el contrario promueven por medio de sus prácticas la formalización de procesos adaptables. De ahi que se puede afirmar que las metodologías ágiles son adaptables en lugar de predictivos,estan orientadas a la gente antes que los procesos. dentro de estas medotodologías podemos mencionar:

1. XP Programación Extrema
2. Scrum
3. Crystal Evolutionary Project Magnagament (EVO)
4. Fature Driven Development (FDD)

Entre otros siendo la más popular y usada la primera propuesta y fundamentada por Kent Beck.