Metodologas giles

Historia

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

RAD
En 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 productivo
Grupos pequeos de programadores
Herramientas 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 GIL

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.

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
tiempo
Las 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 funciona
Trabajo 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 GILES
XP- eXtreme Programming
SCRUM
Crystal Methodologies
Dynamic 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 SCRUM
Est 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 Clear
Se 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 Clear
Patrocinador
Usuario experto
Diseador principal
Diseador programador
Experto en negocios
Coordinador
Verificador
Escritor

Ventajas
Es 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

Desventajas
Falta 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 documentacin
Restricciones en cuanto a tamao de los proyectos
Problemas 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.