METODOLOGIAS AGILES

6,977 views
6,731 views

Published on

mas de metodologías agiles

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
6,977
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
329
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

METODOLOGIAS AGILES

  1. 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 1
  2. 2. ÍndiceIntroducción a las metodologías ágilesDSDM: Dynamic Systems Development MethodFDD: Feature Driven developmentCrystal: (Crystal Clear)AUP: Agile Unified ProcessAnálisis comparativoBibliografía 2
  3. 3. Introducción a las metodologías ágilesLas 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 ApplicationDevelopment). En él, el trabajo se organizaba en pequeños grupos de trabajo de altorendimiento.Las metodologías ágiles se inician con la creación del eXtreme programming o XP queimpulsa el desarrollo mediante iteraciones, aunque éstas ya se utilizaban anteriormente.También destacamos que estos ciclos son cortos intervalos de tiempo, de una a cuatrosemanas, lo que favorece la minimización de riesgos. Actualmente existen diversasmetodologías ágiles que se fueron basando en los principios de esta metodología. Imagen 1: Desarrollo ágil de softwareA continuación estudiaremos cuatro de las metodologías ágiles más destacadas delmomento: DSDM – Dynamic Systems Developmemt Method, Crystal (Crystal Clear), FDD –Feature Driven Development y AUP: Agile Unified Process. 3
  4. 4. DSDM: Dynamic Systems Development MethodEsta metodología surge de un consorcio en Reino Unido. Su primera versión aparece en1994, posteriormente se han realizado varias versiones.Situada dentro de las RAD, DSDM es excelente para proyectos de sistemas de lainformación con presupuestos limitados y agendas muy ocupadas y apretadas.CaracterísticasLos proyectos tendrán las siguientes características que refieren a la aplicabilidad deDSDM:- 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 grantamaño, cuentan con flexibilidad en los requerimientos.- Une técnicas de desarrollo y gestión del proyecto en una misma metodología que secentra 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 grupode usuarios bien definidos y comprometidos al proyecto.- El equipo de desarrollo toma decisiones sin depender de autorizaciones de sus superiorespara realizar entregas, siempre cortas, de forma frecuente, siendo éstas funcionales. Éstoes adecuado al tener el tiempo total acotado, por lo que previene que transcurra muchotiempo y la tecnología cambie.- El desarrollo es iterativo e incremental.- Todos los cambios pueden ser revertibles y son verificados durante todo el desarrollo.RolesEsta metodología define 15 roles para usuarios y desarrolladores, a continuación sedescriben 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). 4
  5. 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.ArtefactosPodemos describir los artefactos obtenidos mediante la metodología DSDM a través de lasdistintas 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 grandesrasgos.- 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 elnegocio o tecnología.Fase 2. Estudio de la empresa.- Descripción de los procesos de negocio y especificación de casos de uso. Laidentificación de los casos de uso ayuda a involucrar al cliente. 5
  6. 6. - Documento de Especificación de Requerimientos de Software (SRS). Descripciones aalto nivel de los requisitos que se presentan en formato correcto diagramas ER, modelos denegocio objetivos, etc.- Definición de la arquitectura del sistema. Es un primer borrador de la arquitectura quepuede cambiar durante el desarrollo del proyecto.- Esbozo del plan de prototipado. Debe declarar la estrategia de prototipado para lassiguientes 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 laiteración.- Resumen de los documentos de prototipos funcionales. Recoge los comentarios delos usuarios sobre el incremento actual, servirá de artefacto de entrada para las siguientesiteraciones.- 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 estafase, pues, a partir de la siguiente fase, los errores encontrados serán más difíciles deubicar 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 losresultados, se establece el curso del desarrollo adicional.PrácticasDado el enfoque hacia proyectos de características RAD, la ideología de la metodologíaDSDM 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 lasdecisiones.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 laaprobación de superiores3. 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 laaceptación de los entregables. 6
  7. 7. DSDM se centra en las funcionalidades críticas del proyecto, no en todas sus posiblesnecesidades.5. El desarrollo iterativo e incremental es necesario para converger hacia una correctasolució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 otrocamino 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 enmantenimiento 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 uncorrecto desarrollo del proyecto.Aparte de estos principios, DSDM también se basa en una serie de consideraciones muyimportantes:● 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.ProcesoDSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planessegún las necesidades de la empresa. Para alcanzar sus metas, DSDM favorece el uso delRAD con el consecuente riesgo de que demasiadas partes estén sin definir correctamente yesto lleve a errores.DSDM aplica algunos principios, roles, y técnicas en las 5 fases en las que define laconstrucció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. 7
  8. 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 alprincipio del proyecto para analizar la factibilidad desde el punto de vista del negocio deldesarrollo, las demás fases presentan las características del modelo iterativo e incrementalya tratado. Imagen 2. Diagrama de procesos de DSDMDSDM aproxima las iteraciones como “timeboxes”. Una “timebox” dura un periodopredefinido de tiempo y la iteración debe finalizar dentro de la “timebox” que suele durardesde unos días hasta unas pocas semanas. 8
  9. 9. Sin embargo, lo que diferencia a DSDM de otros modelos son los principios alrededor de loscuales se estructura, tratados en el apartado anterior, y que hacen énfasis en los equipos dedesarrollo, en el feedback con el cliente y en las entregas frecuentes de productos.Posibles integracionesEs 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), yProyectos en ambientes controlados (PRINCE2), Otro método ágil que tiene semejanzasproceso y concepto con DSDM es Scrum.Entre DSDM y RUP se puede crear una fuerte unión, RUP podría considerarse unaimplementación de DSDM. RUP está más orientado a la arquitectura y a la calidad y DSDMtiene como objetivo el desarrollo rápido de aplicaciones, sin embargo, esto no impidecombinarlos, incluso se pueden relacionar todas las fases y artefactos de RUP con los deDSDM. Al combinarse podemos obtener un sistema con una arquitectura fuertementedefinida en un tiempo récord. 9
  10. 10. FDD: Feature Driven developmentEs un proceso ágil diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Se basa en unproceso iterativo con iteraciones cortas que producen un software funcional que el cliente yla dirección de la empresa pueden ver y monitorizar. Estas iteraciones se deciden en base afeatures o funcionalidades, que son pequeñas partes del software con significado para elcliente.A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases dediseño y construcción. No requiere un modelo específico de proceso y se complementa conotras metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles yformas de evaluación del progreso.CaracterísticasFDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye elsistema. 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 dominioestán al tanto de la visón, el contexto y los requerimientos del sistema a construir. A estaaltura se espera que existan requerimientos tales como casos de uso o especificacionesfuncionales. Los expertos de dominio presentan un ensayo más en el que los miembros delequipo 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ásdetallado para cada uno de los miembros del dominio. Luego, un equipo de desarrollotrabaja 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 derequerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgosson pequeños ítems útiles a los ojos del cliente. La lista de rasgos es revisada por losusuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos querequieran 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 losconjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y seasigna a los programadores jefes.Diseño por rasgos y Construcción por rasgos: Se selecciona un pequeño conjunto derasgos del conjunto, y los propietarios de clases seleccionan los correspondientes equiposdispuestos por rasgos. Se procede luego iterativamente hasta que se producen los rasgosseleccionados. 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óne inspección de código. 10
  11. 11. Miremos una representación gráfica del proceso iterativo que involucran estas dos últimasfases: Imagen 3. Flujo de los procesos en FDDRolesKey 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. 11
  12. 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.ArtefactosEl Release Manager se reúne con los Chief Programmers para que éstos reporten como esel 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 deforma verbal es bueno para que cada uno de los Chief Programmers se tome el tiempo deescuchar 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 datosy 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 debeincluir el porcentaje de avance de cada feature. Para el equipo se informa cual es eldesempeño del mismo.PrácticasFDD consiste en establecer "mejores prácticas" y los desarrolladores del métodoargumentan que a pesar de que las prácticas seleccionadas no son nuevas, la mezclaespecí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 serutilizadas para obtener el mayor beneficio del método y no que una única práctica dominetodo el proceso (2002). FDD consiste en las siguientes prácticas: 12
  13. 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 cumplircon las normas de desarrollo del FDD. Sin embargo, al equipo se le permite adaptarlas deacuerdo a su nivel de experiencia. 13
  14. 14. Crystal: (Crystal Clear)Crystal es una metodología de desarrollo de software ágil, aunque más bien se la consideraun conjunto de metodologías para el desarrollo de software caracterizadas por estarcentradas en las personas que forman parte del equipo y en la reducción al máximodel número de artefactos producidos.El equipo de desarrollo se considera un factor clave en esta metodología, por lo que sedeben invertir esfuerzos en mejorar las habilidades y destrezas, así como tener políticasde trabajo en equipo bien definidas. Estas políticas dependerán del número de personasque formen el equipo, estableciéndose una clasificación por colores, por ejemplo CrystalClear (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ísticasLas 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 14
  15. 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.ProcesoEn lugar de la interpretación lineal de los modelos clásicos, que es interpretada en muchoscasos como inconvenientes, Cristal Clear enfatiza el proceso como un conjunto de ciclosanidados.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. 15
  16. 16. Imagen 4. Ciclos anidados de Crystal ClearPrácticasEn cuanto a las prácticas o técnicas que se favorecen dentro de esta metodología, podemosmencionar 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 16
  17. 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. 17
  18. 18. AUP: Agile Unified ProcessCaracterísticasEs un enfoque al desarrollo de software basado en el Rational Unified Process (RUP) deIBM. El ciclo de vida de AUP es en serie a lo grande e iterativo en lo pequeño, liberandoartefactos 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 elpresupuesto 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 hitoobtenemos la arquitectura del ciclo de vida.- Construcción: esta fase consiste en la construcción del software sobre la baseincremental siguiendo unas prioridades impuestas por los implicados en el proyecto o porlos 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 deproducción. Como hito tenemos la liberación del producto. 18
  19. 19. Roles- Administrador de bases de datos: trabaja con los miembros del equipo del proyecto paradiseñar, probar y dar soporte a los esquemas de datos. Trabaja dentro de la disciplina deimplementación.- Modelador: se encarga de crear modelos (dibujos, archivos, etc) de manera colaborativa yevolutiva. Trabaja dentro de las disciplinas de modelado e implementación.- Administrador de la configuración: se encarga de la infraestructura del medio dondetrabaja el equipo de desarrollo. Forma parte de la disciplina de administración deconfiguración.- Implementador: es el encargado de poner el software a punto para la preproducción. Suparte se desarrolla dentro de la disciplina de desarrollo.- Desarrollador: escribe el código, lo prueba y construye el software. Trabaja en lasdisciplinas de modelado, implementación y desarrollo.- Especialista del proceso: desarrolla, adapta y apoya el material de los procesos deorganización. Trabaja en la disciplina de entorno.- Administrador del proyecto: se encarga de administrar los miembros de los equipos detrabajo, maneja las interacciones entre los involucrados en el proyecto y también se encargade 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 delproyecto. 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 elproducto tengan éxito. Forma parte de la disciplina de pruebas.- Equipo de pruebas: son los miembros que se encargan de ejecutar las pruebas ydocumentar 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. Formaparte de la disciplina de entorno.Artefactos- Sistema: el sistema es el software, hardware y documentación que será liberado a laproducción.- Código fuente: es el código de programación para los sistemas. 19
  20. 20. - Suite de pruebas de regresión: son casos de prueba con sus respectivos códigos listospara ser ejecutados en un orden predefinido.- Scripts de instalación: código necesario para instalar el sistema en el entorno depreproducción.- Documentación del sistema: es la documentación que fluye junto con el sistema paraayudar a los desarrolladores a mantenerlo actualizado. Contiene las operaciones, soportesy documentación general del sistema.- Notas: son resúmenes que se pasan sobre aquellas modificaciones que se realizan en elproceso de construcción.- Modelado de requerimientos: contiene los requisitos a cumplir, junto con pruebas deaceptación, automatización, modelos de procesos de negocio, reglas, modelos de dominio yorganizació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 dedespliegue, objetos, datos físicos y seguridad, así como un resumen del sistema y unmodelo de UI. 20
  21. 21. Análisis comparativoSimilitudes y diferenciasLas metodologías ágiles pueden seguir una guía rígida y concreta de la que no hay quesalirse, con técnicas muy específicas, como sucede con las metodologías FDD y XP, o porel contrario, seguir una guía flexible y abstracta, con métodos que nos ayudan a obtenerel 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 quepresentan 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 losanteriores apartados, se puede decir que no difieren prácticamente, y que en su mayoríalos mismos papeles se repiten en todas. Siempre hay un representante del cliente, quenormalmente es el que se encarga de comprobar que se van cumpliendo todos losrequisitos; un experto en la metodología para guiar al equipo; un gestor del proyecto; yel equipo de desarrolladores (con mayor o menor grado de subdivisiones dentro de estaunidad).En conclusión podemos decir que la asignación de los roles es independiente de lametodologí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 esde las pocas que se desvían de esta norma y han introducido novedades, especialmente enlo que se refiere a herramientas en las fases de pruebas (aunque en este trabajo no sehabla de XP).La familia de las metodologías Crystal es la única que sugiere explícitamente principios delmétodo de diseño para permitir la adaptación en función del tamaño del proyecto y lacriticidad.DSDM se diferencia por usar prototipos y presenta algunos roles no considerados por elresto: 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 realizadotrabajo anteriormenteVentajas y desventajasDSDM une técnicas de desarrollo y gestión del proyecto en una misma metodología que secentra en conseguir un producto que funcione correctamente en los casos máscríticos, por lo que crea un producto en un plazo corto que sólo cubre casos de usobásicos.El equipo de desarrollo toma decisiones sin depender de autorizaciones de sussuperiores evitando tiempos de espera y su consecuente pérdida de tiempo, en el 21
  22. 22. desarrollo al esperar una aprobación. Sobre todo teniendo en cuenta que los plazos dedesarrollo y las iteraciones son cortos períodos de tiempo, punto que tiene la ventaja deprevenir que transcurra mucho tiempo y la tecnología cambie, además de permitir unarevisió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 volvera un punto anterior y corregir errores detectados. Otra ventaja es la continuarealimentación (feedback) entre cliente y desarrolladores que ayuda a obtener un proyectoeficiente 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 elriesgo de los proyectos, pues gracias a sus entregas tangibles cada dos semanas y alconstante 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 unalista llamada feature set.También permite dejar satisfechos a los desarrolladores, gerentes y clientes sin afectar elproyecto. Esto gracias a un buen manejo de las actividades, a la disminución del riesgodel 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 conexperiencia que marquen el camino a seguir desde el principio, con la elaboración delmodelo 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, quienesdirigen equipos de rasgos.Otros críticos sienten que la ausencia de procedimientos detallados de prueba en FDDes llamativa e impropia.Los promotores del método aducen que las empresas ya tienen implementadas susherramientas 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 lasmetodologías más ágiles y flexibles, con gran énfasis en la comunicación (de hecho eslo más importante y crucial) y a los individuos que forman parte del proyecto. Otro puntoque se puede considerar ventaja es que se dispone de la figura del “usuario real”, querealiza validaciones sobre la interfaz de usuario, propone ideas para una mejorimplementación de cara a los usuarios finales de primera mano y participa en la definiciónde requerimientos funcionales y no funcionales del software, lo cual implica que se consigueun sistema totalmente preparado y adaptado a los usuarios finales. Este hecho muchasmetodologías no lo integran.Como inconveniente podríamos decir que es una metodología que no se puede aplicar agrandes proyectos donde absolutamente todo se debe controlar y donde se deben seguir 22
  23. 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 seaaplicable en la práctica en casos muy concretos.Adecuación para distinto tipo de aplicacionesDSDM es excelente para proyectos de sistemas de la información con presupuestoslimitados y agendas muy ocupadas y apretadas. Puede usarse en proyectos de ampliaciónde sistemas TI pero también podría utilizarse para proyectos de cambio de algún sistemaaunque no sea TI. Proyectos interactivos con funcionalidad visible en la interfaz de usuarioFDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la década de1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemasexistentes y recomiendan adoptarlo en forma gradual. Un rasgo llamativo de FDD es que noexige 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 sepuede aplicar a proyectos pequeños, de equipos reducidos y menos a 10 personas, pues enproyectos más ambiciosos es fácil que se pase algo por algo, lo que puede ser fatal. Encambio en proyectos menores, donde la gente se conoce más y todos están apoyados unosen otros, es posible llegar a buen puerto con este método tan flexible y menos estresante encomparación con otras metodologías. Esto último en proyectos más grandes y de másimportancia es necesario que así sean para poder controlar, por ejemplo, los riesgos críticosa los que se debe enfrentar, algo que Crystal Clear no contempla. Más bien Crystal Clearestá 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 herramientastradicionales. El AUP resulta ser un proceso muy pesado pero en comparación con el RUPes muy simple. 23
  24. 24. BibliografíaIntroducciónDiseño de una Metodología Ágil de Desarrollo de Software - Marcelo SchenoneDesarrollo ágil de software - Wikipedia [Imagen 1]DSDM: Dynamic Systems Development MethodMétodo de desarrollo de sistemas dinámicos - WikipediaMetodología ágil DSDM - Bitácora de Audieman [Imagen 2]Diseño de una Metodología Ágil de Desarrollo de Software - Marcelo SchenoneAgile Software Development Methods: Review and Analysis - Abrahamsson, Pekka; Salo,Outi; Ronkainen, Jussi; Warsta, Juhani (PDF/ENG)FDD: Feature Driven developmentFDD - 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 SchenoneAgile 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 SchenoneDocumento sobre la metodología CrystalCrystal Clear Roles and Work Products (ENG)Metodologías ágiles [Imagen 4]Presentación sobre Crystal ClearAUP: Agile Unified ProcessGestion de proyectos ágil: Conceptos básicos (PDF)http://www.ecured.cu/index.php/Agile_Unified_Processhttp://www.ambysoft.com/unifiedprocess/agileUP.htmlhttp://wikis.uca.es/wikiCE/index.php/Agile_unified_processhttp://www.ambysoft.com/downloads/agileUP.ziphttp://www.adolfo.mex.tl/images/18149/METODOLOGIAS%20AGILES.pdfAnálisis comparativoMetodologías ágiles, tesis de master 24

×