For some years now, several authors of the Agile Manifesto have discussed Scrum as a process wrapper for XP processes. It's introduction to a new team can be quick and easy, and XP engineering processes can be adopted over time as the team can adapt. Also, Scrum has a scaling strategy that has repeatedly worked on large implementations, whereas XP engineering approaches are most clearly visible in a small team.
Le numéro de mai/juin 2003 d'IEEE Software est consacré à XP. L'un des articles les plus intéressants concerne l'expérience d'une équipe de deux personnes qui a construit une application de 2445 lignes de code au centre de recherche Langley de la NASA, où l'on construit un logiciel de recherche gouvernemental en Ruby. Ruby combinant certaines des meilleures caractéristiques de Smalltalk et de Perl, c'est sans doute l'un des langages de programmation modernes les plus agréables et un changement majeur par rapport à la programmation en FORTRAN à laquelle ces chercheurs étaient habitués.
Wood, William A. et Kleb, William I. Exploring XP for Scientific Work. IEEE Software 20:3:30-36, mai/juin 2003.
While 2545 lines of code is not very useful for most commercial projects, having spent 13 years in a previous incarnation on research software in numerical analysis and statistics, I know a few lines of code may incorporate many person-years of hard won knowledge. Consider that this small piece of code "delivers a software test bed for evaluating the performance of a numerical scheme to solve a model advection-diffusion problem. The model employs a multistage Runge-Kutta strategy for temporal evolution with multigrid sequencing. The particular algorithmic research feature is a strategy for the pointwise optimization of the Runge-Kutta coefficients to achieve particular damping characteristics as a tool for convergence acceleration."
Le développeur commercial typique devrait passer quelques années sur un master pour être capable d'écrire ce type de code. Mais je m'éloigne du sujet. L'un des aspects les plus intéressants de cet article est que la paire de programmeurs a produit 912 lignes de code de production (le reste étant du code de test et des utilitaires) à un taux de 27 lignes par heure pour la paire. Dans les projets précédents, les programmeurs produisaient 12 lignes de code de production par heure, soit 24 pour une paire de programmeurs. Cependant, ils ont dû produire 2144 lignes de code pour atteindre le même niveau de fonctionnalité que l'application XP, soit plus de deux fois plus de code.
Dans ce projet, le remaniement incessant combiné aux avantages de Ruby par rapport à Fortran ont été des facteurs clés qui ont plus que doublé la productivité d'un projet de la NASA sur un projet initial avec un nouveau processus de développement et un nouveau langage. En moyenne, FORTRAN nécessite 107 lignes de code par point de fonction et Ruby se situe quelque part entre Perl (21) et Java (53). Je m'attends à ce que les gains de productivité soient encore plus élevés pour les projets futurs.
French 
English 
Spanish