La programación extrema es una disciplina de desarrollo de software “relativamente” nueva. Tiene características totalmente diferentes a la planificación tradicional de cualquier proyecto de software; Si bien usa un sistema iterativo de desarrollo, el paradigma es totalmente diferente a lo “estándar”.
Características de XP:
La programación extrema da por supuesto que es imposible prever todo antes de comenzar a programar; es imposible o si lo fuera es demasiado costoso e innecesario, ya que muchas veces se gasta demasiado tiempo y recursos en cambiar la documentación de la planificación para que se parezca al código. Para evitar esto, XP intenta implementar una forma de trabajo donde se adapte fácilmente a las circunstancias.
Básicamente consiste en trabajar estrechamente con el cliente, haciendo pequeñas iteraciones (mini-entregas), cada dos semanas, donde no existe mas documentación que el código en si; cada versión contiene las modificaciones necesarias según el cliente vaya retroalimentando el sistema (por eso es necesaria la disponibilidad del cliente durante todo el desarrollo).
Para suplir la falta de requisitos, casos de uso, y demás herramientas; XP utiliza historias de usuarios, la historia de usuario es una frase corta que representa alguna función que realizara el sistema. Cada historia de usuario no puede demorar en desarrollarse mas de una semana, si así lo requiera, debe segmentarse.
Es requisito para XP definir un estándar en el tipo de codificación, esto hace que los programadores tengan definido ya el estilo de programación y no que cada uno programe a su estilo.
Los programadores trabajan en parejas (dos por cada maquina) intercambiándose en el tipeo, esta interesante forma de trabajar tiene ventajas como:
* Detectar mas fácilmente los errores de programación (el programador libre controla al que tipea);
* El programador poco experimentado aprende del que mas lo esta.
* Si una pareja consigue desarrollar algún trozo de código
reutilizable, se comunica mas fácilmente a los otros programadores.
El testing en cada iteración es más que importante; de eso se trata este paradigma de programación, corregir mientras se programa. De esta forma se van cubriendo todos los baches que cada versión padezca.
El código no es de nadie, todo el equipo puede manipular el código que existe, de esta forma cada pareja puede mejorar cada sección de código que utiliza, esto requiere de un testing del mismo y la re-implementación en el sistema general.
Cada dos semanas se entrega una versión al cliente, que lo verifica, realiza el feedback y se continúa el desarrollo; este ciclo continua hasta que el sistema cumpla con las expectativas del cliente, acto que concluirá el proyecto.
No existe documentación del proyecto (para mi, el talón de Aquiles de este modelo) lo que mas se acerca a la documentación son las historias de usuario, pero al concluir el proyecto se descartan. Inclusive se recomienda hacer dos secciones, una con todas las historias de usuario que faltan desarrollar, y otra donde se archiven las concluidas, esto aproximara el estado de avance del proyecto.
Esquema del modelo de proyecto XP
fuente: http://www.extremeprogramming.org
Para mi punto de vista, este modelo puede ser exquisitamente viable en proyectos chicos, en sistemas donde no existan muchos riesgos de implementación (inclusive menor a lo que le da la escala escala SCRUM) y en donde el equipo de trabajo no sea muy grande.
Además la ausencia de documentación hace que el mantenimiento del sistema (realizado por otro equipo de trabajo) sea muy engorroso y dificil. (ya plantee esta cuestion en el wiki de XP, aver que resulta)
