Integrantes Alexi Espinoza Humbert Ramirez Francisco Snchez Jenny Maza Ricardo Vilela

METODOLOGAS GILES EN TI
INTRODUCCIN
Sabemos que Los procesos de desarrollo llevan asociados un mayor nfasis en el control del proceso mismo. Existe una gran rigurosidad en la definicin de roles, actividades y artefactos, incluyendo modelado y documentacin detallada. El esquema tradicional en el que se basa los puntos anteriores ha demostrado ser efectivo y necesario en proyectos de gran tamao (tiempo y recursos) en donde por lo general se exige un alto grado de anlisis en el proceso.

Sin embargo
El enfoque anterior no resulta ser el ms adecuado: Los proyectos que actualmente surgen presentan un entorno del sistema muy cambiante. Ahora se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Existen mayores restricciones de tiempo y flexibilidad. Ante esto las metodologas giles emergen como una potencial respuesta para llenar ese vaco metodolgico. Se constituyen en una alternativa de solucin a medida para ese entorno cambiante. Aportan una elevada simplificacin en donde a pesar de ello no renuncian a las prcticas esenciales para asegurar la calidad del producto o servicio.

ANTECEDENTES
Muchas ideas que se plantean en las metodologas giles fueron reflejadas por Frederick Phillips Brooks en su mtico libro, The Mythical Man Month y en gran parte responden al sentido comn. En el manifiesto de Edsger Dijkstra se haca un llamado a la disciplina concretndose en el ya famoso Manifest for Agile Software Development, una peticin por la atenuacin de los procesos en pro de las personas.

* Hacia la dcada de los 90 surgi un enfoque revolucionario En la comunidad de Ingeniera de Software fue conocido como RAD (Rapid Application Development)

RAD (Rapid Application Development)

Caracterizado por: Un entorno de desarrollo altamente productivo. Grupos pequeos de programadores. Herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En febrero de 2001 nace el trmino gil (Utah-EEUU) aplicado al desarrollo de software.

Al mismo tiempo se cre The Agile Alliance dedicada a: Promover los conceptos relacionados con el desarrollo gil de software. Ayudar a las organizaciones para que adopten dichos conceptos.

Podemos indicar entonces que La aparicin de las metodologas giles son asociadas a todo un conjunto de factores tales como: Plumbing , en definitiva describe la falta de agilidad de los modelos de desarrollo existente. Las metodologas existentes en aquel momento no cumplieron las expectativas planteadas inicialmente. Explosin de la red y las aplicaciones. Movimiento open source.

I. Y qu es ser gil?...
Jim Highsmith dice que ser Agile significa ser capaz de Deliver quickly, Change quickly, Change often (Entregar rpido, cambiar rpido, cambiar con frecuencia).

II. Y qu es ser gil?... Se centra en la interaccin, comunicacin, y en la reduccin de la creacin de artefactos intermedios Reconocer a las personas como principales patrocinadoras para que un proyecto triunfe Dar una orientacin a la efectividad y la manejabilidad. Es algo ms que seguir las guas que se suponen hacen un proyecto gil; la verdadera agilidad es ms que un conjunto de prcticas, es un estado de nimo.

El Manifiesto gil
Se acu el trmino Mtodos giles (Salt Lake City) para definir los mtodos que estaban surgiendo como alternativa a las metodologas formales.

Valores del Desarrollo gil

Se basa en 04 principios fundamentales en los que 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.

I. Doce principios del Manifiesto

1. 1. La prioridad es satisfacer al cliente. 2. 2. Dar la bienvenida a los cambios. 3. 3. Entregar frecuentemente software (en el menor intervalo de tiempo posible entre entregas). 4. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. 5. Construir el proyecto en torno a individuos motivados. 6. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo.

II. Doce principios del Manifiesto 7. El software que funciona es la medida principal de progreso. 8. Los procesos giles promueven un desarrollo sostenible. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. 12. En intervalos regulares, el equipo reflexiona a cmo llegar a ser ms efectivo.

I. Metodologas giles versus Metodologas Tradicionales

Metodologas giles Basadas en heursticas provenientes de prcticas de produccin de cdigo. Especialmente preparadas para cambios durante el proyecto. Impuestas internamente (por el equipo). Proceso menos controlado, con pocos principios. No existe contrato tradicional o al menos es bastante flexible Metodologas Tradicionales Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo. Cierta resistencia a los cambios. Impuestas externamente. Proceso mucho ms controlado, con numerosas polticas/normas. Existe un contrato prefijado.

I. Metodologas giles versus Metodologas Tradicionales

Metodologas giles El cliente es parte del equipo de desarrollo. Grupos pequeos (<10 integrantes) y trabajando en el mismo sitio. Pocos artefactos. Pocos roles. Menos nfasis en la arquitectura del software. Metodologas Tradicionales El cliente interacta con el equipo de desarrollo mediante reuniones. Grupos grandes y posiblemente distribuidos. Ms artefactos. Ms roles. La arquitectura del software es esencial y se expresa mediante modelos.

