1

Metodologías ágiles Práctica 3

#AESMultimedia - aesmultimedia.blogspot.com

José Luís Contreras Martínez @DkLawis Ana García Domene @agado92

Daniel Martínez Espadas @danielme91 Begoña Morillas Guijarro @begomori

2

Índice

Introducción a las metodologías ágiles DSDM: Dynamic Systems Development Method FDD: Feature Driven development Crystal: (Crystal Clear) AUP: Agile Unified Process Análisis comparativo Bibliografía

3

Introducción a las metodologías ágiles

Las metodologías ágiles surgen a principios de los 90 ante ciertos problemas de tiempo, costo y calidad en el desarrollo de creación de software.

Este nuevo enfoque de desarrollo se dio a conocer como RAP (Rapid Application Development). En él, el trabajo se organizaba en pequeños grupos de trabajo de alto rendimiento.

Las metodologías ágiles se inician con la creación del eXtreme programming o XP que

impulsa el desarrollo mediante iteraciones, aunque éstas ya se utilizaban anteriormente.

También destacamos que estos ciclos son cortos intervalos de tiempo, de una a cuatro

semanas, lo que favorece la minimización de riesgos. Actualmente existen diversas

metodologías ágiles que se fueron basando en los principios de esta metodología.

Imagen 1: Desarrollo ágil de software

A continuación estudiaremos cuatro de las metodologías ágiles más destacadas del

momento: DSDM – Dynamic Systems Developmemt Method, Crystal (Crystal Clear), FDD –

Feature Driven Development y AUP: Agile Unified Process.

4

DSDM: Dynamic Systems Development Method

Esta metodología surge de un consorcio en Reino Unido. Su primera versión aparece en 1994, posteriormente se han realizado varias versiones.

Situada dentro de las RAD, DSDM es excelente para proyectos de sistemas de la información con presupuestos limitados y agendas muy ocupadas y apretadas.

Características

Los proyectos tendrán las siguientes características que refieren a la aplicabilidad de

DSDM:

- Proyectos interactivos con funcionalidad visible en la interfaz de usuario

- De baja o media complejidad computacional.

- Particionables en componentes de funcionalidad más pequeños si la aplicación es de gran tamaño, cuentan con flexibilidad en los requerimientos.

- Une técnicas de desarrollo y gestión del proyecto en una misma metodología que se centra en conseguir un producto que funcione correctamente en los casos más críticos.

- Trabajo en equipo tanto los desarrolladores, los usuarios y los Stakeholders. Con un grupo de usuarios bien definidos y comprometidos al proyecto.

- El equipo de desarrollo toma decisiones sin depender de autorizaciones de sus superiores para realizar entregas, siempre cortas, de forma frecuente, siendo éstas funcionales. Ésto es adecuado al tener el tiempo total acotado, por lo que previene que transcurra mucho tiempo y la tecnología cambie.

- El desarrollo es iterativo e incremental.

- Todos los cambios pueden ser revertibles y son verificados durante todo el desarrollo.

Roles

Esta metodología define 15 roles para usuarios y desarrolladores, a continuación se

describen los más destacados.

Desarrollador y desarrollador senior (developer and senior developer) Son los únicos roles definidos para desarrolladores, por esto este rol incluye a todo el personal de desarrollo, sean diseñadores, analistas, programadores o testers. La diferencia entre desarrollador y desarrollador senior es que los segundos tienen gran experiencia en las tareas que realizan, por lo que suelen dirigir el equipo.

Coordinador técnico (Technical coordinator) Responsable tanto de la calidad técnica como del control técnico del proyecto,

por ejemplo el uso de software de gestión de configuración y el cumplimiento de

estándares técnicos. Está encargado de mantener la arquitectura.

Usuario embajador (Ambassador user).

5

Equivale al on-site customer de XP. El usuario embajador debe ser miembro del grupo de usuarios, que espera utilizar el sistema, pues este rol tiene como función aportar el conocimiento de este grupo al proyecto y difundir información de los avances del proyecto al resto de usuarios. De esta forma se asegura una correcta retroalimentación de los usuarios. se ofrece conocimiento del negocio y define los requisitos del software.

Asesor de usuario (Adviser user). Consejero del usuario embajador. Este rol se emplea cuando el rol de usuario embajador no es suficiente para expresar todas las opiniones o puntos de vista importantes de los usuarios sobre un punto del proyecto.

Visionario (Visionary). El trabajo del visionario es el encargado de asegurar que se satisfacen las

necesidades de negocio, es decir, que desde el principio, los requisitos esenciales

se encuentran y que el proyecto sigue la dirección correcta para cumplir dichos

requisitos. Es el rol con la visión más precisa sobre los objetivos del negocio del

sistema y del proyecto y probablemente aquel que tiene la idea inicial de la

construcción del sistema.

Patrocinador ejecutivo (Executive sponsor).

Es el rol de la organización de usuario que tiene la autoridad y responsabilidad

financiera relacionada al proyecto, por lo tanto tiene el máximo poder en la toma de

decisiones.

Director de proyecto (Project Manager).

