eXtreme Programming
La programaci?n extrema (eXtreme Programming) o XP, es una disciplina de desarrollo basada en la simplicidad. XP aparece para, que equipos peque?os que necesitan desarrollar software r?pidamente, puedan realizarlo en un ambiente donde los requisitos cambian r?pidamente.
La metodolog?a de Desarrollo de Software, siempre necesitar? ser modificada para adaptarla a los requisitos particulares del cliente y de las circunstancias. XP no es ninguna excepci?n.
Hay doce pr?cticas para aplicar XP:El proceso de planteamiento o juego de la planificaci?n
Permite que el XP cliente defina el valor de negocio y las caracter?sticas deseadas, y utiliza las valoraciones de coste proporcionadas por los programadores, para elegir si necesita ser desarrollado o dejar aparcado. Con este proceso es f?cil llevar el proyecto a ?buen puerto?.
Entregas peque?as
La idea es producir r?pidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad, pero constituyan un resultado de valor para el negocio.
Met?fora
Una met?fora, es una historia compartida que describe c?mo deber?a funcionar el sistema. El sistema es definido por una met?fora o un conjunto de met?foras compartidas por el cliente y el equipo de desarrollo. La met?fora consiste en formar un conjunto de nombres que act?en como vocabulario para hablar sobre el dominio del problema.
Dise?o simple
Se debe dise?ar la soluci?n m?s simple que puede funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el c?digo extra debe ser removido inmediatamente.
Pruebas
La producci?n de c?digo est? dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el c?digo y son ejecutadas constantemente ante cada modificaci?n del sistema. En este desarrollo y pruebas constantes, la automatizaci?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 fin de remover duplicaci?n de c?digo, mejorar legibilidad, simplificarlo y hacerlo m?s flexible para facilitar los posteriores cambios. Para mantener un dise?o apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
Programaci?n en parejas
Toda la producci?n de c?digo debe realizarse en parejas de programadores. Muchos errores son detectados conforme son introducidos y la tasa de errores del producto final son mucho menores, los dise?os son mejores y el tama?o del c?digo menor, los problemas de programaci?n se resuelven m?s r?pido, se transfieren los conocimientos de programaci?n entre los miembros del equipo, varias personas entienden las diferentes partes del sistema, mejora el flujo de informaci?n y la din?mica del equipo.
Propiedad colectiva
Cualquier programador puede cambiar cualquier parte del c?digo en cualquier momento. Esta pr?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 alguna porci?n de c?digo.
Integraci?n contin?a
Cada pieza de c?digo es integrada en el sistema una vez que est? lista. As?, el sistema puede llegar a ser integrado y construido varias veces en un mismo d?a. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo c?digo sea incorporado definitivamente. La integraci?n continua a menudo reduce la fragmentaci?n de los esfuerzos de los desarrolladores por falta de comunicaci?n sobre lo que puede ser reutilizado o compartido. Esto es esencial para un proyecto controlado.
40 horas por semana
Se debe trabajar un m?ximo de 40 horas por semana. No se trabajo horas extras en dos semanas seguidas. Si esto ocurre, probablemente est? ocurriendo un problema que debe corregirse. El trabajo extra desmotiva el equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificaci?n para cambiar el ?mbito del proyecto o la fecha de entrega.
Cliente in-situ
El 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 hacia lo que aportar? mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. Algunas recomendaciones propuestas para dicha situaci?n son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que act?e de interlocutor del cliente, contar con el cliente al menos en las reuniones de planificaci?n, establecer visitaqs frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas aosociados estableciendo llamadas telef?nicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.
Est?ndares de programaci?n
Es indispensable que se sigan ciertos est?ndares de programaci?n. Estos mantienen el c?digo legible para los miembros del equipo, facilitando los cambios.
Todas estas pr?cticas, se refuerzan entre s?.
