Desde hace algunos años, varios autores del Manifiesto Ágil han hablado de Scrum como un proceso que envuelve los procesos XP. Su introducción a un nuevo equipo puede ser rápida y fácil, y los procesos de ingeniería XP pueden adoptarse con el tiempo a medida que el equipo pueda adaptarse. Además, Scrum tiene una estrategia de escalado que ha funcionado repetidamente en grandes implementaciones, mientras que los enfoques de ingeniería XP son más claramente visibles en un equipo pequeño.
El número de mayo/junio de 2003 de IEEE Software se centró en XP. Uno de los artículos más interesantes trata de la experiencia de un equipo de dos personas que construyó una aplicación de 2.445 líneas de código en el Centro de Investigación Langley de la NASA, creando software de investigación gubernamental en Ruby. Dado que Ruby combina algunas de las mejores características de Smalltalk y Perl, se puede decir que es uno de los lenguajes de programación modernos más agradables y un cambio importante respecto a la programación FORTRAN con la que estos investigadores estaban familiarizados.
Wood, William A. y Kleb, William I. Exploring XP for Scientific Work. IEEE Software 20:3:30-36, mayo/junio de 2003.
Aunque 2545 líneas de código no son muy útiles para la mayoría de los proyectos comerciales, después de haber pasado 13 años en una encarnación anterior en software de investigación en análisis numérico y estadística, sé que unas pocas líneas de código pueden incorporar muchos años-persona de conocimientos duramente ganados. Considere que esta pequeña pieza de código "ofrece un banco de pruebas de software para evaluar el rendimiento de un esquema numérico para resolver un problema modelo de advección-difusión. El modelo emplea una estrategia Runge-Kutta multietapa para la evolución temporal con secuenciación multigrid. La característica particular de la investigación algorítmica es una estrategia para la optimización puntual de los coeficientes Runge-Kutta para lograr características particulares de amortiguación como herramienta para la aceleración de la convergencia."
El típico desarrollador comercial necesitaría dedicar un par de años a un máster para poder escribir este tipo de código. Pero estoy divagando. Uno de los aspectos más interesantes de este trabajo es que la pareja de programadores produjo 912 líneas de código de producción (el resto era código de prueba y utilidades) a un ritmo de 27 líneas por hora para la pareja. En proyectos anteriores, los programadores producían 12 líneas de código de producción por hora, o 24 para una pareja de programadores. Sin embargo, tuvieron que entregar 2144 líneas de código para lograr el mismo nivel de funcionalidad que la aplicación XP, más del doble de código.
En el proyecto, la refactorización implacable combinada con las ventajas de Ruby sobre Fortran fueron consideraciones clave que más que duplicaron la productividad en un proyecto de la NASA en un proyecto inicial con un nuevo proceso de desarrollo y un nuevo lenguaje. Por término medio, FORTRAN requiere 107 líneas de código por punto de función y Ruby se sitúa entre Perl (21) y Java (53). Yo esperaría que en futuros proyectos pudieran aumentar aún más la productividad.
Spanish 
English 
French