En informática y más particularmente en ingeniería de software , la programación extrema ( XP ) es un método ágil orientado más particularmente al aspecto de implementación de una aplicación, sin descuidar el aspecto de gestión de proyectos . XP es adecuado para equipos pequeños con necesidades cambiantes. XP lleva los principios simples al extremo.
La programación extrema fue inventada por Kent Beck , Ward Cunningham y Ron Jeffries durante su trabajo en un proyecto de cálculo de compensación "C3" en Chrysler. Kent Beck, director de proyectos enMarzo de 1996, comenzó a perfeccionar el método de desarrollo utilizado en el proyecto. Esto nació oficialmente en octubre de 1999 con el libro Extreme Programming Explained por Kent Beck .
En el libro Extreme Programming Explained , el método se define como:
Su objetivo principal es reducir los costos del cambio. En los métodos tradicionales, las necesidades se definen y, a menudo, se fijan al inicio del proyecto de TI, lo que aumenta los costos posteriores de las modificaciones. XP se esfuerza por hacer que el proyecto sea más flexible y abierto al cambio mediante la introducción de valores, principios y prácticas fundamentales.
Los principios de este método no son nuevos: existen en la industria del software durante décadas y en los métodos de gestión desde hace más tiempo. La originalidad del método es llevarlos al extremo:
La programación extrema se basa en ciclos de desarrollo rápidos (iteraciones de unas pocas semanas), cuyas etapas son las siguientes:
El ciclo se repite siempre que el cliente pueda proporcionar escenarios para entregar. Generalmente, el ciclo que precede a la primera entrega se caracteriza por su duración y el gran volumen de funciones a bordo. Después del primer lanzamiento, las iteraciones pueden acortarse (una semana, por ejemplo).
Si bien enfatiza las buenas prácticas de programación, XP recomienda un desdoblamiento por iteraciones cortas y gestionadas colectivamente, con la participación constante del cliente. El resultado es una redefinición de la relación entre cliente y proveedor con resultados sorprendentes en términos de calidad del código, plazos y satisfacción del cliente .
La programación extrema basada en cinco valores fundamentales.
ComunicaciónEsta es la forma fundamental de evitar problemas. Las prácticas recomendadas por XP requieren una comunicación intensa. Las pruebas, la programación de pares y el juego de planificación obligan a los desarrolladores, los responsables de la toma de decisiones y los clientes a comunicarse. Si aparece una falta a pesar de todo, un entrenador se encarga de identificarla y volver a poner en contacto a estas personas.
SencillezLa forma más sencilla de obtener el resultado es la mejor. Anticipar futuras ampliaciones es una pérdida de tiempo. Una aplicación simple será más fácil de actualizar.
RealimentaciónLa retroalimentación es esencial para el programador y el cliente. Las pruebas unitarias indican si el código está funcionando. Las pruebas funcionales dan el avance del proyecto. Las entregas frecuentes permiten probar la funcionalidad rápidamente.
CorajeAlgunos cambios requieren mucho coraje. A veces tienes que cambiar la arquitectura de un proyecto, desechar el código para producir uno mejor o probar una nueva técnica. El coraje es la forma de salir de una situación inadecuada. Es difícil, pero la simplicidad, la retroalimentación y la comunicación hacen que estas tareas sean accesibles.
RespetoEste valor se agregó en la segunda edición de Extreme Programming Explained by K. Beck. Este valor incluye el respeto por los demás, así como el respeto por uno mismo. Los programadores nunca deben realizar cambios que interrumpan la compilación, hagan que fallen las pruebas unitarias existentes o retrasen el trabajo de sus pares. Los miembros respetan su propio trabajo buscando siempre la calidad y el mejor diseño para la solución y esto a través de la refactorización .
Estos cinco valores se dividen en trece prácticas que se refuerzan mutuamente:
Cliente en el sitioUn representante del cliente debería, si es posible, estar presente durante la duración del proyecto. Debe tener el conocimiento del usuario final y tener una visión global del resultado a obtener. Hace su trabajo habitual mientras está disponible para responder preguntas del equipo.
Planificación del juego o planificación del póquerEl cliente crea escenarios para la funcionalidad que desea lograr. El equipo evalúa el tiempo necesario para implementarlos. Luego, el cliente selecciona los escenarios de acuerdo con las prioridades y el tiempo disponible.
Integración continuaCuando se completa una tarea, los cambios se incorporan inmediatamente al producto completo. Esto evita la sobrecarga de trabajo relacionada con la integración de todos los elementos antes de la entrega. Las pruebas facilitan enormemente esta integración: cuando todas las pruebas pasan, la integración está completa.
Pequeñas entregasLas entregas deben ser lo más frecuentes posible. La integración y las pruebas continuas reducen drásticamente el costo de entrega.
Marcha sostenibleEl equipo no trabaja horas extras. Si surge el caso, se debe revisar el cronograma. Un revelador cansado funciona mal.
Pruebas de aceptación (o pruebas funcionales)A partir de los escenarios definidos por el cliente, el equipo crea procedimientos de prueba que permiten verificar el avance del desarrollo. Cuando pasan todas las pruebas funcionales, la iteración se completa. Estas pruebas suelen estar automatizadas, pero esto no siempre es posible.
De hecho, solo las pruebas de no regresión pueden automatizarse potencialmente debido a su recurrencia.
La receta funcional de una aplicación se confía cada vez más a expertos en pruebas independientes de los desarrolladores.
Pruebas unitariasAntes de implementar una función, el desarrollador escribe una prueba que verificará que su programa se comporte como se esperaba. Esta prueba se mantendrá hasta el final del proyecto, siempre que se requiera la funcionalidad. Cada vez que se modifica el código, ejecutamos todas las pruebas escritas por todos los desarrolladores e inmediatamente sabemos si algo ya no funciona.
Diseño simpleEl objetivo de una iteración es implementar los escenarios seleccionados por el cliente y solo eso. Prever las próximas evoluciones sería una pérdida de tiempo sin tener la garantía de una ganancia posterior. Las pruebas permitirán cambiar la arquitectura posteriormente si es necesario. Cuanto más simple sea la aplicación, más fácil será evolucionarla en las próximas iteraciones.
Uso de metáforasSe utilizan metáforas y analogías para describir el sistema y cómo funciona. Lo funcional y lo técnico se entienden mucho mejor cuando se ponen de acuerdo sobre los términos que utilizan.
Refactorización (o reelaboración de código)Mejora regular de la calidad del código sin modificar su comportamiento. Reelaboramos el código para empezar de nuevo sobre una base mejor manteniendo las mismas funcionalidades. Las fases de refactorización no aportan nada al cliente, pero permiten a los desarrolladores avanzar en mejores condiciones y, por lo tanto, más rápido.
Propiedad colectiva del códigoEl equipo es colectivamente responsable de la aplicación. Cada desarrollador puede realizar cambios en cualquier parte del código, incluso en aquellas que no haya escrito. Las pruebas dirán si algo ya no funciona.
Convenio de denominaciónDado que todos los desarrolladores están involucrados en todo el código, es esencial establecer y seguir estándares de nomenclatura para variables, métodos, objetos, clases, archivos, etc.
Programación en parejaLa programación se realiza por parejas. El primer controlador llamado (o piloto ) sostiene el teclado. Es él quien trabajará en la porción de código a escribir. El segundo llamado socio (o copiloto ) está ahí para ayudarlo sugiriéndole nuevas posibilidades o detectando posibles problemas. Los desarrolladores cambian con frecuencia de socios y roles, lo que mejora el conocimiento colectivo de la aplicación y mejora la comunicación dentro del equipo.
Este método se basa en:
En lugar de la desventaja del método, hablaremos más fácilmente de entornos desfavorables en los que el método XP no es aplicable.
En este caso, solo se puede realizar una parte de las prácticas. Los principales contextos desfavorables son: