UADER

Facultad de Ciencia y Tecnologa

LICENCIATURA EN SISTEMAS DE INFORMACIN
Ao 2013
Metodologas giles
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el
trmino gil aplicado al desarrollo de software. En esta reunin participan
un grupo de 17 expertos de la industria del software, incluyendo algunos de
los creadores o impulsores de metodologas de software. Su objetivo fue
esbozar los valores y principios que deberan permitir a los equipos
desarrollar software rpidamente y respondiendo a los cambios que puedan
surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades desarrolladas.
Tras esta reunin se cre La Alianza gil, una organizacin, sin nimo de
lucro, dedicada a promover los conceptos relacionados con el desarrollo gil
de software y ayudar a las organizaciones para que adopten dichos
conceptos. El punto de partida fue el Manifiesto gil, un documento que
resume la filosofa gil

Caractersticas del Manifiesto gil
- Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas. La gente es el principal factor de
xito de un proyecto software. Es ms importante construir un
buen equipo que construir el entorno. Muchas veces se comete
el error de construir primero el entorno y esperar que el equipo
se adapte automticamente. Es mejor crear el equipo y que ste
configure su propio entorno de desarrollo en base a sus
necesidades.

- Desarrollar software que funciona ms que conseguir una buena
documentacin. La regla a seguir es no producir documentos a
menos que sean necesarios de forma inmediata para tomar un
decisin importante. Estos documentos deben ser cortos y
centrarse en lo fundamental.

Caractersticas del Manifiesto gil
- La colaboracin con el cliente ms que la negociacin de un
contrato. Se propone que exista una interaccin constante entre
el cliente y el equipo de desarrollo. Esta colaboracin entre
ambos ser la que marque la marcha del proyecto y asegure su
xito.

- Responder a los cambios ms que seguir estrictamente un plan.
La habilidad de responder a los cambios que puedan surgir a los
largo del proyecto (cambios en los requisitos, en la tecnologa,
en el equipo, etc.) determina tambin el xito o fracaso del
mismo. Por lo tanto, la planificacin no debe ser estricta sino
flexible y abierta.
Principios
Los valores anteriores inspiran los doce principios del
manifiesto. Son caractersticas que diferencian un proceso
gil de uno tradicional. Los dos primeros principios son
generales y resumen gran parte del espritu gil. El resto
tienen que ver con el proceso a seguir y con el equipo de
desarrollo, en cuanto metas a seguir y organizacin del
mismo.
Principios
I. 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.

Principios
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.
Diferencias entre Metodologas gil y
Tradicionales
Metodologas Tradicionales Metodologas giles
Basadas en normas provenientes de
estndares seguidos por el entorno de
desarrollo
Basadas en heursticas provenientes de
prcticas de produccin de cdigo
Cierta resistencia a los cambios Especialmente preparados para cambios
durante el proyecto.
Procesos mucho ms controlados con
numerosas polticas y normas
Procesos menos controlados con menos
principios
El cliente interacta con el equipo de
desarrollo mediante entrevistas
El cliente es parte del equipo de desarrollo
Existe un contrato prefijado No existe contrato tradicional o al menos
es bastante flexible
Grupos grandes y posiblemente
distribuidos
Grupos pequeos (menos de 20) y
trabajando en el mismo sitio
Mas roles Pocos roles
La arquitectura de software es
esencial
y se expresa mediante modelos
Menos nfasis en la arquitectura del
software
Algunas Metodologas giles
Programacin Extrema (Extreme Programming, XP)
SCRUM
Crystal Methodologies
Dynamic Systems Development Method (DSDM).
Adaptive Software Development (ASD).
Feature-Driven Development (FDD).
Lean Development (LD).
Feature Driven Development (FDD)

PROGRAMACIN EXTREMA
(EXTREME PROGRAMMING, XP)
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. 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.

Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementacin.
3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de
tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso.
PROGRAMACIN EXTREMA
(EXTREME PROGRAMMING, XP)
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe
presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el
software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el
mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio
posible con cada iteracin.

