19 de junio de 2011

ndice

Objetivo ..3 Introduccin ...4 Objetivos de la Programacin Extrema ....5 Algunas bases de la Programacin Extrema .. 5 Las cuatro Variables ... 5 El costo del cambio . 6 Los Cuatro Valores .. 7 Roles XP .8 Prcticas bsicas de la Programacin Extrema .. 9 Comentarios respecto de las prcticas ....11 Los pasos a seguir en un proyecto ...12 Cundo usar XP ..... 13 Ventajas y desventajas de la Programacin Extrema14 Aplicacin del Estndar ISO 9001:2000 a la Metodologa de Programacin Extrema.15 Conclusin 16 Anexo I - El Manifiesto gil 17 Referencias bibliogrficas.......18

Pgina

2/18

Objetivo - Introduccin al estudio de la Programacin Extrema (XP, eXtreme Programming) y su aplicacin. . - Conocer las principales prcticas de la Programacin Extrema: programacin basada en tests, diseos

simples, etc.

Introduccin La Programacin Extrema ( del ingls Extreme Programming ) es uno de los llamados procesos o
Pgina

3/18

metodologas giles de desarrollo de software. Consiste en un conjunto de Prcticas que a lo largo de los aos han demostrado ser las mejores prcticas de desarrollo de software, llevadas al extremo, fundamentadas en un conjunto de Valores. De todas las metodologas giles, es la que ha recibido ms atencin. Esto se debe en parte a la notable habilidad de los lderes XP, en particular Kent Beck, para llamar la atencin. Tambin se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento, y tomar un papel principal en l. De alguna maneras, sin embargo, la popularidad de XP se ha vuelto un problema, pues ha acaparado la atencin fuera de las otras metodologas y sus valiosas ideas. Las races de la XP yacen en la comunidad de Smalltalk, y en particular la colaboracin cercana de Kent Beck y Ward Cunningham a finales de 1980. Ambos refinaron sus prcticas en numerosos proyectos a principios de 1990, extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente. El paso crucial de la prctica informal a una metodologa ocurri en la primavera de 1996. A Kent se le pidi revisar el progreso del proyecto de nmina C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por una compaa contratista, y estaba en problemas. Debido a la baja calidad de la base del cdigo, Kent recomend tirar la base del cdigo en su totalidad y empezar desde el principio. El proyecto entonces reinici bajo su direccin y subsecuentemente se volvi el buque insignia temprano y el campo de entrenamiento de la XP. La primera fase del C3 fue muy exitosa y comenz a principios de 1997. El proyecto continu desde entonces y despus se encontr con dificultades, lo que result en la cancelacin del desarrollo en 1999. (Lo cual prueba, si ninguna otra cosa, que la XP no es garanta de xito.) XP ha desarrollado un liderazgo amplio, muchos de ellos provenientes del proyecto fundamental C3. Kent Beck escribi Extreme Programming Explained, el manifiesto clave de la XP que explica las razones detrs de la metodologa y bastante explicacin como para que la gente pueda saber si se interesan en seguirla. Kent Beck fue el pionero de patrones software, creador de las fichas CRC, autor del framework para editores de dibujo HotDraw, del framework de testing xUnit.

Objetivos de la Programacin Extrema Los objetivos de XP son muy simples: la satisfaccin del cliente. Esta metodologa trata de dar al cliente el software que l necesita y cuando lo necesita. Por tanto, debemos responder muy rpido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programacin.

Pgina

4/18

El segundo objetivo es potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estn involucrados en el desarrollo del software.

Algunas bases de la Programacin Extrema En la programacin extrema se da por supuesto que es imposible prever todo antes de empezar a codificar. Es imposible capturar todos los requisitos del sistema, saber qu es todo lo que tiene que hacer, ni hacer un diseo correcto al principio. Es bastante normal hacer un diseo, ponerse a codificar, ver que hay faltantes o errores en el diseo, empezar a codificar fuera del diseo y al final el cdigo y el diseo, o no se parecen, o hemos echado un montn de tiempo en cambiar la documentacin de diseo para que se parezca al cdigo. Todo en el software cambia. Los requisitos cambian. El diseo cambia. El negocio cambia. La tecnologa cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en s mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando ste tiene lugar. En vez de tratar de luchar contra todo eso, lo asume y busca una forma de trabajar que se adapte fcilmente a esas circunstancias. Bsicamente la idea de la programacin extrema consiste en trabajar estrechamente con el cliente, hacindole mini-versiones con mucha frecuencia (cada dos semanas). En cada mini-versin se debe hacer el mnimo de cdigo y lo ms simple posible para que funcione correctamente. El diseo se hace sobre la marcha, haciendo un mini-diseo para la primera mini-versin y luego modificndolo en las siguientes mini-versiones. Adems, no hay que hacer una documentacin para el diseo, no hay mejor documentacin que el mismo cdigo. El cdigo, por tanto, tambin se modifica continuamente de mini-versin en mini-versin, aadindole funcionalidad y extrayendo sus partes comunes.

