Metodologıas AgilesDiego Antonio Lucena Pumar

Reservados algunos derechos de autor amparados en la Ley internacional del Copyright.

c© Diego Antonio Lucena Pumar.

Puedes libremente distribuir este documento, y usarlo para tus propios cometidos, pero nunca seranel de lucro.

En la Villa de Meco a 23 de Febrero de 2010.

Editor: Diego Antonio Lucena PumarMaquetado directamente en LATEX 2εPublica: Bubok

II

A mi profesor de economıa de la empresa: Antonio Aguayo Cordoba.

III

“La religion es el opio de los pueblos”

Karl Marx

The Times They Are A-Changin’Come gather ’round people

Wherever you roamAnd admit that the watersAround you have grownAnd accept it that soon

You’ll be drenched to the bone.If your time to you

Is worth savin’Then you better start swimmin’

Or you’ll sink like a stoneFor the times they are a-changin’.

Come writers and criticsWho prophesize with your pen

And keep your eyes wideThe chance won’t come again

And don’t speak too soonFor the wheel’s still in spinAnd there’s no tellin’ who

That it’s namin’.For the loser now

Will be later to winFor the times they are a-changin’.

Come senators, congressmenPlease heed the call

Don’t stand in the doorwayDon’t block up the hallFor he that gets hurt

Will be he who has stalledThere’s a battle outside

And it is ragin’.It’ll soon shake your windows

And rattle your wallsFor the times they are a-changin’.

Come mothers and fathersThroughout the land

And don’t criticize

VII

What you can’t understandYour sons and your daughters

Are beyond your commandYour old road is

Rapidly agin’.Please get out of the new one

If you can’t lend your handFor the times they are a-changin’.

The line it is drawnThe curse it is castThe slow one nowWill later be fast

As the present nowWill later be past

The order isRapidly fadin’.

And the first one nowWill later be last

For the times they are a-changin’.

Copyright c© 1963; renewed 1991 Special Rider Music

VIII

Prologo

Ahora solo daremos nociones de los que supone la ultima reflexion para el texto.Diremos que se presenta muy conciso. Este no debe ser valorado negativamente. Las demostraciones

y consecuencias son una potente herramienta para esclarecer conceptos, y evita, texto, que de algunamanera difumine la idea a transmitir. Partimos de la base de que los conceptos han de ser claros. Yeste ha sido el eje motor del texto.

Por otra parte anotar que el presente no trata de hacer una sıntesis de todas las metodologıas agiles.Por contra, abstrae las caracterısticas propias de cada una, y da una vision global del termino.

No busque, ni pretenda que se de un epılogo, con los pasos a seguir en cierta X metodologıa.Unicamente se tratan tres documentos formales.

El texto se impregna de conclusiones. Que supone para el autor todo esto. Es cuanto, desde mi puntode vista, aquello que enriquece al conjunto.

Sin mas, agracerle su lectura.Anoto que el texto ha sido elaborado por Diego Antonio Lucena Pumar.

IX

Indice general

Prologo IX

1. Introduccion 1

1.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. ¿Que aportan las Metodologıas Agiles? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3. La ecuacion del desarrollador de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4. Breve introduccion a su historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5. Descripcion general de las metodologıas principales . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.1. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.2. Crystal Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.3. Feature Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.4. XP (Extreme Programming) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.6. Contexto: Pasado y Presente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.7. Conclusion: El negocio de los proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Metodologıa y Burocracia 7

2.1. El equipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Modus operandi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3. Flujo de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2. Todos somos uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Conclusion: ¿Somos mas agiles? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4. Elementos burocraticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.2. El diagrama de red de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.3. Tabla de planificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.4. Diario de cambios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5. Conclusion: ¿Es operativo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Conclusion general de la obra 13

XI

A. Manifiesto para las metodologıas agiles 15A.1. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15A.2. Traduccion libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Bibliografıa 17

Indice alfabetico 19

XII

Capıtulo 1

Introduccion

1.1. Definiciones

Definicion 1.1.1. Las Metodologıas Agiles se fundamentan en la idea de que la proyeccion actual,basada en las clasicas teorıas de la Ingenierıa de Software, han quedado desfasadas para un mundo tan“cambiante”, como es el mercado del Software.

