Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

Extreme programming
A principios de 1990, un hombre llamado Kent Beck estaba pensando en diferentes maneras para desarrollar software. Hasta que en 1996, puso en prctica Kent su nueva metodologa en el proyecto de DaimChrysler utiliz distintas tcnicas de desarrollo de software, esta nueva metodologa para desarrollar software, fue nombrada Extreme programming. Extreme programming es una nueva disciplina del desarrollo de software que se basa en la comunicacin, simplicidad, retroalimentacin y valor. La simplicidad ayuda a que los desarrolladores de software encuentren soluciones ms simples a problemas, segn el cliente lo estipula. Los desarrolladores tambin crean caractersticas en el diseo que pudieran ayudar a resolver problemas en un futuro. La comunicacin prevalece en todas las prcticas de extreme programming. Comunicacin cara a cara es la mejor forma de comunicacin, entre los desarrolladores y el cliente. Mtodo muy gil. Gracias a esto el equipo esta pude realizar cambios que al cliente no le gustaron. Tambin apoya agilidad con la extensin del conocimiento tcito dentro del equipo del desarrollo, evitando la necesidad de mantener la documentacin escrita. La Retroalimentacin continua del cliente permite a los desarrolladores llevar y dirigir el proyecto en una direccin correcta hacia donde el cliente quiera. El valor requiere que los desarrolladores vayan a la par con el cambio, por que sabemos que este cambio es inevitable, pero el estar preparado con una metodologa ayuda a ese cambio. La metodologa se disea para entregar el software segn las necesidades de cliente y cuando sea necesaria. Extreme programming promueve el trabajo del equipo. Cada integrante del proyecto (cliente, desarrolladores, etc.) forman parte integral del equipo encargado de desarrollar software de calidad. 13 prcticas incorporan estos valores y se describen as: El Juego de Planificacin (The planning game). Son una serie de actividades planificadas que son llamados juegos planificados por extreme programming, son asumidos durante el transcurso del proyecto. Un juego inicial planeado se emprende durante el inicio del proyecto e implica una sesin con el cliente de reflexin con algunos personas claves como desarrolladores para determinar los requisitos iniciales y el 1

Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

contorno, conocidos en la metodologa como historias. Si el proyecto contina, se sigue con un emprende Planning game de lanzamiento donde el cliente escribe otras historias en tarjetas y los desarrolladores buscan trminos de Unidades Ideales de Ingeniera. El cliente tambin planea un calendario iterativo de desarrollo, cada iteracin funciona entre dos y cuatro semanas, y subdivide historias en base a la prioridad del negocio. En el comienzo de cada iteracin el cliente puede agregar otras historias, y cambiar el horario de la historia. En realidad pretende un permanente dialogo entre la parte empresarial y tcnica del proyecto, en la que los empresarios deciden el alcance, la prioridad, el contenido de las versiones y la fecha de estas. Y la parte tcnica, son los responsables de establecer la duracin para implementar las funciones deseados por el cliente, de desarrollar la planificacin de cada versin, entre otras. Desarrollo de Probar-Conducir. (Test-driven development). Esta es la forma de prueba de unidad y de prueba de aceptacin, donde las pruebas se escriben antes de la implementacin del cdigo. Las pruebas de aceptacin, son escritas por el cliente, se automatizan y prueban generalmente la funcionalidad del sistema. Las pruebas de unidad son escritas por los desarrolladores y prueba que las unidades del cdigo estn a un nivel segn lo esperado. Programacin del par (Pair programming). Extreme programming requiere que todo el cdigo de la produccin sea producido por un par desarrolladores compartiendo un monitor y un teclado en una estacin de trabajo. Uno acta como conductor y escribe cdigo mientras que el otro, el navegador, observa qu est pasando y proporciona consejos estratgicos para resolver los problemas de manera eficiente. El conductor tiene que estar explicando que es lo que esta haciendo y se pueden intercambiar los roles con frecuencia. Por otro lado, para facilitar el trabajo entre los miembros del equipo, estos pueden interactuar con otros individuos para realizar la tarea. El reorganizado sin piedad (Merciless refactoring ). Los desarrolladores requieren mejorar el cdigo sin que este cambie su funcin para realizar un cdigo simple. Esto dar oportunidad a modificarlo cuando haya necesidad de cambiar una caracterstica. Diseo simple (Simple Design) . Los desarrolladores necesitan seguir el principio de YAGNI (You Are not Going to Need It)(usted no lo va a necesitar) al producir un diseo para una historia dada. El diseo no debe no incluir otra cosa que no sea necesaria para ejecutar la historia y pasar las pruebas de unidad. Y lo que en realidad busca extreme programming es buscar soluciones y disear en cada momento para las decisiones necesitadas en ese momento.

Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