Las cuatro Variables

XP define cuatro variables para cualquier proyecto software: costo, tiempo, calidad y alcance. Adems, especifica que, de estas cuatro variables, slo tres de ellas podrn ser fijadas por las fuerzas externas al proyecto (clientes y jefes de proyecto), mientras que el valor de la variable libre ser establecido por el equipo de desarrollo en funcin de los valores de las otras tres. XP hace a las cuatro variables visibles para todo el mundo programadores, clientes y jefes de proyecto de manera que se pueda jugar con los valores de la entrada hasta que la cuarta variable tenga un valor que satisfaga a todos (pudiendo escoger otras variables diferentes a controlar, por supuesto). Ocurre adems que las cuatro variables no guardan entre s una relacin tan obvia como a menudo se quiere ver. XP hace especial nfasis en equipos de desarrollo pequeos (diez o doce personas como mucho) que, naturalmente, se podrn ir incrementando a medida que sea necesario, pero no antes, o los resultados sern generalmente contrarios a lo esperado. Es bueno, en cambio, incrementar el costo del proyecto en aspectos como mquinas ms rpidas, ms especialistas tcnicos en determinadas reas o mejores oficinas para el equipo de desarrollo.

Con la calidad tambin sucede otro fenmeno extrao: frecuentemente, aumentar la calidad conduce a que el proyecto pueda realizarse en menos tiempo. En efecto, en cuanto el equipo de desarrollo se habite a realizar pruebas intensivas y se sigan estndares de codificacin, poco a poco comenzar a avanzar mucho ms rpido de lo que lo haca antes, mientras la calidad del proyecto se mantiene asegurada por las pruebas al 100%, lo que conlleva mayor confianza en el cdigo y, por tanto, mayor facilidad para adaptarse al cambio, sin estrs, lo que hace que se programe ms rpido y as sucesivamente. Frente a esto, est la tentacin de sacrificar la calidad interna del proyecto la que es apreciada por los programadores para reducir el tiempo de entrega del proyecto, en la confianza de que la calidad
Pgina

5/18

externa la que notan los clientes - no se vea demasiado afectada. Sin embargo, sta es una apuesta a muy corto plazo, que suele ser una invitacin al desastre, pues obvia el hecho fundamental de que todo el mundo trabaja mucho mejor cuando le dejan hacer trabajo de calidad. No tener esto en cuenta conduce a la desmoralizacin del equipo y, con ello, a la larga, a la ralentizacin del proyecto mucho ms all del tiempo que hubiera podido ganarse al principio con esta reduccin de calidad. En cuanto al alcance del proyecto, es una buena idea dejar que sea esta la variable libre, de manera que, una vez fijadas las otras tres, el equipo de desarrollo determinara el alcance mediante: La estimacin de las tareas a realizar para satisfacer los requisitos del cliente. La implementacin de los requisitos ms importantes primero, de manera que el proyecto tenga en cada instante tanta funcionalidad como sea posible.

El costo del cambio

Una de las asunciones ms importantes e innovadoras que hace XP frente a la mayora de los mtodos conocidos es la referida al coste del cambio. En efecto, en la ingeniera de software tradicional siempre ha sido una verdad universal el hecho de que el coste del cambio en el desarrollo de un proyecto se incrementaba exponencialmente en el tiempo:

Lo que XP propone es que esta curva ha perdido validez y que con una combinacin de buenas prcticas de programacin y tecnologa es posible lograr que la curva sea la contraria:

Pgina

6/18

Al emplear XP como proceso de desarrollo de software, deberemos adoptarlo basndonos en esta curva. La idea fundamental aqu es que, en vez de disear para el cambio, disearemos tan sencillo como sea posible, para hacer slo lo que sea imprescindible en un momento dado, pues la propia simplicidad del cdigo, junto con nuestros conocimientos de factorizacin y, sobre todo, los tests y la integracin continua, hacen posible que los cambios puedan ser llevados a cabo tan seguido como sea necesario.

