La programación extrema o e xtreme programming

1,591 views
1,477 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,591
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
41
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

La programación extrema o e xtreme programming

  1. 1. PROGRAMACIÓN EXTREMA O EXTREME PROGRAMMING (XP)RAFAEL SÁNCHEZ ARTOLA.JOSE MARIA ANDUJAR GARCIA.
  2. 2. 1. INTRODUCCIÓN. Xp forma parte del conjunto de métodos ágiles que centran sus prioridades en las personas, no en los procesos, en la actualidad Xp se proyecta para ser un modelo de desarrollo común, sencillo y adaptable a las características cambiantes y exigentes de empresas y clientes. La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, Ron Jeffries y Ward Cinningham. El objetivo de Xp son grupos pequeños y medianos de construcción de software en donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto. La programación extrema o eXtreme Programming (XP) es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Los métodos ágiles surgen como una inflexión en un momento o contexto definido, en donde se hace necesario una renovación metodológica que busca satisfacer la necesidad de realizar los proyectos de una forma más rápida sin disminuir la calidad del mismo pero sí reducir documentación, pasos, procesos y tiempo. Indistintamente en el año 2001 firman para Xp en el manifiesto ágil (*)Kent Beck, Ward Cinningham, Martin Fowler, James Grenning, Ron Jeffries, Brian Marick, y Robert C. Matin, poco después y hasta hoy surge un gran número de libros y escritos que describen los pasos para aplicar esta metodología. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.1. REVISIÓN DE METODOLOGÍAS Aunque los creadores e impulsores de las metodologías ágiles más populares han suscrito el manifiesto ágil y coinciden con los principios enunciados anteriormente, cada metodología tiene características propias y hace hincapié en algunos aspectos más específicos. A continuación se resumen dichas metodologías ágiles, dejando el análisis más detallado de XP para la siguiente sección. SCRUM. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La
  3. 3. segunda característica importante son las reuniones a lo largo proyecto. Éstas son las verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.  CRYSTAL METHODOLOGIES. Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).  DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM). Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases.  ADAPTIVE SOFTWARE DEVELOPMENT (ASD).Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.  FEATURE-DRIVEN DEVELOPMENT (FDD). Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.  LEAN DEVELOPMENT. Definida por Bob Charette’s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios.La Tabla 1 compara las distintas aproximaciones ágiles en base a tres parámetros: vista delsistema como algo cambiante, tener en cuenta la colaboración entre los miembros del equipo ycaracterísticas más específicas de la propia metodología como son simplicidad, excelenciatécnica, resultados, adaptabilidad, etc.
  4. 4. º 2. PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP)XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave parael éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por elaprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa enrealimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entretodos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar loscambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos ymuy cambiantes, y donde existe un alto riesgo técnico.Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene sunombre. Kent Beck, el padre de XP, describe la filosofía de XP sin cubrir los detalles técnicos yde implantación de las prácticas. Posteriormente, otras publicaciones de experiencias se hanencargado de dicha tarea. A continuación presentaremos las características esenciales de XPorganizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas.3.1. LAS HISTORIAS DE USUARIOLas historias de usuario son la técnica utilizada en XP para especificar los requisitos delsoftware. Se trata de tarjetas de papel en las cuales el cliente describe brevemente lascaracterísticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. Eltratamiento de las historias de usuario es muy dinámico y flexible, en cualquier momentohistorias de usuario pueden romperse, reemplazarse por otras más específicas o generales,añadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente comprensibley delimitada para que los programadores puedan implementarla en unas semanas.Respecto de la información contenida en la historia de usuario, existen varias plantillassugeridas pero no existe un consenso al respecto. En muchos casos sólo se propone utilizar unnombre y una descripción [o sólo una descripción más quizás una estimación de esfuerzo endías Beck en su libro presenta un ejemplo de ficha (customer story and task card) en la cualpueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, corrección,mejora), prueba funcional, número de historia, prioridad técnica y del cliente, referencia a otrahistoria previa, riesgo, estimación técnica, descripción, notas y una lista de seguimiento con lafecha, estado cosas por terminar y comentarios.
  5. 5. No hay que preocuparse si en un principio no se identifican todas las historias de usuario. Alcomienzo de cada iteración estarán registrados los cambios en las historias de usuario y segúneso se planificará la siguiente iteración. Las historias de usuario son descompuestas en tareas deprogramación y asignadas a los programadores para ser implementadas durante una iteración.3.2. ROLES XPAunque en otras fuentes de información aparecen algunas variaciones y extensiones de rolesXP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck.PROGRAMADOR. El programador escribe las pruebas unitarias y produce el código delsistema. Debe existir una comunicación y coordinación adecuada entre los programadores yotros miembros del equipo.CLIENTE. El cliente escribe las historias de usuario y las pruebas funcionales para validar suimplementación. Además, asigna la prioridad a las historias de usuario y decide cuáles seimplementan en cada iteración centrándose en aportar mayor valor al negocio. El cliente es sólouno dentro del proyecto pero puede corresponder a un interlocutor que está representando avarias personas que se verán afectadas por el sistema.ENCARGADO DE PRUEBAS (TESTER). El encargado de pruebas ayuda al cliente a escribirlas pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo yes responsable de las herramientas de soporte para pruebas.ENCARGADO DE SEGUIMIENTO (TRACKER). El encargado de seguimiento proporcionarealimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de aciertoentre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados paramejorar futuras estimaciones. También realiza el seguimiento del progreso de cada iteración yevalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes.Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración.ENTRENADOR (COACH). Es responsable del proceso global. Es necesario que conozca afondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen lasprácticas XP y se siga el proceso correctamente.CONSULTORES. Un miembro externo del equipo con un conocimiento específico en algúntema necesario para el proyecto. Guía al equipo para resolver un problema específico.GESTOR (BIG BOSS). Es el vínculo entre clientes y programadores, ayuda a que el equipotrabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.4. PROCESO XPUn proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementarbasado en la habilidad del equipo para medir la funcionalidad que puede entregar a través deltiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementación. 3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1.
  6. 6. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debepresionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en elsoftware o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación demanejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valorde negocio posible con cada iteración.El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega(Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.FASE I: EXPLORACIÓNEn esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interéspara la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiarizacon las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba latecnología y se exploran las posibilidades de la arquitectura del sistema construyendo unprototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo deltamaño y familiaridad que tengan los programadores con la tecnología.FASE II: PLANIFICACIÓN DE LA ENTREGAEn esta fase el cliente establece la prioridad de cada historia de usuario, ycorrespondientemente, los programadores realizan una estimación del esfuerzo necesario decada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina uncronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses.Esta fase dura unos pocos días.Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen losprogramadores utilizando como medida el punto. Un punto, equivale a una semana ideal deprogramación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo dedesarrollo mantiene un registro de la "velocidad" de desarrollo, establecida en puntos poriteración, basándose principalmente en la suma de puntos correspondientes a las historias deusuario que fueron terminadas en la última iteración.La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad delproyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fechadeterminada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar portiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándosecuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la sumade puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendoel número de iteraciones necesarias para su implementación.FASE III: ITERACIONESEsta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entregaestá compuesto por iteraciones de no más de tres semanas. En la primera iteración se puedeintentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto delproyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sinembargo, esto no siempre es posible ya que es el cliente quien decide qué historias seimplementarán en cada iteración (para maximizar el valor de negocio). Al final de la últimaiteración el sistema estará listo para entrar en producción.Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son:historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadasen la iteración anterior y tareas no terminadas en la iteración anterior. Todo el trabajo de la
  7. 7. iteración es expresado en tareas de programación, cada una de ellas es asignada a unprogramador como responsable, pero llevadas a cabo por parejas de programadores. Wakeproporciona algunas guías útiles para realizar la planificación de la entrega y de cada iteración.FASE IV: PRODUCCIÓNLa fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de queel sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisionessobre la inclusión de nuevas características a la versión actual, debido a cambios durante estafase.Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas quehan sido propuestas y las sugerencias son documentadas para su posterior implementación (porejemplo, durante la fase de mantenimiento).FASE V: MANTENIMIENTOMientras la primera versión se encuentra en producción, el proyecto XP debe mantener elsistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar estose requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puedebajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerirnuevo personal dentro del equipo y cambios en su estructura.FASE VI: MUERTE DEL PROYECTOEs cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que sesatisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad delsistema. Se genera la documentación final del sistema y no se realizan más cambios en laarquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficiosesperados por el cliente o cuando no hay presupuesto para mantenerlo.5. PRÁCTICAS XPLa principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curvaexponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseñoevolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con uncomportamiento asintótico. Esto se consigue gracias a las tecnologías disponibles para ayudaren el desarrollo de software y a la aplicación disciplinada de las prácticas que describiremos acontinuación.EL JUEGO DE LA PLANIFICACIÓNEs un espacio frecuente de comunicación entre el cliente y los programadores. El equipo técnicorealiza una estimación del esfuerzo requerido para la implementación de las historias de usuarioy los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración. Esta prácticase puede ilustrar como un juego, donde existen dos tipos de jugadores: Cliente y Programador.El cliente establece la prioridad de cada historia de usuario, de acuerdo con el valor que aportapara el negocio. Los programadores estiman el esfuerzo asociado a cada historia de usuario. Seordenan las historias de usuario según prioridad y esfuerzo, y se define el contenido de laentrega y/o iteración, apostando por enfrentar lo de más valor y riesgo cuanto antes. Este juegose realiza durante la planificación de la entrega, en la planificación de cada iteración y cuandosea necesario reconducir el proyecto.
  8. 8. ENTREGAS PEQUEÑASLa idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamenteno cuenten con toda la funcionalidad pretendida para el sistema pero si que constituyan unresultado de valor para el negocio. Una entrega no debería tardar más 3 meses.METÁFORAEn XP no se enfatiza la definición temprana de una arquitectura estable para el sistema. Dichaarquitectura se asume evolutiva y los posibles inconvenientes que se generarían por no contarcon ella explícitamente en el comienzo del proyecto se solventan con la existencia de unametáfora. El sistema es definido mediante una metáfora o un conjunto de metáforas compartidaspor el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describecómo debería funcionar el sistema. Martin Fowler en [6] explica que la práctica de la metáforaconsiste en formar un conjunto de nombres que actúen como vocabulario para hablar sobre eldominio del problema. Este conjunto de nombres ayuda a la nomenclatura de clases y métodosdel sistema.DISEÑO SIMPLESe debe diseñar la solución más simple que pueda funcionar y ser implementada en un momentodeterminado del proyecto. La complejidad innecesaria y el código extra debe ser removidoinmediatamente. Kent Beck dice que en cualquier momento el diseño adecuado para el softwarees aquel que: supera con éxito todas las pruebas, no tiene lógica duplicada, refleja claramente laintención de implementación de los programadores y tiene el menor número posible de clases ymétodos.PRUEBASLa producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias sonestablecidas antes de escribir el código y son ejecutadas constantemente ante cada modificacióndel sistema. Los clientes escriben las pruebas funcionales para cada historia de usuario que debavalidarse. En este contexto de desarrollo evolutivo y de énfasis en pruebas constantes, laautomatización para apoyar esta actividad es crucial.REFACTORIZACIÓN (REFACTORING)La refactorización es una actividad constante de reestructuración del código con el objetivo deremover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible parafacilitar los posteriores cambios. La refactorización mejora la estructura interna del código sinalterar su comportamiento externo. Robert Martin señala que el diseño del sistema de softwarees una cosa viviente. No se puede imponer todo en un inicio, pero en el transcurso del tiempoeste diseño evoluciona conforme cambia la funcionalidad del sistema. Para mantener un diseñoapropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida delproyecto. De hecho, este cuidado continuo sobre el diseño es incluso más importante que eldiseño inicial. Un concepto pobre al inicio puede ser corregido con esta actividad continua, perosin ella, un buen diseño inicial se degradará.PROGRAMACIÓN EN PAREJASToda la producción de código debe realizarse con trabajo en parejas de programadores. SegúnCockburn y Williams en un estudio realizado para identificar los costos y beneficios de laprogramación en parejas las principales ventajas de introducir este estilo de programación son:muchos errores son detectados conforme son introducidos en el código (inspecciones de código
  9. 9. continuas), por consiguiente la tasa de errores del producto final es más baja, los diseños sonmejores y el tamaño del código menor (continua discusión de ideas de los programadores), losproblemas de programación se resuelven más rápido, se posibilita la transferencia deconocimientos de programación entre los miembros del equipo, varias personas entienden lasdiferentes partes sistema, los programadores conversan mejorando así el flujo de información yla dinámica del equipo, y finalmente, los programadores disfrutan más su trabajo. Dichosbeneficios se consiguen después de varios meses de practicar la programación en parejas. En losestudios realizados por Cockburn y Williams este lapso de tiempo varía de 3 a 4 meses.PROPIEDAD COLECTIVA DEL CÓDIGOCualquier programador puede cambiar cualquier parte del código en cualquier momento. Estapráctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema,evitando a la vez que algún programador sea imprescindible para realizar cambios en algunaporción de código.INTEGRACIÓN CONTINUACada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puedellegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas sonejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporadodefinitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos delos desarrolladores por falta de comunicación sobre lo que puede ser reutilizado o compartido.Martin Fowler en afirma que el desarrollo de un proceso disciplinado y automatizado es esencialpara un proyecto controlado, el equipo de desarrollo está más preparado para modificar elcódigo cuando sea necesario, debido a la confianza en la identificación y corrección de loserrores de integración.40 HORAS POR SEMANASe debe trabajar un máximo de 40 horas por semana. No se trabajan horas extras en dossemanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debecorregirse. El trabajo extra desmotiva al equipo. Los proyectos que requieren trabajo extra paraintentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto sepuede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha deentrega.CLIENTE IN-SITUEl cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte deléxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacialo que aportará mayor valor de negocio y los programadores pueden resolver de manerainmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita, ya queesta última toma mucho tiempo en generarse y puede tener más riesgo de ser mal interpretada.Jeffries indica que se debe pagar un precio por perder la oportunidad de un cliente con altadisponibilidad. Algunas recomendaciones propuestas para dicha situación son las siguientes:intentar conseguir un representante que pueda estar siempre disponible y que actúe comointerlocutor del cliente, contar con el cliente al menos en las reuniones de planificación,establecer visitas frecuentes de los programadores al cliente para validar el sistema, anticiparse alos problemas asociados estableciendo llamadas telefónicas frecuentes y conferencias,reforzando el compromiso de trabajo en equipo.ESTÁNDARES DE PROGRAMACIÓN
  10. 10. XP enfatiza la comunicación de los programadores a través del código, con lo cual esindispensable que se sigan ciertos estándares de programación (del equipo, de la organización uotros estándares reconocidos para los lenguajes de programación utilizados). Los estándares deprogramación mantienen el código legible para los miembros del equipo, facilitando loscambios.COMENTARIOS RESPECTO DE LAS PRÁCTICASEl mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada puestoque se apoyan unas en otras. Esto se ilustra en la Figura 1 donde una línea entre dos prácticassignifica que las dos prácticas se refuerzan entre sí.La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma yahabían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica elmérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde laperspectiva del negocio, los valores humanos y el trabajo en equipo.Figura 1. Las prácticas se refuerzan entre sí 3. CRÍTICAS A EXTREME PROGRAMMINGAlgunas de las críticas recopiladas de Xp son:Xp tiene muchas críticas especialmente contra la programación por parejas por parte de muchosprogramadores con gran sentimiento de posesión del código, piensan que ellos son los mejoresconocedores de las herramientas y lenguajes que utilizan y que si alguien no lo entiende esporque no sabe lo suficiente.
  11. 11. También se critica el mito de las 40 horas semanales ya que es un lujo para las exigencias delmercado.También hay críticas hacia Xp que dicen que solo puede funcionar con programadores muybuenos, como Kent Beck, que son capaces de hacer un buen diseño, sencillo y fácilmenteextensible.Xp es más una filosofía de trabajo que una metodología. Por otro lado ninguna de las practicasdefendidas por Xp son invención de este método, Xp lo que hace es ponerlas todas juntas.Xp está diseñado para grupos de pequeños programadores, más de 10 ya sería muy complicado,y más aun para que estén en el mismo centro de trabajo. 4. VALORESLos Valores originales de la programación extrema son: simplicidad, comunicación,retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segundaedición de Extreme Programming Explained. Los cinco valores se detallan a continuación:•Simplicidad:La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar eldesarrollo y facilitar el mantenimiento. Undiseño complejo del código junto a sucesivasmodificaciones por parte de diferentes desarrolladores hacen que la complejidad aumenteexponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, éstaes la manera de mantener el código simple a medida que crece. También se aplica la simplicidaden la documentación, de esta manera el código debe comentarse en su justa medida, intentandoeso sí que el código esté auto-documentado. Para ello se deben elegir adecuadamente losnombres de las variables, métodos y clases. Los nombres largos no decrementan la eficienciadel código ni el tiempo de desarroll o gracias a las herramientas de autocompletado yrefactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectivadel código y la programación por parejas se asegura que cuanto más grande se haga el proyecto,todo el equipo conocerá más y mejor el sistema completo.•ComunicaciónLa comunicación se realiza de diferentes formas. Para los programadores el código comunicamejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlointeligible. El código auto-documentado es más fiable que los comentarios ya que éstos últimospronto quedan desfasados con el código a medida que es modificado. Debe comentarse sóloaquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de unmétodo. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de lasclases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Losprogramadores se comunican constantemente gracias a la programación por parejas. Lacomunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. Elcliente decide que características tienen prioridad y siempre debe estar disponible parasolucionar dudas.•Retroalimentación(feedback)Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce entiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimizael tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a
  12. 12. centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclosmuy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios delcliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente deretroalimentación gracias a las herramie ntas de desarrollo. Por ejemplo, las pruebasunitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitariasfrecuentemente permite descubrir fallos debidos a cambios recientes en el código.•CorajeLos puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje? Para los gerentesla programación en parejas puede ser difícil de aceptar, porque les parece como si laproductividad se fuese a reducir a la mitad ya que solo la mitad de los programadores estáescribiendo código. Hay que ser valiente para confiar en que la programación por parejasbeneficia la calidad del código sin repercutir negativamente en la productividad. La simplicidades uno de los principios más difíciles de adoptar. Se requiere coraje para implementar lascaracterísticas que el cliente quiere ahora sin caer en la tentación de optar por un enfoque másflexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandesmarcos de trabajo (frameworks) mientra el cliente espera. En ese tiempo el cliente no recibenoticias sobre los avances del proyecto y el equipo de desarrollo no recibe retroalimentaciónpara saber si va en la dirección correcta. La forma de construir marcos de trabajo es mediantela refactorización del código en sucesivas aproximaciones.•RespetoEl respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros,porque los programadores no pueden realizar cambios que hacen que las pruebas existentesfallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porquesiempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o máseficiente para la solución a través de la refactorización del código. Los miembros del equiporespetan el trabajo del resto no haciendo menos a otros, si no orientándolos a realizarlo mejor,obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo deproducción en el equipo.BIBLIOGRAFÍA-Sommerville, I. (2006). Ingeniería del software (Séptima Edición). Madrid.-Kenneth, E. y Kendall, J. (2005). Analisis Y Diseño de Sistemas(Sexta edición).-Solís, M. (2003). Una explicación de la programación extrema (XP).-http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_para_el_desarrollo_de_sofware#Programaci.C3.B3n_Extrema_.28XP.29-http://www.cyta.com.ar/ta0502/v5n2a1.htm-Booch G. et.al, “El Lenguaje Unificado de Modelado,” eXtreme Programming.www.extremeprogramming.org-Larman C., “UML y Patrones”, Prentice Hall, Segunda Edición, 2003-Bruegge B., “Ingenieria de Software Orientada a Objetos,”(*)Manifiesto ágil El 17 de febrero de 2001 diecisiete críticos de los modelos de mejora del desarrollo desoftware basados en procesos, convocados por Kent Beck, quien había publicado un par de años
  13. 13. antes Extreme Programming Explained, libro en el que exponía una nueva metodologíadenominada Extreme Programming, se reunieron en Snowbird, Utah para tratar sobre técnicas yprocesos para desarrollar software. En la reunión se acuñó el término “Métodos Ágiles” paradefinir a los métodos que estaban surgiendo como alternativa a las metodologías formales(CMMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácternormativo y fuerte dependencia de planificaciones detalladas previas al desarrollo. Los integrantes de la reunión resumieron los principios sobre los que se basan losmétodos alternativos en cuatro postulados, lo que ha quedado denominado como ManifiestoÁgil. Hasta 2005 han sido frecuentes las posturas radicales entre los defensores de losmodelos de procesos y los defensores de modelos ágiles, quizá más ocupados en descalificar alotro que en estudiar sus métodos y conocerlos para mejorar los propios. En el Manifiesto Ágil, fue firmado por Kent Beck, Mike Beedle, Arie van Bennekum,Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, KenSchwaber, Jeff Sutherland y Dave Thomas,

×