On lit souvent qu'XP et Scrum s'entendent comme larrons en foire parce qu'ils sont complémentaires, l'un comblant les lacunes de l'autre, et vice versa. L'expérience que j'ai de ces deux méthodologies et l'intérêt que je leur accorde me font dire que l'idée est consensuelle mais inexacte.
Scrum ♥ XP
Nouvelle matérialisation du consensus, le questionnaire sur les méthodes agiles en France publié par le Scrum User Group français fait apparaître la dichotomie habituelle. Scrum rassemblerait les techniques de gestion de projet (réunion d'itération, réunion brève quotidienne, etc.) et XP les techniques d'ingénierie logicielle (tests unitaires, intégration continue, etc.). L'alliance Scrum-XP serait alors la synergie idéale.
XP seul
La réalité est qu'XP possède ses propres pratiques de gestion de projet et n'a donc pas besoin de Scrum pour couvrir l'aspect management des développements. Les itérations courtes, les réunions de planification d'itération, la présence quasi permanente du client, le partage des connaissances entre membres de l'équipe sont autant de pratiques XP qui ne sont pas de l'ordre des pratiques d'ingénierie. Pour être clair :
Scrum seul
Réciproquement, il existe quantité de contextes dans lesquels Scrum n'a pas besoin de compléments XP. Scrum seul excelle dans des projets ou XP est hors sujet car fortement lié à des langages de programmation orientés objets et fortement typés.
Par exemple les tests unitaires chers à XP sont inapplicables en environnement RAD, quand le code est auto-validé au moment même où l'utilisateur (le développeur ?) finit son glisser-déplacer d'un champ de la base de donnée sur un formulaire en construction. Dans ce cas Scrum, lui, reste pertinent, comme plus généralement dans les projets dominés par l'emploi d'outils de génération de code.
Autre exemple, le refactoring intensif est une des pratiques clés d'XP. A chaque changement du code, qu'il soit évolutif ou correctif, le refactoring améliore l'architecture, facilite la maintenabilité du code et fondamentalement le maintient dans un état qui autorise les futures modifications ("embrace changes"). Or le refactoring (petits ou gros remaniements du code) devient délicat et dangereux quand les outils de refactoring automatique (e.g. extract method) ne peuvent plus épauler le développeur. Or les langages dynamiques, JavaScript en tête (et SmallTalk inclus), mettent les bâtons dans les roues à ces outils car certaines ambiguités de syntaxe ne peuvent être résolues qu'au runtime. Dans ce cas encore XP perd de son charme, pas Scrum.
Scrum plus libre qu'XP
En somme XP a une forte adhérence aux environnements de développement devenus standards que sont Java, C# et dans une moindre mesure car un peu plus résistant au refactoring, C++. Dans des contextes dominés par ces langages, faire de l'agile sans adopter les pratiques d'ingénierie d'XP, c'est se priver de ce qui maintient le code évolutif et léger, c'est un peu vouloir construire un building en mode agile…
En revanche dans d'autres contextes, non seulement Scrum se suffit à lui même, mais XP est out. C'est le cas des projets sur lequel le code n'est pas un élément central du système à construire, par exemple lorsque les outils sont graphiques, lorsque le code est généré ou lorsqu'il s'agit de paramétrer un progiciel (SAP, Reporting, CMS, etc.). Ou encore quand le projet comporte un degré d'innovation tel qu'il n'existe pas encore de bonnes pratiques reconnues, mais ça je l'ai déjà dit.
Les commentaires récents