Programacin extrema: Metodologa para desarrollo gil de aplicaciones La programacin extrema, o Extreme Programming (XP) Su autor principal es Kent

Beck, quien eligi algunas caractersticas de otras metodologas y las relacion de forma que cada una complementara a la otra. As, la XP se puede definir como un conjunto de pasos de diversas metodologas, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso comn, para realizar un desarrollo ms agradable y sencillo. Esta metodologa tiene como base la simplicidad y como objetivo principal la satisfaccin del cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales: Comunicacin Es muy importante que haya una comunicacin constante con el cliente y dentro de todo el equipo de trabajo, de esto depender que el desarrollo se lleve a cabo de una manera sencilla, entendible y que se entregue al cliente lo que necesita. Simplicidad En la XP se refiere que ante todo y sin importar qu funcionalidad requiera el usuario en su sistema, ste debe ser fcil. El diseo debe ser sencillo y amigable al usuario, el cdigo debe ser simple y entendible, programando slo lo necesario y lo que se utilizar. Retroalimentacin Es la comunicacin constante entre el desarrollador y el usuario. Coraje Se refiere a la valenta que se debe tener al modificar o eliminar el cdigo que se realiz con tanto esfuerzo; el desarrollador debe saber cuando el cdigo que desarroll no es til en el sistema y, por lo mismo, debe ser eliminado. Tambin se refiere a tener la persistencia para resolver los errores en la programacin. Dentro de la programacin extrema se tiene 12 principios que llevan o guan el desarrollo con esta metodologa: 1. El principio de pruebas 2. Proceso de planificacin 3. El cliente en el lugar 4. Programacin en parejas 5. Integracin contina 6. Refactorizacin 7. Entregas pequeas 8. Diseo simple 9. Metfora 10. Propiedad colectiva del cdigo 11. Estndar de codificacin 12. La semana de 40 horas

El principio de pruebas: se tiene que establecer un perodo de pruebas de aceptacin del programa (llamado tambin perodo de caja negra) donde se definirn las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Proceso de planificacin: en esta fase, el usuario tendr que escribir sus necesidades, definiendo las actividades que realizar el sistema. Se crear un documento llamado Historias del usuario. Entre 20 y 80 historias (dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin para recibir retroalimentacin por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones peridicas durante esta fase de planificacin. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y sealar aquellos puntos a los que se les ha de dar ms importancia por su dificultad o por su punto crtico. El cliente en el lugar: se le dar poder para determinar los requerimientos, definir la funcionalidad, sealar las prioridades y responder las preguntas de los programadores. Esta fuerte interaccin cara a cara con el programador disminuye el tiempo de comunicacin y la cantidad de documentacin, junto con los altos costos de su creacin y mantenimiento. Este representante del cliente estar con el equipo de trabajo durante toda la realizacin del proyecto. Programacin en parejas: uno de los principios ms radicales y en el que la mayora de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su cdigo en parejas, compartiendo una sola mquina. De acuerdo con los experimentos, este principio puede producir aplicaciones ms buenas, de manera consistente, a iguales o menores costos. Aunque el pair-programming puede no ser para todo el mundo. Integracin continua: permite al equipo hacer un rpido progreso implementando las nuevas caractersticas del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su cdigo y reconstruir el sistema varias veces al da. Esto reduce los problemas de integracin comunes en proyectos largos y estilo cascada. Refactorizacin: permite a los equipos de programadores XP mejorar el diseo del sistema a travs de todo el proceso de desarrollo. Los programadores evalan continuamente el diseo y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimizacin del cdigo duplicado y/o ineficiente. Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza de forma rpida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como mximo.

Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos obsoletos de forma sencilla. Metfora: desarrollada por los programadores al inicio del proyecto, define una historia de cmo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metfora expresa la visin evolutiva del proyecto que define el alcance y propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo a definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con ellas). Propiedad colectiva del cdigo: Es un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales en los que un simple programador posee un conjunto de cdigo. Los defensores de XP argumentan que mientras haya ms gente trabajando en una pieza, menos errores aparecern. Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona. La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor calidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad. Herramientas de la XP Historias de usuarios Son tarjetas fsicas en las cuales se anota una descripcin de una funcionalidad del sistema, en una oracin, se le da un nmero y un ttulo para ser identificada. Casos de prueba de aceptacin Son tarjetas que se elaboran para realizar las pruebas de cada historia de usuario. Tarea de ingeniera Son tarjetas que se elaboran para ayudar y simplificar la programacin de una historia de usuario. Tarjetas CRC Describen las clases utilizadas en la programacin de una historia. Ventajas y desventajas Una de las ventajas de la programacin extrema es que se adapta al desarrollo de sistemas

