Metodologias Agiles enseñanza

8/19/2019 Metodologias Agiles enseñanza

http://slidepdf.com/reader/full/metodologias-agiles-ensenanza 1/47

Metodologías Ágiles, Programación Extrema

INDICE1. Introducción.....................................................................................................................................................3

Metodologías Agiles, programación extrema 1Lic. Horacio Kuna – ASC Sergio Caballero



2. La no metodología...........................................................................................................................................43. Metodologías.................................................................................................................................................54. Metodologías Agiles.....................................................................................................................................6 4.1. Características básicas .........................................................................................................................6 4.2 Antecedentes ...............................................................................................................................................7 4.3. Características principales .......................................................................................................................7 4.4. Diferencias con las metodologías tradicionales...................................................................................85. Las Metodologías .....................................................................................................................................126. Manifiesto para el Desarrollo de Software Ágil ......................................................................................17 7. XP ..................................................................................................................................................................187.1. Riesgos ....................................................................................................................................................207.2. Variables a considerar .........................................................................................................................227.3. Los alores...............................................................................................................................................227.3.1. Com nicaci!n .....................................................................................................................................227.3.2. Valentía...................................................................................................................................................237.3.3. Realimentación !feed"ac#$...................................................................................................................237.3.4. Sim licidad.............................................................................................................................................247.4. !rinci io" #$"ico".......................................................................................................................................247.5. Las acti"idades básicas en el desarrollo de sistema ..................................................................26 7.#. Las 12 $rácticas .....................................................................................................................................27 7.#.1. %esting ...................................................................................................................................................27 7.#.2. Programaci!n $or $ares de Programadores ..............................................................................287.#.3. &ise'o (im$le .....................................................................................................................................2%7.#.4. Re)actori*aci!n $ermanente ...........................................................................................................2%7.#.5 Cliente +n,(ite .....................................................................................................................................307.#.#. %aller de $lani)icaci!n .......................................................................................................................307.#.7. -ntegraci!n contin a .........................................................................................................................317.#. . Pe/ e'os releases ............................................................................................................................317.#.0. Pro$iedad Colecti"a del c!digo .....................................................................................................327.#.1 . stándares de Codi)icaci!n ..........................................................................................................327.#.11. Metá)oras del sistema .....................................................................................................................327.#.12. (emana de 4 oras .......................................................................................................................337.7. Conte%to de e&treme 'rograming ........................................................................................................33

7. . strategias de gerenciamiento ..........................................................................................................337.0. l es$acio de traba o ............................................................................................................................347.1 . strategias de $lani)icaci!n en XP .................................................................................................347.11. strategias de desarrollo. .................................................................................................................357.12. strategias de dise'o ........................................................................................................................357.13. strategias de testing. .......................................................................................................................357.14. -m$lementando XP ..............................................................................................................................36 7.14.1. -ntegraci!n del e/ i$o de traba o de)inici!n de necesidades6 ........................................36 7.14.2. Plani)icaci!n ......................................................................................................................................37 7.14.3. &ise'o. ...............................................................................................................................................37 7.14.4. &ise'o de $r ebas codi)icaci!n ...............................................................................................387.14.5. -ntegraci!n .........................................................................................................................................387.14.#. Re)actori*aci!n .................................................................................................................................38

. XP +$en (o rce .....................................................................................................................................3%0. Concl siones .............................................................................................................................................431 . ibliogra)ía ................................................................................................................................................46

1. Introducción

Metodologías Agiles, programación extrema Lic. Horacio Kuna – ASC Sergio Caballero



La sociedad del conocimiento, la globalización de la economía, el avance de latecnología, hacen cada vez más volátiles, tanto los requerimientos de lossistemas, como los entornos en los que se desarrollan, esto profundiza la “Crisisdel Software , siendo necesaria la revisión de las metodologías aplicadas hasta elmomento de manera de adaptar las metodologías, t!cnicas " procedimientos a loscambios que se producen#

$ lo largo del tiempo se ha pasado por varias etapas en el desarrollo de sistemas,en particular los peque%os " medianos sistemas sobre los que tratará este traba&o,desde la no metodología a la aplicación de metodología ingenieriles#'ese a los esfuerzos por aplicar m!todos ingenieriles al desarrollo de sistemas, seobserva en general que los pro"ectos software que no llegan a implementarse o

que no satisfacen las necesidades de los clientes, es creciente# (n este marco esque aparecen con cada vez más fuerza las llamadas “)etodologías *giles comoun intento de dar respuesta a esta situación#

2. La no metodología

Metodologías Agiles, programación extrema !Lic. Horacio Kuna – ASC Sergio Caballero



(n particular en los sistemas peque%os, se verifica que muchos de los desarrollosse caracterizan por la no aplicación de metodología alguna, en general utilizandoel criterio de “codificar " corregir , esta manera de desarrollar sistemas se puedeutilizar con dudoso resultado en peque%as aplicaciones, provocando en generalsistemas con enorme cantidad de bugs, en los que la etapa de depuración abarcamucho tiempo despu!s que el sistema esta en producción, con usuarios quesienten que nunca se cumplen sus e+pectativas iniciales, con costos superiores alos previstos " con plazos que nunca se cumplen#

ada la comple&idad de los sistemas de -nformación esta manera de desarrollar sistemas es casi imposible de aplicar en sistemas medianos " grandes#

.# )etodologías

Metodologías Agiles, programación extrema "Lic. Horacio Kuna – ASC Sergio Caballero



(n la ma"oría de las ingenierías los procesos constructivos son definidos "predictivos, comenzando de una manera determinada, ba&o las mismascondiciones se llega al mismo resultado, esto /0 (S lo que caracteriza el procesode construcción del Software, en este caso se trata de procesos empíricos dondela volatilidad de los requisitos es una característica en la ma"oría de los pro"ectos#

Las metodologías ingenieriles para el desarrollo de sistemas han estado presentesdurante mucho tiempo " en general no han sido mu" e+itosas, la crítica que se leshace es que son mu" burocráticas " “pesadas , por e&emplo )erisse, SS$ ),)etrica, etc#

(n muchos de los pro"ectos que aplican este tipo de metodologías se observa que

el cliente " el producto pasan a segundo plano, siendo el e&e del desarrollo elcumplimiento de la planificación " la documentación# (n el caso de los sistemasque se han implementado suele suceder que es mu" costosa la adaptación de losmismos a los nuevos requerimientos, que la documentación se desactualizarápidamente " que el proceso de 1estión de Configuración se hace muchas vecesinviable por los constantes cambios " el costo que implica mantener ladocumentación actualizada#

(ntonces por)*e no poner el e+e en el cliente, en el prod*cto - en la realidad .

2# )etodologías *giles

Metodologías Agiles, programación extrema #Lic. Horacio Kuna – ASC Sergio Caballero



.1. Características !"sicasComo reacción a lo que muchos consideran un fracaso surgió un grupo demetodologías que en principio se llamaron “)etodologías ligeras " ahora se lasconoce como “)etodologías ágiles , para mucha gente lo importante de ellas essu reacción ante la monumentalidad de las metodologías predictivas tradicionales#

$lgunas diferencias entre los m!todos ágiles " los tradicionales son3

• Los m!todos ingenieriles tradicionales ponen el acento en la planificación,por lo tanto es difícil su adaptación al cambio, en cambio los m!todos ágilesson adaptables en lugar de predictivos# 'ara los m!todos ágiles el cambioes una característica del proceso de desarrollo " están preparados para

adaptarse a estos cambios#

• Los m!todos tradicionales están orientados a los procesos " los *giles a lagente# 'ara los m!todos *giles la base del !+ito esta en el equipo detraba&o " no en la 'lanificación# La base de las metodologías tradicionaleses la documentación a diferencia de las metodologías ágiles que su base esel código fuente#

Los m/todos 0giles son adapta"les en l*gar de predicti osLos m/todos 0giles est0n orientados a la gente - no orientados al proceso

.2 #ntecedentes

Metodologías Agiles, programación extrema $Lic. Horacio Kuna – ASC Sergio Caballero



Se detectan antecedentes de este tipo de metodologías en forma paralela envarios lugares del mundo3