Es responsable de entregar los productos acordados de forma exitosa, al acordado standar de calidad, a tiempo y dentro del presupuesto. Además de ser capaz de entregar los beneficios estipulados en el PID. El director del proyecto puede venir de IT o de la comunidad de usuarios, e informa a la Junta del Proyecto.

Artefactos

Podemos describir los artefactos obtenidos mediante la metodología DSDM a través de las distintas fases que lo forman.

Fase 1. Estudio de viabilidad.

- Informe de viabilidad. Análisis de viabilidad del proyecto - Esbozo del plan para el desarrollo. Planteamiento del desarrollo del proyecto a grandes rasgos. - Listado de riesgos. Lista con los riesgos que puede ofrecer el sistema. - Prototipo rápido. Es un artefacto opcional, sólo aparecerá si no se conoce lo suficiente el negocio o tecnología.

Fase 2. Estudio de la empresa.

- Descripción de los procesos de negocio y especificación de casos de uso. La

identificación de los casos de uso ayuda a involucrar al cliente.

6

- Documento de Especificación de Requerimientos de Software (SRS). Descripciones a alto nivel de los requisitos que se presentan en formato correcto diagramas ER, modelos de negocio objetivos, etc. - Definición de la arquitectura del sistema. Es un primer borrador de la arquitectura que puede cambiar durante el desarrollo del proyecto. - Esbozo del plan de prototipado. Debe declarar la estrategia de prototipado para las siguientes fases y un plan para la configuración de la administración.

Fase 3. Iteración del modelo funcional.

- Modelo funcional. Contiene el código prototipo y los modelos de análisis - Casos de prueba. Pruebas a realizar a código. - Funciones prioritarias. Lista de prioridades de las funciones que se entregan al final de la iteración. - Resumen de los documentos de prototipos funcionales. Recoge los comentarios de los usuarios sobre el incremento actual, servirá de artefacto de entrada para las siguientes iteraciones. - Requisitos no funcionales. Lista de requisitos que se tratarán en la siguiente fase. - Análisis de riesgos de desarrollo superior. Documento de gran importancia en esta fase, pues, a partir de la siguiente fase, los errores encontrados serán más difíciles de ubicar y dirigir.

Fase 4. Diseño e iteración de la estructura.

- Sistema probado. Debe cumplir al menos los requisitos mínimos acordados.

Fase 5. Implementación.

- Sistema entregado. Sistema finalizado y entregado al cliente. - Manual de usuario. Instrucciones de uso del sistema. - Informe de revisión de proyecto. Resume el resultado del proyecto. Según los

resultados, se establece el curso del desarrollo adicional.

Prácticas

Dado el enfoque hacia proyectos de características RAD, la ideología de la metodología

DSDM se define en nueve principios:

1. Involucrar al usuario es la base para obtener un proyecto eficiente y efectivo.

Cliente y desarrolladores comparten entorno de trabajo para mejorar la precisión de las

decisiones.

2. Los equipos de DSDM deben tener poder de toma de decisiones. Es importante que se puedan tomar decisiones para el desarrollo del proyecto sin esperar la aprobación de superiores

3. El foco está puesto en la entrega frecuente de productos. Esto permite una verificación y revisión continua del producto desde el principio.

4. La conformidad con los propósitos del negocio es el criterio esencial para la

aceptación de los entregables.

7

DSDM se centra en las funcionalidades críticas del proyecto, no en todas sus posibles

necesidades.

5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta

solución del negocio.

Se basa en la retroalimentación de os usuarios para dirigirse hacia una solución precisa.

6. Todos los cambios durante el desarrollo son reversibles. Saber dónde estamos en cada momento para tener la posibilidad de deshacer y probar otro camino si el elegido no funciona.

7. Los requerimientos están especificados a un alto nivel. Alcance de alto nivel y requisitos deben ser „base-lined‟ desde el inicio del proyecto.

8. El testing es integrado a través del ciclo de vida. Durante todo el ciclo de vida se realizan pruebas para evitar costes extraordinarios en mantenimiento y arreglos del sistema.

9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. La colaboración y cooperación entre el equipo, usuarios y stakeholders es esencial para un correcto desarrollo del proyecto.

Aparte de estos principios, DSDM también se basa en una serie de consideraciones muy importantes:

Ningún sistema es construido a la perfección en el primer intento. La entrega del proyecto deberá ser a tiempo, respetando presupuesto y asegurando la

calidad. DSDM solo requiere que se complete cada paso que forma una iteración con la

funcionalidad suficiente como para que inicie el siguiente paso de la siguiente iteración. DSDM puede utilizarse en proyectos de ampliación de sistemas TI pero también podría

utilizarse para proyectos de cambio de algún sistema aunque no sea TI. La evaluación de riesgo debe estar enfocada en entregar funcionalidad de negocio y no

en el proceso de desarrollo. La estimación debe estar basada en funcionalidad del negocio no en líneas de código. La gestión recompensa la entrega continua de productos antes que la consecución de

tareas.

Proceso

DSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planes

según las necesidades de la empresa. Para alcanzar sus metas, DSDM favorece el uso del

