19 de junio de 2011

Índice Objetivo ……………………………………………………………………..12 Cuándo usar XP ……………………………………………………………………………………….…....15 Conclusión …………………………………………………………………………………………………16 Anexo I ..……………………………….………………………………. 7 Roles XP …………………………………………………………………………………………………….. 5 El costo del cambio ………………………………………………………………………………………..4 Objetivos de la Programación Extrema …………………………………...………………………….………………………….3 Introducción ………………………………………………………………..………………………….……………………………. 6 Los Cuatro Valores ……………………………………………………………………………………….11 Los pasos a seguir en un proyecto ………………………………………….El Manifiesto Ágil ………………………………………………………………………………17 Referencias bibliográficas……………………………………………….5 Algunas bases de la Programación Extrema ……………………………... 5 Las cuatro Variables …………………………………………………………. 13 Ventajas y desventajas de la Programación Extrema…………………………………………………14 Aplicación del Estándar ISO 9001:2000 a la Metodología de Programación Extrema……………. 9 Comentarios respecto de las prácticas ………………………………..…………………………...8 Prácticas básicas de la Programación Extrema ……………………………………………………….……..18 Página 2/18 .…………………………….

Introducción La Programación Extrema ( del inglés Extreme Programming ) es uno de los llamados procesos o Página 3/18 . . diseños simples.Introducción al estudio de la Programación Extrema (XP.Conocer las principales prácticas de la Programación Extrema: programación basada en tests. etc. .Objetivo . eXtreme Programming) y su aplicación.

Página 4/18 . la popularidad de XP se ha vuelto un problema. incluso cuando los cambios sean al final de ciclo de la programación. De alguna maneras.metodologías ágiles de desarrollo de software. debemos responder muy rápido a las necesidades del cliente. Kent recomendó tirar la base del código en su totalidad y empezar desde el principio. Kent Beck fue el pionero de patrones software. (Lo cual prueba. que la XP no es garantía de éxito. Consiste en un conjunto de Prácticas que a lo largo de los años han demostrado ser las mejores prácticas de desarrollo de software. y en particular la colaboración cercana de Kent Beck y Ward Cunningham a finales de 1980. El proyecto continuó desde entonces y después se encontró con dificultades. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. y estaba en problemas. De todas las metodologías ágiles. sin embargo. 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. es la que ha recibido más atención. A Kent se le pidió revisar el progreso del proyecto de nómina C3 para Chrysler. El proyecto entonces reinició bajo su dirección y subsecuentemente se volvió el buque insignia temprano y el campo de entrenamiento de la XP. llevadas al extremo. para llamar la atención. Esto se debe en parte a la notable habilidad de los líderes XP. en particular Kent Beck. y tomar un papel principal en él. del framework de testing xUnit. Por tanto. pues ha acaparado la atención fuera de las otras metodologías y sus valiosas ideas. Objetivos de la Programación Extrema Los objetivos de XP son muy simples: la satisfacción del cliente. Las raíces de la XP yacen en la comunidad de Smalltalk. si ninguna otra cosa. fundamentadas en un conjunto de Valores. extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente. Kent Beck escribió Extreme Programming Explained. Debido a la baja calidad de la base del código. muchos de ellos provenientes del proyecto fundamental C3. lo que resultó en la cancelación del desarrollo en 1999. El paso crucial de la práctica informal a una metodología ocurrió en la primavera de 1996. El proyecto estaba siendo llevado en Smalltalk por una compañía contratista. La primera fase del C3 fue muy exitosa y comenzó a principios de 1997.) XP ha desarrollado un liderazgo amplio. creador de las fichas CRC. autor del framework para editores de dibujo HotDraw. Ambos refinaron sus prácticas en numerosos proyectos a principios de 1990. También se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento.