Los Cuatro Valores La XP empieza con cuatro valores: Comunicacin, Retroalimentacin, Simplicidad y Coraje. Construye sobre ellos una docena de prcticas que los proyectos XP deben seguir. Muchas de estas prcticas son tcnicas antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos, incluyendo la mayora de los procesos planeados. Adems de resucitar estas tcnicas, la XP las teje en un todo sinrgico dnde cada una refuerza a las dems. Una de las ms llamativas, es su fuerte nfasis en las pruebas. Mientras todos los procesos mencionan la comprobacin, la mayora lo hace con muy poco nfasis. Sin embargo la XP pone la comprobacin como el fundamento del desarrollo, con cada programador escribiendo pruebas cuando escriben su cdigo de produccin. Las pruebas se integran en el proceso de integracin continua y construccin lo que rinde una plataforma altamente estable para el desarrollo futuro. En esta plataforma XP construye un proceso de diseo evolutivo que se basa en refactorar un sistema simple en cada iteracin. Todo el diseo se centra en la iteracin actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseo disciplinado, lo que es ms, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la ms desarrollada entre todas las metodologas adaptables.

Roles XP Aunque en otras fuentes de informacin aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck. Programador

Pgina

7/18

El programador escribe las pruebas unitarias y produce el cdigo del sistema. Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo. Cliente El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin, centrndose en aportar mayor valor al negocio. El cliente es slo uno dentro del proyecto pero puede corresponder a un interlocutor que est representando a varias personas que se vern afectadas por el sistema. Encargado de pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker) El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es necesario realizar algn cambio para lograr los objetivos de cada iteracin. Entrenador (Coach) Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Consultor Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. Gestor (Big boss) Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

Prcticas bsicas de la Programacin Extrema La mayora de estas prcticas no son nuevas, sino que han sido reconocidas por la industria como las mejores prcticas durante aos. En la XP, dichas prcticas son llevadas al extremo para que se obtenga algo mucho mejor que la suma de las partes: Planificacin

Pgina

8/18

XP no es slo un mtodo centrado en el cdigo que lo es, sino que sobre todo es un mtodo de gestin de proyectos software. Una parte fundamental de XP es precisamente la planificacin. Lo que ocurre es que, aceptando que el desarrollo de software, como acaso cualquier cosa en esta vida, es un proceso catico, no trata de buscar un determinismo inexistente y s de poner los medios necesarios para manejar esa complejidad, aceptndola, sin tratar de doblegarla con los mtodos pesados o burocrticos. La teora del caos tiene mucho que ver con esta idea subyacente de XP. En definitiva, los mtodos ligeros y XP es uno de ellos son adaptativos ms que predictivos . XP plantea la planificacin como un permanente dilogo entre la parte empresarial y tcnica del proyecto, en la que los primeros decidirn el alcance qu es lo realmente necesario del proyecto?, la prioridad qu debe ser hecho en primer lugar, la composicin de las versiones qu debera incluir cada una de ellas y la fecha de las mismas. En cuanto a los tcnicos, son los responsables de estimar la duracin requerida para implementar las funcionalidades deseadas por el cliente, de informar sobre las consecuencias de determinadas decisiones, de organizar la cultura de trabajo y, finalmente, de realizar la planificacin detallada dentro de cada versin. Versiones pequeas El sistema se pone por primera vez en produccin en, a lo sumo, unos pocos meses, antes de estar completamente terminado. Las sucesivas versiones sern ms frecuentes entre un da y un mes. El cliente y el equipo de desarrollo se beneficiarn de la retroalimentacin que produce un sistema funcionando, y esto se reflejar en sucesivas versiones. Diseo sencillo En vez de perseguir a toda costa un diseo en el que hemos de desarrollar dotes adivinatorias para tratar de anticiparnos al futuro, lo que XP preconiza es disear en cada momento para las necesidades presentes. El diseo adecuado para el software es aquel que: supera con xito todas las pruebas, no tiene lgica duplicada, refleja claramente la intencin de implementacin de los programadores y tiene el menor nmero posible de clases y mtodos. Pruebas El pilar bsico sobre el que se sustenta XP es Cualquier caracterstica de un programa para la que no haya un test automatizado, simplemente no existe. Otros principios son susceptibles de ser adaptados a las caractersticas del proyecto, de la organizacin, del equipo de desarrollo, etc. Pero aqu no hay discusin posible: si no hacemos tests, no estaremos haciendo XP. Para ello, deberemos emplear algn framework de testing automtico, como JUnit [www.junit.org] o cualquiera de sus versiones para diferentes lenguajes. No slo eso, sino que escribiremos los tests antes incluso que la propia clase a probar. Esto ayuda al principio de programacin por intencin, esto es, a escribir el cdigo como si los mtodos ms costosos ya hubieran sido escritos y slo tuviramos as que enviar el correspondiente mensaje, de manera que el cdigo refleje bien su intencin y se documente a s mismo. En el sitio web de JUnit mencionado en el prrafo anterior se pueden encontrar interesantes artculos que explican cmo deben escribirse estos tests.

