Presentacin de PowerPoint

Metodologasgiles

HistoriaLa definicin moderna de desarrollo gil de software evolucion a mediados de los aos1990como parte de una reaccin contra los mtodos de "peso pesado", muy estructurados y estrictos, extrados del modelo de desarrollo en cascada.

RADEn la dcada del 90, surgi un enfoque revolucionario para su momento ya que iba en contra de toda creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad. En la comunidad de Ingeniera de Software conocido como RAD o Rapid Application Development (Desarrollo rpido de aplicaciones). Entorno de desarrollo altamente productivoGrupos pequeos de programadoresHerramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel.

La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento"

Principales valores del desarrollo gil. Segn el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.Desarrollar software que funciona ms que conseguir una buena documentacin.La colaboracin con el cliente ms que la negociacin de un contrato.Responder a los cambios ms que seguir estrictamente un plan.

EL MANIFIESTO GILI. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo.VII. El software que funciona es la medida principal de progreso.VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante.IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.X. La simplicidad es esencial.XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos.XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

Qu es una metodologa gil? Consiste en desarrollar una pequea parte del software que se desea construir. De esta forma, el cliente nos indica si vamos por el buen camino, estableciendo aquellas partes que le son ms relevantes y as juntos, nos aseguramos de que construimos una aplicacin que aadir valor a su negocio.

La mayora minimiza riesgos desarrollando software en cortos lapsos de tiempoLas metodologas giles de desarrollo estn especialmente indicadas en proyectos con requisitos poco definidos o cambiantes. Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo Entrega continua y en plazos breves de software funcionaTrabajo conjunto entre el cliente y el equipo de desarrollo Importancia de la simplicidad, eliminado el trabajo innecesario Atencin continua a la excelencia tcnica y al buen diseo Mejora continua de los procesos y el equipo de desarrollo

METODOLOGAS GILESXP- eXtreme ProgrammingSCRUMCrystal MethodologiesDynamic Systems Development Method (DSDM) Adaptive Software Development (ASD)Feature-Driven Development (FDD)Lean Development (LD)XP- eXtreme Programming

Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo.Roles XP Los roles de acuerdo con la propuesta original de Beck son:

Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema.

Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio.

Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker). Proporciona realimentacin al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin.

Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente.

Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas.

Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

Prcticas XP El juego de la planificacin. Hay una comunicacin frecuente el cliente y los programadores.

Entregas pequeas. Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema.

Metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema.Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto.

Pruebas. La produccin de cdigo est dirigida por las pruebas unitarias. stas son son establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada modificacin del sistema.

Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios.Programacin en parejas. Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor satisfaccin de los programadores, ).

Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento.

Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. 40 horas por semana. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas.

Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo.

Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin para mantener el cdigo legible. Mtodo SCRUMEst especialmente indicada para proyectos con un rpido cambio de requisitos. Sus principales caractersticas se pueden resumir en dos.Mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente.Reuniones a lo largo proyecto. Una reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin.

SCRUM

Crystal ClearSe trata de un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el xito del proyecto) y la reduccin al mximo del nmero de artefactos producidos.

Roles en Crystal ClearPatrocinador Usuario experto Diseador principal Diseador programador Experto en negociosCoordinador Verificador Escritor

VentajasEs que estas metodologas ofrecen una rpida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como despus poder modificarlos evitando grandes prdidas en cuanto a costes, motivacin, tiempo.

El cliente, si quiere colaborar, puede observar como va avanzando el proyecto, y por supuesto, opinar sobre su evolucin gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.

Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologas, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un pequeo intervalo de tiempo un pequeo trozo del proyecto al cliente, y si ste quiere cambiarlo, solo se habr perdido unas semanas de trabajo.

Importancia de la simplicidad al eliminar trabajo innecesario

DesventajasFalta de documentacin del diseo. Al no haber documentacin es el cdigo (junto con sus comentarios) lo que se toma como documentacin.Problemas derivados de la comunicacin oral. No hace falta decir que algo que est escrito no se puede borrar, en cambio, algo dicho es muy fcil crear ambigedad.Fuerte dependencia de las personas.Falta de reusabilidad derivada de la falta de documentacinRestricciones en cuanto a tamao de los proyectosProblemas derivados del fracaso de los proyectos giles. Si un proyecto gil fracasa no hay documentacin o hay muy poca; lo mismo ocurre con el diseo. La comprensin del sistema se queda en las mentes de los desarrolladores.