"namic S"stem development )ethod, en (uropa#

4eature 5 riven evelopment, en $ustralia

6', Cr"stal, $daptative Software evelopment, Scrum en (stados 7nidos#

.$. Características %rinci%ales

Los m!todos ágiles cambian significativamente algunos de los !nfasis de losm!todos ingenieriles#La diferencia inmediata es que son menos orientados al documento, e+igiendo unacantidad más peque%a de documentación para una tarea dada# Se trata dem!todos orientados al código siguiendo un camino que dice que la parteimportante de la documentación es el código fuente#Los m!todos ingenieriles tienden a intentar planear una parte grande del proceso

del software en gran detalle para un plazo largo de tiempo, esto funciona bienhasta que las cosas cambian# $sí que su naturaleza es resistirse al cambio# 'aralos m!todos ágiles, los cambios son bienvenidos# -ntentan ser procesos que seadaptan " crecen en el cambio, incluso al punto de cambiarse ellos mismos#Los m!todos ágiles están orientados a la gente " no orientados al proceso como lama"oría de los m!todos ingenieriles# La meta de los m!todos ingenieriles esdefinir un proceso que funcionará bien con cualquiera que lo use# Los m!todoságiles afirman que lo central para el !+ito de un pro"ecto son las habilidades delequipo de desarrollo, de modo que el papel del proceso es apo"ar al equipo dedesarrollo en su traba&o# (+plícitamente puntualizan el traba&ar a favor de lanaturaleza humana en lugar de en su contra " enfatizan que el desarrollo desoftware debe ser una actividad agradable para quien la desarrolla#

. . Di&erencias con las metodologías tradicionales Metodologías Agiles, programación extrema %

Lic. Horacio Kuna – ASC Sergio Caballero



Separación de Diseño y Construcción / Diseño y construcción integrados

Las metodologías ingenieriles tradicionales se basan en realizar un plan " un

dise%o " despu!s construir la aplicación lo más e+acta posible de loplaneado " dise%ado, por lo tanto el proceso de construcción es “menosintelectual " predecible#

La pregunta es si esto es posible en los pro"ectos software, 8es factible que elproceso de construcción sea predecible9, basta sólo recordar en nuestrae+periencia personal cuantas veces los programadores “destrozaron el dise%ooriginal para que sea posible su implementación# (n general se está utilizando el

formalismo 7#)#L# :Lengua&e 7nificado de )odelado; pero muchos lo reconocencomo bueno en el papel pero con muchos inconvenientes a la hora de la etapa deprogramación#0tro problema es el costo comparativo# Cuando se constru"e un puente, el costodel esfuerzo en el plan es apro+imadamente un <=> del total, siendo el resto laconstrucción# (n los pro"ectos software basados en metodología predictivas lacantidad de tiempo utilizada codificando es mucho menor#

Requisitos estables / Impredecibilidad de los Requisitos?ace muchos a%os, los sistemas de información se caracterizaban por suestabilidad " predicibilidad, pero es una realidad que la globalización " losconstantes cambios tecnológicos que vivimos hacen que los requisitos sean cadavez más volátiles, los cambios en muchos casos se producen en forma diaria, por cierto nuestro país es un ícono de esta situación, entonces si se esta traba&andoen procesos de alta impredictibilidad no se puede usar una metodología predictivade acuerdo a la opinión de quienes sostienen las metodologías ágiles#

Grandes cambios en cada versión / Iteraciones

Metodologías Agiles, programación extrema &Lic. Horacio Kuna – ASC Sergio Caballero



@efinamiento sucesivo, desarrollo incremetal, interactivo, espiral, prototipo, etc#,muchos son los nombres pero la base conceptual es la misma, se trata de producir en forma frecuente versiones que funcionen " que sean depuradas hasta llegar alproducto final que satisfaga al cliente6' sugiere iteraciones de entre una " tres semanas# SC@7) propone realizar unrelease por mes# Cristal estira aun más# La tendencia, es hacer las interaccioneslos mas cortas posibles, esta es la manera de garantizar que los cambios quetiene cada nueva versión del sistema son tan peque%os que el impacto de unamodificación en los requisitos es mucho menor que en el caso de los sistemasdonde cada versión contiene grandes cambios#(sto no significa que no se pueda fi&ar un presupuesto para software por

adelantado# Lo que significa es que no se puede fi&ar el tiempo, precio " alcancede manera “dura # La manera ágil usual es fi&ar tiempo " precio " permitir que elalcance pueda “moverse de manera controlada#

Clientes pasivos / Clientes activos

Las metodologías tradicionales suelen asignarle a los clientes un rol secundario,son casi 1*n mal necesario que cumplen un rol en especial en las primeras etapas

del ciclo de vida " despu!s que el producto está terminado, prácticamente nointervienen en la construcción del mismo'ara los defensores de las metodologías ágiles !sta es una de las principalescausas del fracaso de muchos pro"ectos, el ob&etivo es que el usuario participe enforma activa a lo largo de todo el ciclo de vida#

Líderes de proyecto con rol central / quipos de desarrollo con rol

centralLas metodologías de desarrollo de sistemas basadas en procesos predictiblesconsideran a los programadores en un rol “pasivo que tienen prácticamente que“obedecer el dise%o establecido " su opinión usualmente no es tenida en cuenta#

Metodologías Agiles, programación extrema 'Lic. Horacio Kuna – ASC Sergio Caballero



Los partidarios de las metodologías ágiles opinan que para poder e&ecutar pro"ectos se requiere un equipo mu" eficaz de desarrolladores# (l equipo necesitaser eficaz tanto en la calidad de los individuos como en la manera en quefuncionan &untos en equipo#

(n esta filosofía las personas no se consideran como recursos sino como actorescentrales que deben tomar decisiones t!cnicas importantes " en algunos casoscomo 6' son los que pueden estimar el tiempo que tomará el traba&o#

La base es la plani!icación / La base son las pruebas

Lo que guía el desarrollo en las metodologías ágiles son las pruebas, que sondise%adas entre el equipo de desarrollo " el cliente que se integra a eseequipo antes de la codificación# $ diferencia de las metodologíastradicionales donde lo que guía el desarrollo es la documentación

"etrica rígida / m#trica !le$ible

Los m!todos tradicionales consideran más eficaz la gestión basada en m!tricas,

aplicando t!cnicas específicas para establecer esas m!tricas :punto de función 5Cocomo, por e&emplo;#

Los defensores de las metodologías ágiles consideran que el desarrollo desoftware tiene características tales que la gestión basada en m!tricas lleva eltrastorno de la medida a niveles mu" importantes# Se considera más eficaz usar un estilo delegatorio de administración, donde por e&emplo los programadores sonlos que establecen los tiempos del desarrollo#

Metodologías Agiles, programación extrema 1(Lic. Horacio Kuna – ASC Sergio Caballero



Cuadro com%arati'o

Metodologías Ágiles Metodologías no Ágiles1rupos peque%os :A <B integrantes; "traba&ando en el mismo sitio#

1rupos grandes de traba&o#

)enos !nfasis en la arquitectura# La arquitectura es esencial#

(l cliente es parte del equipo de desarrollo:además in situ;#

(l cliente interactDa con el equipode desarrollo mediante reuniones#

'eque%os cambios en cada versión 1randes cambios en cada versión

@ol central del equipo de desarrollo @ol central del líder de pro"ecto "dise%adores

esarrollo basado en pruebas esarrollo basado en laplanificación

/o e+iste un contrato tradicional o almenos es bastante fle+ible#

(+iste un contrato prefi&ado#

ise%o " construcción integrados Separación dise%o " construcción

4ácilmente adaptable a los cambios ifícil de adaptar a los cambios




(. Las Metodologías%& '&rogramación $trema(4ormalmente el t!rmino (%treme 'rogramming se dio a conocer en un

artículo en la edición de octubre de <EEF de la revistaDistri"*ted Comp*ting , en elque se relataba la e+periencia del (quipo C. en el desarrollo del sistema de pagode Chr"sler, me&or conocido comoC r-sler Compre ensi e Compensation. (ntrelos miembros del equipo C. se encontraban Gent HecI, @on Jeffries " )artin4owler# HecI es conocido como el padre de 6' gracias a la publicación, en <EEEde (%treme 'rogramming (%plained #

$unque el sistema de Chr"sler de&ó de utilizarse a finales del a%o B=== elmensa&e de 6' está cada vez más e+tendido " el !+ito de las conferencias de'rogramación (+trema " metodologías ágiles es cada vez ma"or#La 6' empieza con cuatro valores3 Comunicación, @etroalimentación, Simplicidad" Cora&e#6' constru"e un proceso de dise%o evolutivo que se basa en refactorar un sistemasimple en cada iteración

La )amilia de Crystal de Coc*burn $listair CocIburn ha estado traba&ando en metodologías desde que la -H) leencargó escribir sobre ellas a inicios de los E=#Su libro, KSo"re i iendo 'ro-ectos rientados a "+etos5 , fue su primer conse&o enpro"ectos corrientes# )ás recientemente $listair escribió un libro de de desarrollode software ágil que mira los principios sub"acentes de este tipo de metodologías#

esde ese libro ha e+plorado más los m!todos ágiles, desarrollando la familia demetodologías Cr"stal#Se trata de una familia, "a que CocIburn considera que diferentes pro"ectosrequieren diferentes metodologias# l observa esta variación a lo largo de dose&es3 el nDmero de personas en el pro"ecto, " las consecuencias de los errores#Cristal comparte con la 6' una orientación humana, pero esta centralización en lagente se hace de una manera diferente# $listair considera que las personas




encuentran difícil seguir un proceso disciplinado, así que más que seguir la altadisciplina de la 6', $listair e+plora la metodología menos disciplinada que aDnpodría tener !+ito, intercambiando conscientemente productividad por facilidad dee&ecución#

$listair tambi!n pone mucho peso en las revisiones al final de la iteración,animando al proceso a ser auto me&orable#

Código #!ierto

Los principios del 0pen Source son3@edistribución libre3 La licencia no deberá impedir la venta o el ofrecimiento

del software con un componente de una distribución agregado,conteniendo programas de muchas distintas fuentes#Código fuente3 (l programa debe incluir el código fuente " se debe distribuir

tanto el e&ecutable como este Dltimo#Mraba&os derivados3 La licencia debe permitir modificaciones " traba&os

derivados#-ntegridad del código fuente " del autor3 Se debe mantener la integridad con

el código desarrollado por el propietario del pro"ecto/o a la discriminación de personas o grupos3 no se puede discriminar a

ninguno en un pro"ecto basado en la filosofía 0pen Source#/o a la discriminación de campos laborales3 no se tiene que restringir a

nadie en el uso del sistema en un campo laboral específico#istribución de la licencia3 Los derechos ad&untos al programa tienen que

aplicarse a todos aquellos que reciben el programa sin la necesidad de

e&ecutar una licencia adicional para estas partes#La licencia no tiene que ser específica de un producto3 Los derechos

ad&untos al programa no deben depender de que el programa forme partede una distribución particular del software

Metodologías Agiles, programación extrema 1!Lic. Horacio Kuna – ASC Sergio Caballero



La licencia no tiene que restringir a otro software3 La licencia no tiene que

colocar restricciones en otro software que es distribuido &unto con eldesarrollo licenciado#

Se desarrollará más adelante en detalle las diferencias " similitudes entre 6' "0pen Source#

El Desarrollo de )o&t*are #da%ta!le de +ig smit

Jim ?ighsmith despu!s de traba&ar durante a%os con metodologías predictica, dedesarrollarlas " ense%arlas conclu"ó que son profundamente defectuosas,particularmente para los negocios modernos#Su reciente libro se enfoca en la naturaleza adaptable de las nuevasmetodologías, con un !nfasis particular en aplicar las ideas que se originaron en elmundo de los sistemas comple&os adaptables :normalmente conocida como teoríadel caos;#/o se trata de la descripción detallada de actividades a desarrollar como lo hace6', pero proporciona la base fundamental de por qu! el desarrollo adaptable#(l corazón del esarrollo de Software $daptable tiene tres fases que se

desarrollan en paralelo3(speculación

Colaboración

$prendiza&e

?ighsmith ve la planificación como una parado&a en un ambiente adaptable, "aque los resultados son naturalmente imprevisibles(n este ambiente imprevisible se necesita que las personas colaboren de la me&or

manera para tratar con la incertidumbre# La atención de la gerencia es menor en loque tiene que hacer la gente " ma"or sobre la comunicación alentadora para quelas personas puedan proponer las respuestas creativas ellos mismos#(n ambientes predictivos, el aprendiza&e se desalienta a menudo# Las cosas seponen de antemano " entonces se sigue ese dise%o#

Metodologías Agiles, programación extrema 1"Lic. Horacio Kuna – ASC Sergio Caballero



(n un ambiente adaptable, aprender desafía a todos :desarrolladores " clientes; ae+aminar sus presunciones " usar los resultados de cada ciclo de desarrollo paraadaptar el siguiente#(l aprendiza&e como tal es un rasgo continuo e importante, que asume que losplanes " los dise%os deben cambiar conforme avanza el desarrollo#(l beneficio atropellado, poderoso, indivisible " predominante del Ciclo de Nida de

esarrollo $daptable es que nos obliga a confrontar los modelos mentales queestán en la raíz de nuestro autoenga%o# /os obliga a estimar con realismo nuestrahabilidad#

)crumScrum divide un pro"ecto en iteraciones denominadas “carreras cortas de .=días# $ntes de que comience una carrera se define la funcionalidad requerida paraesa carrera " entonces se de&a al equipo para que la desarrolle# (l punto esestabilizar los requisitos durante la carrera#

Sin embargo la gerencia no se desentiende durante la carrera corta# Modos losdías el equipo sostiene una &unta corta :quince minutos;, llamada scrum, donde el

equipo discurre lo que hará al día siguiente

Desarrollo Mane-ado %or asgosJeff e Luca " 00 'eter Coad dise%aron (l esarrollo )ane&ado por @asgos:4 ;# Como las otras metodologías adaptables, se enfoca en iteraciones cortasque entregan funcionalidad tangible# (n el caso del 4 las iteraciones duran dossemanas#(l 4 tiene cinco procesos# Los primeros tres se hacen al principio del pro"ecto#

• esarrollar un )odelo 1lobal• Construir una Lista de los @asgos• 'lanear por @asgo• ise%ar por @asgo

Metodologías Agiles, programación extrema 1#Lic. Horacio Kuna – ASC Sergio Caballero



• Construir por @asgo

D)DM /M0todo de Desarrollo de )istema Din"mico(l )!todo de esarrollo de Sistema inámico empezó en 1ran Hreta%a en <EE2como un consorcio de compa%ías del @eino 7nido que querían construir sobre@$ : ise%o @ápido de $plicaciones;# (l resto del proceso forma tres ciclosrelacionados3

el ciclo del modelo funcional produce documentación de análisis "

prototipos

el ciclo de dise%o del modelo dise%a el sistema para uso operacional

el ciclo de implantación se ocupa del despliegue al uso operacional

Metodologías Agiles, programación extrema 1$Lic. Horacio Kuna – ASC Sergio Caballero

http://www.dsdm.org/

http://www.dsdm.org/



. Mani&iesto %ara el Desarrollo de )o&t*are Ágil $ partir de reconocer la similitud en muchas metodologías, surge el inter!s de

realizar un traba&o colaborativo " en febrero de B==< se reDnen representantes de<O metodologias con características comunes en un taller de dos días que serealiza en Snowbird, 7tah, 7S$# P se elabora lo que se conoce con el nombre de“)anifiesto de las metodologías ágiles 3

Los indi"id os e interacciones son másim$ortantes / e los $rocesos 8erramientas

(o)t9are / e ) ncione es más im$ortante / ela doc mentaci!n e:8a sti"a.