Refactorizacin Responde al principio de simplicidad. Y, muy escuetamente, consiste en dejar el cdigo existente en el estado ms simple posible, de manera que no pierda ni gane funcionalidad y que se sigan ejecutando correctamente todos los tests. Esto nos har sentirnos ms cmodos con el cdigo ya escrito y, por tanto, menos reacios a modificarlo cuando haya que aadir o cambiar alguna caracterstica. En el caso de sistemas heredados, o de proyectos que se tomen ya empezados, seguramente habr que dedicar varias semanas slo a factorizar el cdigo lo cual suele ser fuente de tensiones con el correspondiente jefe de proyecto, cuando se le diga que se va a parar ste varios das slo para modificar el cdigo existente, que funciona, sin aadirle ninguna nueva funcionalidad. Programacin en parejas
Pgina

9/18

Todo el cdigo ser desarrollado en parejas dos personas compartiendo un solo monitor y teclado. Quien codifica estar pensando en el mejor modo de implementar un determinado mtodo, mientras que su compaero lo har de una manera ms estratgica: Estamos siguiendo el enfoque apropiado? Qu es lo que podra fallar aqu? Qu deberamos comprobar en los tests ? Hay alguna manera de simplificar el sistema? Por supuesto, los roles son intercambiables, de manera que en cualquier momento quien observaba puede tomar el teclado para ejemplificar alguna idea o, simplemente, para turnar a su compaero. Igualmente, la composicin de las parejas cambiar siempre que uno de los dos sea requerido por algn otro miembro del equipo para que le ayude con su cdigo. Propiedad colectiva del cdigo Cualquiera puede modificar cualquier porcin del cdigo, en cualquier momento. En efecto, cualquiera que vea una posibilidad de simplificar, mediante refactoring, cualquier clase o cualquier mtodo, hayan sido o no escritos por l, deber hacerlo sin ms dilacin. El uso de estndares de codificacin y la confianza que nos dan los tests de que todo va a seguir funcionando bien tras una modificacin, hacen que esto no sea ningn problema en XP. Integracin continua Cada pocas horas o al cabo de un da de programacin, como mucho se integra el sistema completo Para ello existir un mquina as llamada, de integracin, a la que se acercar una pareja de programadores cada vez que tengan una clase que haya sido probada unitariamente. Si al aadir la nueva clase junto con sus tests unitarios, el sistema completo sigue funcionando correctamente pasa todos los tests, los programadores darn por finalizada esa tarea. Si no, sern los responsables de dejar el sistema de nuevo con los tests funcionando al 100%. Si despus de un cierto tiempo no son capaces de descubrir qu es lo que falla, tirarn el cdigo a la basura y volvern a comenzar de nuevo. 40 horas semanales Si realmente queremos ofrecer calidad, y no meramente un sistema que funcione lo cual, en informtica, ya sabemos que es trivial querremos que cada miembro de nuestro equipo se levante cada maana descansado y se vaya a las 6 de la tarde a su casa cansado y con la satisfaccin del trabajo bien hecho, y que al llegar el viernes sepa que cuenta con dos das para descansar y dedicarse a cosas que nada tengan que ver con el trabajo. Naturalmente, las 40 horas no es una regla fija pueden ir de 35 a 45, pero lo que es seguro es que nadie es capaz de trabajar 60 horas a la semana y hacerlo con calidad. Cliente in situ Otra controvertida regla de XP: al menos un cliente real debe estar permanentemente junto al equipo de desarrollo, para responder cualquier consulta que los programadores le planteen, para establecer prioridades. Si el cliente arguye que su tiempo es demasiado valioso, deberemos entender que realmente el proyecto que nos ha encomendado es lo suficientemente trivial como para que no merezca su atencin, y que no importa que est construido a partir de suposiciones hechas por programadores que nada, o muy poco, saben del negocio real. Estndares de codificacin Es decisiva para poder plantear con xito la propiedad colectiva del cdigo. sta sera impensable sin una codificacin basada en estndares que haga que todo el mundo se sienta cmodo con el cdigo escrito por cualquier otro miembro del equipo.

Metforas Hay que buscar unas frases o nombres que definan cmo funcionan las distintas partes del programa, de forma que slo con los nombres se pueda uno hacer una idea de qu es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qu estamos hablando y que no haya mal entendidos.

Comentarios respecto de las prcticas El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se apoyan unas en otras. La mayora de las prcticas propuestas por XP no son novedosas sino que en
Pgina

10/18

alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la prctica . El mrito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

Las Prcticas se refuerzan entre s: Una lnea entre dos prcticas significa que las dos prcticas se refuerzan entre s.