pequeos y grandes; optimiza el tiempo de desarrollo; permite realizar el desarrollo del sistema en parejas para complementar los conocimientos; el cdigo es sencillo y entendible, adems de la poca documentacin a elaborar para el desarrollo del sistema. Las desventajas son que no se tiene la definicin del costo y el tiempo de desarrollo; el sistema va creciendo despus de cada entrega al cliente y nadie puede decir que el cliente no querr una funcin ms; se necesita de la presencia constante del usuario, lo cual en la realidad es muy difcil de lograr. Otra desventaja es la programacin en parejas, algunos desarrolladores son celosos del cdigo que escriben y no les es grato que alguien ms modifique las funciones que realiz o que su cdigo sea desechado por no cubrir el estndar. Interaccin con el cliente. En este tipo de programacin el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es mxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificacin. Tiene un papel importante de interaccin con el equipo de programadores, sobre todo despus de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programacin existirn pruebas de aceptacin de la programacin que ayudarn a que su labor sea lo ms provechosa posible. Al fin y al cabo, el cliente se encuentra mucho ms cerca del proceso de desarrollo. Se elimina la fase inicial de recopilacin de requerimientos, y se permite que stos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. Historia de usuario: Se trata de una lista de caractersticas que el cliente necesita que existan en el producto final. Estas constan de dos fases. En la primera fase, el cliente describe con sus propias palabras las caractersticas y, es el responsable del equipo, el encargado de informarlo de las dificultades tcnicas de cada una de ellas y de su costo. A consecuencia de este dilogo, el cliente deja por escrito un conjunto de historias y las ordena en funcin de la prioridad que tiene pera l. De esta manera ya es posible definir unas fechas aproximadas para ellos. En la segunda fase, el cliente coger las primeras historias a implementar y las dividir en trabajos a realizar. El cliente tambin participa, pero hay ms peso por parte del equipo de desarrolladores, esto dar como resultado una planificacin ms exacta. Este mtodo se repetir para cada historia. Se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. En esta fase, el equipo tcnico ser el encargado de catalogar las historias del cliente y asignarles una duracin. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programacin. Las que requieran menos tiempo sern agrupadas, y las que necesiten ms sern modificadas o divididas. Finalmente decir que las historias de los usuarios sern escritas en tarjetas, lo que facilitar que el cliente pueda

especificar la importancia relativa entre las diferentes historias de usuario, as como el trabajo de los programadores que podrn catalogarlas correctamente. Este formato tambin es muy til en el momento de las pruebas de aceptacin.

1.-Autor principal Kent Beck 2.-Iniciales de la programacin extrema en ingles XP 3.- a que se le llama tambin perodo de caja negra? Principio de pruebas 4.- En qu proceso se crear un documento llamado Historias del usuario.? Planificacin 5.- Requiere que todos los programadores XP escriban su cdigo en parejas Programacin en parejas 6.- Es un cdigo con propiedad compartida Propiedad colectiva del cdigo 7.- Tiene un papel importante de interaccin con el equipo de programadores El cliente 8.- Cuntas fases tiene la Historia de usuario? Dos 9.- Estas entregas no pueden pasar las 2 o 3 semanas como mximo Entregas pequeas 10.- Quin es el encargado de escribir los documentos con las especificaciones de lo que realmente quiere? El cliente