INS

ContenidoMETODOLOGIAS AGILES3Clasificacin4XP- eXtreme Programming5Scrum6Ciclo de Vida de Scrum7Crystal Clear7Los siete valores o propiedades de Crystal Clear son:9DSDM Dynamic Systems Development Method10FDD Feature Driven Development11ASD Adaptive Software Development12Aspectos claves de ASD son:12Conclusin13BIBLIOGRAFIA13

METODOLOGIAS AGILES

Eldesarrollo gil de softwareson mtodos de ingeniera del software basado en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos auto organizado y multidisciplinario. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener una demo (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto.Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la documentacin. La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpenen ingls). La oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin ydirectores de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica

Clasificacin

XP- eXtreme ProgrammingXP es la primera metodologa gil y la que le dio conciencia al movimiento actual de metodologas giles. De la mano de Kent Beck, XP ha conformado un extenso grupo de seguidores en todo el mundo.La imagen mental de Beck al crear XP [3] era la de perillas en un tablero de control. Cada perilla representaba una prctica que de su experiencia saba que trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As fue como dio inicio a XP.

XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. A continuacin presentaremos las caractersticas esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prcticas.

Scrum

Scrum define un proceso emprico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la utilizacin de prcticas tendientes a manejar la predictibilidad y el riesgo a niveles aceptables. El mismo surge e n 1 9 8 6 , de un artculo de la Harvard Business titulado The New New Product Development Game de Hirotaka Takeuchi e Ikujiro Nonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995. Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores de project management por sobre las dems disciplinas del desarrollo.Al principio del proyecto se define el Product Backlog, que contiene todos los requerimientos funcionales y no funcionales que deber satisfacer el sistema a construir. Los mismos estarn especificados de acuerdo a las convenciones de la organizacin ya sea mediante: features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog ser definido durante reuniones de planeamiento con los stakeholders. A partir de ah se definirn las iteraciones, conocidas como Sprint en la juerga de Scrum, en las que se ir evolucionando la aplicacin evolutivamente. Cada Sprint tendr su propio Sprint Backlog que ser un subconjunto del Product Backlog con los requerimientos a ser construidos en el Sprint correspondiente. La duracin recomendada del Sprint es de un mes. Dentro de cada Sprint el Scrum Master (equivalente al Lder de Proyecto) llevar a cabo la gestin de la iteracin, convocando diariamente al Scrum Daily Meeting que representa una reunin de avance diaria de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los obstculos que se presentan. Ciclo de Vida de Scrum El ciclo de vida de Scrum es el siguiente: 1. Pre-Juego: Planeamiento. El propsito es establecer la visin, definir expectativas y asegurarse la financiacin. Las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso Metodologas giles 21 (backlog) del producto inicial y los tems estimados, as como la arquitectura de alto nivel, el diseo exploratorio y los prototipos. El registro de acumulacin es de alto nivel de abstraccin. 2. Pre-Juego: Montaje (Staging). El propsito es identificar ms requerimientos y priorizar las tareas para la primera iteracin. Las actividades son planificacin, diseo exploratorio y prototipos. 3. Juego o Desarrollo. El propsito es implementar un sistema listo para entrega en una serie de iteraciones de treinta das llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteracin, la definicin del registro de acumulacin de corridas y los estimados, y encuentros diarios de Scrum. 4. Pos-Juego: Liberacin. El propsito es el despliegue operacional. Las Actividades, documentacin, entrenamiento, mercadeo y venta.

Crystal ClearEs la encarnacin ms gil de la serie y de la que ms documentacin se dispone. La misma se define con mucho nfasis en la comunicacin y de forma muy liviana en relacin a los entregables. Crystal maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma parte time para realizar validaciones sobre la Interface del Usuario y para participar en la definicin de los requerimientos funcionales y no funcionales del software.La familia Crystal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto ms oscuro un color, ms pesado es el mtodo. Cuanto ms crtico es un sistema, ms rigor se requiere. El cdigo cromtico se aplica a una forma tabular elaborada por Cockburn que se usa en muchas metodologas giles para situar el rango de complejidad al cual se aplica una metodologa.

Los mtodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versin del proceso, y todas se sitan en torno a un ncleo idntico. Hay cuatro variantes de metodologas: Crystal Clear (Claro como el cristal) para equipos de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100.

Se promete seguir con Marrn, Azul y Violeta. La ms exhaustivamente documentada es Crystal Clear (CC), la misma que puede ser usada en proyectos pequeos de categora D6, aunque con alguna extensin se aplica tambin a niveles E8 a D10.