RAD con el consecuente riesgo de que demasiadas partes estén sin definir correctamente y

esto lleve a errores.

DSDM aplica algunos principios, roles, y técnicas en las 5 fases en las que define la

construcción de un sistema:

1. Estudio de viabilidad: Estudia la factibilidad del proyecto en una pequeña fase que

propone DSDM para determinar si la metodología se ajusta éste. se realiza un

estudio de los requisitos humanos materiales y financieros y los problemas de la

empresa o el cliente.

8

2. Estudio de la empresa: Durante el estudio del negocio se involucra al cliente para

tratar de entender la operatoria que el sistema deberá automatizar. Este estudio

sienta las bases para iniciar el desarrollo, definiendo las características de alto nivel

que deberá contener el software, es decir, planifica la base de las actividades de la

empresa.

3. Iteración del modelo funcional: Se inician las iteraciones en las que se describirán

en detalle las características definidas en la fase anterior, planteando un modelo

previo que de solución aceptable a la problemática. Esta es la etapa de diseño.

4. Diseño e iteración de la estructura: Se realizará el diseño de los mismos

codificando el modelo diseñado, se construirán los componentes de software, se

prueba paralelamente la calidad del producto y se documenta el manual de usuario y

técnico.

5. Implementación: Entrega del producto al cliente o usuario final. Cuando éste de su

aprobación se implantará el sistema en producción.

La primera y segunda fase son secuenciales y, por lo tanto, realizadas una única vez al

principio del proyecto para analizar la factibilidad desde el punto de vista del negocio del

desarrollo, las demás fases presentan las características del modelo iterativo e incremental

ya tratado.

Imagen 2. Diagrama de procesos de DSDM

DSDM aproxima las iteraciones como “timeboxes”. Una “timebox” dura un periodo

predefinido de tiempo y la iteración debe finalizar dentro de la “timebox” que suele durar

desde unos días hasta unas pocas semanas.

9

Sin embargo, lo que diferencia a DSDM de otros modelos son los principios alrededor de los

cuales se estructura, tratados en el apartado anterior, y que hacen énfasis en los equipos de

desarrollo, en el feedback con el cliente y en las entregas frecuentes de productos.

Posibles integraciones

Es posible integrar DSDM con otros métodos para complementar el desarrollo del proyecto. Entre ellos tenemos el Proceso Unificado de Rational (RUP), Programación Extrema (XP), y Proyectos en ambientes controlados (PRINCE2), Otro método ágil que tiene semejanzas proceso y concepto con DSDM es Scrum.

Entre DSDM y RUP se puede crear una fuerte unión, RUP podría considerarse una

implementación de DSDM. RUP está más orientado a la arquitectura y a la calidad y DSDM

tiene como objetivo el desarrollo rápido de aplicaciones, sin embargo, esto no impide

combinarlos, incluso se pueden relacionar todas las fases y artefactos de RUP con los de

DSDM. Al combinarse podemos obtener un sistema con una arquitectura fuertemente

definida en un tiempo récord.

10

FDD: Feature Driven development

Es un proceso ágil diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Se basa en un

proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y

la dirección de la empresa pueden ver y monitorizar. Estas iteraciones se deciden en base a

features o funcionalidades, que son pequeñas partes del software con significado para el

cliente.

A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases de diseño y construcción. No requiere un modelo específico de proceso y se complementa con otras metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso.

Características

FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el

sistema. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y una salida.

Desarrollo de un modelo general: Cuando comienza el desarrollo, los expertos de dominio

están al tanto de la visón, el contexto y los requerimientos del sistema a construir. A esta

altura se espera que existan requerimientos tales como casos de uso o especificaciones

funcionales. Los expertos de dominio presentan un ensayo más en el que los miembros del

equipo y el arquitecto jefe se informan de la descripción de alto nivel del sistema.

El dominio general se subdivide en áreas más específicas y se define un ensayo más

detallado para cada uno de los miembros del dominio. Luego, un equipo de desarrollo

trabaja en pequeños grupos para producir modelos de objetos de cada área de dominio.

Simultáneamente, se construye un gran modelo general para todo el sistema.

Construcción de la lista de rasgos: Los ensayos, modelos de objeto y documentación de

requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos

son pequeños ítems útiles a los ojos del cliente. La lista de rasgos es revisada por los

usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que

requieran de más de diez días se descomponen en otros más pequeños.

Planeamiento por rasgos: Incluye la creación de un plan de alto nivel, en el que los

conjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y se

asigna a los programadores jefes.

Diseño por rasgos y Construcción por rasgos: Se selecciona un pequeño conjunto de

rasgos del conjunto, y los propietarios de clases seleccionan los correspondientes equipos

dispuestos por rasgos. Se procede luego iterativamente hasta que se producen los rasgos

seleccionados. Una iteración puede tomar de unos pocos días un máximo de dos semanas.

El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración

e inspección de código.

11

Miremos una representación gráfica del proceso iterativo que involucran estas dos últimas fases:

Imagen 3. Flujo de los procesos en FDD

Roles

Key Roles / Roles claves

Project Manager / Director del Proyecto: Es el líder administrativo y financiero del