Definicion 1.1.2. Diremos para referirnos en este trabajo a extension como aquello que no es necesariopara entender nuestras aplicaciones.

Definicion 1.1.3. La incertidumbre juega un papel relevante en las Metodologıas Agiles, ya que, sepropone en estas, que el ingeniero sea consciente de la totalidad de proyecto que desarrolla.

Corolario 1.1.4. Por consecuencia, un ingeniero de Software trabajando con Metodologıas Agileses capaz de desarrollar cada una de las fases en sus distintas partes de desarrollo.

Definicion 1.1.5. Gran parte del problema actual de lo proyectos viene en el estado de “ejecucion dela aplicacion”.

Definicion 1.1.6. La velocidad es una variable multiplicativa, puesto que como hemos dicho, cadadesarrollador es consciente de la global del trabajo.

1.2. ¿Que aportan las Metodologıas Agiles?

While Agile techniques vary in practices and emphasis, they share common characteristics,including iterative development and a focus on interaction, communication, and the reduction ofresource-intensive intermediate artifacts. Developing in iterations allows the development team toadapt quickly to changing requirements. Working in close location and focusing on communicationmeans teams can make decisions and act on them immediately, rather than wait on correspondence.Reducing intermediate artifacts that do not add value to the ?nal deliverable means more resourcescan be devoted to the development of the product itself and it can be completed sooner.[DCC04]

Sintetizando diremos que aportan:

1

2 1.3. LA ECUACION DEL DESARROLLADOR DE SOFTWARE

Conocimiento: Para y por el desarrollador.

Comunicacion: Flujos entre el equipo de trabajares y el cliente.

Reduccion de “papeleo”: Menor burocracia administrativa.

1.3. La ecuacion del desarrollador de Software

Para cada desarrollador se cumple que [Chi04]:

Ambiente = (Incertidumbre + Experto)·V elocidad

Nota Hemos de decir que no se tiene en cuenta el factor psicologico lo que para el autor es realmenterelevante. Por ello se anade este nuevo porcentaje que formula la ecuacion:

Ambiente = (Incertidumbre + Experto + FactorPsiq.)·V elocidad

Desglosemos cada uno de los conceptos que aparecen en las ecuaciones:

Incertidumbre: De manera que se desconoce bastante, segun el contexto actual, de lo que puedepasar en las distintas fases del proyecto, por lo que, y sobre los pilares de las Metodologıas Agiles,se remarca la idea de que un desarrollador ha de conocer lo maximo de la aplicacion.

Experto: Cuanto es de experto en terminos globales. Ciertamente se derrumba la idea de que undesarrollador solo cumple una funcion dentro del proyecto. Ahora, tiene un cuantificador direc-tamente relacionado con su experiencia donde denotamos a niveles genericos su especializacionen el computo global de la aplicacion.

Factor Psicologico: Hemos de tener en cuenta que influye y de que manera en el proceso dedesarrollo. Proyecto en demasıa temporal acaban por mermar la paciencia de la mayorıa de losprogramadores (sino todos). Por ello este factor mide su grado de satisfaccion en las diferentesetapas de desarrollo.

Velocidad: Un trabajador tiene ademas un rendimiento directamente implicado con su experienciaademas de actitudes. Es por ello que determina junto con los anteriores el ambiente de desarrollode dicho trabajador sobre una aplicacion en concreto.

1.4. Breve introduccion a su historia

En la mitad de la decada de los noventa del siglo XX, surgieron por parte de ciertas organizacionesdiversas intenciones por formalizar algo que ya se venıa gestando a mediados de los ochenta de dichosiglo. Y eran, las Metodologıas Agiles, que rompıan cual reforma luterana los preceptos arcaicos de laIngenierıa de Software.

De modo que en 2001 por parte de las Universidades de Snowbird y Utah, se centralizaron esteconjunto de metodos bajo el nombre de “Metodologıas Agiles”.

La cronologıa se cuenta de la siguiente manera:

2

CAPITULO 1. INTRODUCCION 3

