Ansiedad

1.- INDICE

1. CARATULA

2. INDICE

3. INTRODUCCION

4. DESARROLLO

5. CONCLUSION

6. BIBLIOGRAFIA

4.- DESARROLLO

XP (PROGRAMACIÓN EXTREMA)

DE TODAS LAS METODOLOGÍAS ÁGILES, ÉSTA ES LA QUE HA RECIBIDO MÁS ATENCIÓN. ESTO SE DEBE EN PARTE A LA NOTABLE HABILIDAD DE LOS LÍDERES XP, EN PARTICULAR KENT BECK, PARA LLAMAR LA ATENCIÓN. TAMBIÉN SE DEBE A LA HABILIDAD DE KENT BECK DE ATRAER A LAS PERSONAS A ESTE ACERCAMIENTO, Y TOMAR UN PAPEL PRINCIPAL EN ÉL. DE ALGUNAS MANERAS, SIN EMBARGO, LA POPULARIDAD DE XP SE HA VUELTO UN PROBLEMA, PUES HA ACAPARADO LA ATENCIÓN FUERA DE LAS OTRAS METODOLOGÍAS Y SUS VALIOSAS IDEAS.

LAS RAÍCES DE LA XP YACEN EN LA COMUNIDAD DE SMALLTALK, Y EN PARTICULAR LA COLABORACIÓN CERCANA DE KENT BECK Y WARD CUNNINGHAM A FINALES DE LOS 1980S. AMBOS REFINARON SUS PRÁCTICAS EN NUMEROSOS PROYECTOS A PRINCIPIOS DE LOS 90S, EXTENDIENDO SUS IDEAS DE UN DESARROLLO DE SOFTWARE ADAPTABLE Y ORIENTADO A LA GENTE.

LA XP EMPIEZA CON CUATRO VALORES: COMUNICACIÓN, RETROALIMENTACIÓN, SIMPLICIDAD Y CORAJE. CONSTRUYE SOBRE ELLOS UNA DOCENA DE PRÁCTICAS QUE LOS PROYECTOS XP DEBEN SEGUIR. MUCHAS DE ESTAS PRÁCTICAS SON TÉCNICAS ANTIGUAS, TRATADAS Y PROBADAS, AUNQUE A MENUDO OLVIDADAS POR MUCHOS, INCLUYENDO LA MAYORÍA DE LOS PROCESOS PLANEADOS. ADEMÁS DE RESUCITAR ESTAS TÉCNICAS, LA XP LAS TEJE EN UN TODO SINÉRGICO DÓNDE CADA UNA REFUERZA A LAS DEMÁS.

EN ESTA PLATAFORMA XP CONSTRUYE UN PROCESO DE DISEÑO EVOLUTIVO QUE SE BASA EN REFACTORAR UN SISTEMA SIMPLE EN CADA ITERACIÓN. TODO EL DISEÑO SE CENTRA EN LA ITERACIÓN ACTUAL Y NO SE HACE NADA ANTICIPADAMENTE PARA NECESIDADES FUTURAS. EL RESULTADO ES UN PROCESO DE DISEÑO DISCIPLINADO, LO QUE ES MÁS, COMBINA LA DISCIPLINA CON LA ADAPTABILIDAD DE UNA MANERA QUE INDISCUTIBLEMENTE LA HACE LA MÁS DESARROLLADA ENTRE TODAS LAS METODOLOGÍAS ADAPTABLES.

XP HA DESARROLLADO UN LIDERAZGO AMPLIO, MUCHOS DE ELLOS PROVENIENTES DEL PROYECTO FUNDAMENTAL C3. COMO RESULTADO HAY MUCHAS FUENTES PARA MÁS INFORMACIÓN. KENT BECK ESCRIBIÓ EXTREME PROGRAMMING EXPLAINED, EL MANIFIESTO CLAVE DE LA XP QUE EXPLICA LAS RAZONES DETRÁS DE LA METODOLOGÍA Y BASTANTE EXPLICACIÓN COMO PARA QUE LA GENTE PUEDA SABER SI SE INTERESAN EN SEGUIRLA. EN EL ÚLTIMO PAR DE AÑOS HA HABIDO UNA EPIDEMIA DE LIBROS SOBRE XP BRILLANTEMENTE COLOREADOS LA MAYORÍA DE LOS CUALES SON BASTANTE SIMILARES EN QUE DESCRIBEN

EL PROCESO ENTERO DESDE EL PUNTO DE VISTA DE VARIOS SEGUIDORES TEMPRANOS.

LA FAMILIA DE CRISTAL DE COCKBURN

ES UNA FAMILIA PORQUE ÉL CREE QUE LOS TIPOS DIFERENTES DE PROYECTOS REQUIEREN TIPOS DIFERENTES DE METODOLOGÍAS. ÉL MIRA ESTA VARIACIÓN A LO LARGO DE DOS EJES: EL NÚMERO DE PERSONAS EN EL PROYECTO, Y LAS CONSECUENCIAS DE LOS ERRORES. CADA METODOLOGÍA ENCAJA EN UNA PARTE DIFERENTE DE LA REJA, DE MODO QUE PARA UN PROYECTO DE 40 PERSONAS QUE PUEDE PERDER DINERO DISCRECIONALMENTE TIENE UNA METODOLOGÍA DIFERENTE A LA DE UN PROYECTO VITAL DE SEIS PERSONAS.