Algunas de las prcticas de XP son:
El juego de la planificacin, hay una comunicacin frecuente el cliente y los programadores. El
equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las
historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada
iteracin.

Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas
seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El
trabajo extra desmotiva al equipo.

Entregas pequeas, producir rpidamente versiones del sistema que sean operativas, aunque no
cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para
el negocio. Una entrega no debera tardar ms 3 meses.
SCRUM
Define un marco para la gestin de proyectos, que estn cambiando constantemente de
requisitos, el desarrollo se realiza mediante iteraciones llamadas sprints que duran
mximo treinta (30) das, en donde el resultado de cada sprint es un incremento
ejecutable que se muestra al cliente.
Uno de los elementos ms usados es la realizacin de reuniones a lo largo del proyecto, en
especial las reuniones diarias de 15 minutos del equipo de desarrollo para coordinar e
integrar el trabajo realizado.

Ventajas

Seguimiento del proyecto para ir controlando el avance.
Evita el estancamiento del proyecto.
Seguimiento del equipo que permite ajustar los desfases y fortalecer las habilidades de
cada una de las personas que lo conforman.
Al final se obtiene un Software que incrementa su funcionalidad con cada sprint
Se tienen mecanismos de control para las variables cambiantes con el entorno.
Progreso en el producto con requerimientos inestables.
Aumenta la comunicacin con el equipo y el cliente obtiene feedback frecuente sobre el
producto.

Crystal Methodologies
Propone distintos procesos a aplicar segn tres variables bsicas: el tamao del
proyecto, la criticidad y las prioridades del mismo.
Los miembros del equipo en conjunto son los que definen el proceso a seguir en el
proyecto. Enfatiza la comunicacin del equipo.
El desarrollo de software se considera un juego cooperativo de invencin y
comunicacin limitado por los recursos a utilizar. Se enfatiza en la necesidad de
invertir esfuerzos en mejorar las habilidades y destrezas del equipo de trabajo, as
como tener polticas de trabajo en equipo bien definidas las cuales dependen del
tamao del equipo estableciendo una clasificacin por colores eje Crystal Clear (3 a
8 miembros), Crystal Yellow (10 a 20 miembors), Crystal Orange (25 a 50
miembros), Crystal Red (50 a 100 miembros) y Crystal Blue (para ms de 100
miembros). Por ejemplo, Crystal Clear, la metodologa ms ligera de este conjunto,
esta dirigida a la comunicacin de equipos pequeos que desarrollan software cuya
criticidad no es elevada. Tiene asociadas siete caractersticas: liberacin frecuente
de funcionalidad, mejora reflexiva, comunicacin osmtica, seguridad personal,
atencin, fcil acceso para usuario expertos y requisitos para el entorno tcnico.