Metodlogıa Ano

Scrum 1986Crystal Clear 2004Feature Driven Development 1995XP 1996

Cuadro 1.1: Evolucion de las principales Metodologıas Agiles.

1.5. Descripcion general de las metodologıas principales

1.5.1. Scrum

Scrum surge como estandar de facto debido principalmente a la idea de aproximacion holısticaideada para el sector empresarial por Hirotaka Takeuchi e Ikujiro en 1986.

Los primeros pasos de Scrum fueron: Ken Schwaber y Jeff Sutherland en sus respectivas empresasde Software.

Basicamente consiste en una reunion en conjunto donde se fijan los objetivos y la temporalidad.Al finalizar dicho periodo se obtiene una version del Software y se planifica de nuevo otra etapa dedesarrollo.

The stated, accepted philosophy for systems development is that the development process is a wellunderstood approach that can be planned, estimated, and successfully completed. This has provenincorrect in practice. SCRUM assumes that the systems development process is an unpredictable,complicated process that can only be roughly described as an overall progression. SCRUM definesthe systems development process as a loose set of activities that combines known, workable tools andtechniques with the best that a development team can devise to build systems. Since these activitiesare loose, controls to manage the process and inherent risk are used. SCRUM is an enhancementof the commonly used iterative/incremental object-oriented development cycle.[Sch]

1.5.2. Crystal Clear

Ideado por Alistair Cockburn, contiene una familia de Metodologıas Agiles.Dicha metodologıas se centra en los desarrolladores, procurando equipo de 6 a 8 personas buscando

siempre un ambiente comodo y eficiente.

1.5.3. Feature Driven Development

Feature Driven Development es una metologıa agil que se ampara en el flujo entre usuario ydesarrolladores por medio de “metodos” que conducen el desarrollo del Software.

1.5.4. XP (Extreme Programming)

Ideado originalmente por Kent Beck, extreme programming, se fundamenta en la idea de que elSoftware debe ser adaptativo en cada una de sus fases.

Sus pilares principales son: simplicidad, comunicacion, retroalimentacion y coraje.

3

4 1.6. CONTEXTO: PASADO Y PRESENTE

Extreme Programming (XP) was conceived and developed to address the specific needs of soft-ware development conducted by small teams in the face of vague and changing requirements. Thisnew lightweight methodology challenges many conventional tenets, including the long-held assum-ption that the cost of changing a piece of software necessarily rises dramatically over the courseof time. XP recognizes that projects have to work to achieve this reduction in cost and exploit thesavings once they have been earned.[Bec99]

0 100 200 300 400 500 600 700 800 900 1000 11000

5

10

15

20

25

30

35

40

45

Figura 1.1: f(incertidumbre) = experiencia

1.6. Contexto: Pasado y Presente

Definicion 1.6.1. En terminos financieros vivimos en un mercado altamente competitivo y muy dinami-co.

En un mercado, repetimos, tan “dinamico” como es el del Software, las Metodologıas Agiles debidoa su fundamentos hermanan, con el presente. Hace algunos anos no tendrıan cabida, ya que, se tendıaa una menor heterogeneidad de Software y empresas que desarrollaran el mismo.

Por otra parte, estas metodologıas imponen para el contexto una frecuencia continua donde eldesarrollado es capaz mediante la ”agilidad“ en su trabajo, de asimilar cambios en la manera de construir

4

CAPITULO 1. INTRODUCCION 5

Software mucho mayor que con las tecnicas tradicionales.El concepto de organizacion dedicada a un unico proyecto ha quedado desfasado. Pasamos a una

vertiente donde todo el mundo quiere repartirse el ”pastel“. En especial, el de las administraciones publi-cas. Tecnologıas muy diversas hacen posible construir con Software una idea desde puntos filosoficos(en cuanto al mismo) distintos.

Por ello se supone que una empresa debe estar preparada para el mercado. Lo que demanda elmercado marcara su desarrollo. Y es, con las Metodologıas Agiles donde conseguimos esta verticalidad,y a la vez calidad, de progreso conceptual de los desarrolladores.

1.7. Conclusion: El negocio de los proyectos