proyecto. También protege al equipo de situaciones externas.

Chief Architect / Arquitecto jefe: Se encarga del diseño global del sistema y de la

ejecución de todas las etapas.

Development Manager / Director de desarrollo: Lleva diariamente las actividades

de desarrollo, resuelve conflictos en el equipo y resuelve problemas referentes a

recursos.

Chief Programmer / Programador Jefe: Analiza los requerimientos, diseña el

proyecto y selecciona las funcionalidades a desarrollar de la última fase del FDD.

Class Owner / Propietario de clases: Responsable del desarrollo de las clases

que se le asignaron como propias. Participa en la decisión de que clase será

incluida en la lista de funcionalidades de la próxima iteración.

Expertos de dominio: Puede ser un usuario, un cliente, analista o una mezcla de

estos. También poseen el conocimiento de los requerimientos del sistema. Y pasa

el conocimiento a los desarrolladores para que se asegure la entrega de un sistema

completo.

Supporting Roles / Roles de soporte

Domain Manager: Lidera al grupo de expertos del dominio y resuelve sus

diferencias de opinión concernientes a los requerimientos del sistema.

12

Release Manager: Controla el avance del proceso mediante la revisión de los

reportes del Chief Programmer. Y reporta resultados obtenidos semanalmente al

gerente, al cliente donde incluye el porcentaje de avance de cada feature.

Language Lawyer / Guru del Lenguaje: Es el responsable de poseer un vasto

conocimiento en, por ejemplo, un lenguaje específico de programación o

tecnología. Este rol es fundamental cuando se trabaja una nueva tecnología.

Build Engineer / Ingeniero de construcción: Es el responsable de preparar,

mantener y correr el proceso de construcción. También realiza el mantenimiento de

las versiones y la publicación de la documentación.

Toolsmith / Herramentista: Construye herramientas específicas para el desarrollo,

conversión de datos y testeo. Puede trabajar en la preparación y mantenimiento

tanto de bases de datos o sitios web destinados al proyecto.

System Administrator / Administrador del sistema: Configura, administra y

repara los servidores, estaciones de trabajo y equipos de desarrollo y testeo

utilizados por el equipo.

Additional Roles / Roles adicionales

Tester: Verifica que el sistema recién creado cumpla con los requerimientos del

cliente. Y puede llegar a ser una persona independiente del equipo del proyecto.

Deployer: Es el encargado de convertir la información existente requerida por el

nuevo sistema. Participa en el lanzamiento de los nuevos productos.

Technical Writer / Escritor de documentos técnicos: Prepara documentación

para los usuarios, que pueden formar parte o no del equipo del proyecto.

Artefactos

El Release Manager se reúne con los Chief Programmers para que éstos reporten como es

el avance de las tareas. En esta reunión, que tiene una duración de 30 minutos o menos,

cada Chief Programmer informa de manera verbal el avance de sus features. Hacer esto de

forma verbal es bueno para que cada uno de los Chief Programmers se tome el tiempo de

escuchar a los otros y saber dónde están situados los demás en el proceso de desarrollo.

Al final de la entrevista, el release manager anota los resultados, actualiza la base de datos y genera los reportes.

El release manager reporta los resultados obtenidos semanalmente, tanto para el equipo,

para el cliente y para el Project Manager. Para los clientes y los gerentes, el reporte debe

incluir el porcentaje de avance de cada feature. Para el equipo se informa cual es el

desempeño del mismo.

Prácticas

FDD consiste en establecer "mejores prácticas" y los desarrolladores del método argumentan que a pesar de que las prácticas seleccionadas no son nuevas, la mezcla específica de estos ingredientes hacen a los cinco procesos FDD únicos para cada caso. Palmer y Felsing también argumentan que todas las prácticas disponibles deben ser utilizadas para obtener el mayor beneficio del método y no que una única práctica domine todo el proceso (2002). FDD consiste en las siguientes prácticas:

13

Dominio de modelado de objetos: exploración y explicación del dominio del problema. Los resultados se dan en un marco donde las características se añaden.

El desarrollo por función: El cliente valora las funciones, desarrollando y siguiendo los progresos a través de una lista de pequeñas funcionalidades descompuestas.

Propiedad de clase individual (código): Cada clase tiene una sola persona elegida

para ser la responsable de la consistencia, rendimiento e integridad conceptual de la

clase.

Características de los equipos: Se refiere a pequeños equipos formados

dinámicamente.

Inspección: Se refiere a la utilización de los mecanismos de detección de defectos

más conocidos.

Construcciones regulares: se refiere a asegurar que siempre hay un sistema en

funcionamiento, demostrable y disponible. Las construcciones regulares forman la

línea base a la que se añaden nuevas funciones.

Gestión de la configuración: Permite la identificación y el seguimiento histórico de las

últimas versiones de cada archivo de código fuente completo.

Los informes de progreso: Se informa del progreso basado en el trabajo completado

a todos los niveles organizativos necesarios.

El equipo del proyecto debe poner todas las prácticas anteriores en uso con el fin de cumplir