Los siete valores o propiedades de Crystal Clear son: 1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal, mensual o lo que fuere. La entrega puede hacerse sin despliegue, si es que se consigue algn usuario corts o curioso que suministre feedback. 2. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseador seor; eso se llama Experto al Alcance de la Oreja. Una reunin separada para que los concurrentes se concentren mejor es descripta como El Cono del Silencio. 3. Mejora reflexiva. Tomarse un pequeo tiempo (unas pocas horas por algunas semanas o una vez al mes) para pensar bien qu se est haciendo, cotejar notas, reflexionar, discutir. 4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su cdigo necesita mejorarse, o que sera conveniente que se baase ms seguido. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliacin. Tcnicamente, estas cuestiones se han caracterizado como una importante variable de confianza y han sido estudiadas con seriedad en la literatura. 5. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicacin sobre direccin y prioridades, tpicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles. 6. Fcil acceso a usuarios expertos. Una comunicacin de Keil a la ACM demostr hace tiempo, sobre una amplia muestra estadstica, la importancia del contacto directo con expertos en el desarrollo de un proyecto. No hay un dogma de vida o muerte sobre esto, como s lo hay Metodologas giles 26 en XP. Un encuentro semanal o semi-semanal con llamados telefnicos adicionales parece ser una buena pauta. Otra variante es que los programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un Experto en Negocios. 7. Ambiente tcnico con prueba automatizada, management de configuracin e integracin frecuente. Microsoft estableci la idea de los builds cotidianos, y no es una mala prctica. Muchos equipos giles compilan e integran varias veces al da.

El proceso de Cristal Clear se basa en una exploracin refinada de los inconvenientes de los modelos clsicos.

DSDM Dynamic Systems Development Method

Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente en el movimiento de metodologas giles. La estructura del mtodo fue guiada por estos nueve principios:1. El involucramiento del usuario es imperativo. 2. Los equipos de DSDM deben tener el poder de tomar decisiones. 3. El foco est puesto en la entrega frecuente de productos. 4. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos estn especificados a un alto nivel. 8. El testing es integrado a travs del ciclo de vida. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.

DSDM define cinco fases en la construccin de un sistema ver Figura N8. Las mismas son: estudio de factibilidad, estudio del negocio, iteracin del modelo funcional, iteracin del diseo y construccin, implantacin.FDD Feature Driven Development

Los cinco roles de soporte comprenden (1) administrador de entrega, que controla el progreso del proceso revisando los reportes del programador jefe y manteniendo reuniones breves con l; reporta al manager del proyecto; (2) abogado/guru de lenguaje, que conoce a la perfeccin el lenguaje y la tecnologa; (3) ingeniero de construccin, que se encarga del control de versiones de los builds y publica la documentacin; (4) herramientita (toolsmith), que construye herramientas ad hoc o mantiene bases de datos y sitios Web y (5) administrador del sistema, que controla el ambiente de trabajo o productiva el sistema cuando se lo entrega.

FDD se utiliz por primera vez en grandes aplicaciones bancarias a fines de la dcada de 1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes, y recomiendan adoptarlo en forma gradual.

ASD Adaptive Software Development

La estrategia entera se basa en el concepto de emergencia, una propiedad de los sistemas adaptativos complejos que describe la forma en que la interaccin de las partes genera una propiedad que no puede ser explicada en funcin de los componentes individuales.ASD presupone que las necesidades del cliente son siempre cambiantes. La iniciacin de un proyecto involucra definir una misin para l, determinar las caractersticas y las fechas y descomponer el proyecto en una serie de pasos individuales, cada uno de los cuales puede abarcar entre cuatro y ocho semanas. Los pasos iniciales deben verificar el alcance del proyecto.Aspectos claves de ASD son: 1. Un conjunto no estndar de artefactos de misin (documentos para ti y para m), incluyendo una visin del proyecto, una hoja de datos, un perfil de misin del producto y un esquema de su especificacin 2. Un ciclo de vida, inherentemente iterativo. 3. Cajas de tiempo, con ciclos cortos de entrega orientados por riesgo.

Un ciclo de vida es una iteracin; este ciclo se basa en componentes y no en tareas, es limitado en el tiempo, orientado por riesgos y tolerante al cambio. Que se base en componentes implica concentrarse en el desarrollo de software que trabaje, construyendo el sistema pieza por pieza. En este paradigma, el cambio es bienvenido y necesario, pues se concibe como la oportunidad de aprender y ganar as una ventaja competitiva; de ningn modo es algo que pueda ir en detrimento del proceso y sus resultados.

Conclusin

No existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software y las metodologas tradicionales histricamente han intentado abordar la mayor cantidad de situaciones del contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y de requisitos cambiantes. Las metodologas giles ofrecen una solucin casi a medida para una gran cantidad de proyectos.BIBLIOGRAFIA[1]. Boehm, Barry W., A Spiral Model of Software Development and Enhancement, IEEE Computer, Vol.21, No 15 (Mayo 1988), pp.61-72. [2]. Martin, J., Rapid Application Development, Macmillan Inc., New York, 1991. [4]. Alistair Cockburn. Balancing Lightness with Sufficiency. Septiembre del 2000. Disponible en: http: //alistair.cockburn.us/crystal/articles/blws/balancinglightnesswithsufficiency.html, Setiembre de 2000. [5]. Prez S. Jess, Metodologas giles: La ventaja competitiva de estar preparado para tomar decisiones lo ms tarde posible y cambiarlas en cualquier momento. Pgina oficial de DSDM Disponible en: http://www.dsdm.org