en cambio. también se modifica continuamente de mini-versión en mini-versión. no hay mejor documentación que el mismo código. no hay que hacer una documentación para el diseño. mientras la calidad del proyecto se mantiene asegurada –por las pruebas– al 100%. Además. poco a poco comenzará a avanzar mucho más rápido de lo que lo hacía antes. La tecnología cambia. El problema no es el cambio en sí mismo. empezar a codificar fuera del diseño y al final el código y el diseño. Con la calidad también sucede otro fenómeno extraño: frecuentemente. tiempo. Todo en el software cambia. está la tentación de sacrificar la calidad interna del proyecto –la que es apreciada por los programadores – para reducir el tiempo de entrega del proyecto. o no se parecen. naturalmente. Los requisitos cambian. Frente a esto. pero no antes. ver que hay faltantes o errores en el diseño. Las cuatro Variables XP define cuatro variables para cualquier proyecto software: costo. incrementar el costo del proyecto en aspectos como máquinas más rápidas. especifica que. El negocio cambia. El código. En vez de tratar de luchar contra todo eso. en la confianza de que la calidad Página 5/18 . mientras que el valor de la variable libre será establecido por el equipo de desarrollo en función de los valores de las otras tres. o hemos echado un montón de tiempo en cambiar la documentación de diseño para que se parezca al código. Algunas bases de la Programación Extrema En la programación extrema se da por supuesto que es imposible prever todo antes de empezar a codificar. los clientes y desarrolladores. saber qué es todo lo que tiene que hacer. lo asume y busca una forma de trabajar que se adapte fácilmente a esas circunstancias. Es bueno. son parte del equipo y están involucrados en el desarrollo del software. sin estrés. XP hace a las cuatro variables visibles para todo el mundo –programadores. XP hace especial énfasis en equipos de desarrollo pequeños (diez o doce personas como mucho) que. por tanto. lo que conlleva mayor confianza en el código y. 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. El diseño se hace sobre la marcha. En efecto. en cuanto el equipo de desarrollo se habitúe a realizar pruebas intensivas y se sigan estándares de codificación. haciendo un mini-diseño para la primera mini-versión y luego modificándolo en las siguientes mini-versiones. de estas cuatro variables. Es imposible capturar todos los requisitos del sistema. añadiéndole funcionalidad y extrayendo sus partes comunes. Básicamente la idea de la programación extrema consiste en trabajar estrechamente con el cliente. El equipo cambia. por tanto. ponerse a codificar. por supuesto). Además. Es bastante normal hacer un diseño. aumentar la calidad conduce a que el proyecto pueda realizarse en menos tiempo. haciéndole mini-versiones con mucha frecuencia (cada dos semanas). calidad y alcance. el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar. sólo tres de ellas podrán ser fijadas por las fuerzas externas al proyecto (clientes y jefes de proyecto). o los resultados serán generalmente contrarios a lo esperado. puesto que sabemos que el cambio va a suceder. Ocurre además que las cuatro variables no guardan entre sí una relación tan obvia como a menudo se quiere ver. Tanto los jefes de proyecto. mayor facilidad para adaptarse al cambio. más especialistas técnicos en determinadas áreas o mejores oficinas para el equipo de desarrollo.El segundo objetivo es potenciar al máximo el trabajo en grupo. Los miembros del equipo cambian. lo que hace que se programe más rápido y así sucesivamente. El diseño cambia. En cada mini-versión se debe hacer el mínimo de código y lo más simple posible para que funcione correctamente. ni hacer un diseño correcto al principio. se podrán ir incrementando a medida que sea necesario.

de manera que el proyecto tenga en cada instante tanta funcionalidad como sea posible.no se vea demasiado afectada. de manera que. a la ralentización del proyecto mucho más allá del tiempo que hubiera podido ganarse al principio con esta reducción de calidad. una vez fijadas las otras tres. en la ingeniería 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 combinación de buenas prácticas de programación y tecnología es posible lograr que la curva sea la contraria: Página 6/18 .externa –la que notan los clientes –. ésta es una apuesta a muy corto plazo. pues obvia el hecho fundamental de que todo el mundo trabaja mucho mejor cuando le dejan hacer trabajo de calidad. con ello. • La implementación de los requisitos más importantes primero. En cuanto al alcance del proyecto. No tener esto en cuenta conduce a la desmoralización del equipo y. a la larga. En efecto. es una buena idea dejar que sea esta la variable libre. que suele ser una invitación al desastre. Sin embargo. El costo del cambio Una de las asunciones más importantes e innovadoras que hace XP frente a la mayoría de los métodos conocidos es la referida al coste del cambio. el equipo de desarrollo determinaría el alcance mediante: • La estimación de las tareas a realizar para satisfacer los requisitos del cliente.

combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la más desarrollada entre todas las metodologías adaptables. aunque a menudo olvidadas por muchos. lo que es más. Construye sobre ellos una docena de prácticas que los proyectos XP deben seguir. Una de las más llamativas. Mientras todos los procesos mencionan la comprobación.Al emplear XP como proceso de desarrollo de software. los tests y la integración continua. la XP las teje en un todo sinérgico dónde cada una refuerza a las demás. deberemos adoptarlo basándonos en esta curva. Sin embargo la XP pone la comprobación como el fundamento del desarrollo. Simplicidad y Coraje. Las pruebas se integran en el proceso de integración continua y construcción lo que rinde una plataforma altamente estable para el desarrollo futuro. incluyendo la mayoría de los procesos planeados. junto con nuestros conocimientos de factorización y. Retroalimentación. Los Cuatro Valores La XP empieza con cuatro valores: Comunicación. tratadas y probadas. hacen posible que los cambios puedan ser llevados a cabo tan seguido como sea necesario. Roles XP Aunque en otras fuentes de información aparecen algunas variaciones y extensiones de roles XP. la mayoría lo hace con muy poco énfasis. Programador Página 7/18 . El resultado es un proceso de diseño disciplinado. En esta plataforma XP construye un proceso de diseño evolutivo que se basa en refactorar un sistema simple en cada iteración. en vez de diseñar para el cambio. La idea fundamental aquí es que. es su fuerte énfasis en las pruebas. sobre todo. Además de resucitar estas técnicas. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. con cada programador escribiendo pruebas cuando escriben su código de producción. Muchas de estas prácticas son técnicas antiguas. en este apartado describiremos los roles de acuerdo con la propuesta original de Beck. pues la propia simplicidad del código. para hacer sólo lo que sea imprescindible en un momento dado. diseñaremos tan sencillo como sea posible.

Cliente El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo.El programador escribe las pruebas unitarias y produce el código del sistema. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración. Además. Gestor (Big boss) Es el vínculo entre clientes y programadores. Es necesario que conozca a fondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. Encargado de pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. comunicando los resultados para mejorar futuras estimaciones. Encargado de seguimiento (Tracker) El encargado de seguimiento proporciona realimentación al equipo en el proceso XP. sino que han sido reconocidas por la industria como las mejores prácticas durante años. Ejecuta las pruebas regularmente. Guía al equipo para resolver un problema específico. Su labor esencial es de coordinación. El cliente es sólo uno dentro del proyecto pero puede corresponder a un interlocutor que está representando a varias personas que se verán afectadas por el sistema. centrándose en aportar mayor valor al negocio. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado. Consultor Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración. difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Prácticas básicas de la Programación Extrema La mayoría de estas prácticas no son nuevas. dichas prácticas son llevadas al extremo para que se obtenga algo mucho mejor que la suma de las partes: Planificación Página 8/18 . Entrenador (Coach) Es responsable del proceso global. También realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. En la XP.