con las normas de desarrollo del FDD. Sin embargo, al equipo se le permite adaptarlas de

acuerdo a su nivel de experiencia.

14

Crystal: (Crystal Clear)

Crystal es una metodología de desarrollo de software ágil, aunque más bien se la considera un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que forman parte del equipo y en la reducción al máximo del número de artefactos producidos.

El equipo de desarrollo se considera un factor clave en esta metodología, por lo que se

deben invertir esfuerzos en mejorar las habilidades y destrezas, así como tener políticas

de trabajo en equipo bien definidas. Estas políticas dependerán del número de personas

que formen el equipo, estableciéndose una clasificación por colores, por ejemplo Crystal

Clear (3 a 8 personas, es decir proyectos pequeños) y Crystal Orange (25 a 50 personas).

En este trabajo se hablará en concreto de Crystal Clear.

Características

Las seis características o propiedades de Crystal Clear son las siguientes:

1. Entrega frecuente. Se trata de entregar software a los clientes de forma frecuente,

no solamente cuando el proyecto está acabado. La frecuencia dependerá del

proyecto, puede ser diaria, semanal o mensual. Lo importante es mantener

informado al cliente del estado del sistema.

2. Comunicación osmótica. Todos los miembros del proyecto deben estar juntos en

la misma habitación.

3. Mejora reflexiva. Disponer de un tiempo breve (unas pocas horas cada ciertas

semanas o una vez al mes) para observar bien el progreso, cotejar ideas y notas,

reflexionar y discutir.

4. Seguridad personal. Cuando hay alguna inquietud o problema en el equipo,

hablarlo para solucionarlo.

5. Foco. Siempre se debe tener claro lo que se está haciendo en cada momento del

proyecto, tener el tiempo y la tranquilidad necesaria para llevarlo a cabo.

6. Fácil acceso a usuarios expertos. Disponer de ayuda y consejo de desarrolladores

expertos y con experiencia en proyectos similares.

Roles y artefactos

El patrocinador se encarga de conseguir recursos y de definir el proyecto general.

Produce un sólo artefacto: la Misión con Prioridades de Compromiso.

El equipo como Grupo es responsable de producir dos artefactos:

Estructura y los Convenios del Equipo

Resultados del Taller de Reflexión

El coordinador, junto con el equipo, es responsable de la producción de:

Mapa de proyecto.

Plan de Lanzamiento

Estado del proyecto

Lista de riesgos

15

Plan de Iteración y Estado

Visualización del Calendario

El experto en negocios y el usuario experto; el primero debe conocer las reglas y

políticas de la empresa; el segundo debe familiarizarse con el uso del software,

sugerir mejoras e ideas, en definitiva, implementar una buena interfaz de cara a los

usuarios finales. Juntos son responsables de producir los siguientes artefactos:

Lista de Actores-Objetivos

Archivos de Casos de Uso y Requerimientos

Modelo del Rol de Usuario

El diseñador jefe es el responsable de producir la Descripción de la Arquitectura.

El diseñador-programador, junto con el diseñador jefe, son los responsables de los

siguientes artefactos:

Borradores de Pantallas

Modelo Común de Dominio

Bocetos de Diseño y Notas

Código Fuente

Código de Migraciones

Pruebas

Empaquetación del Sistema

Como curiosidad, en la metodología Crystal Clear no tiene cabida un diseñador que

no programe.

El verificador (tester) se encargará de producir Informes de Errores de última

hora.

Por último, el escritor producirá el Manual de Ayuda para el Usuario.

Proceso

En lugar de la interpretación lineal de los modelos clásicos, que es interpretada en muchos casos como inconvenientes, Cristal Clear enfatiza el proceso como un conjunto de ciclos anidados.

En la mayoría de los proyectos se perciben siete ciclos:

1. El proyecto en sí. 2. El ciclo de entrega de una unidad. 3. La iteración (nótese que CC requiere múltiples entregas por proyecto pero no

muchas iteraciones por entrega). 4. La semana laboral. 5. El período de integración, de 30 minutos a tres días. 6. El día de trabajo. 7. El fragmento de desarrollo de una sección de código, de pocos minutos a pocas

horas.

16

Imagen 4. Ciclos anidados de Crystal Clear

Prácticas

En cuanto a las prácticas o técnicas que se favorecen dentro de esta metodología, podemos mencionar las siguientes:

1. Entrevistas de proyectos. Es costumbre entrevistar a más de un responsable para tener visiones más enriquecedoras y variadas.

2. Talleres de reflexión. El equipo debe descansar de treinta minutos a una hora para reflexionar, discutir sobre posibles problemas y mejoras y organizarse de cara a la siguiente etapa.

3. Planeamiento „Blitz‟. Técnica equivalente al Juego de Planeamiento de XP. Se ponen tarjetas enumeradas en la mesa, con una historia de usuario o función visible en cada una. El grupo simula que no hay dependencias entre ellas, y se alinean en secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo estimado para desarrollar cada función. El patrocinador escribe el orden de prioridades, teniendo en cuenta los tiempos y el valor de negocio de cada función. Las tarjetas se agrupan en iteraciones que se agrupan a su vez en entregas, normalmente no más largas de tres meses.

