Documente Academic
Documente Profesional
Documente Cultură
LAS METODOLOG
IAS AGILES
A principios de la decada del 90, surgio un enfoque que fue bastante
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. El enfoque fue planteado por
primera vez por Martin y se dio a conocer en la comunidad de Ingeniera de
Software con el nombre de RAD o Rapid Application Development. RAD
consista en un entorno de desarrollo altamente productivo, en el que participaban grupos peque
nos de programadores utilizando herramientas que
generaban c
odigo en forma automatica tomando como entradas sintaxis de
alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo. La historia de las
Metodologas Agiles
y su apreciacion como tales en la comunidad de la Ingeniera de Software tiene sus inicios en la creacion de una de las metodologas
utilizada como arquetipo: XP - eXtreme Programming, que nace de la mente
de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham. Durante 1996, Beck es llamado por Chrysler como asesor del proyecto Chrysler
Comprehensive Compensation (C3) payroll system. Dada la poca calidad
del sistema que se estaba desarrollando, Beck decide tirar todo el codigo
y empezar de cero utilizando las practicas que el haba ido definiendo a lo
largo del tiempo. El sistema, que administra la liquidacion de aproximadamente 10.000 empleados, y consiste de 2.000 clases y 30.000 metodos, es
puesto en operaci
on en Mayo de 1997 casi respetando el calendario propuesto. Como consecuencia del exito de dicho proyecto, Kent Beck dio origen
a XP iniciando el movimiento de metodologas agiles al que se anexaran
otras metodologas surgidas mucho antes que el propio Beck fuera convocado
por Chrysler. Es as como que este tipo de metodologas fueron inicialmente
llamadas metodologas livianas, sin embargo, a
un no contaban con una
aprobaci
on pues se le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el pasar de los a
nos, en febrero de 2001, tras
una reuni
on celebrada en Utah-EEUU, nace formalmente el termino agil
aplicado al desarrollo de software. En esta misma reunion participan un
grupo de 17 expertos de la industria del software, incluyendo algunos de los
creadores o impulsores de metodologas de software con el objetivo de esbozar los valores y principios que deberan permitir a los equipos desarrollar
software r
apidamente 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 documentaci
on que se genera en cada una de las actividades desarrolladas. Tras esta reuni
on se creo The Agile Alliance, una organizacion,
sin
animo de lucro, dedicada a promover los conceptos relacionados con el
desarrollo
agil de software y ayudar a las organizaciones para que adopten
3
dichos conceptos. El punto de partida fue el Manifiesto Agil,
un documento
que resume la filosofa
agil.
USAR METODOLOG
POR QUE
IAS AGILES?
METODOLOG
IA AGIL
DE DESARROLLO DE SOFTWARE
CRYSTAL
En los inicios de 1990, en un estudio realizado en IBM se llego a los siguientes acuerdos (Cockburn, 2001). Los equipos exitosos enfatizaban que no
haban seguido metodos formales ni herramientas CASE y que haban estimulado la comunicaci
on y los test. Los equipos con problemas no entendan
sus fallas o si haban cumplido con los metodos formales.
Qu
e es Crystal Clear
Por ejemplo.
- Clear es para equipos de hasta 8 personas o menos.
- Amarillo para equipos entre 10 a 20 personas.
- Naranja para equipos entre 20 a 50 persona.
- Roja para equipos entre 50 a 100 personas.
- Azul para equipos entre 100 a 200 personas.
criticidad.
a. De acuerdo a su tama
no
Se le asigna un valor en funcion del n
umero de personas que participaran.
Por regla general se eligen valores de la siguiente secuencia:
- 6 (proyectos entre 3 y 6 personas)
- 20 (proyectos entre 7 y 20 personas)
- 40 (proyectos entre 21 y 40 personas)
- 100 (proyectos entre 41 y 100 personas)
- 200 (proyectos entre 101 y 200)
b. De acuerdo a su Criticidad: Se le asigna una de las siguientes opciones
en funci
on del peor de los casos que se pueda producir en el caso de un
fallo del sistema.
- L: Perdida de una Vida
- E: Importante perdida economica que puede poner en riesgo la
continuidad de la organizaci
on. (Dinero Esencial)
- D: Perdida econ
omica no significativa (Dinero Discrecional)
- C: Comodidad.
C
odigo de Colores
La familia cristal dispone de un codigo de color para marcar la complejidad
de una metodologa: cuanto mas oscuro un color, mas pesado es el metodo.
Cuanto m
as crtico es un sistema, mas rigor se requiere. El cromatico se
aplica a una forma tabular elaborada por Cockburn que se usa en muchas
metodologas agiles para situar el rango de complejidad. Caractersticas
1) Entrega frecuente. Consiste en entregar software a los clientes con
frecuencia, no solamente en compilar el codigo. La frecuencia dependera
del proyecto, pero puede ser diaria, semanal o mensual.
2) Comunicaci
on osm
otica. Todos juntos en el mismo cuarto. Una variante
especial es disponer en la sala de un experto dise
nador senior y discutir
respecto del tema que se trate.
3) Seguridad personal. Hablar con los compa
neros cuando algo molesta
dentro del grupo.
4) Foco. Saber lo que se est
a haciendo y tener la tranquilidad y el tiempo
para hacerlo.
5) F
acil acceso a usuarios expertos. Tener alguna comunicacion con
expertos desarrolladores.
El C
odigo Gen
etico