etc. En cuanto a los técnicos. menos reacios a modificarlo cuando haya que añadir o cambiar alguna característica. del equipo de desarrollo. La teoría del caos tiene mucho que ver con esta idea subyacente de XP. Y. de la organización. unos pocos meses. lo que XP preconiza es diseñar en cada momento para las necesidades presentes. no trata de buscar un determinismo inexistente y sí de poner los medios necesarios para manejar esa complejidad. antes de estar completamente terminado. Pero aquí no hay discusión posible: si no hacemos tests. en la que los primeros decidirán el alcance –¿qué es lo realmente necesario del proyecto?–. sino que sobre todo es un método de gestión de proyectos software. deberemos emplear algún framework de testing automático. y esto se reflejará en sucesivas versiones. consiste en dejar el código existente en el estado más simple posible. de organizar la cultura de trabajo y. Pruebas El pilar básico sobre el que se sustenta XP es “Cualquier característica de un programa para la que no haya un test automatizado. El cliente y el equipo de desarrollo se beneficiarán de la retroalimentación que produce un sistema funcionando. Versiones pequeñas El sistema se pone por primera vez en producción en. Esto ayuda al principio de programación por intención. a escribir el código como si los métodos más costosos ya hubieran sido escritos y sólo tuviéramos así que enviar el correspondiente mensaje. En el caso de sistemas heredados. de manera que no pierda –ni gane– funcionalidad y que se sigan ejecutando correctamente todos los tests. finalmente. la prioridad –qué debe ser hecho en primer lugar–. Esto nos hará sentirnos más cómodos con el código ya escrito y. no tiene lógica duplicada. esto es. XP plantea la planificación como un permanente diálogo entre la parte empresarial y técnica del proyecto. muy escuetamente. Refactorización Responde al principio de simplicidad. como acaso cualquier cosa en esta vida. Programación en parejas Página 9/18 . de informar sobre las consecuencias de determinadas decisiones. sin tratar de doblegarla con los métodos pesados o burocráticos.org] o cualquiera de sus versiones para diferentes lenguajes. por tanto. aceptándola. no estaremos haciendo XP. Una parte fundamental de XP es precisamente la planificación. Las sucesivas versiones serán más frecuentes –entre un día y un mes. como JUnit [www. El diseño adecuado para el software es aquel que: supera con éxito todas las pruebas. sino que escribiremos los tests antes incluso que la propia clase a probar. Lo que ocurre es que. es un proceso caótico. de realizar la planificación detallada dentro de cada versión. la composición de las versiones –qué debería incluir cada una de ellas– y la fecha de las mismas. refleja claramente la intención de implementación de los programadores y tiene el menor número posible de clases y métodos. o de proyectos que se tomen ya empezados. sin añadirle ninguna nueva funcionalidad. que funciona. de manera que el código refleje bien su intención y se documente a sí mismo. los métodos ligeros –y XP es uno de ellos– son adaptativos más que predictivos . cuando se le diga que se va a parar éste varios días sólo para modificar el código existente. En definitiva. Para ello. seguramente habrá que dedicar varias semanas sólo a factorizar el código –lo cual suele ser fuente de tensiones con el correspondiente jefe de proyecto. En el sitio web de JUnit mencionado en el párrafo anterior se pueden encontrar interesantes artículos que explican cómo deben escribirse estos tests. Otros principios son susceptibles de ser adaptados a las características del proyecto. simplemente no existe”. a lo sumo. No sólo eso. Diseño sencillo En vez de perseguir a toda costa un diseño en el que hemos de desarrollar dotes adivinatorias para tratar de anticiparnos al futuro. aceptando que el desarrollo de software. son los responsables de estimar la duración requerida para implementar las funcionalidades deseadas por el cliente.junit.XP no es sólo un método centrado en el código –que lo es–.

En efecto. Si al añadir la nueva clase junto con sus tests unitarios. deberá hacerlo sin más dilación. tirarán el código a la basura y volverán a comenzar de nuevo. de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. mientras que su compañero lo hará de una manera más estratégica: • ¿Estamos siguiendo el enfoque apropiado? • ¿Qué es lo que podría fallar aquí? ¿Qué deberíamos comprobar en los tests ? • ¿Hay alguna manera de simplificar el sistema? Por supuesto. a la que se acercará una pareja de programadores cada vez que tengan una clase que haya sido probada unitariamente. pero lo que es seguro es que nadie es capaz de trabajar 60 horas a la semana y hacerlo con calidad. ya sabemos que es trivial– querremos que cada miembro de nuestro equipo se levante cada mañana descansado y se vaya a las 6 de la tarde a su casa cansado y con la satisfacción del trabajo bien hecho. de integración. el sistema completo sigue funcionando correctamente –pasa todos los tests–. hayan sido o no escritos por él. y que no importa que esté construido a partir de suposiciones hechas por programadores que nada. para turnar a su compañero. Si después de un cierto tiempo no son capaces de descubrir qué es lo que falla. cualquiera que vea una posibilidad de simplificar. los programadores darán por finalizada esa tarea. Un ejemplo claro es el "recolector de basura" de java. para responder cualquier consulta que los programadores le planteen. serán los responsables de dejar el sistema de nuevo con los tests funcionando al 100%. Propiedad colectiva del código Cualquiera puede modificar cualquier porción del código. Si no. los roles son intercambiables. mediante refactoring. para establecer prioridades. o muy poco.Todo el código será desarrollado en parejas –dos personas compartiendo un solo monitor y teclado. y no meramente un sistema que funcione –lo cual. Cliente in situ Otra controvertida regla de XP: al menos un cliente real debe estar permanentemente junto al equipo de desarrollo. como mucho– se integra el sistema completo Para ello existirá un máquina así llamada. Quien codifica estará pensando en el mejor modo de implementar un determinado método. de manera que en cualquier momento quien observaba puede tomar el teclado para ejemplificar alguna idea o. 40 horas semanales Si realmente queremos ofrecer calidad. Estándares de codificación Es decisiva para poder plantear con éxito la propiedad colectiva del código. El uso de estándares de codificación y la confianza que nos dan los tests de que todo va a seguir funcionando bien tras una modificación. Naturalmente. hacen que esto no sea ningún problema en XP. Metáforas Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa. simplemente. saben del negocio real. y que al llegar el viernes sepa que cuenta con dos días para descansar y dedicarse a cosas que nada tengan que ver con el trabajo. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos. La mayoría de las prácticas propuestas por XP no son novedosas sino que en Página 10/18 . Ésta sería impensable sin una codificación basada en estándares que haga que todo el mundo se sienta cómodo con el código escrito por cualquier otro miembro del equipo. Igualmente. Integración continua Cada pocas horas –o al cabo de un día de programación. cualquier clase o cualquier método. en informática. en cualquier momento. la composición de las parejas cambiará siempre que uno de los dos sea requerido por algún otro miembro del equipo para que le ayude con su código. las 40 horas no es una regla fija –pueden ir de 35 a 45–. Comentarios respecto de las prácticas El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada puesto que se apoyan unas en otras. deberemos entender que realmente el proyecto que nos ha encomendado es lo suficientemente trivial como para que no merezca su atención. Si el cliente arguye que su tiempo es demasiado valioso.

se quitarán o se añadirán Página 11/18 . que debe ser corto. La planificación deberá revisarse y modificarse continuamente a lo largo del proyecto. Para ello utilizan las "historias de usuario". El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio. hay que partir la historia en otras más pequeñas. inexacta. de aproximadamente una semana. Las historias de usuario se modificarán. No se puede saber todo lo que va a ser necesario ni evaluar los tiempos correctamente. Si es más largo. Toda esta planificación va a ser. los valores humanos y el trabajo en equipo. pero la estimación es menos fiable si es de un plazo superior a una semana. Es más extensa que un requisito (que suele ser una frase corta) y menos que un caso de uso (que puede ser de una o dos páginas). Se evalúa para cada historia de usuario el tiempo que puede llevar.alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica . Un programador puede estimar con cierta fiabilidad un trabajo que le lleve unos días. de forma que cada mini-versión implementa varias de las historias de usuario. por supuesto. Las Prácticas se refuerzan entre sí: Una línea entre dos prácticas significa que las dos prácticas se refuerzan entre sí. Los pasos a seguir en un proyecto En un proyecto usando programación extrema se siguen más o menos los siguientes pasos: El cliente junto al equipo de desarrollo definen qué es lo que se quiere hacer. Luego se ordenan en el orden en que se van a desarrollar y se establecen las mini-versiones. Una historia de usuario en un texto de una o dos frases en las que se dice algo que debe hacer el sistema.

Primero deben diseñarse y codificarse los casos de prueba que cada clase debe superar al ser codificada. el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. De esta manera el conocimiento del código ya hecho se propaga de forma natural entre todos los programadores del equipo. hay dos programadores que lo saben y que lo reutilizarán cuando puedan (ya que saben cómo funciona). • El estilo de programación tiende a unificarse. cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo. de forma que haya un programa de pruebas que ejecutemos y nos diga si la mini-versión es o no correcta. Luego se ponen a codificar hasta que se pasen con éxito todas las pruebas. Esta práctica es la base principal de las demás. Al escribir primero las pruebas. puede que uno de ellos recuerde haber hecho un trozo de código en otro lado que podría reutilizar. Estas pruebas deben ser automáticas. primero se escriben los tests y después el código. Puesto que el cliente estará presente día a día durante todo el proyecto. Cuando se escriben los tests. En su código hacen de la forma más sencilla posible lo mínimo imprescindible para que se pasen las pruebas automáticas. Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberación. Cuando una nueva pareja va a realizar un nuevo código para una historia de usuario. Los tests son parte integral del diseño y del desarrollo. se define una prueba para ver si la versión cumple perfectamente con la historia. el código será de mayor calidad desde el mismo momento de crearlo y tendrá menos fallos. • Si una pareja realiza un trozo de código susceptible de ser reutilizado en el proyecto. Codifican sus programas de prueba y ven que también fallan. Es un desarrollo guiado por pruebas que nos ayuda a cumplir de manera natural con los Valores de la XP. verá el efecto y el esfuerzo necesario para las modificaciones pedidas y sabrá evaluar si merecen o no la pena.nuevas sobre la marcha. nos concentramos en entregar lo absolutamente necesario y no más. • Los programadores novatos aprenderán de los expertos al emparejarse con ellos. Luego piensan cómo van a implementar la historia y hacen sus propios programas de prueba (también automáticos). Primero codifican el programa de pruebas y ven que falla (El código todavía no está hecho). Por regla general. Para las primeras historias que se van a implementar. deben asegurarse Página 12/18 . enseñándolo a sus nuevos compañeros. Las parejas de programadores se intercambian con frecuencia. El trabajo por parejas haciendo intercambios tiene las siguientes ventajas: • Al trabajar de dos en dos. Los programadores se ponen por parejas (dos personas en el mismo ordenador) para codificar esas historias. como simplicidad y retroalimentación y se complementa con Las Practicas. 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 algún cambio no hemos roto ninguna funcionalidad. Como beneficio adicional de este tipo de desarrollo. Al desarrollar un sistema. se prueba lo que se espera que haga el sistema y no lo que el programador cree que debe hacer el sistema. modificándolo si es necesario. de forma que todos acaban trabajando con todos. Después de modificarlo. Primero creo las pruebas de unidad. Esta pareja irá a ese trozo de código y lo reutilizará.

Cuándo usar XP Una de las limitaciones más grandes de estas nuevas metodologías es cómo manejan equipos más grandes. También a menudo se han creado con énfasis en equipos pequeños. El código. no se ha hecho documentación. con la condición de que después de tocarlo las pruebas automáticas sigan pasándose correctamente y que añadan sus propias pruebas automáticas para las correcciones realizadas. etc. Si una pareja al reutilizar código ya hecho ve que es mejorable. lo mejoran. así como añadir nuevas pruebas para comprobar las modificaciones que han hecho. ellos tienden a ser usados primero a escala pequeña antes que a gran escala. añadir nuevas o cambiar las que ya hay. o más correctamente un alcance o contrato fijo Ventajas y desventajas de Programación Extrema Página 13/18 . de modo que si se considera a los desarrolladores de baja calidad y motivación. Como muchas nuevas tendencias. por tanto. código que se está realizando. Cada vez que se consigue codificar y que funcione una historia de usuario. Se pueden tirar las tarjetas. se debe usar un acercamiento predictivo. no es de nadie. Si al reutilizar el código ya hecho descubren un error que las pruebas automáticas no detectan. se necesita confiar en los desarrolladores e involucrarlos en la decisión. añaden pruebas capaces de detectar el error y lo corrigen. Incluso la planificación inicial debe hacerse escribiendo cada historia de usuario en un tarjeta. Los procesos adaptables cuentan en se confía en los desarrolladores. las que ya están hechas y las que no. Si se va a aplicar XP. Este ciclo se va repitiendo una y otra vez hasta que el cliente se de por satisfecho y cierre el proyecto. Para resumir. la pruebe y añada las posibles modificaciones para las siguientes mini-versiones. Estos factores sugieren un proceso predictivo • • Un equipo de más de cien Un precio fijo. se le da al cliente para que la vea. Cómo se ve. Cuando se realiza un mini-versión completa (compuesta por varias de las historias de usuario). Todos los días se hace una pequeña reunión a primera hora de la mañana con todo el equipo en la que se comentan problemas.que se siguen pasando las pruebas automáticas que se hicieron en su momento. pasando las pruebas automáticas después. los métodos ligeros (y XP es uno de ellos) son adaptativos más que predictivos . Cualquier pareja puede tocar el código ya hecho por otras personas si lo necesita. La XP explícitamente dice que está diseñada para equipos de no más de veinte personas. En definitiva. incluso se entrega al usuario final para que empiece a trabajar con ella y reportar incidencias o mejoras. Los siguientes factores sugieren un proceso XP • • • Requisitos inciertos o volátiles Desarrolladores responsables y motivados Clientes que entienden y se involucrarán. Hay que recordar que muchos equipos de software pueden reducirse en tamaño sin reducir su productividad total. haciendo dos montones. El número de tarjetas en cada montón nos da una idea exacta de cuánto hay hecho del proyecto. historias de usuario terminadas.

Altos costos en caso de fallar. Menor tasa de errores. es más sencillo remover funciones para cumplir con el tiempo de desarrollo sin poner en riesgo el resto del sistema. Además de que cada participante al poseer un nivel diferente de conocimiento y experiencia puede generar cierto grado de descoordinación en el avance del proyecto. Debido a que se concibe que la “propiedad” del código es colectiva. Debido a la filosofía del “pair programming” (programación en parejas).4 la cual menciona que: “Los registros deberán Página 14/18 . contar con una educación base apropiada. Gracias al “refactoring” es más fácil el modificar los requerimientos del usuario. usando siempre sistemas tipo CVS para evitar la duplicación de trabajo usando el “ refactoring” si se trata de una modificación. ya que XP no propone criterios o guías de cómo se deben asignar las parejas de los programadores. cualquier necesidad del proyecto.Ventajas: Programación organizada.2 que: “El personal que participe en el desarrollo del producto deberá ser competente. debido a la constante refactorización. entrenándose. cualquiera puede desarrollar. El planteamiento que propone al respecto dicha metodología es muy sencillo. El estándar ISO 9001:2000 especifica en la cláusula 6. El desarrollo de software con XP es más flexible. 2) Realización del Producto El modo de operación 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 problemática referente a los requisitos. Satisfacción del programador. el estándar ISO 9001:2000 plantea la siguiente cláusula 4. Es difícil predecir costo y tiempo de desarrollo. en particular si se utilizan patrones de diseño.2. La calidad de los sistemas basados en XP tiende a ser un poco mejor. en la cual en el contexto de XP se reduce a la especificación y seguimiento de los historiales de usuario. Desventajas: Es recomendable emplearlo solo en proyectos a corto plazo. 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. pero esta practica en realidad presenta algunos inconvenientes. Con la finalidad de cubrir este punto débil de XP. y como el sistema comienza a crecer orgánicamente. Además de analizar las habilidades de cada miembro del equipo para la asignación de responsabilidades en el proyecto. 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 gestión puede llegar a ser complicada. Si se utilizan diagramas UML. éstos tienden a estar poco actualizados. Aplicación del Estándar ISO 9001:2000 a la Metodología de Programación Extrema Se deben adoptar algunas prácticas de XP a las necesidades de realización de producto en base a la ISO 9001:2000 en base a los siguientes enfoques: 1) Administración de Recursos La metodología XP plantea la practica “Pair Programming”. simplificar. mejorar. se consigue que los desarrolladores apliquen las buenas prácticas que se les ofrecen con la XP.