Mtodos de Desarrollo de Sistemas
Dinmicos
(Dynamic Systems Development Method (DSDM))
Define el marco para desarrollar un proceso de produccin de software. Nace
en 1994 con el objetivo de crear una metodologa RAD (Rapid Application
Development) unificada. Divide el proyecto en tres fases: pre-proyecto, ciclo
de vida del proyecto y post-proyecto especificando de forma rigurosa la
arquitectura y gestin del proyecto.
As, propone cinco fases en el desarrollo del proyecto: estudio de la
viabilidad y estudio del negocio que constituyen la etapa de pre-proyecto; y,
de forma iterativa, modelado funcional, diseo y construccin y finalmente
implementacin, adems de una adecuada retroalimentacin a todas las
fases. Sus principales caractersticas son interaccin con el usuario, poder
del equipo de desarrollo, liberaciones frecuentes de funcionalidad, regirse
siguiendo las necesidades del negocio, desarrollo iterativo e incremental,
adaptacin a los cambios reversibles, fijar el nivel de alcance al comienzo del
proyecto, pruebas durante todo el desarrollo y eficiente y efectiva
comunicacin.
Desarrollo Basado en Funciones
(FDD)
FDD con sus siglas en ingls Feature Driven Development es un
enfoque gil para el desarrollo de sistemas. Dicho enfoque no
hace nfasis en la obtencin de los requerimientos sino en como
se realizan las fases de diseo y construccin. Sin embargo, fue
diseado para trabajar con otras actividades de desarrollo de
software y no requiere la utilizacin de ningn modelo de proceso
especfico. Adems, hace nfasis en aspectos de calidad durante
todo el proceso e incluye un monitoreo permanente del avance
del proyecto. Al contrario de otras metodologas, FDD afirma ser
conveniente para el desarrollo de sistemas crticos.
Desarrollo Basado en
Funciones (FDD)
En conclusin FDD:
- Es un proceso que ayuda al equipo a producir resultados
peridicos y tangibles.
- Esta metodologa utiliza pequeos bloques que contienen
la funcionalidad del sistema, llamados features.
- Organiza los bloques que estn relacionados entre s, en
una lista llamada feature set. Hace nfasis en la obtencin
de resultados cada dos semanas.
- Incluye estrategias de planificacin que hacen que las
features puedan desarrollarse en dichos lapsos.
Investigaciones Wicc 2013
Del anlisis de literatura existente, encuestas realizadas por investigadores,
experiencias exitosas, asociacin a comunidades de desarrolladores giles locales y
regionales, hemos obtenido informacin de las metodologas giles vigentes.
Hicimos una primera seleccin para analizar en detalle, teniendo en cuenta
criterios como: (a) la metodologa ms presente en Internet, (b) la metodologa
ms documentada, (c) la metodologa con certificaciones y entrenamiento, (d) la
metodologa con comunidad propia, (e) la metodologa ms utilizada por
organizaciones y (f ) la metodologa ms utilizada en proyectos software; esto dio
como resultado la seleccin de:
Agile Project Management
Crystal Methods
Dynamic System Development Methods
Extreme Programming
Scrum
Test Driven Development
Resultados
Los equipos giles estn utilizando XP,
Scrum, sus variantes y FDD.
Las prcticas giles ms utilizadas son las reuniones diarias.
Las principales razones para implantar la agilidad son: incrementar el
time-to-market, gestionar los cambios de prioridades y alinear el
negocio e IT.
Las prcticas menos utilizadas son: BDD5, la entrega continua y la
programacin por pares.
Los procesos giles son apropiados para una gran proporcin de
proyectos.
Las prcticas que ms afectaron la calidad de las entregas fueron: guas
de cdigo comunes, refactorizacin (realizar modificaciones en el
cdigo con el objetivo de mejorar su estructura interna, sin alterar su
comportamiento externo), test de regresin y la integracin continua.

Conclusin
Las metodologas giles no son adecuadas para cualquier tipo de organizacin y
proyecto. Hay que tener en cuenta unas cuantas cosas para tomar la decisin de apostar
por una metodologa de este tipo. Una de las grandes limitaciones de estas metodologas
es su uso en grandes
equipos, aunque hay experiencias que demuestran que con mayor control es posible
aplicarlas. Se estn desarrollando trabajos de investigacin que permitan determinar la
forma de aplicar metodologas giles en grandes proyectos. Sin embargo cuando los
requisitos no se pueden definir con detalle o cambian a menudo, las metodologas giles
ofrecen mecanismos efectivos para gestionarlos. La gran barrera suele ser el cliente, que
debe estar muy unido al equipo de desarrollo e involucrado en el proyecto.
Si se decide apostar por una metodologa gil es importante depositar toda la confianza
en los desarrolladores y involucrarles en la toma de decisiones. Es una prctica bsica. La
confianza en el equipo de desarrollo, el compromiso y la comunicacin son las piezas
clave para el funcionamiento y la implantacin de este tipo de metodologas.
El hecho de no tener equipos ubicados en el mismo espacio fsico puede hacer que se
desve el foco de la metodologa y se pierdan los beneficios de la interaccin.