Propiedad colectiva del cdigo (Colective code ownership) . Todos los desarrolladores son propietarios del cdigo. Cualquier desarrollador puede modificar el cdigo base en cualquier momento aunque haya sido hecho por otro par de desarrolladores, por ejemplo, si un desarrollador encuentra otra forma de hacer el cdigo de manera mas simple lo puede hacer sin ningn inconveniente, claro siempre y cuando no altere su funcionalidad. El objetivo es quitar dependencias en individuos. Integracin continua (Continuos Integration). Al cabo de un da el sistema deber de ser integrado por una mquina, cada vez que un para de programadores tengan una clase ya probada unitariamente. Si al aadir la clase el sistema completo sigue funcionando correctamente, la tarea fue realizada con xito. De lo contrario, esto permite que los desarrolladores detecten errores en la integracin del sistema en una etapa antes ejecutando las pruebas de unidad del proyecto. Si despus de esto no pueden realizar el cdigo, lo borraran y comenzaran desde cero. Cliente en el sitio (On-site Costumer). Los desarrolladores tienen acceso continuo con el cliente para poner en claro las historias y discutir el desarrollo de ediciones y proporcionar retroalimentacin. Y un cliente real debe permanecer junto al equipo de desarrollo, para cualquiera duda o aclaracin. Lanzamientos pequeos (Small releases) . Al final de cada iteracin el sistema es lanzado y el cliente lo observa. Se lanza primero unos meses antes de estar completamente terminado, las otras versiones sern mas frecuentes entre un da y un mes. La mayora de estos lanzamientos es para conseguir retroalimentacin del cliente. Semana de 40 horas (40 hours week). Si queremos que sea un trabajo de calidad , los trabajadores tienen que estar bien descansados , no superando la regla de las 40 horas semanales y que tengan otras cosas que hacer y no estn obsesionados con el trabajo. El objetivo no es el trabajo extra, sino mantener el balance entre el trabajo y la vida. Esto est en los intereses del proyecto. Aplique los estndares de la codificacin (Apply coding standards) . El cdigo es la forma principal de documentacin y por lo tanto debe de estar escrito de una manera clara y constante, que pueda ser identificado fcilmente por cualquier programador de otro equipo. Metfora del sistema (System metaphore) . Un lenguaje de metforas se utiliza para describir la arquitectura del sistema. Esto ayuda a la comunicacin entre los mismos desarrolladores y entre los desarrolladores y el cliente. 3

Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

Reunin (Stand-up meeting). Una reunin de 15 minutos en el comienzo de cada da para discutir problemas encontrados el da anterior y los problemas que se resolvern durante el da.

Extreme programming es como un rompecabezas .Hay muchos pedazos pequeos. Los pedazos individualmente no tienen ningn sentido, pero cuando estn combinados pueden ser considerados un cuadro completo. Esto es una salida significativa de mtodos tradicionales y del desarrollo del software en un cambio en la manera que programamos. Extreme programming establece cuatro variables para cualquier proyecto de software: costo, tiempo, calidad y alcance. Tambin establece, que de estas cuatro variables que tenemos, solo tres de ellas podrn ser fijadas o indicadas por el cliente o jefe del proyecto, mientras que una variable quedar libre. Un problema de esto es la calidad, por que muchas veces se ignora, por que nadie es capaz de trabajar bien cuando esta sometido a mucha presin. Las variables entre s, no guardan una relacin tan obvia. Extreme programming, hace nfasis en equipos de desarrollo pequeos entre diez y doce personas, que podrn ir incrementando. El costo del proyecto se incrementa cuando se necesita mquinas ms rpidas, mas especialistas tcnicos en determinadas reas o mejores oficinas para el equipo de desarrollo. La calidad puede representar un cambio extrao; debido a que a mayor calidad menor tiempo de realizacin del proyecto. Por lo tanto el equipo de desarrolladores esta encargado de la tarea de hacer las pruebas con los mejores resultados posibles para as tener una idea de cual es el problema y como lo van a resolver de una manera simple y eficiente, para que la calidad del proyecto se mantenga al 100% y tener una facilidad de adaptarse a los cambios del cdigo lo que hace este proceso ms rpido. No tener en cuenta que la gente trabaja mejor cuando la dejan hacer trabajo de calidad y sin presin puede llegar a que el proyecto no se desarrolle a su tiempo y con una calidad por los suelos. La ultima variable es la que se encuentra libre y como ya mencion no es establecida por los directores, sino que ya que se tiene una buen idea de las otras tres variables, se contina a realizar el proceso de alcance del proyecto, en la cual el equipo determina: la estimacin de las tareas a realizar, que es lo que

Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