Los pasos a seguir en un proyecto En un proyecto usando programacin extrema se siguen ms o menos los siguientes pasos: El cliente junto al equipo de desarrollo definen qu es lo que se quiere hacer. Para ello utilizan las "historias de usuario". Una historia de usuario en un texto de una o dos frases en las que se dice algo que debe hacer el sistema. Es ms extensa que un requisito (que suele ser una frase corta) y menos que un caso de uso (que puede ser de una o dos pginas). Se evala para cada historia de usuario el tiempo que puede llevar, que debe ser corto, de aproximadamente una semana. Un programador puede estimar con cierta fiabilidad un trabajo que le lleve unos das, pero la estimacin es menos fiable si es de un plazo superior a una semana. Si es ms largo, hay que partir la historia en otras ms pequeas. Luego se ordenan en el orden en que se van a desarrollar y se establecen las mini-versiones, de forma que cada mini-versin implementa varias de las historias de usuario. Toda esta planificacin va a ser, por supuesto, inexacta. No se puede saber todo lo que va a ser necesario ni evaluar los tiempos correctamente. La planificacin deber revisarse y modificarse continuamente a lo largo del proyecto. Las historias de usuario se modificarn, se quitarn o se aadirn
Pgina

11/18

nuevas sobre la marcha. Puesto que el cliente estar presente da a da durante todo el proyecto, ver el efecto y el esfuerzo necesario para las modificaciones pedidas y sabr evaluar si merecen o no la pena. Para las primeras historias que se van a implementar, se define una prueba para ver si la versin cumple perfectamente con la historia. Estas pruebas deben ser automticas, de forma que haya un programa de pruebas que ejecutemos y nos diga si la mini-versin es o no correcta. Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin para recibir retroalimentacin por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Esta prctica es la base principal de las dems. Primero deben disearse y codificarse los casos de prueba que cada clase debe superar al ser codificada. Primero creo las pruebas de unidad. Los tests son parte integral del diseo y del desarrollo. Al desarrollar un sistema, primero se escriben los tests y despus el cdigo. Cuando se escriben los tests, se prueba lo que se espera que haga el sistema y no lo que el programador cree que debe hacer el sistema. Al escribir primero las pruebas, nos concentramos en entregar lo absolutamente necesario y no ms. Como beneficio adicional de este tipo de desarrollo, se tiene un conjunto de pruebas con las que se puede verificar en cualquier momento que el sistema hace lo que tiene que hacer y que al introducir algn cambio no hemos roto ninguna funcionalidad. Es un desarrollo guiado por pruebas que nos ayuda a cumplir de manera natural con los Valores de la XP, como simplicidad y retroalimentacin y se complementa con Las Practicas. Los programadores se ponen por parejas (dos personas en el mismo ordenador) para codificar esas historias. Primero codifican el programa de pruebas y ven que falla (El cdigo todava no est hecho). Luego piensan cmo van a implementar la historia y hacen sus propios programas de prueba (tambin automticos). Codifican sus programas de prueba y ven que tambin fallan. Luego se ponen a codificar hasta que se pasen con xito todas las pruebas. En su cdigo hacen de la forma ms sencilla posible lo mnimo imprescindible para que se pasen las pruebas automticas. Las parejas de programadores se intercambian con frecuencia, de forma que todos acaban trabajando con todos. El trabajo por parejas haciendo intercambios tiene las siguientes ventajas: Al trabajar de dos en dos, el cdigo ser de mayor calidad desde el mismo momento de crearlo y tendr menos fallos. Los programadores novatos aprendern de los expertos al emparejarse con ellos. Si una pareja realiza un trozo de cdigo susceptible de ser reutilizado en el proyecto, hay dos programadores que lo saben y que lo reutilizarn cuando puedan (ya que saben cmo funciona), ensendolo a sus nuevos compaeros. De esta manera el conocimiento del cdigo ya hecho se propaga de forma natural entre todos los programadores del equipo. El estilo de programacin tiende a unificarse.

Cuando una nueva pareja va a realizar un nuevo cdigo para una historia de usuario, puede que uno de ellos recuerde haber hecho un trozo de cdigo en otro lado que podra reutilizar. Esta pareja ir a ese trozo de cdigo y lo reutilizar, modificndolo si es necesario. Despus de modificarlo, deben asegurarse
Pgina

12/18