La colaboraci!n con el cliente es másim$ortante / e la negociaci!n de contratos

La res$ esta ante los cambios es másim$ortante / e el seg imiento de n $lan

(ste )anifiesto fue suscripto por 3

Gent HecI)iIe Heedle

$rie van HenneIum $listair CocIburnQard Cunningham

)artin 4owler

James 1renningJim ?ighsmith $ndrew ?unt@on Jeffries

Jon GernHrian )aricI

@obert C# )artinSteve )ellor

Gen Schwaber Jeff Sutherland

ave Mhomas

Metodologías Agiles, programación extrema 1%Lic. Horacio Kuna – ASC Sergio Caballero



3. 4P

Gent HecI define al 6' como ;<n $roceso ligero= de ba o riesgo= )le:ible=

$redecible= cientí)ico di"ertido de desarrollar (o)t9are 5. $llistair CocIburn lo define como ;<na metodología ágil / e re/ iere gran

disci$lina>

$l igual que la ma"oría de metodologías de desarrollo de software, laprogramación e+trema no es el resultado de un plan maestro incubado en lasmentes de genios, sino el fruto de la formalización de un con&unto de prácticas quedemostraron ser e+itosas en el desarrollo de sistema#

Se diferencia de otras metodologías por3

Su acercamiento a la planificación incremental que rápidamente propone un

plan global que se espera que evolucione a trav!s de la vida del pro"ecto#

Su habilidad para definir las funcionalidades de la aplicación de manera

fle+ible, de manera de dar respuesta a las cada vez más cambiantesnecesidades de los negocios#

Su regeneración a partir de ciclos cortos#

Su confianza en un proceso de testing escrito por programadores " clientesque supervisa el progreso del desarrollo, de esta manera se posibilita tomar losdefectos a tiempo " corrigi!ndolos, posibilitar la evolución del sistema hacia loque el cliente necesita en ese momento#

Metodologías Agiles, programación extrema 1&Lic. Horacio Kuna – ASC Sergio Caballero



Su confianza en la comunicación oral, las pruebas " el código de la fuente para

comunicar la estructura del sistema#

Su confianza en un proceso del plan evolutivo que dura toda la vida Dtil del

sistema#

Su confianza en la colaboración íntima de programadores#

El ciclo de 'ida

Si los largos ciclos de desarrollo de los m!todos tradicionales son incapaces deadaptarse al cambio, tal vez ha"a que traba&ar en ciclos de desarrollo más cortos#(sta es una de las ideas centrales de 6'#(n la figura se observa una comparativa gráfica entre el modelo en cascada, elmodelo en espiral " 6'#

3.1. iesgos

Metodologías Agiles, programación extrema 1'Lic. Horacio Kuna – ASC Sergio Caballero



