P. 1
Programación Extrema

Programación Extrema

|Views: 1.570|Likes:
Publicado porgeorunner

More info:

Published by: georunner on Jul 09, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

04/10/2013

pdf

text

original

19 de junio de 2011

5 El costo del cambio ……………………………………………………………………………………….…………………………....……………………………….5 Algunas bases de la Programación Extrema …………………………….……………………………...12 Cuándo usar XP ……………………………………………………………………………………….3 Introducción ………………………………………………………………..15 Conclusión …………………………………………………………………………………………………16 Anexo I .. 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 ………………………………………………………. 5 Las cuatro Variables ………………………………………………………….. 6 Los Cuatro Valores ……………………………………………………………………………………….. 7 Roles XP ……………………………………………………………………………………………………..………………………….……………………………….…….…………………………....…………………………….………………………….11 Los pasos a seguir en un proyecto ………………………………………….4 Objetivos de la Programación Extrema ………………………………….Índice Objetivo …………………………………………………………………….18 Página 2/18 ...El Manifiesto Ágil ………………………………………………………………………………17 Referencias bibliográficas……………………………………………….…..

Conocer las principales prácticas de la Programación Extrema: programación basada en tests. eXtreme Programming) y su aplicación. 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. .Objetivo .Introducción al estudio de la Programación Extrema (XP. etc.

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

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

• La implementación de los requisitos más importantes primero. que suele ser una invitación al desastre. 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 . Sin embargo.externa –la que notan los clientes –. una vez fijadas las otras tres. 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. 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 desmoralización del equipo y. ésta es una apuesta a muy corto plazo. es una buena idea dejar que sea esta la variable libre. En cuanto al alcance del proyecto. con ello. a la larga. de manera que. de manera que el proyecto tenga en cada instante tanta funcionalidad como sea posible. a la ralentización del proyecto mucho más allá del tiempo que hubiera podido ganarse al principio con esta reducción de calidad. En efecto.no se vea demasiado afectada.

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

Encargado de seguimiento (Tracker) El encargado de seguimiento proporciona realimentación al equipo en el proceso XP. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo. Consultor Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración. asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración. Su labor esencial es de coordinación. 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 . ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Además. En la XP. 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. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado. centrándose en aportar mayor valor al negocio. 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.El programador escribe las pruebas unitarias y produce el código del sistema. Cliente El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. Prácticas básicas de la Programación Extrema La mayoría de estas prácticas no son nuevas. 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. Guía al equipo para resolver un problema específico. comunicando los resultados para mejorar futuras estimaciones. sino que han sido reconocidas por la industria como las mejores prácticas durante años. difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Entrenador (Coach) Es responsable del proceso global. Ejecuta las pruebas regularmente. Encargado de pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.

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

saben del negocio real. Igualmente. pero lo que es seguro es que nadie es capaz de trabajar 60 horas a la semana y hacerlo con calidad. cualquiera que vea una posibilidad de simplificar. de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. y no meramente un sistema que funcione –lo cual.Todo el código será desarrollado en parejas –dos personas compartiendo un solo monitor y teclado. o muy poco. 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. hacen que esto no sea ningún problema en XP. Si al añadir la nueva clase junto con sus tests unitarios. en cualquier momento. como mucho– se integra el sistema completo Para ello existirá un máquina así llamada. para establecer prioridades. a la que se acercará una pareja de programadores cada vez que tengan una clase que haya sido probada unitariamente. Si el cliente arguye que su tiempo es demasiado valioso. Estándares de codificación Es decisiva para poder plantear con éxito la propiedad colectiva del código. tirarán el código a la basura y volverán a comenzar de nuevo. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos. Integración continua Cada pocas horas –o al cabo de un día de programación. en informática. É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. y que no importa que esté construido a partir de suposiciones hechas por programadores que nada. 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. los roles son intercambiables. 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. para responder cualquier consulta que los programadores le planteen. 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. Propiedad colectiva del código Cualquiera puede modificar cualquier porción del código. Si después de un cierto tiempo no son capaces de descubrir qué es lo que falla. para turnar a su compañero. de integración. deberemos entender que realmente el proyecto que nos ha encomendado es lo suficientemente trivial como para que no merezca su atención. Naturalmente. simplemente. las 40 horas no es una regla fija –pueden ir de 35 a 45–. 40 horas semanales Si realmente queremos ofrecer calidad. 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. 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. Metáforas Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa. Cliente in situ Otra controvertida regla de XP: al menos un cliente real debe estar permanentemente junto al equipo de desarrollo. el sistema completo sigue funcionando correctamente –pasa todos los tests–. los programadores darán por finalizada esa tarea. Si no. hayan sido o no escritos por él. Un ejemplo claro es el "recolector de basura" de java. La mayoría de las prácticas propuestas por XP no son novedosas sino que en Página 10/18 . En efecto. cualquier clase o cualquier método. mediante refactoring. 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. serán los responsables de dejar el sistema de nuevo con los tests funcionando al 100%. deberá hacerlo sin más dilación.

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

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

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

Desventajas: Es recomendable emplearlo solo en proyectos a corto plazo. contar con una educación base apropiada.2 que: “El personal que participe en el desarrollo del producto deberá ser competente. 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. Además de analizar las habilidades de cada miembro del equipo para la asignación de responsabilidades en el proyecto. Si se utilizan diagramas UML. Altos costos en caso de fallar.2. y como el sistema comienza a crecer orgánicamente. El desarrollo de software con XP es más flexible. se consigue que los desarrolladores apliquen las buenas prácticas que se les ofrecen con la XP. 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. éstos tienden a estar poco actualizados. La calidad de los sistemas basados en XP tiende a ser un poco mejor. entrenándose.4 la cual menciona que: “Los registros deberán Página 14/18 . simplificar. Menor tasa de errores. Debido a que se concibe que la “propiedad” del código es colectiva. es más sencillo remover funciones para cumplir con el tiempo de desarrollo sin poner en riesgo el resto del sistema. El planteamiento que propone al respecto dicha metodología es muy sencillo. ya que XP no propone criterios o guías de cómo se deben asignar las parejas de los programadores. 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. el estándar ISO 9001:2000 plantea la siguiente cláusula 4.Ventajas: Programación organizada. debido a la constante refactorización. en particular si se utilizan patrones de diseño. 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. cualquier necesidad del proyecto. en la cual en el contexto de XP se reduce a la especificación y seguimiento de los historiales de usuario. El estándar ISO 9001:2000 especifica en la cláusula 6. Es difícil predecir costo y tiempo de desarrollo. cualquiera puede desarrollar. 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. Con la finalidad de cubrir este punto débil de XP. Debido a la filosofía del “pair programming” (programación en parejas). mejorar. 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”.

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

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

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

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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->