7/26/2019 Manifiesto Agil valores y principios

1/5

Scientia et Technica Ao XIII, No 34, Mayo de 2007. Universidad Tecnolgica de Pereira. ISSN 0122-1701 381

Fecha de Recepcin: 24 Agosto de 2006

Fecha de Aceptacin: 16 Marzo de 007

DEL MANIFIESTO GIL SUS VALORES Y PRINCIPIOS

RESUMENEl manifiesto gil es un documento que resume en cuatro valores y doce

principios las mejores prcticas para el desarrollo de software, basados en la

experiencia de 17 industriales del software, en procura de desarrollos ms

rpidos conservando su calidad. Este artculo presenta de manera general la

evolucin de las metodologas para el desarrollo de software y una resea de losvalores y principios del manifiesto gil.

PALABRAS CLAVES: Metodologas giles, manifiesto gil, desarrollo desoftware, metodologas pesadas, desarrollo gil.

ABSTRACTThe agile manifesto is a document that summarizes, in four values and twelve

principles, the best practices of software development based on 17 softwareprofessionals experience, on how to develop software quickly, yet keeping its

quality. This article presents, in a general manner, the evolution of

methodologies used to develop software and a short view of the values and

principles of said document

KEYWORDS: Agile methodologies, agile manifesto, agile development,software development,

ELICER HERRERA URIBEIngeniero de Sistemas.Docente auxiliar,

Universidad Tecnolgica de Pereira

eherrera@utp.edu.co

LUZ ESTELA VALENCIAAYALAIngeniero Industrial.

Docente auxiliar,Universidad Tecnolgica de Pereira

levayala@utp.edu.co

1. INTRODUCCIN

En la actualidad, las metodologas giles se conviertenen un modelo para los iniciados en el desarrollo de

software, estas metodologas presentan algunas ventajas

ante las metodologas pesadas pero son limitadas por el

tamao del proyecto y el nmero de programadores que

pueden intervenir. Sin embargo, resultan muy atractivaspara el desarrollo de aplicaciones en empresas de

software que estn iniciando o para el desarrollo de

software por mdulos, sin descuidar la calidad ygarantizando la actualizacin de la documentacin.

En este artculo se presenta el concepto de metodologas

giles. Se inicia con una breve resea histrica delsurgimiento de la computacin. A continuacin se

expone la idea de ciclo de vida del software. Luego

analizamos las metodologas pesadas que son las

antecesoras de las metodologas giles. Finalmente, se

explican los valores, principios y las implementaciones

de las metodologas giles.

2. RESEA HISTRICA

En el siglo XIX Charles Babbage concibi y diseo lamquina analtica[1], la primera mquina de propsito

general, la cual poda ser programada e implementaba elconcepto de almacenamiento de datos, bucles e

instrucciones de decisin, de modo que el programa se

ejecutaba sin la intervencin de una persona que la

operase.

Aunque esta mquina puede considerarse,conceptualmente, como el primer computador, en

realidad nunca se construy. Por tal razn, muchos

historiadores atribuyen el calificativo de primer