Para finalizar el capıtulo tratamos a ”David contra Goliat“, es decir, a las grandes empresas deSoftware con la pequena y mediana empresa.

Por todo lo que acabamos de introducir, y sobre todo con el enfoque de la Ingenierıa de Softwaretradicional es tal la necesidad de recursos destinados a dicha ingenierıa que en proyectos sumamentegrandes para las Pyme se hace imposible el tratar llevarlas a cabo.

Las Metodologıas Agiles tienen mucho que decir en esto y es que aunque todavıa no lo hayamoshablado es el nucleo de nuestro trabajo, el agilizar lo tradicional, “recortar”, un modelo totalmentedesfasado, con mas de 60 anos de existencia. Se ha tratado de dar nuevos enfoques al mismo, pero loque empieza mal termina, por lo general, muy mal.

Ante la crisis de Software alla por la mitad de siglo XX se propusieron distintas metodologıas aunqueno se llego a un conjunto de ellas en forma de ciclos hasta los anos setenta. Pero, es que resulta, queen vez de tratar de volver a fundamentar, se uso material de antes, que ya por aquel entonces noresolvıa los ”modernos“ problemas. Por supuesto en los ochenta del mismo siglo y ante el crecimientoexponencial del Software, ya se constataron como autenticos dinosaurios inservibles para el desarrollodel Software.

Aun hoy las grandes empresas derivan estos ciclo primitivos presionados mayormente por orga-nizaciones, que se constituyen como autenticos gigantes en la computacion y que, es tremendamentecuestionable su ”etica“ ya que, se hacen llamar no gubernamentales, mas aun, son progubernamentales.

La empresa Pyme vive la peor de sus historias. Es cuestion de dıas, meses u horas el que seasabsorbido por otra gran empresa que derive tu filosofıa empresarial a modo dictatorial en los interesde mercado de la compradora. Antes esto, poco se puede hacer, el mundo es ”libre“.

En este contexto nacen las Metodologıas Agiles. De nuevo tratan en mayor medida de crear unSoftware: etico, didactico, y sobre todo (si cuestiones de mercado se lo permiten) mucho mas artesanal.

Contra esto, lo que sucedio, en los ochenta del siglo XX han sido sendos movimientos, los que hantratado por todos los medios de recordarle al mundo que los desarrolladores de Software son artistas,y los artistas no tienen leyes.

Imagine 50 people getting together to write a 20,000-line epic poem on cost and time. What wouldyou expect to find? Lots of arguments, for one thing. People trying to be creative, trying to do theirbest, without enough talent, time, or resources.

Who are the players in this drama? First, the people who ordered the poem. What do they want?They want something they can use to amuse themselves or impress their friends, not too expensive,and soon.[Coc]

5

Capıtulo 2

Metodologıa y Burocracia

Metodologias Agiles ⇐⇒ Requerimientos ⇐⇒ V ersiones parciales ⇐⇒ Iteracion ⇐⇒ Proyecto completo

(2.1)

2.1. El equipo

En la Ingenierıa de Software clasica el modelo de trabajo se basaba en grupos con una relaciones enla mayorıa de los casos extremadamente debiles. Es por ello, que las metodologıas a estudio proponenuna nueva vision respecto al conjunto, y al todo, ya que poco a poco iremos tratando los distintosestratos (en cuanto a la creacion del Software) para ası tener una idea de lo que realmente implica una“Metodologıa Agil”

2.1.1. Modus operandi

Sintetizando diremos que el eje central de comunicacion se basa en el cumplimiento de objetivos, demodo, que los participes del proyecto actuan segun sus capacidades, y en funcion de un tiempo estimanque su porcion de codigo estara listo para el dıa X a a la hora Y .

2.1.2. Definiciones

Definicion 2.1.1. En estos equipos de trabajo se dice que hay dos tipos de lıderes. Por una parte ellıder burocratico que trabaja como intermediario entre el mundo exterior y el equipo, y por otra partecada uno de los integrantes que como hemos dicho, fijan siempre con responsabilidad su objetivo.

Definicion 2.1.2. Las cuestiones de “lıder espiritual” quedan en un segundo plano. Lo importante esque el proyecto sea uno, y lo integren tanto desarrolladores como usuarios.