que se siguen pasando las pruebas automticas que se hicieron en su momento, as como aadir nuevas pruebas para comprobar las modificaciones que han hecho. Si una pareja al reutilizar cdigo ya hecho ve que es mejorable, lo mejoran, pasando las pruebas automticas despus. Si al reutilizar el cdigo ya hecho descubren un error que las pruebas automticas no detectan, aaden pruebas capaces de detectar el error y lo corrigen. El cdigo, por tanto, no es de nadie. Cualquier pareja puede tocar el cdigo ya hecho por otras personas si lo necesita, con la condicin de que despus de tocarlo las pruebas automticas sigan pasndose correctamente y que aadan sus propias pruebas automticas para las correcciones realizadas. Todos los das se hace una pequea reunin a primera hora de la maana con todo el equipo en la que se comentan problemas, cdigo que se est realizando, historias de usuario terminadas, etc. Cada vez que se consigue codificar y que funcione una historia de usuario, se le da al cliente para que la vea, la pruebe y aada las posibles modificaciones para las siguientes mini-versiones. Cuando se realiza un mini-versin completa (compuesta por varias de las historias de usuario), incluso se entrega al usuario final para que empiece a trabajar con ella y reportar incidencias o mejoras. Este ciclo se va repitiendo una y otra vez hasta que el cliente se de por satisfecho y cierre el proyecto. Cmo se ve, no se ha hecho documentacin. Incluso la planificacin inicial debe hacerse escribiendo cada historia de usuario en un tarjeta, haciendo dos montones, las que ya estn hechas y las que no. Se pueden tirar las tarjetas, aadir nuevas o cambiar las que ya hay. El nmero de tarjetas en cada montn nos da una idea exacta de cunto hay hecho del proyecto. Cundo usar XP Una de las limitaciones ms grandes de estas nuevas metodologas es cmo manejan equipos ms grandes. Como muchas nuevas tendencias, ellos tienden a ser usados primero a escala pequea antes que a gran escala. Tambin a menudo se han creado con nfasis en equipos pequeos. En definitiva, los mtodos ligeros (y XP es uno de ellos) son adaptativos ms que predictivos . La XP explcitamente dice que est diseada para equipos de no ms de veinte personas. Hay que recordar que muchos equipos de software pueden reducirse en tamao sin reducir su productividad total. Si se va a aplicar XP, se necesita confiar en los desarrolladores e involucrarlos en la decisin. Los procesos adaptables cuentan en se confa en los desarrolladores, de modo que si se considera a los desarrolladores de baja calidad y motivacin, se debe usar un acercamiento predictivo.

Para resumir. Los siguientes factores sugieren un proceso XP Requisitos inciertos o voltiles Desarrolladores responsables y motivados Clientes que entienden y se involucrarn.

Estos factores sugieren un proceso predictivo Un equipo de ms de cien Un precio fijo, o ms correctamente un alcance o contrato fijo

Ventajas y desventajas de Programacin Extrema

Pgina

13/18

Ventajas: Programacin organizada. La calidad de los sistemas basados en XP tiende a ser un poco mejor, en particular si se utilizan patrones de diseo. Menor tasa de errores. El desarrollo de software con XP es ms flexible, y como el sistema comienza a crecer orgnicamente, es ms sencillo remover funciones para cumplir con el tiempo de desarrollo sin poner en riesgo el resto del sistema. Gracias al refactoring es ms fcil el modificar los requerimientos del usuario. Debido a la filosofa del pair programming (programacin en parejas), se consigue que los desarrolladores apliquen las buenas prcticas que se les ofrecen con la XP. Debido a que se concibe que la propiedad del cdigo es colectiva, cualquiera puede desarrollar, mejorar, simplificar, cualquier necesidad del proyecto, usando siempre sistemas tipo CVS para evitar la duplicacin de trabajo usando el refactoring si se trata de una modificacin. Satisfaccin del programador. Desventajas: Es recomendable emplearlo solo en proyectos a corto plazo. Altos costos en caso de fallar. Es difcil predecir costo y tiempo de desarrollo. Si se utilizan diagramas UML, stos tienden a estar poco actualizados, debido a la constante refactorizacin.

Aplicacin del Estndar ISO 9001:2000 a la Metodologa de Programacin Extrema Se deben adoptar algunas prcticas de XP a las necesidades de realizacin de producto en base a la ISO 9001:2000 en base a los siguientes enfoques: 1) Administracin de Recursos La metodologa XP plantea la practica Pair Programming, pero esta practica en realidad presenta algunos inconvenientes, ya que XP no propone criterios o guas de cmo se deben asignar las parejas de los programadores. Adems de que cada participante al poseer un nivel diferente de conocimiento y experiencia puede generar cierto grado de descoordinacin en el avance del proyecto. El estndar ISO 9001:2000 especifica en la clusula 6.2 que: El personal que participe en el desarrollo del producto deber ser competente, contar con una educacin base apropiada, entrenndose, desarrollando habilidades y experiencia El enfoque de XP-ISO al respecto es que antes de comenzar con el proyecto se comience con un entrenamiento en el equipo desarrollador con la finalidad de igualar el nivel de desarrollo de los diferentes participantes. Adems de analizar las habilidades de cada miembro del equipo para la asignacin de responsabilidades en el proyecto. 2) Realizacin del Producto El modo de operacin que XP propone para el desarrollo de software es bastante flexible por lo que puede generar ciertas informalidades en el proyecto de desarrollo como la problemtica referente a los requisitos, en la cual en el contexto de XP se reduce a la especificacin y seguimiento de los historiales de usuario. El planteamiento que propone al respecto dicha metodologa es muy sencillo, pero debido a la gran cantidad de historiales de usuario que puede tener un proyecto y a la volatilidad de los requisitos es que su gestin puede llegar a ser complicada. Con la finalidad de cubrir este punto dbil de XP, el estndar ISO 9001:2000 plantea la siguiente clusula 4.2.4 la cual menciona que: Los registros debern

Pgina

14/18

ser establecidos y mantenidos para proveer evidencia de la conformidad de los requisitos y la efectividad del SGC. Los registros debern ser legibles, fcilmente identificables y recuperables. Se establecer un procedimiento documentado para la identificacin, almacenamiento, proteccin, recuperacin, tiempo de retencin y disposicin de registros [ISO 9001:2000]. Es por tal motivo que XP-ISO plantea el uso de ciertos documentos con el propsito de tener un mejor control de requisitos y realizar un ptimo seguimiento de los mismos, los cuales seran: - Historiales de Usuario: Documentos en los cuales se establecen los requisitos que el cliente solicite, adems se describe la funcionalidad del sistema con el propsito de tener una mejor perspectiva del proyecto que se requiere. - Seguimiento de Actividades: Se aconseja dividir el proyecto en mdulos para lograr un optimo desarrollo, cada modulo esta conformado por actividades. En este documento se identifica las actividades de cada modulo, establecindose un tiempo para su desarrollo y asignando un factor de riesgo para cada actividad en caso que exista; adems se designan a las personas responsables de dicha actividad - Cambio de Requisitos: En el caso que existiese alguna inconformidad se utiliza este documento para registrar la modificacin del requisito incumplido, se propone la nueva alternativa, se analiza el impacto de este cambio y se establece un tiempo estimado el cual debe ser breve para no obstaculizar el tiempo de desarrollo del proyecto. Entre una de las secciones relevantes en la metodologa XP se encuentra de que el cliente debe de estar integrado con el proyecto, de tal manera que las preguntas que surjan del mismo puedan ser resueltas de la mejor manera, sta caracterstica puede ser integrada a la metodologa propuesta de XP-ISO ya que el estndar ISO 9001:2000 establece para la definicin de requisitos relacionados con el cliente la siguiente clusula 7.2.1 tem b) El desarrollo de los requisitos se llevara a cabo con la cooperacin del cliente o usuarios, y se realizara con gran nfasis para evitar malentendidos. Por ejemplo, la definicin de condiciones se puede realizar considerando los antecedentes de los requisitos. [ISO 9001:2000]. En lo concerniente a la participacin del cliente en el proyecto de desarrollo establece la siguiente la clusula 7.2.2.3: El cliente tiene la responsabilidad en el contrato. "Los asuntos particulares pueden incluir la necesidad que el cliente coopere con la organizacin, proveer informacin necesaria de una manera oportuna, y resolver detalles de accin [ISO 9001:2000]. Esta ltima clusula no es para nada incompatible con el requisito que propone XP en la cual puede llegar al punto en el cual el cliente, aparte de escribir los casos de uso y pruebas funcionales, pueda incluso ser asignado a la parte de pruebas del modelo a ser desarrollado. Es por esta razn que nuestra metodologa plantea se establezca un cronograma para la realizacin de las conversaciones con el cliente, respetando su tiempo disponible para la elaboracin del proyecto y reconociendo el papel importante que juega el cliente en el desarrollo del proyecto en los campos de: especificacin de requisitos, cambios en la funcionalidad del sistema, determinacin de alcance y otros. 3) Mejoramiento contino Tanto la metodologa XP como el estndar ISO 9001:2000 buscan lograr desarrollar un software de alta calidad mejorando los procesos de desarrollo, pero surge un punto dbil en XP ya que este solo corrige errores que ocurren en el proceso de desarrollo mas no involucra ninguna actividad de accin correctiva como lo establece el estndar ISO 9001:2000 en su clusula 8.5.3: La organizacin deber determinar las acciones para eliminar las causas de inconformidades potenciales e impedir su incidencia. Las acciones preventivas sern apropiadas para los efectos de los problemas potenciales. La metodologa XP tambin puede quedar entrampada en una bsqueda por la simplicidad de un modelo, la cual quizs no pueda llegar a darse por una falta de comunicacin entre los desarrolladores y los clientes, este efecto sera minimizado en el caso de establecer la clusula 8.5.3 anteriormente mencionada [ISO 9001:2000]. Por tal motivo la extensin XP-ISO propone un control ms detallado estableciendo el uso de un proceso documentado llamado Verificacin de cdigo el cual tiene como propsito la revisin del cdigo avanzado, estableciendo se registren los posibles errores junto con su posible solucin, la cual debe ser evaluada por el resto del equipo desarrollador para ser aprobada.