4. Estimación Delphi con estimaciones de pericia. Se reúnen los expertos y proponen el tamaño del sistema, su tiempo de ejecución, la fecha de entregas y equilibrarlas entregas en paquetes de igual tamaño.

5. Encuentros diarios de pie. Deben ser muy breves, de 5 a 10 minutos. Se trata únicamente de identificar problemas y no de debatir.

6. Miniatura de procesos. Para que así la gente pueda disfrutar de esta metodología sin que les resulte muy pesada.

7. Gráficos de quemado. Se usan también en Scrum. Es una técnica de graficación

para descubrir retardos y problemas en el proceso a tiempo, evitando que se

descubran demasiado tarde o cuando ya no tengan solución. Para ello se hace una

estimación del tiempo que falta para programar lo que queda al ritmo actual. Esta

técnica se asocia con la Lista Témpana, llamada así porque se refiere al agregado

de tareas u objetos de alta prioridad al principio de las listas de trabajos pendientes,

esperando que los demás se hundan debajo de la línea de flotación; los elementos

17

que están sobre la línea se entregarán en la iteración siguiente, los que están por

debajo en las restantes. Los gráficos de quemado muestran gráficamente la

velocidad del proceso.

8. Programación lado a lado. Crystal Clear establece proximidad con los miembros del equipo. Cada persona se enfoca a su propia tarea asignada pero echando un ojo a lo que hace su compañero. Es una ampliación de la Comunicación Osmótica al contexto de la programación, y un contraste a la presión extrema que muchos consideran a la programación en pares de XP.

18

AUP: Agile Unified Process

Características

Es un enfoque al desarrollo de software basado en el Rational Unified Process (RUP) de IBM. El ciclo de vida de AUP es en serie a lo grande e iterativo en lo pequeño, liberando artefactos incrementales en el tiempo.

El AUP consta de 7 flujos de trabajo o disciplinas: Modelado, Implementación, Prueba,

Despliegue, Gestión de configuración, Gestión de proyectos y Ambiente.

- Modelado: Tiene como objetivo entender el negocio, entender cuál es el problema que se va a abordar e identificar las posibles soluciones viables para dicho problema.

- Implementación: El objetivo de esta disciplina es transformar el modelo en código y realizar pruebas básicas sobre él.

- Prueba: Tiene como meta evaluar una evaluación de los objetivos y encontrar defectos para mejorar la calidad. Se encarga también de verificar si el sistema funciona correctamente.

- Despliegue: Su objetivo es ejecutar un plan para que el sistema esté a disposición de los usuarios.

- Administración de la configuración: Su meta es administrar el acceso a los artefactos del proyecto. Lleva un registro de las versiones del producto y controla los cambios que ocurran.

- Administración del proyecto: Tiene el objetivo de administrar los riesgos, la asignación de tareas, el seguimiento de los procesos y coordinar con las personas fuera del proyecto para facilitar que acabe a tiempo y sin pasar el presupuesto.

- Entorno: Apoya los esfuerzos para garantizar la disponibilidad de los procesos, normas y herramientas cuando sea necesario.

También consta de 4 fases del ciclo de desarrollo:

- Inicio: se trata de identificar el alcance y dimensión del proyecto, su arquitectura y el

presupuesto junto con su aprobación por parte de aquellos que pertenecen al proyecto.

Como hito de esta fase obtenemos los objetivos de ciclo de vida.

- Elaboración: en esta fase se prueba y se confirma la arquitectura del sistema. Como hito

obtenemos la arquitectura del ciclo de vida.

- Construcción: esta fase consiste en la construcción del software sobre la base

incremental siguiendo unas prioridades impuestas por los implicados en el proyecto o por

los propios usuarios. Como hito obtenemos la capacidad operacional inicial.

- Transición: esta fase tiene el objetivo de validar e implantar el sistema en el entorno de

producción. Como hito tenemos la liberación del producto.

19

Roles

- Administrador de bases de datos: trabaja con los miembros del equipo del proyecto para diseñar, probar y dar soporte a los esquemas de datos. Trabaja dentro de la disciplina de implementación.

- Modelador: se encarga de crear modelos (dibujos, archivos, etc) de manera colaborativa y evolutiva. Trabaja dentro de las disciplinas de modelado e implementación.

- Administrador de la configuración: se encarga de la infraestructura del medio donde trabaja el equipo de desarrollo. Forma parte de la disciplina de administración de configuración.

- Implementador: es el encargado de poner el software a punto para la preproducción. Su parte se desarrolla dentro de la disciplina de desarrollo.

- Desarrollador: escribe el código, lo prueba y construye el software. Trabaja en las

disciplinas de modelado, implementación y desarrollo.

- Especialista del proceso: desarrolla, adapta y apoya el material de los procesos de

organización. Trabaja en la disciplina de entorno.

- Administrador del proyecto: se encarga de administrar los miembros de los equipos de trabajo, maneja las interacciones entre los involucrados en el proyecto y también se encarga de administrar los recursos y las prioridades. Trabaja dentro de las disciplinas de modelado, pruebas, desarrollo y administración del proyecto.