Algunas Metodologas giles de Desarrollo de SW

Metodologa Acrnimo Adaptive ASD Software Development Agile Modeling AM Creacin Highsmith 2000 Tipo de modelo Prcticas + ciclo de vida Caracterstica Inspirado en sistemas adaptativos complejos Metodologa basada Suministra en la modelado prctica gil a otros mtodos Familia de Metodologa metodologas gil con nfasis en modelo Framework/Disciplina XP dado vuelta con artefactos RUP

Ambler 2002

Cristal Methods

CM

Cockbum 1998

Agile RUP

dX

Booch, Martin, Newkirk 1998

Algunas Metodologas giles de Desarrollo de SW

Metodologa Dynamic Solutions Delivery Model Evolutionary Project Management eXtreme Programming Acrnimo DSDM Creacin Stapleton 1997 Tipo de modelo Framework/modelo de ciclo de vida Framework adaptativo Caracterstica Creado por 16 expertos en RAD Primer mtodo gil existente Mtodo gil radical Mtodo gil de diseo y construccin

EVO

Gilb 1976

XP

Beck 1999

FeatureFDD Driven Development

Disciplina en prcticas de ingeniera De Luca & Coad Metodologa 1998 Palmer & Felsing 2002

Algunas Metodologas giles de Desarrollo de SW

Metodologa Acrnimo Lean LD Development Rapid RAD Development Microsoft Solutions Framework Scrum MSF Creacin Charette 2001, Mary y Tom Poppendieck McConnell 1996 Caracterstica Metodologa basada en procesos Seleccin de best practices, no mtodo Microsoft 1994 Lineamientos, Framework de disciplinas, desarrollo de prcticas soluciones Sutherland 1994 Proceso framework Complemento Schwaber 1995 de de otros management mtodos, giles o no Tipo de modelo Forma de pensar modelo logstico Survey de tcnicas y modelos

Scrum

Beneficios de las Metodologas giles

Simplificacin de los procesos Calidad mejorada Mejor productividad Mejor gestin del riesgo Aprovecha las inversiones realizadas

XP- EXTREME PROGRAMMING

Qu es? Es una metodologa gil bien estructurada. Se centra en potenciar las relaciones interpersonales, promoviendo el continuo trabajo en equipo. Un enfoque refrescante en contraposicin a la metodologas tradicionales.

Las cuatro claves de XP

Comunicacin Simplicidad Retroalimentacin (Feedback) Coraje

Y cuando usar XP?

Proyectos de duracin no muy larga con requisitos imprecisos y muy cambiantes. El riesgo del proyecto es muy alto. Equipos de desarrollo pequeos (2 a 12 personas)

Cmo funciona?

Historias de Usuario
Utilizadas para especificar los requisitos del software. Parecidas a los casos de uso, pero ms relajadas. Son redactadas por el cliente, no por el equipo de desarrollo. Sirven para crear las pruebas de aceptacin. A cada historia se le estima un tiempo.

Tarjetas de papel que contienen: nmero de historia, fecha, tipo de actividad, prueba funcional, prioridad, estimacin tcnica, descripcin.

Roles y responsabilidades Cliente Programador Encargado de pruebas Encargado de seguimiento Coach o entrenador Consultor Gestor

Prcticas de XP (Claves de xito)

El juego de la planificacin Entregas pequeas Metfora Diseo simple Pruebas Refactorizacin Programacin en parejas Propiedad colectiva del cdigo Integracin contina 40 horas por semana Cliente in-situ Estndares de programacin

FDD FEATURE DRIVEN DEVELOPMENT

Fue desarrollado por Jeff De Luca y el viejo gur de la orientacin a objetos Peter Coad. Es una tcnica de programacin guiada por rasgos o caractersticas, centradas en el usuario, no en el programador. Los principios de FDD son pocos y simples: Se requiere un sistema para construir sistemas si se pretende escalar a proyectos grandes. Un proceso simple y bien definido trabaja mejor. Los pasos de un proceso deben ser lgicos y su mrito inmediatamente obvio para cada miembro del equipo. Vanagloriarse del proceso puede impedir el trabajo real.

Proceso
FDD consiste en cinco procesos secuenciales durante los cuales se disea y construye el sistema. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y una salida.

Roles Roles Claves:

Administrador del Proyecto Arquitecto jefe Manager de desarrollo Programador jefe Propietarios de clases

Expertos de dominio

Roles
Roles de Soporte:
Administrador de entrega Abogado/Gur del Lenguaje Ingeniero de construccin Herramientista (Toolsmith) Administrador del sistema Roles Adicionales: Verificadores (Tester) Encargados del despliegue Escritores tcnicos