En lo concerniente a la participación del cliente en el proyecto de desarrollo establece la siguiente la cláusula 7. [ISO 9001:2000].2. se propone la nueva alternativa. "Los asuntos particulares pueden incluir la necesidad que el cliente coopere con la organización. cambios en la funcionalidad del sistema. de tal manera que las preguntas que surjan del mismo puedan ser resueltas de la mejor manera. la cual debe ser evaluada por el resto del equipo desarrollador para ser aprobada. Es por esta razón que nuestra metodología plantea se establezca un cronograma para la realización de las conversaciones con el cliente.Historiales de Usuario: Documentos en los cuales se establecen los requisitos que el cliente solicite. pero surge un punto débil en XP ya que este solo corrige errores que ocurren en el proceso de desarrollo mas no involucra ninguna actividad de acción correctiva como lo establece el estándar ISO 9001:2000 en su cláusula 8. 3) Mejoramiento continúo Tanto la metodología XP como el estándar ISO 9001:2000 buscan lograr desarrollar un software de alta calidad mejorando los procesos de desarrollo. los cuales serían: . . pueda incluso ser asignado a la parte de pruebas del modelo a ser desarrollado. ésta característica puede ser integrada a la metodología propuesta de XP-ISO ya que el estándar ISO 9001:2000 establece para la definición de requisitos relacionados con el cliente la siguiente cláusula 7.1 ítem b) “El desarrollo de los requisitos se llevara a cabo con la cooperación del cliente o usuarios.2. En este documento se identifica las actividades de cada modulo.ser establecidos y mantenidos para proveer evidencia de la conformidad de los requisitos y la efectividad del SGC. además se designan a las personas responsables de dicha actividad . además se describe la funcionalidad del sistema con el propósito de tener una mejor perspectiva del proyecto que se requiere.Seguimiento de Actividades: Se aconseja dividir el proyecto en módulos para lograr un optimo desarrollo.Cambio de Requisitos: En el caso que existiese alguna inconformidad se utiliza este documento para registrar la modificación del requisito incumplido. cada modulo esta conformado por actividades. respetando su tiempo disponible para la elaboración del proyecto y reconociendo el papel importante que juega el cliente en el desarrollo del proyecto en los campos de: especificación de requisitos. Por ejemplo. Página 15/18 .3 anteriormente mencionada [ISO 9001:2000]. Por tal motivo la extensión XP-ISO propone un control más detallado estableciendo el uso de un proceso documentado llamado “Verificación de código” el cual tiene como propósito la revisión del código avanzado.” La metodología XP también puede quedar entrampada en una búsqueda por la simplicidad de un modelo.5. Las acciones preventivas serán apropiadas para los efectos de los problemas potenciales.5. Entre una de las secciones relevantes en la metodología XP se encuentra de que el cliente debe de estar integrado con el proyecto. tiempo de retención y disposición de registros” [ISO 9001:2000]. estableciéndose un tiempo para su desarrollo y asignando un factor de riesgo para cada actividad en caso que exista. Es por tal motivo que XP-ISO plantea el uso de ciertos documentos con el propósito de tener un mejor control de requisitos y realizar un óptimo seguimiento de los mismos.3: “La organización deberá determinar las acciones para eliminar las causas de inconformidades potenciales e impedir su incidencia. recuperación. y se realizara con gran énfasis para evitar malentendidos. fácilmente identificables y recuperables. la cual quizás no pueda llegar a darse por una falta de comunicación entre los desarrolladores y los clientes. almacenamiento. aparte de escribir los casos de uso y pruebas funcionales. protección. 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. Los registros deberán ser legibles.3: “El cliente tiene la responsabilidad en el contrato.2. este efecto sería minimizado en el caso de establecer la cláusula 8. y resolver detalles de acción” [ISO 9001:2000]. estableciendo se registren los posibles errores junto con su posible solución. la definición de condiciones se puede realizar considerando los antecedentes de los requisitos”. Esta última cláusula no es para nada incompatible con el requisito que propone XP en la cual puede llegar al punto en el cual el cliente. determinación de alcance y otros. proveer información necesaria de una manera oportuna. Se establecerá un procedimiento documentado para la identificación.