LOS CRISTALES COMPARTEN CON LA XP UNA ORIENTACIÓN HUMANA, PERO ESTA CENTRALIZACIÓN EN LA GENTE SE HACE DE UNA MANERA DIFERENTE. ALISTAIR CONSIDERA QUE LAS PERSONAS ENCUENTRAN DIFÍCIL SEGUIR UN PROCESO DISCIPLINADO, ASÍ QUE MÁS QUE SEGUIR LA ALTA DISCIPLINA DE LA XP, ALISTAIR EXPLORA LA METODOLOGÍA MENOS DISCIPLINADA QUE AUN PODRÍA TENER ÉXITO, INTERCAMBIANDO CONSCIENTEMENTE PRODUCTIVIDAD POR FACILIDAD DE EJECUCIÓN. ÉL CONSIDERA QUE AUNQUE CRISTAL ES MENOS PRODUCTIVO QUE LA XP, MÁS PERSONAS SERÁN CAPACES DE SEGUIRLO.

ALISTAIR TAMBIÉN PONE MUCHO PESO EN LAS REVISIONES AL FINAL DE LA ITERACIÓN, ANIMANDO AL PROCESO A SER AUTO MEJORANTE. SU ASERCIÓN ES QUE EL DESARROLLO ITERATIVO ESTÁ PARA ENCONTRAR LOS PROBLEMAS TEMPRANO, Y ENTONCES PERMITIR CORREGIRLOS. ESTO PONE MÁS ÉNFASIS EN LA GENTE SUPERVISANDO SU PROCESO Y AFINÁNDOLO CONFORME DESARROLLAN.

CÓDIGO ABIERTO

DESPUÉS DE TODO EL CÓDIGO ABIERTO ES UN ESTILO DE SOFTWARE, NO TANTO UN PROCESO. SIN EMBARGO HAY UNA MANERA DEFINIDA DE HACER LAS COSAS HACIENDO EN LA COMUNIDAD DE CÓDIGO ABIERTO, Y MUCHO DE SU ACERCAMIENTO ES TAN APLICABLE A LOS PROYECTOS DE CÓDIGO CERRADO COMO A LOS DE CÓDIGO ABIERTO. EN PARTICULAR SU PROCESO SE ENGRANA A EQUIPOS FÍSICAMENTE DISTRIBUIDOS, LO QUÉ ES IMPORTANTE PORQUE LA MAYORÍA DE LOS PROCESOS ADAPTABLES EXIGEN EQUIPOS LOCALES.

LA MAYORÍA DE LOS PROYECTOS DE CÓDIGO ABIERTO TIENEN UNO O MÁS MANTENEDORES. UN MANTENEDOR ES LA ÚNICA PERSONA A LA QUE SE LE PERMITE INTEGRAR UN CAMBIO EN EL ALMACÉN DE CÓDIGO FUENTE. SIN EMBARGO OTRAS PERSONAS PUEDEN HACER CAMBIOS A LA BASE DEL CÓDIGO. LA DIFERENCIA IMPORTANTE ES QUE ESTAS OTRAS PERSONAS NECESITAN ENVIAR SU CAMBIO AL MANTENEDOR QUE

ENTONCES LO REVISA Y LO APLICA A LA BASE DEL CÓDIGO. NORMALMENTE ESTOS CAMBIOS SON HECHOS EN FORMA DE ARCHIVOS DE PARCHES QUE HACEN ESTE PROCESO MÁS FÁCIL. EL MANTENEDOR ASÍ ES RESPONSABLE DE COORDINAR LOS PARCHES Y MANTENER LA COHESIÓN EN EL DISEÑO DEL SOFTWARE.

PROYECTOS DIFERENTES MANEJAN EL PAPEL DEL MANTENEDOR DE DIFERENTES MANERAS. ALGUNOS TIENEN UN MANTENEDOR PARA EL PROYECTO ENTERO, ALGUNOS LO DIVIDEN EN MÓDULOS Y TIENE UN MANTENEDOR POR MÓDULO, ALGUNOS ROLAN EL MANTENEDOR, ALGUNOS TIENEN MÚLTIPLES MANTENEDORES SOBRE EL MISMO CÓDIGO, OTROS TIENEN UNA COMBINACIÓN DE ESTAS IDEAS. LA MAYOR PARTE DE LA GENTE DE CÓDIGO ABIERTO SON DE TIEMPO PARCIAL, ASÍ QUE HAY UNA DUDA EN QUÉ TAN BIEN SE COORDINA UN EQUIPO ASÍ PARA UN PROYECTO DE TIEMPO COMPLETO.

UN RASGO PARTICULAR DEL DESARROLLO DE CÓDIGO ABIERTO ES QUE LA DEPURACIÓN ES ALTAMENTE PARALELIZABLE. MUCHAS PERSONAS PUEDEN INVOLUCRARSE EN EL DEPURADO. CUANDO ENCUENTRAN UN BUG PUEDEN ENVIAR EL PARCHE AL MANTENEDOR. ESTO ES UN BUEN PAPEL PARA LOS NO MANTENEDORES YA QUE LA MAYOR PARTE DEL TIEMPO SE GASTA EN ENCONTRAR BUGS. TAMBIÉN ES BUENO PARA GENTE SIN MUCHA DESTREZA EN PROGRAMACIÓN.

EL PROCESO PARA EL CÓDIGO ABIERTO AUN NO SE ESCRIBE BIEN. LA REFERENCIA MÁS FAMOSA ES EL ARTÍCULO DE ERIC RAYMOND THE CATEDRAL AND THE BAZAR, QUE AUNQUE ES UNA DESCRIPCIÓN EXCELENTE TAMBIÉN ES

...