SCRUM

Entrega parciales y regulares del producto final. Aplicado proyecto complejos. Resultados pronto Es empleado para situaciones como:
Demoras en las entregas Costos elevados Calidad no aceptable Rotacin de los equipos alta

SCRUM
BENEFICIOS Gestin regular de las expectativas del cliente Resultados anticipados (Time to market ) Flexibilidad y adaptacin Retorno de la inversin (ROI) Mitigacin de Riesgos Productividad y calidad Alineamiento entre cliente y equipo. Equipo motivado

SCRUM
PROCESO

ASP (ADAPTIVE SOFTWARE DEVELOPMENT)

Desarrollo adaptable de software. Se adapta al cambio Trabaja bajo un ciclo especular - colaborar aprender Funcionamiento cclico. Aprende de los errores y vuelve a iniciar el ciclo de desarrollo.

ASP (ADAPTIVE SOFTWARE DEVELOPMENT)

Crystal Clear
Crystal Clear es la menor de la familia de metodologas Crystal desarrollada por el investigador de IBM el Dr. Alistair Cockbum. El nombre Crystal deriva de la caracterizacin de los proyectos segn 2 dimensiones, tamao y complejidad. Crystal Clear est diseada para ser utilizada por equipos de hasta ocho integrantes y en el desarrollo de sistemas cuyos posibles errores puedan causar una prdida prudencial de dinero o de confort. Crystal Clear es una metodologa centrada en el factor humano, donde un diseador lder y de dos a siete desarrolladores ms se encuentran juntos en un local grande o en locales adyacentes con radiadores de informacin como pizarras y diagramas bien visibles en la pared, teniendo acceso fcil a usuarios claves; eliminando las distracciones; entregando cdigo funcional, testeado y utilizable en intervalos de uno a tres meses; reflexionando peridicamente y ajustando continuamente su estilo de trabajo.

Propiedades
Crystal Clear se centra en tres propiedades claves:
Efectuar entregas frecuentes. Mejora reflexiva Comunicacin Osmtica.

Otras propiedades importantes son:

Confianza Personal Foco en la tarea Acceso Fcil a Usuarios Expertos. Trabajo en ambiente tcnico.

Estrategias
Las estrategias que propone Crystal Clear son: Exploracin de 360 Victoria Temprana Esqueleto Ambulante Re arquitectura Incremental Radiadores de Informacin
Las tres primeras guan el camino del equipo durante los primeros momentos del desarrollo y las dos restantes pueden aplicarse durante todo el proyecto

Tcnicas
Las tcnicas propuestas por Crystal Clear
Taller de Perfilacin de la Metodologa. Talleres de Reflexin. Planeacin Rpida Estimacin Delfos Reuniones diarias Diseo de Interacciones Esenciales Miniatura del Proceso Programacin Lado a Lado Grfico de Quemado.

Roles nominados
En Crystal Clear existen ocho roles nominados
Patrocinador Ejecutivo Usuario Embajador Diseador Lder Diseador Programador Experto del Negocio Coordinador Verificador Escritor

Los cuatro primeros necesariamente deben ser desempeados por personas distintas, mientras los restantes pueden ser roles adicionales asignados a algunos miembros del equipo.

Ciclos de Crystal Clear

Crystal Clear define su proceso como un conjunto de ciclos anidados de diferentes duraciones. Cada ciclo tiene su propia secuencia, y pueden desarrollarse simultneamente varias actividades pertenecientes a distintos ciclos. Crystal Clear posee siete ciclos:
Ciclo del Proyecto Ciclos de Entrega Ciclo de Iteracin. Ciclos Semanales Ciclos Diarios Ciclos de Integracin

KANBAN
Sistema de produccin altamente efectivo y eficiente
Origen
La metodologa KANBAN tiene su origen en los procesos de produccin justin-time (JIT) ideados por TOYOTA, en los que se utilizaban tarjetas para identificar necesidades de material en la cadena de produccin.

KANBAN
Palabra japonesa que significa tarjetas visuales, donde Kan es visual, y Ban corresponde a tarjeta.

Ventajas
Fcil de utilizar, actualizar y asumir por parte del equipo. Destaca por ser una tcnica de gestin de las tareas muy visual, que permite ver a golpe de vista el estado de los proyectos, as como tambin pautar el desarrollo del trabajo de manera efectiva.

Principios KANBAN
Calidad garantizada
Todo lo que se hace debe salir bien a la primera, no hay margen de error. En KANBAN no se premia la rapidez, sino la calidad final de las tareas realizadas. Basado en el hecho que muchas veces cuesta ms arreglarlo despus que hacerlo bien a la primera.

Reduccin del desperdicio