Pgina

15/18

Conclusin
La Programacin Extrema es ideal en aquellos proyectos en donde se requiere un desarrollo a corto plazo, en donde los requerimientos pueden ser cambiados en cualquier instante, de hecho, su principal objetivo es reducir los costos generados por los cambios en los requerimientos. Se propone como un paradigma en donde se proveen numerosas ventajas en la reutilizacin del cdigo.. Las prcticas principales en la Programacin Extrema son aquellas que generalmente son aceptadas como buenas, pero en este paradigma se llevan al extremo. Por otro lado, ninguna de las prcticas establecidas por XP son una invencin del mtodo; todas ellas ya existan, y lo que XP ha hecho ha sido ponerlas todas juntas y comprobar que funcionaban. Las metodologas giles son sin duda uno de los temas recientes en ingeniera de software que estn acaparando gran inters. Prueba de ello es que se estn haciendo un espacio destacado en la mayora de conferencias y Workshops celebrados en los ltimos aos. En la comunidad de la ingeniera del software, se est viviendo con intensidad un debate abierto entre los partidarios de las metodologas tradicionales (referidas peyorativamente como "metodologas pesadas") y aquellos que apoyan las ideas emanadas del "Manifiesto gil".

Anexo I
El Manifiesto gil Cuando en 2001 se crearon las bases de las metodologas gil, se creo un manifiesto con los puntos que diferencian una metodologa gil del proceso tradicional. La metodologa gil se basa en los siguientes valores: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es .no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin importante.. Estos documentos deben ser cortos y centrarse en lo fundamental. -La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta. El manifiesto consta de los siguientes doce puntos: I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas software que le aporte un valor.

Pgina

16/18

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga ventaja competitiva. III. Entregar frecuentemente software que funcione desde un par de semanas a un par meses, con el menor intervalo de tiempo posible entre entregas. IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. VII. El software que funciona es la medida principal de progreso. VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. X. La simplicidad es esencial. XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por mismos. XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, segn esto ajusta su comportamiento.

Referencias bibliogrficas:
- www.extremeprogramming.org - Extreme Programming Explained, Kent Beck - Addison-Wesley - 2000 Chapter 4 - Four Variables: (l.c.: Las Cuatro Variables, pag 5,6) Chapter 5 - Cost of Change: (l.c.: El Costo del Cambio, pag 6,7)

- Una explicacin de la Programacin Extrema (XP) Manuel Calero Sols. V Encuentro usuarios xBase 2003 Madrid l.c.: (Objetivos de la Programacin Extrema, pag. 5) - The New Methodology, Martin Fowler, de 2003. l.c.: (Introduccin, pag. 3) (Los Cuatro Valores, pag. 7) (Cundo usar XP, pag 13) Aplicacin del Estndar ISO 9001:2000 a la Metodologa de Programacin Extrema (XP) , Juan Manuel Gutirrez Crdenas,Universidad Catlica San Pablo l.c.:(pag. 15) - Agile software development methods Review and analysis, Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. VTT Publications. 2002. Roles and Responsabilites l.c.: (Roles XP, pag 8)

Pgina

17/18

- Mtodologas giles para el desarrollo de software: eXtreme Programming (XP), Letelier y Penads - Universidad Politcnica de Valencia. 2002 l.c.: (Comentarios respecto de las Prcticas, pag. 11) (Anexo 1 El Manifiesto gil, pag. 17) - eXtreme Programming (XP): un nuevo mtodo de desarrollo de software Csar F. Acebal, Juan M. Cueva Lovelle Universidad de Oviedo, 2002 l.c.:(Practicas bsicas de la Programacin Extrema, pag. 9,10) - www.chuidiang.com/ood/metodologia/extrema.html l.c.: (Algunas bases de la Programacin Extrema, pag. 5) (Metforas, pag 11) (Los pasos a seguir en un proyecto, pag 12,13)

Pgina

18/18