Corolario 2.1.3. La Metodologıa Extrema hace de los usuarios, desarrolladores.

7

8 2.2. ROLES

2.1.3. Flujo de trabajo

Hay un interesante flujo de trabajo entre los componentes del equipo. De modo que las reunionesson muy frecuentes. Se buscan dos objetivos. Desarrollar la apliacion, es el punto de vista puramentefuncional, y otro mas social, que es el progreso de cada uno de los integrantes, bajo las directrices quese marca ası mismo.

Con ello conseguimos que se habran nuevas puertas a dicho disenadores.

2.2. Roles

Definicion 2.2.1. Diremos que rol es un prototipado de comportamiento de una persona fısica.

2.2.1. Definiciones

Definicion 2.2.2. El termino “rol” tendra un caracter de guıa para cada uno de los integrantes. Ha dequedar claro que no se pretende etiquetar a las personas.

Definicion 2.2.3. Se dan en estas metodologıas tres roles principales, cada uno ordenados por priori-dad.

Definicion 2.2.4. El “rol” primero se denota como permanente.

Definicion 2.2.5. El “rol” segundo se denota como regular.

Definicion 2.2.6. El “rol” tercero se denota como ocasional.

Definicion 2.2.7. Recordemos de nuevo que uno de los objetivos es la retroalimentacion del equipo.

Corolario 2.2.8. El fondo es tratar de ser lo mas agiles posible.

Definicion 2.2.9. Los “roles” tratan de dar expresividad, discursion positiva al equipo.

2.2.2. Todos somos uno

El lıder tiene un papel en el equipo no mas relevante que cualquier otro participe del mismo. Demodo, que en el fondo se ahorra en cuanto a las comunicaciones puesto que cada uno, no ha de pasarpor el filtro de una figura que responda por todos y que lleve el peso del total de la aplicacion. Porcontra, aquı todos son peso y responsabilidad del trabajo. Repetimos, el principal cometido del lıder esactuar de intermediario entre el equipo y el mundo exterior y el de verificar que los plazo se cumplende acuerdo a lo propuesto.

2.3. Conclusion: ¿Somos mas agiles?

A lo largo del capıtulo, destaca, sin lugar a dudas, y ha sido el proposito, la palabra “agil”. El ejehorizontal de este trabajo no es desde luego el de sintetizar que suponen las “Metodologıas Agiles”. Porcontra, el autor, por todos los medios trata de mostrarle un conjunto de ideas, que tratan de solucionarun problema.

8

CAPITULO 2. METODOLOGIA Y BUROCRACIA 9

Probablemente las veamos como algo tremendamente ingenieril, pero desde luego, le aconsejo quese lea el manifiesto que adjuntamos en el apendice Para que se haga una idea de lo que supone, cuanrevolucionarias son, y como de nuevo, se vuelve a lo social, palabra que han tratado de borrar decualquier diccionario.

Las decisiones, la identidad, las herramientas, la organizacion, forman parte de un todo, por encimase situa uno mismo, el desarrollador de Software. Es como sı se organizasen en comunas, compartieransu Software y no respondieran mas que ante ellos. Lector: ¿Sabe de lo que estoy hablando?

El tema para este epıgrafe es la “agilidad”. Realmente estamos reduciendo pasos intermedios, lo queconlleva racionalmente a perder menos tiempo en temas burocraticos.

Esto desde luego es un hito, ya que, atienda, el mundo del Software cada vez se automatiza mas.Esto llega a terminos ciertamente difıciles de contextualizar. Se estan llegando ha hacer automatismosde automatismos.

Como deciamos en la anterior conclusion, el Software es una artesanıa. Creo que si se puederelacionar esta metodologıa con el hecho de que Software generado sea mas casero. Terriblementeimportante desde mi punto de vista. El ser “agil” no implica vivir de automatismos. “Agil” mas bien,sugiere en nuestra tematica, una persona preparada ara diferentes cambios, cambios que debido a suexperiencia y madurez uno ha de afrontar y superar. Y para ello tiene el apoyo de sus companeros ysu evolucion como intelectual del Software.