Basado en hacer solamente lo justo y necesario, pero hacerlo bien. Supone la reduccin de todo aquello que es superficial o secundario (principio YAGNI).

Mejora continua
KANBAN no es simplemente un mtodo de gestin, sino tambin un sistema de mejora en el desarrollo de proyectos, segn los objetivos a alcanzar.

Flexibilidad
Lo siguiente a realizar se decide del backlog (o tareas pendientes acumuladas), pudindose priorizar aquellas tareas entrantes segn las necesidades del momento (capacidad de dar respuesta a tareas imprevistas).

Cmo configurar KANBAN?

1. Definir el flujo de trabajo de los proyectos
Debemos crear nuestro propio tablero, que deber ser visible y accesible por parte de todos los miembros del equipo. Cada una de las columnas corresponder a un estado concreto del flujo de tareas, que nos servir para saber en qu situacin se encuentra cada proyecto (p.e: diagnstico, definicin, programacin, ejecucin, testing, etc.). A medida que se avanza, las nuevas tareas (mejoras, incidencias o nuevas funcionalidades) se acumulan en la seccin inicial, de manera que en las reuniones peridicas con el cliente se priorizan y se colocan dentro de la seccin que se estima oportuna. No hay unas fases del ciclo de produccin establecidas sino que se definirn segn el caso en cuestin, o se establecer un modelo aplicable genricamente para cualquier proyecto de la organizacin.

2.

Visualizar las fases del ciclo de produccin

Cada una de las tareas a realizar se escribe en un post-it y se pega en el tablero, en la fase que corresponda. La pizarra tiene tantas columnas como estados por los que puede pasar la tarea (ejemplo, en espera de ser desarrollada, en anlisis, en diseo, etc.). Dichos post-its contienen la informacin bsica para que el equipo sepa rpidamente la carga total de trabajo: descripcin de la tarea con la estimacin de horas. Se pueden emplear fotos para asignar responsables as como tambin usar tarjetas con distintas formas para poner observaciones o indicar bloqueos (cuando una tarea no puede hacerse porqu depende de otra).

3.

Stop Starting, start finishing

Principal aporte de KANBAN: El trabajo en curso debe estar limitado y, por tanto, existe un nmero mximo de tareas a realizar en cada fase.
Se trata de definir el mximo nmero de tareas que podemos tener en cada una de las fases (p.e: 3 tareas en la fase de planificacin; 2, en la fase de desarrollo; una, en la fase de pruebas, etc.). No se puede abrir una nueva tarea sin finalizar otra. Se pretende dar respuesta al problema habitual de muchas empresas de tener muchas tareas abiertas pero con un ratio de finalizacin muy bajo. Aqu lo importante es que las tareas que se abran se cierren antes de empezar con la siguiente.

4.

Control del Flujo La metodologa KANBAN no se aplica a un nico proyecto, sino que mezcla tareas y proyectos. Se mantiene a los trabajadores con un flujo de trabajo constante. Las tareas ms importantes en cola para ser desarrolladas Seguimiento pasivo para no tener que interrumpir al trabajador en cada momento. Nos permite hacer un seguimiento del trabajo realizado, almacenando la informacin que nos proporcionan las tarjetas

Diferencias entre SCRUM y KANBAN

SCRUM
Las iteraciones deben ser de tiempo fijo.

KANBAN
El tiempo fijo en las iteraciones es opcional. La cadencia puede variar en funcin del plan del producto y la mejora del proceso. Pueden estar marcadas por la previsin de los

eventos en lugar de tener un tiempo

pre-fijado. El equipo asume un compromiso de trabajo por iteracin El compromiso es opcional.

La mtrica por defecto para la planificacin y la mejora del proceso es la La mtrica por defecto para la planificacin y la mejora del proceso es el Lead Velocidad. Time (tiempo de entrega o tiempo medio que tarda una peticin en salir del ciclo) Los equipos deben ser multifuncionales. Los equipos pueden ser multifuncionales o especializados.

Las funcionalidades deben dividirse en partes que puedan completarse en No hay ninguna prescripcin en cuanto al tamao de las divisiones.

un sprint.
Deben emplearse grficos Burndown. Se emplea una limitacin WIP indirecta (por sprint). Se deben realizar estimaciones. No se pueden aadir tareas en medio de una iteracin. La pila del sprint pertenece a un equipo determinado. Se prescriben 3 roles (PP/SM/Equipo). No se prescriben diagramas de seguimiento concretos Se emplea una limitacin WIP directa (marcada por el estado del trabajo). Las estimaciones son opcionales Siempre que haya capacidad disponible, se pueden aadir tareas. Varios equipos o personas pueden compartir la misma pizarra Kanban. No hay roles prescritos.

En cada sprint se limpia el tablero de seguimiento.

La pila del producto debe estar priorizada.

El tablero Kanban es persistente.

La priorizacin es opcional.