. El manifiesto consta de los siguientes doce puntos: I. La gente es el principal factor de éxito de un proyecto software. se está viviendo con intensidad un debate abierto entre los partidarios de las metodologías tradicionales (referidas peyorativamente como "metodologías pesadas") y aquellos que apoyan las ideas emanadas del "Manifiesto Ágil". pero en este paradigma se llevan al extremo. · Responder a los cambios más que seguir estrictamente un plan. Estos documentos deben ser cortos y centrarse en lo fundamental. etc. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo.) determina también el éxito o fracaso del mismo. -La colaboración con el cliente más que la negociación de un contrato. Por otro lado.. Prueba de ello es que se están haciendo un espacio destacado en la mayoría de conferencias y Workshops celebrados en los últimos años. y lo que XP ha hecho ha sido ponerlas todas juntas y comprobar que funcionaban. de hecho.Conclusión La Programación Extrema es ideal en aquellos proyectos en donde se requiere un desarrollo a corto plazo. · Desarrollar software que funciona más que conseguir una buena documentación. La metodología ágil se basa en los siguientes valores: · Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos. en donde los requerimientos pueden ser cambiados en cualquier instante. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas software que le aporte un valor.no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante. en la tecnología. Anexo I El Manifiesto Ágil Cuando en 2001 se crearon las bases de las metodologías ágil. En la comunidad de la ingeniería del software. se creo un manifiesto con los puntos que diferencian una metodología ágil del proceso tradicional. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. en el equipo. Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería de software que están acaparando gran interés. Las prácticas principales en la Programación Extrema son aquellas que generalmente son aceptadas como buenas. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Por lo tanto. La regla a seguir es . todas ellas ya existían. ninguna de las prácticas establecidas por XP son una invención del método. Es más importante construir un buen equipo que construir el entorno. Se propone como un paradigma en donde se proveen numerosas ventajas en la reutilización del código. la planificación no debe ser estricta sino flexible y abierta. su principal objetivo es reducir los costos generados por los cambios en los requerimientos. Página 16/18 .