2.4. Elementos burocraticos

2.4.1. Definiciones

Definicion 2.4.1. Se dice que en las Metodologıas Agiles, para el desarrollo de la aplicacion, el conjuntode programadores se distribuye bajo comites.

Corolario 2.4.2. Por consecuencia se opone a la metodologıa tradicional basado en el trabajo yreunion a posteriori.

Definicion 2.4.3. Igualmente tenemos eventos frente a las clasicas actividades.

2.4.2. El diagrama de red de trabajo

Basicamente consiste en descomponer la aplicacion a realizar en distintos modulos de forma queorigine una red de trabajo con sus correspondientes relaciones.

2.4.3. Tabla de planificacion

Contiene de modo general cada una de las partes del proyecto. Desde esta perspectiva se componede los siguientes apartados:

1. Identificacion del equipo: Se ha de anotar todos los datos relevantes a los integrantes del equipo.

2. Defincion del proyecto: Es el esquema base para desarrollar la aplicacion.

3. Plan de proyecto: ¿Que metodologıa usamos?

4. Diagrama de relaciones: En el se detallan R, de como trabajan desarrolladores y usuario.

9

10 2.5. CONCLUSION: ¿ES OPERATIVO?

5. La lınea temporal de compromiso: Dependiendo de la metodologıas varia.

6. Recursos: Fijados previamente.

7. Diario de cambios: Que desglosaremos a continuacion.

Genero Desarrollo

Identificacion del equipo · · ·

Defincion del proyecto · · ·

Plan de proyecto · · ·

Diagrama de relaciones · · ·

La lınea temporal de compromiso · · ·

Recursos · · ·

Diario de cambios · · · (se vera en la siguiente seccion)

Cuadro 2.1: Ejemplo generico de la tabla de planificacion.

2.4.4. Diario de cambios

Se trata de tablas diarias que anotan la actividad realizada en el proyecto por parte de cada progra-mador.

La tabla tiene un aspecto, tal que ası:

Fecha Actividad

1 · · ·

2 · · ·

......

n · · ·

Cuadro 2.2: Ejemplo generico del diario de cambios.

2.5. Conclusion: ¿Es operativo?

La infraestrutura sintetiza lo mınimo y necesario para que un equipo desarrolle su trabajo. De modoque si somos mas agiles.

La tabla de planificacion es el documento final que da fe de la creacion del Software. Por otra partese adjunta un manual de usuario.

Para auditores de codigo se trabaja con comentarios en el mismo, ya que el trabajo aun en estadode fase de creacion es auditado y se verifica constantemente. Un codigo bien elaborado es un codigoque no necesita comentarios.

10

CAPITULO 2. METODOLOGIA Y BUROCRACIA 11

Existe como hemos comentardo una total cooperacion durante la elaboracion de la aplicacion. La re-troalimentacion es tremendamente importante. Cada uno de los integrantes es consciente de la totalidaddel trabajo.

11

Conclusion general de la obra

Para concluir trataremos aquello que ha sido descifrado a lo largo de los capıtulos, y es, el significadode las Metodologıas Agiles.

Metodologıa es una norma, con caracter de facto, que especifica una serie de pasos que hay queseguir para llegar a un resultado.

Por otra parte, el calificativo de agil hace de estas metodologıas mas livianas, en cuanto al pesoburocratico, en cuanto al desarrollo por parte de los disenadores del Software.

Lo que aquı tratamos tiene una vital importancia, y es la rebeldıa. Se trata de decir en todo momento,que por este camino, no llegamos a buen puerto. Sobretodo queremos dar nuevos puntos de vista, sobrelo que es una misma realidad, el construir Software.

Mas alla de los problemas propios de la empresa, aquı hemos tratado principalmente el metodo. Quesiempre buscaba dicha agilidad, necesaria para poder sobrevivir en un mercado tan difıcil. Igualmentehemos desglosado su matematica, y son apenas tres informes de caracter general.

Siempre, desde luego, a la hora de confeccionar el texto, pretendemos ser lo mas genericos posibles.Hablamos de una autentica forma de concebir los proyecto de Software a nivel industrial.