(n las metodologías tradicionales se observa que gran cantidad de riesgos sehacen presentes " se convierten en problemas que hacen que en una enormecantidad de casos los pro"ectos fracasen, algunos de estos riesgos son3

(rrores en la planificación, no se cumple la planificación original " esto implicaatrasos altamente costosos#'ro"ectos que se cancelan antes de entrar en la fase de producción#

(rrores en el sistema que "a está en producción, la gran cantidad de errores

provoca que despu!s de un tiempo se evalDe necesario remplazarlo "a que elcosto de corregir esos errores es más alto que remplazarlo por otro sistema#La cantidad de errores es tan grande que inviabiliza la utilización del sistema#

esarrolladores que no entendieron bien el negocio " producen software queno resuelve los problemas que se propuso originalmente#(l sistema se pone en producción pero los requerimientos originales han

cambiado desde el momento en que se plantearon hasta el momento en que elsistema se termina#La producción de los desarrolladores se degrada con el tiempo#

4P intenta dar res%uesta a cada uno de esos riesgos6(rrores en la planificaci n, no se c*mple la planificaci n original - esto implicaatrasos altamente costosos.6' plantea ciclos cortos de interacción :cuatro semanas;, al segmentarla, selimita cualquier error en la planificación# 6' ataca primero los rasgosprincipales del sistema entonces el costo de cualquier error en la planificaciónal producir los rasgos principales tiene menor costo#'ro-ectos )*e se cancelan antes de entrar en la fase de prod*cci n.

Se traba&a con peque%os releases por lo tanto el traba&o anterior al primer release es menor que en las metodologías tradicionales " las p!rdidas sonmenores en el caso de una cancelación anticipada#(rrores en el sistema )*e -a est0 en prod*cci n, la gran cantidad de errores

pro oca )*e desp*/s de *n tiempo se e al e necesario rempla8arlo -a )*e el costo de corregir esos errores es m0s alto )*e rempla8arlo por otro sistema.

Metodologías Agiles, programación extrema (Lic. Horacio Kuna – ASC Sergio Caballero



6' garantiza la calidad a partir de que las pruebas guían el proceso de dise%o,La cantidad de errores es tan grande )*e inviabiliza la utilización del sistema#

6' ise%a las pruebas antes de comenzar la codificación en forma con&untaentre los programadores " el cliente#Desarrolladores )*e no entendieron "ien el negocio - prod*cen software )*e

no res*el e los pro"lemas )*e se prop*so originalmente.6' plantea que el cliente debe ser parte activa del equipo de desarrollo, lasespecificaciones del pro"ecto son continuamente refinadas durante el mismo,el aprendiza&e permanente que tienen el cliente " los desarrolladores se refle&aen el producto final# (l sistema se pone en prod*cci n pero los re)*erimientos originales an

cam"iado desde el momento en )*e se plantearon asta el momento en )*e el sistema se termina.6' al traba&ar con peque%os releases, plantear interacciones cortas en eltiempo " tener al cliente “in situ reduce sustancialmente el riesgo de obtener un producto que no responda a las necesidades del usuario "a que estas sevan a&ustando en cada peque%o release#La prod*cci n de los desarrolladores se degrada con el tiempo.

6' tiene como uno de sus principios la responsabilidad de los programadores,tienen un rol sustantivo en el desarrollo, por e&emplo estimando los plazos,características arquitectónicas, etc# por otro lado el traba&o cooperativo, laprogramación por pares, el ob&etivo que el equipo acepte gradualmente cadavez más responsabilidad, hacen que la motivación de los desarrolladores seamucho ma"or que en las metodologías tradicionales donde el programador esun su&eto mucho más pasivo que en general debe “obedecer sin tener muchaparticipación en las decisiones importantes#

3.2. 7aria!les a considerar Las variables que guían el proceso del desarrollo de un sistema son3




Costo

8iem%o

Calidad

#lcance

e estas variables el alcance es fundamental para el !+ito de un pro"ecto#6' plantea que el cliente debe tener control sobre al menos . variables " el equipode desarrollo sobre la restante#

3.$. Los 'alores6' se basa en 2 valores que tienen como ob&etivo garantizar el !+ito de un

pro"ecto, estos valores son3Comunicación

7alentía

etroalimentación

)im%licidad

3.$.1. Comunicación) esde el momento en que se detecta un problema, la comunicación comienza aser un elemento central en el desarrollo de productos Software#(n e6treme 'rogramming, esta comunicación es central, se considera que losintegrantes del equipo cuando establecen una comunicación directa es muchomás eficaz que si esta comunicación se mediatiza o es indirecta, se plantea contar con entornos de desarrollo confortables que incentiven esta comunicación#(l equipo de desarrollo debería estar compuesto tambi!n por un representante

autorizado del cliente, con ello no sólo se me&ora la comunicación entredesarrolladores, sino tambi!n entre !stos " los clientes, elemento central paragarantizar el !+ito de los pro"ectos#Cuando aparecen los problemas se resuelven en el momento, la comunicación esdirecta " no se debe perder tiempo "endo a “consultar al cliente, "a que el mismoestá presente " todo el equipo participa de las soluciones# (s importante tener en

Metodologías Agiles, programación extrema Lic. Horacio Kuna – ASC Sergio Caballero



cuenta que en muchos desarrollos tradicionales la estratificación de los distintosmiembros de los equipos es tan grande que en general la comunicación entredise%adores R programadores " clientes es mínima, 6' rompe esa aislacióncreando un entorno de desarrollo cooperativo " altamente comunicativo#

O#.#B#7alentía (n las metodologías tradicionales de desarrollo de sistemas en general nosencontramos con programadores pasivos que deben aceptar sin poder emitir opinión alguna lo que el líder del pro"ecto impone# La filosofía de traba&o de 6' essustancialmente distinta, el programador puede modificar en forma responsable elcódigo cuando lo considere necesario, el hecho de que se realicen pruebas

unitarias sobre cada cambio antes de ponerlo en el repositorio central hace quese garantice la calidad de cada modificación#(sta valentía que debe tener el equipo de desarrollo debe estar acompa%ada por la humildad " se debe decir en el seno del equipo de desarrollo con cora&e todo loque se piensa sin miedos in&ustificados# Lo cierto es que no muchos equiposestán acostumbrados a esta metodología de traba&o, basada en el valor demodificar lo que es perfectible " tener un rol activo en el proceso de desarrollo,

pero la sinceridad, la humildad " el cora&e son elementos sustantivos paragarantizar el !+ito de un pro"ecto basado en 6'#

3.$.$. ealimentación :feedbacI;Gent HecI en su libro sobre e6treme 'rogramming tiene un subtítulo que diceem"race c ange :abraza el cambio;, que nos indica que se deben aceptar loscambios " que los mismos deben estar incluidos en nuestro traba&o cotidiano

)ientras más rápido se identifica el cambio, más rápido se lo puede mane&ar# (ngeneral, el principio es encontrar el error lo más cerca posible al tiempo en que fueintroducido# 6' se esfuerza para que se pueda recibir la retroalimentación lo másrápido posible en todos los aspectos del pro"ecto#


http://www.agile-spain.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Valent%EDa

http://www.agile-spain.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Realimentaci%F3n

http://www.agile-spain.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Valent%EDa

http://www.agile-spain.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Realimentaci%F3n



La generación de pruebas unitarias antes de actualizar el repositorio central " laspruebas de aceptación con el cliente, hacen que los cambios que se introducentengan niveles de calidad aceptables, cuanto antes se incorporan estos cambios,cuanto antes se detectan los errores, me&or es para el pro"ecto# Con estas premisas en el pro"ecto nos realimentamos cuidando una relaciónestrecha con el cliente sabiendo siempre si lo que estamos haciendo va bienencaminado " cubre las necesidades de !ste#

3.$. . )im%licidad 7no de los principios de la programación e+trema es la simplicidad# (l cliente es ele&e que conduce todo el proceso de desarrollo en 6', hacer lo que el cliente

necesita, tan simple como sea posible es el ob&etivo, reduciendo la comple&idaddesde el comienzo de cada pro"ecto#Modo el código debería ser “refabricado tan frecuentemente como sea posible# Larefabricación es el proceso de me&orar estructuras de código sin cambiar lafuncionalidad que proveen#(l dise%o debe ser lo más simple posible# (l paradigma G-SS : Geep -t Small andSimple para unos o Geep it Simple, Stupid para otros; se lleva hasta las Dltimas

consecuencias# 'or e&emplo, se hace !nfasis en no a%adir funcionalidad nuncaantes de lo necesario, por las sencillas razones de que probablemente ahoramismo no sea lo más prioritario o porque quizás nunca llegue a ser necesaria#

3. . Princi%ios !"sicos@ápido feedbacI