IX. pag. 15) . Los procesos ágiles promueven un desarrollo sostenible. X. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. J. Juan Manuel Gutiérrez Cárdenas.Extreme Programming Explained. Referencias bibliográficas: . V Encuentro usuarios xBase 2003 Madrid l. Ronkainen. Kent Beck .c. III.c. pag 6.Four Variables: (l. Abrahamsson.: (Introducción. con el menor intervalo de tiempo posible entre entregas.Universidad Católica San Pablo l.extremeprogramming.c. pag 8) Página 17/18 .:(pag. pag 13) Aplicación del Estándar ISO 9001:2000 a la Metodología de Programación Extrema (XP) . VIII.: (Roles XP.: Las Cuatro Variables. requisitos y diseños surgen de los equipos organizados por mismos.www.c. Salo. El software que funciona es la medida principal de progreso.: El Costo del Cambio. Los promotores.Cost of Change: (l. P. V. IV. Roles and Responsabilites l.Una explicación de la Programación Extrema (XP) Manuel Calero Solís.7) . XI.6) Chapter 5 . VI. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.II.Agile software development methods Review and analysis.: (Objetivos de la Programación Extrema. Dar la bienvenida a los cambios.. pag. pag. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. según esto ajusta su comportamiento.2000 Chapter 4 . J.c. XII. VII. Warsta. de 2003. Las mejores arquitecturas. O.The New Methodology. La simplicidad es esencial. desarrolladores y usuarios deberían ser capaces de mantener una paz constante.. 2002. Martin Fowler.. 3) (Los Cuatro Valores. En intervalos regulares.Addison-Wesley . VTT Publications.org . Construir el proyecto en torno a individuos motivados. l. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. pag 5.c. 5) . el equipo reflexiona respecto a cómo llegar a ser más efectivo. Se capturan los cambios para que el cliente tenga ventaja competitiva. 7) (Cuándo usar XP. Entregar frecuentemente software que funcione desde un par de semanas a un par meses.

c. Letelier y Penadés .chuidiang. pag 11) (Los pasos a seguir en un proyecto. pag 12. 2002 l.: (Comentarios respecto de las Prácticas.com/ood/metodologia/extrema.: (Algunas bases de la Programación Extrema. pag.:(Practicas básicas de la Programación Extrema. 11) (Anexo 1 El Manifiesto ágil.c.html l.13) Página 18/18 . 17) .Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP). pag. 5) (Metáforas.www.10) . 2002 l. 9. Cueva Lovelle Universidad de Oviedo. Juan M..Universidad Politécnica de Valencia.eXtreme Programming (XP): un nuevo método de desarrollo de software César F. pag.c. pag. Acebal.

Sign up to vote on this title
UsefulNot useful