computador al Z3, construido en Alemania por KonradZuse en los 40`s, la cual era digital, multiusos y, a

diferencia de los dos primeros modelos (Z1 y Z2),

plenamente funcional. [2]

De manera simultnea en Inglaterra y Estados Unidos se

adelantaron proyectos de investigacin que aos ms

tarde dieron como resultado mquinas ms sofisticadas y

ms veloces, programables, de propsitos generales ycapaces de ejecutar un considerable nmero de tareas de

mayor complejidad.

Dado que el objetivo de este artculo no es el debate

dialctico respecto a la razn que puedan tener los

historiadores en cuanto a cundo y cul fue el primercomputador y cul fue el primer programa de computador

desarrollado; se acepta el reconocimiento dado por la

literatura existente sobre el inicio de la informtica y la

computacin, en los aos 50.

En la siguiente dcada, la programacin paso de serexterna (conexin de cables y dispositivos) a ser

almacenada en la memoria del computador; estos

primeros programas se caracterizaron por un alto grado

de dependencia entre los lenguajes, el computador y laspersonas que los escriban. Para enfrentar tal situacin

surgieron los lenguajes de alto nivel, los compiladores ylos programas almacenados en medios magnticos,

haciendo el proceso de elaboracin de programas ms

exigente, dadas las numerosas y nuevas posibilidades

respecto al uso del computador.

Sin embargo, en una disciplina naciente la falta detcnicas o metodologas, hicieron evidente el exceso en

los tiempos empleados, los sobrecostos, la insatisfaccin

de los usuarios o clientes; en definitiva, la baja calidad de

7/26/2019 Manifiesto Agil valores y principios

2/5

Scientia et Technica Ao XIII, No 34, Mayo de 2007. Universidad Tecnolgica de Pereira382

los programas. Esto fue lo que finalmente desemboc en

la llamada crisis del software.

Como respuesta a esta crisis, en la segunda mitad de la

dcada de los 60 se populariz el concepto de ingenierade software. Al formalizarse una metodologa para la

elaboracin de programas bajo conceptos de ingeniera,

esta tarea se transform en un proceso riguroso

propendiendo por el cumplimiento de los cronogramas,los presupuestos, y lo ms importante, la satisfaccin del

cliente.

Durante el proceso de evolucin de la ingeniera delsoftware, se la ha concebido y definido de diversas

formas, al respecto la IEEE (IEEE93), dice: La

Ingeniera de Software consiste en la aplicacin de unenfoque sistemtico, disciplinado y cuantificable hacia el

desarrollo, operacin y mantenimiento del software.

En general la ingeniera de software establece losmtodos, los principios y las reglas para obtener software

confiable de excelente calidad, a partir de un enfoquesistmico.

3. CICLO DE VIDA

Tradicionalmente se reconoce que, si bien, producido por

el hombre, el software padece del rigor del llamado ciclode vida, que rige a todo en la naturaleza, tiene un

comienzo, un desarrollo, un proceso de maduracin y un

final. En el entorno del desarrollo de software, se

identifica el ciclo de vida como la secuencia de: anlisis yespecificacin de requerimientos, diseo de interfaces y

de software, implementacin y pruebas unitarias, de

integracin y del sistema, implantacin, y finalmente elmantenimiento (Figura 1)

Figura1. Modelo de cascada

En su comienzo las metodologas para el desarrollo desoftware fueron muy claras en llamar etapas a estos

conjuntos de actividades que se requieren, estableciendo

un grado fuerte de discrecin y secuencialidad. Cadaetapa tena un puesto en la secuencia, sus objetivos, sus

entradas y salidas, sus herramientas y mtodos; se poda

saber en qu etapa se encontraba un proyecto.

4. METODOLOGAS PESADAS

Existen varios modelos para el desarrollo de software,

entre los que se encuentran el modelo de cascada, el

modelo incremental y el modelo en espiral. Presentamosel modelo en cascada por ser el ms difundido, el de

mayor popularidad, y por considerar que refleja fielmente

los principios de las metodologas convencionales.

4.1 Caractersticas del modelo en cascada

Entre las ms notables caractersticas del este modelo se

pueden citar:

Prestan especial atencin al modelado y al

mantenimiento de los modelos.

Hacen nfasis en el control del proceso de desarrollo,

en la metodologa, en el rigor de las actividades

involucradas en el desarrollo, en las herramientas yen la notacin que se usa.

Hacen nfasis en la especificacin minuciosa del

proceso, con un alto nmero y especializacin deroles.

Limitan la participacin del cliente slo a reunionesde control, reduciendo de manera significativa sus

aportes.

Asumen que no se van a presentar cambios una vez

iniciado el proyecto y esperan que la arquitectura se

defina tempranamente.

Procuran documentar de manera rigurosa todaactividad desarrollada en el proyecto.

Ocasionan largos tiempos de espera por parte del

usuario para ver los resultados.

Se rige por la rigurosidad de un contrato.

5. METODOLOGAS GILES

Las metodologas giles resuelven los problemas

surgidos, posteriormente, a la masificacin del uso del

computador personal, dado que las expectativas y

necesidades por parte de los usuarios se hicieron msurgentes y frecuentes. Fue as como a comienzo de los 90

surgieron propuestas metodolgicas para lograr

resultados ms rpidos en el desarrollo de software sindisminuir su calidad.

Despus de casi una dcada de esfuerzos aislados, en

febrero de 2001 en Utah-EEUU, se reunieron 17empresarios de la industria del software

1 y como

resultado del debate respecto a las metodologas,

principios y valores que deben regir el desarrollo de

software de buena calidad, en tiempos cortos y flexible a

1 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,

Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,

Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,

Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

Implementacin

Diseo

Anlisis

Mantenimiento

Implantacin

S e m a n a s

7/26/2019 Manifiesto Agil valores y principios

3/5

Scientia et Technica Ao XIII, No 34, Mayo de 2007. Universidad Tecnolgica de Pereira 383

los cambios, se acept el trmino gil para hacer

referencia a nuevos enfoques metodolgicos en eldesarrollo de software.

En esta reunin se cre The Agile Alliance,organizacin sin nimo de lucro dedicada a promover los

conceptos relacionados con el desarrollo gil de software

y acompaar a las organizaciones para que adopten

dichos conceptos. Como punto de partida o basefundamental de las metodologas giles se redact y

proclam el manifiesto gil.

5.1. Manifiesto gil5.1.1 ValoresEl manifiesto hace nfasis en cuatro valores principales

que deben soportar el desarrollo de software:

a. Los individuos e interacciones por encima de losprocesos y las herramientas:para garantizar una mayor

productividad, las metodologas giles valoran el recursohumano como el principal factor de xito. Reconocen que

contar con recurso humano calificado con capacidadestcnicas adecuadas, facilidades para adaptarse al entorno,

trabajar en equipo e interactuar convenientemente con el

usuario, da mayor garanta de xito que contar conherramientas y procesos rigurosos.

Las metodologas giles reconocen que es msimportante construir un buen equipo de trabajo que las

herramientas y procesos. Procura primero conformar el

equipo y que ste defina el entorno mas conveniente de

acuerdo con las necesidades y las circunstancias.

b. Software funcionando por encima de la

documentacin: los profesionales relacionados con eldesarrollo de software, aunque no es su fuerte producirdocumentos, reconocen su importancia, al igual que

reconocen el tiempo y costo de mantener una

documentacin completa y actualizada.

En este sentido, las metodologas giles respetan la

importancia de la documentacin como parte del proceso

y del resultado de un proyecto de desarrollo de software,sin embargo, con la misma claridad hacen nfasis en que

se deben producir los documentos estrictamente

necesarios; los documentos deben ser cortos y limitarse a

lo fundamental, dando prioridad al contenido sobre la

forma de presentacin.

La documentacin, en las metodologas giles procura

mecanismos ms dinmicos y menos costosos como sonla comunicacin personal, el trabajo en equipo, la

autodocumentacin y los estndares.

c. La colaboracin del cliente por encima de lanegociacin del contrato: clsicamente el usuario ocliente es quien solicita e indica qu debe hacer el

software, y espera los resultados de acuerdo con sus

exigencias o expectativas, en los plazos establecidos.

Con frecuencia las dos partes, cliente y equipo de

desarrollo, asumen posiciones distantes, con ingredientesde rivalidad y prevencin al punto de tener que dedicar

tiempo valioso a la tarea de redactar, depurar y firmar el

contrato.

En este sentido, y complementando el valor que se da al

trabajo en equipo, las metodologas giles incluyen de

manera directa y comprometida al cliente o usuario en elequipo de trabajo. Es un ingrediente ms en el camino al

xito en un proyecto de desarrollo de software. Ms que

un ambiente de enfrentamiento en el cual las partes

buscan su beneficio propio, evadiendo responsabilidadesy procurando minimizar sus riesgos, bajo la filosofa de

las metodologas giles se busca el beneficio comn, el

del equipo de desarrollo y el del cliente. La participacindel cliente debe ser constante, desde el comienzo hasta la

culminacin del proyecto, y su interaccin con el equipo

de desarrollo, de excelente calidad.

Es el cliente quien sabe qu es lo que necesita o desea, el

ms indicado para corregir o hacer recomendaciones encualquier momento del proyecto.

d. La respuesta al cambio por encima del seguimientode un plan: dada la naturaleza cambiante de latecnologa y la dinmica de la sociedad moderna, un

proyecto de desarrollo de software se enfrenta confrecuencia a cambios durante su ejecucin.

Van desde ajustes sencillos en la personalizacin delsoftware hasta cambios en las leyes, pasando por la

aparicin de nuevos productos en el mercado,

comportamiento de la competencia, nuevas tendencias

tecnolgicas, etc. En este sentido, las metodologaspesadas con frecuencia caen en la idea de tener todocompleto y correctamente definido desde el comienzo.

No se cuenta entre sus fortalezas la habilidad para

responder a los cambios.

Por el contrario, en las metodologas giles la

planificacin no debe ser estricta, puesto que hay muchas

variables en juego, debe ser flexible para poder adaptarsea los cambios que puedan surgir. Una buena estrategia es

hacer planificaciones detalladas para unas pocas semanas

y planificaciones mucho ms abiertas para los siguientes

meses.

5.1.2 Principios del manifiesto gilBajo el concepto de principio se hace referencia a las

caractersticas que hacen la diferencian entre un procesogil y uno tradicional, y constituyen las ideas centrales

del desarrollo gil.

I. Nuestra mayor prioridad es satisfacer al clientemediante entregas tempranas y continuas de softwarecon valor. Para que una metodologa puede ser calificadacomo gil debe empezar a entregar software funcionando

y til en pocas semanas. Esto acaba con la incertidumbre,

7/26/2019 Manifiesto Agil valores y principios

4/5

Scientia et Technica Ao XIII, No 34, Mayo de 2007. Universidad Tecnolgica de Pereira384

desconfianza, insatisfaccin y desmotivacin producidas

en el cliente debido a las largas esperas para verresultados concretos.

Por lo tanto, la participacin del cliente se hace msproductiva en la medida en que el software esta siendo

probado, revisado y aprobado constantemente por quien

lo requiri y lo va a usar.

II. Bienvenidos los cambios a los requerimientos,incluso los tardos. Los procesos giles aprovechan loscambios para la ventaja competitiva del cliente. Esambicioso esperar que el cliente defina de maneradefinitiva todos sus requerimientos desde el comienzo y

peor an depender de ello para adelantar el proyecto.

Los cambios en los requerimientos deben asumirse como

parte del proceso de maduracin del software, debe

entenderse que cuando el cliente describe una necesidad

lo hace desde su perspectiva de usuario y que susconocimientos tcnicos lo pueden limitar para hacerse

entender completamente. Por lo tanto, las novedades enlos requerimientos pueden ser ajenas a la voluntad del

cliente.

Esta forma de ver los cambios en los requerimientos

induce al equipo de desarrollo a preferir los diseos

flexibles, lo cual aumenta la satisfaccin del cliente yredunda finalmente en beneficio del equipo de desarrollo

dada la comodidad en el diagnstico y ajustes que se

requieren en la etapa de mantenimiento.

III. Liberar frecuentemente software funcionando,desde un par de semanas a un par de meses, con

preferencia por los periodos ms cortos. El clientesiempre espera ver funcionando el programa, y es eso loque debe entregrsele. Pocas veces resulta conveniente,

despus de varios meses de trabajo, entregar slo

informes, modelos abstractos y planes. Se deben entregarresultados que incluyan software que el usuario pueda ver

trabajando. Si hay una circunstancia que motiva al

cliente es poder usar el software que solicit.

IV. Las personas del negocio y los desarrolladoresdeben trabajar juntos diariamente a lo largo delproyecto. Si bien el usuario desconoce lo referente allenguaje, el diseo de bases de datos, protocolos y dems

aspectos tcnicos, es l, quien nos puede sealar qu est

bien desde el punto de vista de la funcionalidad yresultados entregados por el software.

La intervencin oportuna del usuario puede resultar

decisiva en el xito de un proyecto y puede reducir el

costo o el tiempo. Esta intervencin puede ser en

cualquier momento, por lo cual el usuario debe estarinvolucrado todo el tiempo que dure el proyecto.

V. Construir proyectos en torno a individuosmotivados. Darles el entorno y apoyo que necesiten, y

confiar en ellos para que consigan hacer su trabajo.Elnimo, el sentido de pertenencia y la disposicin delequipo de trabajo son fundamentales en un proyecto de

software.

Parte de la motivacin est en la confianza que se

muestre en el equipo de trabajo, el respeto por sus aportes

y la comodidad que se les conceda en el momento de

realizar su trabajo. Todo lo que se pueda hacer por darnimo y motivacin a las personas participantes en el

proyecto debe hacerse.

VI. El mtodo ms efectivo y eficiente de compartirinformacin a, y dentro de un equipo de desarrollo, esla conversacin cara a cara. El trabajo en equipo debeapoyarse con un buen sistema de comunicacin tantoentre los miembros del equipo de desarrollo como entre

stos y el usuario. La mejor forma de hacerlo es hablando

personalmente; en la medida en que se evitan los

intermediarios en el proceso de comunicacin, como sonel papel, el telfono, el sistema de correo, y dems

medios de comunicacin, se incrementa la posibilidad deque el resultado sea el que se solicit.

VII. El software funcionando es la medida deprogreso. Cuando se trata de establecer el estado de un

proyecto, si bien existen diversas formas de medirlo, es la

cantidad de requerimientos implementados yfuncionando la que mas claridad y confiabilidad ofrecen

para establecer una medida del avance del proyecto.

Cualquiera otra que se presente ser superada por una

que involucre el software qu ya ha sido probado yaprobado por el usuario.

VIII. Los procesos giles promueven el desarrollosostenible. Los patrocinadores, desarrolladores yusuarios deberan ser capaces de mantener relacionescordiales. Se debe trabajar de forma que lo urgente no seimponga sobre lo importante. Desde el inicio del

proyecto se debe asignar responsabilidades y tareas de

manera que siempre se puedan cumplir.

IX. La atencin continua a la excelencia tcnica y albuen diseo incrementan la agilidad. Adems desatisfacer los requerimientos del usuario, los aspectos

tcnicos deben ser excelentes, independientemente de su

cantidad y complejidad. La calidad debe ser vista desde

dos perspectivas, la del usuario y la del equipo

desarrollador. Para el personal tcnico resulta evidenteque cuanta ms calidad tenga el software en cuanto a

diseo y estndares de implementacin, ms rendimientoobtiene en las tareas de pruebas, mantenimiento, y mayor

reusabilidad.

X. La simplicidad el arte de maximizar la cantidadde trabajo no hecho- es esencial. Se estima que elcliente nunca usar el 90% de la funcionalidad que se

implementa sin que est haya sido solicitada. Se deben

centrar los esfuerzos en lo que realmente importa, de

7/26/2019 Manifiesto Agil valores y principios

5/5

Scientia et Technica Ao XIII, No 34, Mayo de 2007. Universidad Tecnolgica de Pereira 385

manera simple, sin excederse en refinamientos y

optimizaciones innecesarias. Si funciona as, djelo as,si se va a perfeccionar u optimizar una rutina o programa

se debe evaluar minuciosamente el costo beneficio.

XI. Las mejores arquitecturas, requerimientos ydiseos emergen de los equipos auto-organizados.Los

principios que rijan en equipo de trabajo deben surgir de

su interior, los ajustes, estructuras administrativas debenformularse con la participacin de todo el equipo

teniendo siempre presente el bien colectivo, la

responsabilidad es de todos.

XII. En intervalos regulares, el equipo reflexionasobre cmo volverse ms efectivo, entonces afina yajusta su comportamiento como corresponde. Elequipo de trabajo est todo el tiempo dispuesto a cambiar

lo que sea necesario para mejorar. En cada tarea siempre

existe la posibilidad de hacerlo mejor la prxima vez.

5.2. Implementaciones del manifiesto gil

Existen en el mercado varias propuestas sobre cmoimplementar los valores y principios enunciados, a las

cuales los autores les colocan su toque personal

dependiendo de su experiencia o necesidad.

Entre las ms reconocidas se cuentan: SCRUM, CrystalMethodologies, Dynamic Systems DevelopmentMethod (DSDM), Adaptive Software Development(ASD), Feature-Driven Development (FDD), LeanDevelopment(LD) 2

6. CONCLUSIONES Y RECOMENDACIONES

Las metodologas giles son una alternativa interesantepara superar las debilidades de las metodologasconvencionales, pero, al igual que los computadores no

son en s mismos la solucin a los problemas de

procesamiento de informacin, stas no son la solucin atodos los problemas que enfrenta el desarrollo de

software.

Con el surgimiento de las metodologas giles, elconcepto de etapa se desvanece dando paso a la idea de

actividades, las cuales pueden ser organizadas a

comodidad del equipo de trabajo, en paquetes pequeos

conservando las mismas labores e identidad de las etapas

concebidas en las primeras metodologas.

Es claro que la informtica y la computacin son ciencias

nuevas, sin embargo ya es tiempo de que se les concedanespacios diversos y espontneos en los que las personas

que participan en los proyectos del rea puedan sentirse

ms productivos con base en las circunstancias

particulares de cada proyecto.

2 Para detalles sobre las diferentes propuestas de metodologas giles

ver la bibliografa.

La participacin directa del usuario durante todo el

proyecto es una garanta de xito, ya que la deteccin delos errores es ms oportuna y de igual manera su

correccin

Si bien los proponentes presentan su experiencia como

muestra de conveniencia en el uso de sus metodologas,

en trminos generales stas ofrecen mayores

probabilidades de xito en proyectos que cumplan ciertascondiciones como son no involucrar a ms de 15 o 20

programadores, que no requieran ms de cinco o seis

meses de trabajo, que el entorno de desarrollo sea

apropiado para la comunicacin entre los miembros delequipo, que el cliente o usuario este dispuesto y

disponible para el trabajo en equipo con el personal

tcnico y que los requerimientos puedan ser formuladossegn va avanzando el proyecto.

7. BIBLIOGRAFA

[1] PRESSMAN, Roger S. Ingeniera del Software: Un

enfoque prctico, Quinta edicin, 601 pginas,McGraw-Hill, Madrid 2002.

[2] LAWRECE, Shari P. Ingeniera del Software, Teora

y prctica, Primera edicin, 759 pginas, PrenticeHall, Buenos Aires 2002.

[3] McCONNELL, Steve. Desarrollo y gestin de

Proyectos informticos, Primera edicin, 691 pginas,McGraw-Hill, Mxico 1997.

[4] KENDALL, Kenneth. Anlisis y diseo de sistemas,

Tercera edicin, 913 pginas, Prentice Hall, Mxico,

1997[5] CRYSTAL, Agile project management.

http://crystalmethodologies.org/. Visitado en Marzo

2006[6] DSDM, Dynamic Systems Development Method.http://en.wikipedia.org/wiki/Dynamic_Systems_Devel

opment_Method#Principles_of_DSDM. Visitado en

Marzo 2006[7] FDD. Feature Driven Development

http://en.wikipedia.org/wiki/Feature_Driven_Develop

ment. Visitado en Marzo 2006

[8] Historia de la Informtica.http://ciberhabitat.gob.mx/museo/historia/texto/texto

_guerra.htm. Visitado en Marzo 2006.

[9] Manifesto for Agile Software Development.

http://agilemanifesto.org/ Visitado en Marzo 2006

[10] Mquina Analtica.

http://www.dma.eui.upm.es/historia_informatica/Doc/Maquinas/MaqAnaliticaBabbage.htm. Visitado en

Marzo 2006[11] XP. Extreme programming.

www.extremeprogramming.org. Visitado en Marzo

2006