(s fundamental que todo lo que se va aprendiendo a lo largo del desarrollo sea

socializado rápidamente# Los programadores aprenden que es lo me&or para elpro"ecto, a utilizar nuevas herramientas, a crear pruebas para el sistema " esteaprendiza&e debe ser compartido e incorporado en los equipos en forma inmediata#

$sumir la simplicidad


http://www.agile-spain.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Simplicidad

http://www.agile-spain.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Simplicidad



(l EF> de los problemas se resuelve en forma sencilla, se trata de traba&ar en eldía a día simplificándolos, es un vicio de muchos programadores comple&izar aquello que se puede resolver en forma sencilla

Cambio incremental

Los problemas se deben resolver con peque%os cambios, se trata departicionarlos para simplificar " que el impacto de cada cambio sea lo menor posible# (l dise%o, la codificación, el equipo de traba&o se deben modificar enforma incremental, incluso la propia implementación del 6' debe ser de apeque%os pasos

$doptar los cambiosLa me&or estrategia es preservar la ma"oría de las opciones mientras se resuelvelos problemas más urgentes

Mraba&o de calidad

Se trata de hacer el traba&o lo me&or posible " con el ma"or placer posible#

Cada uno de estos principios tiene embebidos los 2 valores mencionadosanteriormente#

$ continuación se detallan otros principios a considerar que si bien sonsecundarios tienen mucha importancia3

(nse%ar aprendiendo

Jugar para ganar

Concretar los e+perimentos

(stablecer una comunicación honesta

Metodologías Agiles, programación extrema #Lic. Horacio Kuna – ASC Sergio Caballero



Mraba&ar con el instinto de las personas no contra ellos, 6' le da mucha

importancia a este punto#

$ceptar las responsabilidades

3.(. Las acti'idades !"sicas en el desarrollo de sistemaLas actividades básicas son3

Codi)icar 6

Lo que se esta produciendo es software, si no ha" código, no se tiene nada#Probar6

ebe e+istir una manera de saber en que punto termina la tarea, las pruebascumplen esa función#

sc c8ar6

Los clientes deben estar presentes en el proceso porque son ellos los querealmente van a obtener algo del software#

&ise'ar6

(l programa debe ser claro " comprensible para que se pueda traba&ar con !l#

3. . Las 12 %r"cticas

Metodologías Agiles, programación extrema $Lic. Horacio Kuna – ASC Sergio Caballero



6' propone <B prácticas que deben ser tenidas en cuenta, no es recomendableseguir sólo algunas " otras no, se trata de aplicar en forma bastante estricta elcon&unto de prácticas propuestas3

%esting Programaci!n $or $ares de Programadores

&ise'o sim$leRe)actori*aci!n $ermanente

Cliente +n,(ite%aller de $lani)icaci!n-ntegraci!n contin aPe/ e'os releases

Pro$iedad Colecti"a del c!digostándares de Codi)icaci!n

Metá)oras del sistema(emana de 4 oras

(+iste una estrecha relación entre estas doce prácticas " las mismas debenimplementarse en forma integral#

3. .1. 8estingLas pruebas guían el proceso de desarrollo " son cruciales entre otras cosas para

garantizar la calidad " la retroalimentación#Se de"en reali8ar pr*e"as *nitarias - de aceptaci n.4ormar una colección de pruebas unitarias desde el primer día, se convierte enuna herramienta bastante poderosa despu!s en el pro"ecto# /o es posibleactualizar el “repositorio central sin haber realizado estas pruebas#'ara esto se implementa una práctica mu" interesante de codificación que es lallamada “test first # $ntes de a%adir un nuevo módulo al sistema, se escribe unaprueba unitaria que e&ecuta el código aDn no e+istente#Las pruebas de aceptación se caracterizan por requerir que se pruebe el sistemaen forma total, el cliente está involucrado en la creación de las pruebas deaceptación# Las pruebas unitarias se centran en que cada detalle t!cnico est!funcionando de acuerdo a lo previsto " son dise%adas básicamente por elprogramador, las pruebas de aceptación aseguran que cada requerimiento del

Metodologías Agiles, programación extrema %Lic. Horacio Kuna – ASC Sergio Caballero



cliente está funcionando correctamente " el mismo tiene un rol central en suelaboración#Como la programación es por pares de programadores, si uno de ellos no esta encondiciones de dise%ar una prueba es posible que el otro si pueda hacerlo, " en lamedida que el cliente dise%e las pruebas funcionales sentirá que su participaciónes central " su rol se ve realzado#

3. .2. Programación %or %ares de Programadores(l software producido con 6' es construido por dos programadores, sentados unoal lado del otro en la misma máquina# Se espera que esta práctica garantice quelas pruebas unitarias las realice al menos un programador " se obtenga un me&or

dise%o " código#(n general se observa que los programadores solos tienden a producir grancantidad de errores#

$unque parezca ineficiente tener dos programadores haciendo un mismo traba&o,esto no es así, Laurie Qilliams de la universidad de 7tah en Salt LaIe Cit"demostró que la programación por pare&as es un <T> más lenta que laprogramación solitaria, pero que en cambio reduce los errores en el código en un

<T>, por lo tanto se obtiene en casi el mismo tiempo un software de ma"or calidad# La programación por pares, al ser los mismos rotativos garantiza enconocimiento general, los programadores aprenden en forma continua habilidadesque son aplicadas en cada pro"ecto#7na buena práctica mientras se programa por pare&as es que mientras uno de losmiembros de la pare&a escribe el código de test el otro va pensando sobre laimplementación que se tiene que llevar a cabo para que el test pase#(s posible que sea una de las prácticas más resistidas "a que muchos lideres depro"ecto consideran que es una perdida de recursos que dos personas programenen una sola maquina#

Metodologías Agiles, programación extrema &Lic. Horacio Kuna – ASC Sergio Caballero



3. .$. Dise9o )im%leSe trata de buscar el camino más sencillo para lograr el ob&etivo inmediato en eldesarrollo, o sea enfocar todos los esfuerzos para hacer sencillo el dise%o de losrequisitos planteados en la actual interacción " no pensar en un “futuro queprobablemente cambie cuando se haga presente

(+iste una clara relación entre la retroalimentación :una de la prácticas de 6'; " elmantener el dise%o simple, "a que se eliminar tiempo de desarrollo innecesario#Se trata entonces de no pensar en funcionalidades futuras "a que la fle+ibilidad dela metodología permitirá incorporar " cambiar, así que no es necesario hacer másde lo que ho" se necesita#

3. . . e&actori:ación %ermanente(sta práctica permite a los desarrolladores reestructurar el sistema sin cambiar lafuncionalidad del mismo, eliminando duplicidades, simplificando el código,fle+ibilizándolo/ormalmente se aplica cuando se solicita una nueva funcionalidad, ese es elme&or momento para refabricar el código " desarrollar la nueva funcionalidad# (l

ob&etivo es que el código no solo sea entendible por la maquina sino tambi!n por las personas#'ara evitar errores en este proceso de refabricación se debe garantizar que sehagan suficientes pruebas unitarias#La refactorización permite ahorrar tiempo " aumentar la calidad(s claro que los factores que se están enumerando tienen una profunda relaciónentre si, por e&emplo la refactorización, con la simplicidad, la propiedad colectiva,la valentía :porque en general se refabrica lo que funciona, no lo que no funciona;,la programación por pares " las pruebas#

3. .( Cliente ;n<)ite(s una condición esencial que se incorpore al equipo de desarrollo unrepresentante del cliente en forma permanente, para responder preguntas,

Metodologías Agiles, programación extrema 'Lic. Horacio Kuna – ASC Sergio Caballero



interactuar con el equipo " participar en el dise%o de las pruebas funcionales# Suparticipación activa garantiza que los cambios se incorporan en forma inmediata#(ste representante debe ser una persona con autoridad para decidir sobre lamarcha cuestiones relacionadas con la funcionalidad del producto#

3. . . 8aller de %lani&icación(l ob&etivo de la planificación es determinar rápidamente que contendrá el pró+imorelease, combinando las necesidades “del negocio con las posibilidades t!cnicas#(l 9elease 'lanning es una práctica donde el cliente presenta las característicasdeseadas a los programadores a trav!s de un formulario denominado “historias deusuario , " los programadores estiman su dificultad " factibilidad de

implementación, se trata de una acción donde se integran las necesidades "posibilidades a corto plazo :un nuevo release;# Pa que se trata de peque%osreleases estas reuniones de planificación se realizan como má+imo cada tressemanas, entonces los a&ustes a la planificación general se van detectando enforma casi interactiva, 6' modifica la planificación tentativa original no se a&ustacomo un dogma a ella# Con estas reuniones se logra3• La participación del equipo completo en todas las decisiones

<# ecidir el alcance " prioridadesB# (stimar tiempos de desarrollo

• 'otenciar la retroalimentación

3. .3. Integración continua(l sistema se constru"e e integra varias veces por día, cada vez que se conclu"euna tarea# (l &untar el código de varios programadores puede ser mu" comple&o sino se realiza cada vez que se finaliza una tarea, por lo tanto para garantizar lafle+ibilidad del sistema se debe seguir la siguiente secuencia3• ise%ar pruebas

Metodologías Agiles, programación extrema !(Lic. Horacio Kuna – ASC Sergio Caballero



• Codificar • 'rueba 7nitaria• -ntegrar •

'robar el sistema integrado(n el caso que no se pasen correctamente las pruebas se debe tomar comoprioridad la corrección de los errores, corrigiendo los mismos hasta que todas laspruebas se realicen sin que se produzcan errores# (s conveniente realizar estatarea varias veces al día preferentemente en una máquina dedicada para laintegración#

3. .=. Pe>ue9os releasesSe trata de producir un sistema simple rápidamente, que el mismo este probado "funcionaado " que tenga las funciones que el cliente eli&a en cada interacción#

espu!s se debe liberar nuevas versiones en ciclos de desarrollo rápido, desdeuna por semana a una por mes#Las entregas frecuentes salen de la idea del creador de Linu+ cita6 release earl-,release often #

e lo que se trata es de garantizar que el sistema haga lo que el cliente quiere quehaga " se pueda me&orar interactivamente cada nueva versión, considerando queno se incorporan gran cantidad de funcionalidades en cada interacción, por lotanto el costo de cualquier desviación es mínimo " los a&ustes son menoscomple&os#

3. .?. Pro%iedad Colecti'a del código

(l concepto de propiedad colectiva : collecti e code owners ip;, esto se relacionacon la posibilidad que cualquier miembro del equipo de desarrollo puede modificar cualquier parte del código fuente, esto tiene un efecto mu" interesante "a que alsaber cada programador que “su código pasa a ser de todos se esmera por hacerlo lo me&or posible, me&orando la calidad, aumentando la cohesión "

Metodologías Agiles, programación extrema !1Lic. Horacio Kuna – ASC Sergio Caballero



reduciendo los errores# (sto rompe alguno de los vicios que tienen lasmetodologías tradicionales donde cada programador es due%o e+clusivo de sucódigo " solo el puede modificarlo# (ste sentimiento de “team potencia laproductividad#

3. .1@. Est"ndares de Codi&icación'ara lograr la propiedad colectiva del software " la refabricación es necesario queel equipo de desarrollo escriba el código respetando estrictas reglas de

programación estipuladas previamente# Cuando se utilizan estos estándares deprogramación el código fuente es más fácil de leer " es más sencillo tener “valentía para modificarlo "a que muchas veces sucede en pro"ectos que utilizanesta metodología que a un programador al leer el código le cuesta saber si loescribió el mismo#

3. .11. Met"&oras del sistemaSe trata de una descripción informal de la arquitectura del sistema, se describe alsistema en conceptos simples, la idea es que en base a estas metáforas se puedaentender como traba&a el sistema# (n otras metodologías se pueden encontrar conceptos parecidos, como en el caso del @7' : 9ational :nified 'rocess ; los :seCases #

3. .12. )emana de @ +oras7na de las dificultades que aparecen en los equipos de desarrolladores en lospro"ectos tradicionales es la sobreactividad, 6' promueve la semana de 2= horasde traba&o, considerando que un programador descansado produce me&or " conmenos errores




(ste concepto intenta hacer entender que un programador que traba&a <2 horasdiarias no esta en condiciones de producir con calidad, muchas veces estasactitudes “heroicas solo per&udican los pro"ectos#

3.3. Contexto de e4treme Programing6' se limita a un conte+to mu" delimitado3 entornos cambiantes, con requisitos

volátiles " con equipos de <B personas o menos#

3.=. Estrategias de gerenciamiento

(n los pro"ectos software suelen darse dos tipos de estrategias degerenciamiento, por un lado el Líder de 'ro"ecto todopoderoso que resuelve todoslos temas sin dar participación a nadie, por el otro podemos encontrar equiposdonde cada integrante traba&a en forma aislada " autónoma sin ningDn tipo dedirección# 6' plantea una alternativa intermedia que se caracteriza por3

$ceptar la responsabilidad, el líder de pro"ecto se%ala lo que se necesita hacer

no ordena#Mraba&o de calidad, la relación entre los programadores " el líder del pro"ecto

se debe basar en la confianza, considerando que los programadores quierenhacer bien su traba&o " el líder del pro"ecto tiene como función a"udar, orientar, no“ordenar #

Cambios incrementales, propone que el líder de pro"ecto brinde una guía a lo

largo del pro"ecto " no provea un gran plan cerrado que cubre todo el pro"ecto# $daptarse a la realidad local, se trata que todo pro"ecto se adapte a la

situación concreta " la cultura organizacional del lugar donde se va a aplicar#Mareas cortas, el líder de pro"ecto debe requerir de los programadores tareas

concretas " no mu" “pesadas , que puedan hacerse en poco tiempo#7tilizar una m!trica adecuada, no intentar por e&emplo medir en minutos la

productividad de los programadores#

Metodologías Agiles, programación extrema !!Lic. Horacio Kuna – ASC Sergio Caballero



3.?. El es%acio de tra!a-o6' recomienda especialmente que el espacio de traba&o debe ser cómodo "

confortable, se trata de contar con un espacio comDn para los desarrolladores "que los mismos sean quienes acondicionan ese lugar# 7n lugar de traba&oagradable a"uda a que los desarrolladores est!n a gusto " el traba&o se haga deme&or forma#

3.1@. Estrategias de %lani&icación en 4PSe trata de hacer un plan general en forma rápida e ir refinándolo en formapermanente a&ustándolo a la realidad, o sea que la realidad modele el plan " no elplan a la realidad :motivo del fracaso de muchos pro"ectos;# Las tareas tienen queser a corto plazo, de manera que si es necesario realizar cambios el impacto seamenor sobre el con&unto del plan al realizarlo en base a peque%as tareas# $lgunasde las tareas relacionadas con la planificación son3

@eunir al equipo

ecidir las prioridades " el alcance

(stimar el costo " la agenda

ar confianza al equipo que la tarea es posible

@ealizar la planificación detallada considerando el horizonte pró+imo, el

pró+imo release, la pró+ima interacción# $ceptar la responsabilidad, la responsabilidad solo puede ser aceptada por el

equipo no puede se impuesta por el Líder del pro"ecto#7na vez aceptada la responsabilidad, el encargado de realizar la tarea debe

estimar cuanto tiempo le llevará#

3.11. Estrategias de desarrollo.Se trata de abordar los problemas en el día a ida, al traba&ar con peque%osreleases el ob&etivo es ir resolviendo los problemas en la medida que aparecen,esperando que se trate de peque%os problemas relacionados con el sistema

Metodologías Agiles, programación extrema !"Lic. Horacio Kuna – ASC Sergio Caballero



integral# La estrategia de desarrollo comienza con la planificación de la interacción,la interacción continua disminu"e los conflictos en el desarrollo " posibilitaestablecer el fin natural de una etapa# La propiedad colectiva del software a"uda adisminuir los problemas en la etapa del desarrollo#Los programadores deben usar la regla del B= F= donde el F=> de los beneficiosprovienen del B=> del traba&o#(l traba&o cooperativo " la definición de tareas peque%as a"udan a disminuir losproblemas en la etapa de desarrollo#

3.12. Estrategias de dise9oContinuamente se debe refinar el dise%o del sistema, empezando de manerasimple# La estrategia es tener el dise%o más simple posible que permita e&ecutar las pruebas que se planificaron#

3.1$. Estrategias de testing.Las pruebas se dise%an antes de codificar, o sea las pruebas guiaran el procesode dise%o, por esta razón en 6' &uegan un rol central, las pruebas deben ser dise%adas desde el punto de vista del cliente entre los desarrolladores " el cliente#

(s imposible probar todo pero se debe considerar que el ob&etivo de la prueba esdeterminar que debe hacer el sistema " como debe hacerlo#

3.1 . Im%lementando 4P

3.1 .1. Integración del e>ui%o de tra!a-o A de&inición denecesidades6(l rol del cliente es central el mismo es parte del equipo de desarrollo como "a see+plico anteriormente " su importancia es capital tanto en la definición de las

Metodologías Agiles, programación extrema !#Lic. Horacio Kuna – ASC Sergio Caballero



“?istorias de 7suarios , las reuniones de planificación, el dise%o de las pruebasfuncionales, etc#(n el punto O#B# se hablo de las variables que e+isten en un proceso de desarrollode un sistema, (l costo, Miempo, La calidad, (l alcance# e estas 2 variables elalcance es la más importante, por lo tanto la determinación de los requisitos tieneun papel fundamental#(n 6p los requisitos se definen en torno a lo llamado “?istorias de 7suarios "tienen dos fases3

• (n la primera fase el cliente describe con sus propias palabras las

características que piensa debe tener el sistema " el responsable delequipo de desarrollo le informa de la dificultad t!cnica " el costo de cada

una de ellas# (l cliente de&a por escrito sus necesidades " las ordena deacuerdo a sus prioridades

• La segunda fase consiste en tomar las primeras historias :de acuerdo a su

nivel de prioridad; " determinar las tareas necesarias para implementar losrequisitos planteados en esa “historia # (l cliente participa de este procesopero el peso más importante en esta etapa es del equipo de desarrollo, elresultado será una planificación más e+acta#

Si bien las ?istorias de 7suarios tienen alguna similitud con los 7ses Cases de7)L el proceso de creación es mu" distinto# (s más e+tensa que un requisito :quesuele ser una frase corta; " menos que un caso de uso :que puede ser de una odos páginas;#Los desarrolladores son los responsables de catalogar las historias de los usuarios" asignarles una duración, el tiempo de programación de cada una de estashistorias no debe ser ma"or a tres semanas " menor a una, en el caso que ocupenmenos de una semana se las agrupa " si ocupan más de tres se las divide#Cuando se habla de una semana de traba&o se considera T días a F horas cadadía# $l hacer la planificación se aplica un factor de corrección medido de pro"ectosanteriores para a&ustar este tiempo ideal al real#Las historias de los usuarios se plasmarán en tar&etas especialmente dise%adaspara ese fin#

Metodologías Agiles, programación extrema !$Lic. Horacio Kuna – ASC Sergio Caballero



3.1 .2. Plani&icaciónLa planificación debe definir cada una de las iteraciones, teniendo en cuenta quese deben generar entregas frecuentemente#(l ob&etivo es que las necesidades del cliente guíen el desarrollo " no laplanificación, por lo tanto se debe prever que cada . a T iteraciones se tengan querevisar las historias de los usuarios " renegociar nuevamente la planificación#Se debe tambi!n definir la planificación de cada iteración, en esta planificación seespecifica que historias de usuarios son prioritarias " se agrega las historias deusuarios que no han pasado las pruebas de la iteración anterior#(s por eso, que el dise%o que seguimos se puede calificar de continuo# Se trata en

general de optimizar al final del desarrollo, se trata de maIe it worI, maIe it rightand then maIe it fast :haz que funcione, hazlo bien " entonces haz que searápido;#

3.1 .$. Dise9o.Se habla de dise%o continuo, el mismo debe ser revisado " me&oradopermanentemente a medida que se agregan funcionalidades, esto se contrapone

con las metodologias tradicionales que hablan de un gran dise%o previo#La metáfora tiene un papel central en esta etapa, me&orando la relación en elequipo de traba&o " dando una visión general del sistema que se quieredesarrollar#'uede suceder que el cliente participe en esta etapa# )uchas veces se utiliza untipo de tar&etas denominadas C@C :Class, @esponsabilities and Collaboration Clases, @esponsabilidades " Colaboración;# 'ara cada clase identificada se

rellenará una tar&eta de este tipo " se especificará su finalidad así como otrasclases con las que interaccione# 'ara algunos autores el uso de estas tar&etas solodebe limitarse a los pro"ectos comple&os#

3.1 . . Dise9o de %rue!as A codi&icación

Metodologías Agiles, programación extrema !%Lic. Horacio Kuna – ASC Sergio Caballero



Las pruebas unitarias se desarrollan antes de codificar# ?a" mucha literatura sobrelas pruebas unitarias pero en general se coincide en que cuanto más difícil seaimplementar una prueba, más necesaria es#Las pruebas unitarias se diferencias de las de aceptación, las primeras lasdise%an los programadores " las de aceptación son realizadas por el cliente, setrata de pruebas de ca&a negra " se utilizan las historias de usuarios para hacerlas#Los programadores se ponen por pare&as :dos personas en el mismo ordenador;para codificar esas historias# 'rimero entonces se dise%a la prueba " despu!s secodifica hasta que se pasen con !+ito todas las pruebas#

3.1 .(. Integración

espu!s de codificar cada nueva funcionalidad se debe integrar, esta integracióncomo "a fue mencionado es continua, evitando una gran integración final#(n todo desarrollo de programación e+trema debería e+istir, por tanto, una versiónsiempre integrada# (+iste un repositorio central que debe sincronizar cada moduloal menos una vez por día#

3.1 . . e&actori:ación

@efactorizar consiste en me&orar el código# (l código no solo debe funcionar sinodebe ser simple# (l proceso de refactorización inclu"e las pruebas unitarias#

ado que se trata de desarrollos que se basan en los cambios, todo el proceso ende tipo incremental#

=. 4P A ;%en )ource

(+isten algunas características comunes entre las )etodologías *giles " el 0penSource Software que serán analizadas en este capitulo, sin lugar a dudas amboshan recorrido un camino en el desarrollo de sistemas con muchos puntos encomDn#

Metodologías Agiles, programación extrema !&Lic. Horacio Kuna – ASC Sergio Caballero



(n <EFT nace la 4ree Software 4undation, este momento es considerado como elnacimiento formal del 0pen Source Software :00S;, la base filosófica quesustenta este movimiento tiene que ver con la socialización del conocimiento, conusuarios activos, en contra de la filosofía del gigante de )icrosoft que cierra elconocimiento al ocultar el código fuente de sus productos " entiende al usuariocomo un ob&eto pasivo#(l concepto de desarrollo de Linus Morvalds es claro para entender el 00S “ Li"erer0pido - a men*do, deleg*e todo lo )*e p*eda, sea a"ierto asta el p*nto de la

promisc*idad .(ric S# @a"mond, un teórico del software libre, escribió en <EEO que el modelo dedesarrollo del software libre es similar a la construcción de los bazares , en contra

de las metodología tradicional que las compara con la construcción de lascatedrales con un arquitecto que dise%a " distribu"e tareas " alba%iles queconstruían las catedrales respetando e+actamente los planes " con t!cnicassecretas :recordemos que el sindicato de alba%iles de catedrales es el que daorigen a la secta secreta de los )asones;# (n cambio en la construcción de losbazares, los planes no tienen un orden tan estricto, se constru"e colectivamente "todos ven sus secretosLa ma"oría de los pro"ectos de código abierto tienen uno o más mantenedores#7n mantenedor es la Dnica persona a la que se le permite integrar un cambio en elalmac!n de código fuente# Sin embargo otras personas pueden hacer cambios ala base del código# La metodología de traba&o es que el usuario desarrollador envía al mantenedor los cambios propuestos " este decide si es incluido o no esecambio, la clave que impulsa este tipo de desarrollo es la “meritocracia # (lmantenedor es el responsable de mantener la integridad del producto0tro rasgo distintivo es que muchas personas participan simultáneamente del

proceso de testing " cuando se encuentra un defecto estos usuarios activospueden enviar la corrección del bug al mantenedor para que lo inclu"a en lapró+ima versión#(n el articulo “La catedral " el Hazar (ric S# @a"mon plantea algunos principios "características comunes que tienen los pro"ectos de 0SS, estos principios tienen

Metodologías Agiles, programación extrema !'Lic. Horacio Kuna – ASC Sergio Caballero



sin lugar a dudas muchos puntos en comDn con los de las )etodologías *giles,algunos de los principios planteados por @a"mon son3

“;odo "*en tra"a+o de software empie8a a partir de las necesidades

personales del programador 1Los "*enos programadores sa"en )*e escri"ir. Los me+ores )*e reescri"ir.

1Si tienes la actit*d adec*ada tendr0s pro"lemas interesantes.

1C*ando se pierde el inter/s de *n programa se lo de"e eredar a *n s*cesor

competente. 1;ratar a los *s*arios como cola"oradores es la forma m0s apropiada de

me+orar el c digo - la m0s efecti a de dep*rarlo. 1Li"ere r0pido - a men*do - esc*c e a s*s clientes.

1Dada *na "ase s*ficiente de desarrolladores asistentes - "eta<tester casi

c*al)*ier pro"lema p*ede se r caracteri8ado r0pidamente - s* sol*ci n ser o" ia para alg*ien.Si *sted trata a s*s "eta tester como si f*eran *n rec*rso m*- alioso, ellos le

responder0n como rec*rsos m*- aliosos. 1Las estr*ct*ras de datos inteligentes - el c digo "*rdo f*ncionan m*c o me+or

)*e en el caso in erso.

1Lo m0s grande desp*/s de tener "*enas ideas es reconocer las "*enas ideasde s*s *s*arios. 1La perfecci n en dise=o se logra c*ando -a no a- nada )*e )*itar.

(tc#

e estos principios se desprenden algunas características modulares que tieneque ver con el rol del Cliente , con el uso colectivo del código fuente, con el rol

central del programados, con la metodología incremental, con el testeo, con lanecesidad de hacer simple el código#(l siguiente cuadro muestra una comparación entre 0SS " )etodología ágiles3

Item +SS "etodologías ,gilesDesarrolladores Colaborati*os, capacitados,

+giles.Colaborati*os capaces +giles.

n un mismo lugar -ísico

Metodologías Agiles, programación extrema "(Lic. Horacio Kuna – ASC Sergio Caballero



)istribuidos geogr+-icamenteClientes )edicados, capaces

colaborati*osAutori ados, especiali ados,integrantes del e/uipo dedesarrollo.

Requerimientos 0ol+tiles Cambian r+pidamente

-rquitectura )ise ada para losre/uerimientos actuales. )ise ada para losre/uerimientos actuales.amaño /uipos grandes 2 dispersos.

Sistema pe/ue os/uipos 2 sistemas pe/ue os.

+b etivo principal 3roblemas desa-iantes 4apide .

7na de las diferencias fundamentales aparecen en relación con el rol " laubicación del cliente, mientras el 0pen Source Software se trata de clientesdesarrolladores distribuidos geográficamente, en las )etodologías ágiles el cliente

forma parte “in situ del equipo de desarrollo#(n forma más estructurada considerando cuatro elementos, la metodología dedesarrollo, el traba&o cooperativo, el software sencillo " la adaptabilidad, se puedenanalizar las siguientes coincidencias3

;.).). Metodologías "giles"etodologíaIncremental

istribución frecuente dereleases, con aporte de losdesarrolladores " testeadospor la “comunidad , segDnLinus Morvald “@elease earl",release often

Se desarrollan pe/ue os releases

Cooperativo (+iste un propietario delpro"ecto, pero se captan

desarrolladores utilizando-nternet " se integran a lospro"ectos a partir de susmeritos como programadores,que se integran a partir de uncomple&o proceso de

7na de las características del equipode desarrollo tiene que ver con el

conocimiento colectivo del código, laprogramación por pares deprogramadores, las reuniones diariasde planificación, el cliente como parteactiva del equipo de desarrollo#

Metodologías Agiles, programación extrema "1Lic. Horacio Kuna – ASC Sergio Caballero



-ngeniería Social#)encillo Se trata de utilizar procesos

de construcción pocoortodo+os, con poca

documentación conocidos por la comunidad donde la basees la calidad

Se trata de garantizar un procesosencillos de construcción segmentadolos problemas lo má+imo posible,

donde el e&e de la documentación esel código fuente

#da%tati'o Los requerimientos se vanelaborando constantementepor la comunidad, partiendode algunas ideas básicas seconstru"e el producto

7na de las razones del nacimiento delas )etodologías ágiles es laadaptabilidad, los peque%os releasesaportan en este sentido#

Como conclusión puede afirmarse que si bien ambas filosofías tienen orígenesdistintos " una base filosófica distinta, donde en el 0pen Source Software ladistribución del código fuente es modular " para las )etodologías *giles lo centrales el desarrollo rápido de sistemas " que sean fácilmente adaptables, en ambasprácticas se observan muchos puntos en comDn como claramente que dae+presado en la tabla anterior, " la interrelación entre ambas prácticas puede ser mu" beneficiosa " no es imposible imaginar la aparición de híbridos entre el 0SS "las metodologías ágiles#

?. Conclusiones

(+iste un antecedente claro de las metodologías ágiles que es el m!todo-ncremental e -nteractivo, el origen de estas metodologías datan de <E.= " seobservan muchos pro"ectos desarrollados a partir de la d!cada del U=#Considerando que el )anifiesto de las )etodologías ágiles surge en el a%o B==<,estamos considerando metodologías que cuentan con antecedentes pero que se




constitu"en " reconocen con principios comunes no hace mucho tiempo, en estacorta historia se detectan las siguientes discusiones3

(n el a%o B==< se discutía que son en realidad las )etodologías ágiles#

(n el a%o B==B La discusión paso por determinar si no e+iste contradicción

entre C)) :Capabilit" )aturit" )odel; desarrollado por el S(-, las normas-S0 E=== " las metodologías ágiles, determinándose que no e+istía muchointer!s en relacionarse#(n el a%o B==. La discusión pasa por determinar si es posible combinar las

prácticas ágiles con los m!todos tradicionales " tomar algunos de loselementos de cada uno#

La aplicación de las metodologías ágiles implica un cambio importante en las

organizaciones, afecta la estructura de poder donde el programador " el clienteadquieren un rol central desplazando el de los gerentes " $nalistas#(stas metodologías obligan a tener un ma"or nivel de interacción entre losprogramadores " Lideres de 'ro"ecto, por otro lado el tema que los testetadores "programadores traba&en &untos tambi!n implica un cambio en los hábitos detraba&o#(l siguiente cuadro muestra un resumen, diferenciando por áreas, las

características que debe tener un pro"ecto basado en la filosofía de )etodologías $giles3

0rea "etodologías 0giles

&e"arrolladore" Ágiles, capacitados, cola"orati os - sit*ados enel mismo l*gar.

Metodologías Agiles, programación extrema "!Lic. Horacio Kuna – ASC Sergio Caballero



Clientes '" eciali(ado") re re"entati*o" )

"ituado" en el mi"mo lugar

+ autori(ado".

9e)*erimientos >eneralmente en ías de desarrollo cam"ianr0pidamente.

,r-uitectura &i"e ada ara lo" re-uerimiento" actuale".

;ama=o '-ui o" + roducto" e-ue o".

/# eti*o !rinci al Ra ide(.

Las )etodologías $giles proveen un con&unto de prácticas mu" interesantes, quefueron mencionadas en el presente traba&o, por cierto e+isten muchos seguidores" muchos detractores, se trata que el lector evalDe las venta&as " desventa&as "realice su propia e+periencia, tanto en desarrollos a medida tradicionales, comoen los basados en la filosofía del 0pen Source Software#(l uso de un m!todo ágil no es para todos ni para todos los pro"ectos, solo se

limitan a los entornos cambiantes " equipos peque%os#La realidad es que gran parte de los desarrollos peque%os ho" en día utilizanla “metodologia de codificar " corregir, las metodologías ágiles aportan uncon&unto de principios " pasos “livianos a seguir que sin duda a"udaran a losdesarrollos que traba&an sin metodología " que producen ho", software de ba&acalidad " que en muchos casos nunca se implementa# Mambi!n es una a"uda alos equipos que aplican metodologías tradicionales en desarrollos peque%os omedianos para hacer el e&e del desarrollo en la realidad " en el cliente, " no en laaplicación rígida de metodologías que son mu" pesadas de seguir#Los cambios relacionados con la Mecnología de la -nformación obligan a losprofesionales del área a estar abiertos a cualquier cambio que implique me&orar lacalidad del software " permitir que los clientes queden satisfechos, las)etodologías $giles sin duda se orientan en este sentido#

Metodologías Agiles, programación extrema ""Lic. Horacio Kuna – ASC Sergio Caballero



Metodologías Agiles, programación extrema "#Lic. Horacio Kuna – ASC Sergio Caballero



[email protected]!liogra&ía

Extreme %rogramming ex%lained# Gent HecI# (ditorial $ddison Qesle"

<EEEuestioning Extreme Programming #'ete )cHreen # (ditorial $ddison

Qesle" B==BExtreme Programming Pers%ecti'as #)ichele )archesi , 1iancarlo Succi ,

on Qells , Laurie Qilliams# (ditorial $ddison Qesle"# B==Ba'a Extreme Programming CooF!ooF (ric )# HurIe , Hrian )# Co"ner

(ditorial 0V@eill"# B==.

8esting Extreme Programming # Lisa Crispin, Mip ?ouse# (ditorial $ddison Qesle" B==B#gile )o&t*are De'elo%ment EcosAstems # J#?ighsmith # (ditorial

$ddison Qesle"# B==B#gile )o&t*are De'elo%ment *it )C GM # G# Schwaber and )#Heedle,

'rentice ?all# B==BExtreme %rogramming &rom CMM %ers%ecti'e. )# 'aulI# -((( Software

/ovR ic B==< pp <E BU#gile )o&t*are De'elo%ment6 ItHs a!aut &eed!acF and c ange. Laurie

Qilliams# $listair CocIburn# Computer &unio B==.# pp .E 2.#gile 8 roug disci%line6 a de!ate. Gent HecI# Harr" Hoehm# Computer

&unio B==. pp 22 2UInteracti'e and Incremental de'elo%ment6 a !rie& istorA. Craig Larman#

Nictor Hasili# Computer &unio B==.# pp2O TT

#gile so&t*are de'elo%ment6 t e %eo%le &actor. $# CocIburn # Computer nov#B==< pp <.< <..Extreme Programming Ex%lore # Qilliams QaIe# (ditorial $ddison Qesle"#

B===#

Metodologías Agiles, programación extrema "$Lic. Horacio Kuna – ASC Sergio Caballero

http://www.informit.com/safari/author_bio.asp@ISBN=0201844575





http://www.oreillynet.com/cs/catalog/view/au/110@x-t=book.view
















a'a 8ools &or Extreme Programming # @ichard ?ightower /icholas

LesiecIi# (ditorial Qile"# B==BLa Catedral A el Ba:ar # (ric @a"mond# <EEO

Culti'ando la Noos&era # (ric @a"mon# <EEF

)C GM3http3RRcontrolcaos#com

eature Dri'en De'elo%ment 3http3RRwww#featuredrivendevelopment#comR

CrAstal Met odologies 3http3RRmembers#aol#comRacocIburn

#da%tati'e )o&t*are De'elo%ment 3http3RRwww#adaptivesd#com

#gile Modeling 3http3RRwww#agilemodeling#com

http://controlcaos.com/

http://www.featuredrivendevelopment.com/

http://members.aol.com/acockburn

http://www.adaptivesd.com/

http://www.agilemodeling.com/

http://controlcaos.com/

http://www.featuredrivendevelopment.com/

http://members.aol.com/acockburn

http://www.adaptivesd.com/

http://www.agilemodeling.com/

Metodologias Agiles enseñanza

Documents

Transcript of Metodologias Agiles enseñanza