el cliente quiere, la implementacin de los requisitos mas importantes de manera que este siempre sea funcional. En extreme programming el costo del cambio maneja un papel muy importante, por que comparado con otras metodologas para implementar software, es mucho mas barato, debido a que las pruebas se van haciendo segn las versiones liberadas, no es como una metodologa normal, que primero se realiza el anlisis, despus el diseo, implementacin, pruebas y finalmente produccin, mientras que en la extreme programming siempre estas implementando, probando y produciendo.

*.Costo del cambio en la ingeniera de software tradicional.

*Costo del cambio en extreme programming.

Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

Los largos ciclos de desarrollo de las metodologas tradicionales son incapaces de adaptarse al cambio, tal vez una solucin puede ser ciclos de desarrollo ms cortos como la extreme programming.

*Diagrama de los ciclos de desarrollo de software Conclusin Y concluy que extreme programming es una metodologa de desarrollo de software basada en la simplicidad, la comunicacin, el valor y la retroalimentacin. Simplicidad en la realizacin de cdigo. Valor en el desarrollo de software y estar prevenidos para adaptarse a los cambios. Comunicacin contina entre el cliente, los directores del proyecto y los desarrolladores. La retroalimentacin para que el cliente pueda opinar y detectar las cosas que no sean necesarias. Trabaja al traer a todo el equipo junto para prcticas presenciales simples, con suficiente retroalimentacin para saber donde esta el equipo y para ver que es lo que necesitan. Extreme programming ayuda a desarrollar solo lo que se necesita desarrollar para resolver un problema. Algo muy importante en esta metodologa es que si no hay una comunicacin efectiva el proyecto no tendr xito. Una ventaja del extreme programming es que como se trabaja en parejas, lo que uno lo ve muy complicado otro lo puede ver de una manera simple y que puede ser interpretado por otra pareja de programadores. Otra ventaja de esta metodologa es la constante comunicacin y retroalimentacin que no tenamos en otras metodologas. Y por ltimo tenemos la ventaja de que podemos detectar errores desde el principio y no hasta el ultimo. Por eso la extreme programming es una buena metodologa para usar.

Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

*Diagrama del extreme programming

Fausto Alberto Paredes Villarreal Ingeniera de Software

ITC

792696

Bibliografa
{Chris Loftus and Mark Ratcliffe} 2003 <http://0-delivery.acm.org.millenium.itesm.mx/10.1145/1070000/1067531/p311loftus.pdf? key1=1067531&key2=4928581311&coll=portal&dl=ACM&CFID=60152549&CFT OKEN=19787734> {Roland E. Jefrries- www} 1999- 2005. <http://www.extremeprogramming.org/rules/iterative.html > {James Kewkirk y Robert C. Martin }Object Magazine, 1996 <http://0-delivery.acm.org.millenium.itesm.mx/10.1145/370000/367909/p25newkirk.pdf? key1=367909&key2=5218581311&coll=portal&dl=ACM&CFID=60152549&CFTO KEN=19787734> {Kent Beck} Dedalous consulting Germany <http://0-delivery.acm.org.millenium.itesm.mx/10.1145/320000/318778/p1beck.pdf? key1=318778&key2=9387581311&coll=portal&dl=ACM&CFID=60152549&CFTO KEN=19787734> {Don Wells-www}1999<http://www.xprogramming.com/xpmag/whatisxp.htm> *{Antonio Crespo Foix-www} 2002 <http://www.ati.es/novatica/2002/156/nv156sum.html#edit >