- Examinador: es el miembro que se encarga de someter a evaluación los productos del

proyecto. Su trabajo forma parte de la disciplina de pruebas.

- Documentador técnico: se encarga de la documentación sobre los materiales,

operaciones, mantenimiento y del usuario. Forma parte de la disciplina de desarrollo.

- Administrador de pruebas: se encarga de que las pruebas a las que se somete el

producto tengan éxito. Forma parte de la disciplina de pruebas.

- Equipo de pruebas: son los miembros que se encargan de ejecutar las pruebas y

documentar las. Pertenecen a la disciplina de pruebas.

- Especialista en herramientas: son los responsables de la elección, adquisición,

configuración y mantenimiento de los equipos que se utilizaran durante el proceso. Forma

parte de la disciplina de entorno.

Artefactos

- Sistema: el sistema es el software, hardware y documentación que será liberado a la producción.

- Código fuente: es el código de programación para los sistemas.

20

- Suite de pruebas de regresión: son casos de prueba con sus respectivos códigos listos para ser ejecutados en un orden predefinido.

- Scripts de instalación: código necesario para instalar el sistema en el entorno de preproducción.

- Documentación del sistema: es la documentación que fluye junto con el sistema para

ayudar a los desarrolladores a mantenerlo actualizado. Contiene las operaciones, soportes

y documentación general del sistema.

- Notas: son resúmenes que se pasan sobre aquellas modificaciones que se realizan en el

proceso de construcción.

- Modelado de requerimientos: contiene los requisitos a cumplir, junto con pruebas de

aceptación, automatización, modelos de procesos de negocio, reglas, modelos de dominio y

organización, glosarios, requisitos técnicos y modelos de UI.

- Modelo de diseño: es una descripción del diseño del sistema que contiene modelos de

despliegue, objetos, datos físicos y seguridad, así como un resumen del sistema y un

modelo de UI.

21

Análisis comparativo

Similitudes y diferencias

Las metodologías ágiles pueden seguir una guía rígida y concreta de la que no hay que

salirse, con técnicas muy específicas, como sucede con las metodologías FDD y XP, o por

el contrario, seguir una guía flexible y abstracta, con métodos que nos ayudan a obtener

el mismo resultado de una manera más eficiente, como es el caso de Crystal.

Una de las similitudes que comparten prácticamente todas las metodologías ágiles es que

presentan guías ajustables y adaptables ante cambios una vez empezado el proyecto.

Crystal es la única excepción.

En cuanto a los roles que intervienen en las diferentes metodologías comentadas en los

anteriores apartados, se puede decir que no difieren prácticamente, y que en su mayoría

los mismos papeles se repiten en todas. Siempre hay un representante del cliente, que

normalmente es el que se encarga de comprobar que se van cumpliendo todos los

requisitos; un experto en la metodología para guiar al equipo; un gestor del proyecto; y

el equipo de desarrolladores (con mayor o menor grado de subdivisiones dentro de esta

unidad).

En conclusión podemos decir que la asignación de los roles es independiente de la

metodología y que tan sólo se van adaptando según el estilo que tenga cada una.

Las herramientas usadas por las metodologías ágiles son en general muy comunes, XP es

de las pocas que se desvían de esta norma y han introducido novedades, especialmente en

lo que se refiere a herramientas en las fases de pruebas (aunque en este trabajo no se

habla de XP).

La familia de las metodologías Crystal es la única que sugiere explícitamente principios del

método de diseño para permitir la adaptación en función del tamaño del proyecto y la

criticidad.

DSDM se diferencia por usar prototipos y presenta algunos roles no considerados por el

resto: ambassador, visionary y advisor (representan diferentes puntos de vista del cliente).

FDD no cubre las primeras fases de un proyecto, pues presupone que se ha realizado

trabajo anteriormente

Ventajas y desventajas

DSDM une técnicas de desarrollo y gestión del proyecto en una misma metodología que se

centra en conseguir un producto que funcione correctamente en los casos más

críticos, por lo que crea un producto en un plazo corto que sólo cubre casos de uso

básicos.

El equipo de desarrollo toma decisiones sin depender de autorizaciones de sus

superiores evitando tiempos de espera y su consecuente pérdida de tiempo, en el

22

desarrollo al esperar una aprobación. Sobre todo teniendo en cuenta que los plazos de

desarrollo y las iteraciones son cortos períodos de tiempo, punto que tiene la ventaja de

prevenir que transcurra mucho tiempo y la tecnología cambie, además de permitir una

revisión continua del producto a través de entregas frecuentes de productos.

Llegados aquí, gracias a que los cambios son revertibles y verificados es posible volver

a un punto anterior y corregir errores detectados. Otra ventaja es la continua

realimentación (feedback) entre cliente y desarrolladores que ayuda a obtener un proyecto

eficiente y efectivo aunque el desarrollo sea rápido y en tiempo reducido.

Como ventajas, FDD tiene que es una metodología de desarrollo ágil, que disminuye el

riesgo de los proyectos, pues gracias a sus entregas tangibles cada dos semanas y al