Permitanme lector, aclararle, que esta guerra, la tenemos todos. La guerra del gigante contra elpequeno.

13

Apendice A

Manifiesto para las metodologıasagiles

A.1. Principios

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuablesoftware.

2. Welcome changing requirements, even late in development. Agile processes harness change forthe customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a pre-ference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need,and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a developmentteam is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should beable to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjustsits behavior accordingly.

15

16 A.2. TRADUCCION LIBRE

A.2. Traduccion libre

Nota Fuente: http://es.wikipedia.org/wiki/Manifiesto agil. Contrastada.

1. Nuestra principal prioridad es satisfacer al cliente a traves de la entrega temprana y continua desoftware de valor.

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos agilesse doblegan al cambio como ventaja competitiva para el cliente.

3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un parde meses, con preferencia en los periodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a travesdel proyecto.

5. Construccion de proyectos en torno a individuos motivados, dandoles la oportunidad y el respaldoque necesitan y procurandoles confianza para que realicen la tarea.

6. La forma mas eficiente y efectiva de comunicar informacion de ida y vuelta dentro de un equipode desarrollo es mediante la conversacion cara a cara.

7. El software que funciona es la principal medida del progreso.

8. Los procesos agiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores yusuarios deben mantener un ritmo constante de forma indefinida.

9. La atencion continua a la excelencia tecnica enaltece la agilidad.

10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.

11. Las mejores arquitecturas, requisitos y disenos emergen de equipos que se auto-organizan.

12. En intervalos regulares, el equipo reflexiona sobre la forma de ser mas efectivo y ajusta suconducta en consecuencia.

16

Bibliografıa

[Bec99] Kent Beck. Extreme programming explained. 0201616416, 1999.

[Chi04] Gary Chin. Agile Project Management. Amacom, 2004.

[Coc] Alistair Cockburn. Agile Software Development. Highsmith Series Editors.

[DCC04] Mikael Lindvall David Cohen and Patricia Costa. An introduction to agile methods. Advancesin computers, Vol. 62, 2004.

[Sch] Ken Schwaber. Scrum development process.

17

Indice alfabetico

Agiles, 1agil, 8, 13etico, 5

agilidad, 4, 13artesanal, 5artistas, 5automatismos, 9

burocratico, 13

codigo, 10calificativo, 13clasia, 7competitivo, 4comunas, 9conjunto, 7cooperacion, 11crisis de Software, 5Crystal Clear, 3

Defincion del proyecto, 9desfasado, 5Diagrama de relaciones, 9Diario de cambios, 10didactico, 5difıcil, 13dinamico, 4disenadores, 8

ejecucion de la aplicacion, 1El “rol” primero, 8El “rol” segundo, 8El “rol” tercero, 8empresa Pyme, 5equipo, 7estratos, 7Experto, 2

expresividad, 8extension, 1extremadamente debiles, 7

facto, 13Factor Psicologico, 2factor psicologico, 2Feature Driven Development, 3flujo de trabajo, 8

genericos, 13gigante, 13guıa, 8

heterogeneidad de Software, 4

Identificacion del equipo, 9Incertidumbre, 2incertidumbre, 1Ingenierıa de Software, 1, 2, 7ingenieril, 9integrantes, 7

lıder burocratico, 7lıder espiritual, 7lıderes, 7La lınea temporal de compromiso, 10livianas, 13

matematica, 13mercado, 13mercado del Software, 1Metodologıa Agil, 7Metodologıa Extrema, 7Metodologıas Agiles, 9, 13

norma, 13

objetivos, 7

19

20 INDICE ALFABETICO

pequeno, 13persona fısica, 8Plan de proyecto, 9progubernamentales, 5prototipado, 8puntos filosoficos, 5

rebeldıa, 13recortar, 5Recursos, 10reforma luterana, 2relaciones, 7resultado, 13retroalimentacion, 11revolucionarias, 9rol, 8

Scrum, 3sintetiza, 10

tecnicas tradicionales, 5tablas diarias, 10

Universidades de Snowbird y Utah, 2

Velocidad, 2velocidad, 1

XP, 3

20