SCRUM : Gains de productivité avec la programmation eXtreme

Depuis quelques années, plusieurs auteurs du Manifeste Agile ont discuté du Scrum en tant qu'enveloppe de processus pour les processus XP. Son introduction dans une nouvelle équipe peut être rapide et facile, et les processus d'ingénierie XP peuvent être adoptés au fil du temps, au fur et à mesure que l'équipe s'adapte. De plus, Scrum a une stratégie de mise à l'échelle qui a fonctionné à plusieurs reprises sur de grandes implémentations, alors que les approches d'ingénierie XP sont plus clairement visibles dans une petite équipe.

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.

Bien que 2545 lignes de code ne soient pas très utiles pour la plupart des projets commerciaux, ayant passé 13 ans dans une incarnation précédente sur des logiciels de recherche en analyse numérique et en statistiques, je sais que quelques lignes de code peuvent incorporer de nombreuses années-personnes de connaissances durement acquises. Considérez que ce petit morceau de code "fournit un banc d'essai logiciel pour évaluer les performances d'un schéma numérique permettant de résoudre un problème d'advection-diffusion modélisé. Le modèle utilise une stratégie de Runge-Kutta à plusieurs étapes pour l'évolution temporelle avec un séquençage multigrille. La caractéristique particulière de la recherche algorithmique est une stratégie d'optimisation ponctuelle des coefficients de Runge-Kutta pour obtenir des caractéristiques d'amortissement particulières en tant qu'outil d'accélération de la convergence".

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.