constante monitoreo de su calidad, se asegura el firme avance del mismo.

Esta metodología utiliza pequeños bloques que contienen la funcionalidad del sistema, llamados features. Estos bloques, que están relacionados entre sí, son organizados en una lista llamada feature set.

También permite dejar satisfechos a los desarrolladores, gerentes y clientes sin afectar el proyecto. Esto gracias a un buen manejo de las actividades, a la disminución del riesgo del proyecto y al aseguramiento de la calidad del mismo, respectivamente.

FDD presenta su talón de Aquiles en la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el principio, con la elaboración del modelo global, puesto que no es tan ágil como otras metodologías.

Algunos “agilistas” sienten que FDD es demasiado jerárquico para ser un método ágil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos.

Otros críticos sienten que la ausencia de procedimientos detallados de prueba en FDD es llamativa e impropia.

Los promotores del método aducen que las empresas ya tienen implementadas sus herramientas de prueba, pero subsiste el problema de su adecuación.

En cuanto a Crystal Clear podríamos meter en el saco de ventajas que es una de las

metodologías más ágiles y flexibles, con gran énfasis en la comunicación (de hecho es

lo más importante y crucial) y a los individuos que forman parte del proyecto. Otro punto

que se puede considerar ventaja es que se dispone de la figura del “usuario real”, que

realiza validaciones sobre la interfaz de usuario, propone ideas para una mejor

implementación de cara a los usuarios finales de primera mano y participa en la definición

de requerimientos funcionales y no funcionales del software, lo cual implica que se consigue

un sistema totalmente preparado y adaptado a los usuarios finales. Este hecho muchas

metodologías no lo integran.

Como inconveniente podríamos decir que es una metodología que no se puede aplicar a

grandes proyectos donde absolutamente todo se debe controlar y donde se deben seguir

23

por necesidad instrucciones más disciplinadas y concretas, Crystal Clear es demasiado

ágil y abstracta en sus métodos, lo que hace que esta metodología por sí sola sea

aplicable en la práctica en casos muy concretos.

Adecuación para distinto tipo de aplicaciones

DSDM es excelente para proyectos de sistemas de la información con presupuestos

limitados y agendas muy ocupadas y apretadas. Puede usarse en proyectos de ampliación

de sistemas TI pero también podría utilizarse para proyectos de cambio de algún sistema

aunque no sea TI. Proyectos interactivos con funcionalidad visible en la interfaz de usuario

FDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la década de 1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes y recomiendan adoptarlo en forma gradual. Un rasgo llamativo de FDD es que no exige la presencia del cliente.

Crystal Clear al darle más importancia a los individuos y basarse fundamentalmente el éxito del proyecto en la comunicación cara a cara, es una metodología que únicamente se puede aplicar a proyectos pequeños, de equipos reducidos y menos a 10 personas, pues en proyectos más ambiciosos es fácil que se pase algo por algo, lo que puede ser fatal. En cambio en proyectos menores, donde la gente se conoce más y todos están apoyados unos en otros, es posible llegar a buen puerto con este método tan flexible y menos estresante en comparación con otras metodologías. Esto último en proyectos más grandes y de más importancia es necesario que así sean para poder controlar, por ejemplo, los riesgos críticos a los que se debe enfrentar, algo que Crystal Clear no contempla. Más bien Crystal Clear está pensada para combinarse junto a otras metodologías como XP o Scum.

AUP es un método ágil entre XP y RUP que incluye las actividades y herramientas tradicionales. El AUP resulta ser un proceso muy pesado pero en comparación con el RUP es muy simple.

24

Bibliografía Introducción

Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone

Desarrollo ágil de software - Wikipedia [Imagen 1] DSDM: Dynamic Systems Development Method

Método de desarrollo de sistemas dinámicos - Wikipedia

Metodología ágil DSDM - Bitácora de Audieman [Imagen 2]

Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone

Agile Software Development Methods: Review and Analysis - Abrahamsson, Pekka; Salo,

Outi; Ronkainen, Jussi; Warsta, Juhani (PDF/ENG)

FDD: Feature Driven development

FDD - Wikipedia(Traducido) Presentación FDD (PPT)

Procesos ágiles (MSWord)

Metodología FDD - Luis Calabria (cátedra) Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone Agile Software Development Methods: Review and Analysis - Abrahamsson, Pekka; Salo, Outi; Ronkainen, Jussi; Warsta, Juhani (PDF/ENG) Crystal: (Crystal Clear)

Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo Schenone

Documento sobre la metodología Crystal Crystal Clear Roles and Work Products (ENG) Metodologías ágiles [Imagen 4] Presentación sobre Crystal Clear AUP: Agile Unified Process

Gestion de proyectos ágil: Conceptos básicos (PDF) http://www.ecured.cu/index.php/Agile_Unified_Process

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://wikis.uca.es/wikiCE/index.php/Agile_unified_process http://www.ambysoft.com/downloads/agileUP.zip

http://www.adolfo.mex.tl/images/18149/METODOLOGIAS%20AGILES.pdf

Análisis comparativo Metodologías ágiles, tesis de master