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.
XP se suffit à lui même. On ne le répètera jamais assez !
Quelques remarques sur ta classification :
Sur XP seul, est-il vraiment lié au monde "objet fortement typé" ?
Je crois savoir qu'il est utilisé avec succès en Erlang (qui n'est pas objet).
Pour le faible typage, cela pose effectivement un problème de refactoring intensif cela ne me parait pas être une condition essentielle pour XP. J'ai fait du TDD et du refactoring en PHP. L'outillage n'est pas au niveau de ce que je connais par ailleurs en .NET mais cela reste pratiquable.
Sur Scrum seul, aux projets dominés par l'emploi d'outils de génération de code, je rajouterais les projets dominés par l'emploi de frameworks. Dans les 2 cas, soit les outils ou les frameworks intègrent les pratiques d'ingénierie attendues et tout va bien, soit ils ne les intègrent pas et là il vaut mieux s'en passer.
Plus généralement, on peut faire du Scrum seul quand la maitrise technique du projet peut être obtenue autrement (et plus facilement) que par la mise en oeuvre des pratiques d'ingénierie mises en avant par XP.
Rédigé par : Oaz | 11 mai 2009 à 10:34
Je vois plus Scrum comme un cadre méthodologique simple et volontairement "incomplet", dans le sens où les pratiques d'ingénierie logicielle ne sont pas spécifiées et sont laissées à l'appréciation de l'équipe suivant le contexte technique. Mais cela ne veut pas dire qu'on déclare Scrum comme auto-suffisant.
Quelque soit le langage, le framework, et plus généralement la chaîne de production logicielle, on ne peut pas échapper à la maîtrise de la qualité du code (donc des techniques garantissant le refactoring, la non-régression, la standardisation etc) sans quoi, on n'est plus agile du tout.
Il faut aussi préciser qu'on doit à Scrum, la vague de déploiement actuelle d'agilité. Il aurait suffit que les géniteurs d'XP le rebaptise afin d'éviter les réticences des décideurs parfois uniquement liées au nom provocateur de la méthode.
Enfin, je reste convaincu que Scrum et XP = meme combat, dans la mesure on applique les principes minimum permettant d'être factuellement agile.
Rédigé par : David Brocard | 17 mai 2009 à 15:24
Scrum fait un peu moins peur aux décideurs, et son programme de certification en fait une méthode "sérieuse" de leur point de vue.
Ceci étant effectivement Scrum est un framework, ses fondateurs affirment eux même qu'il faut le compléter avec les pratiques d'ingénieries adaptées au projet. D'où souvent le mix Scrum-XP, en prenant les bonnes pratiques de cette dernière.
Ceci étant, travaillant en PHP quotidiennement, je trouve les frameworks TDD très aboutis (PHPUnit et Simpletest), et surtout le faible typage n'est en rien un frein au remaniement, puisque ce sont les tests unitaires et non les automates de refactoring qui assurent la non-régression.
J'ai été surpris que le remaniement soit bloqué par l'absence d'un IDE le facilitant. Les pratiques avant l'outil me semble une notion très agile.
Cédric
Rédigé par : Cédric | 23 juin 2009 à 11:14
La dépendance du remaniement vis-à-vis de la nature typée/dynamique du langage considéré est une idée qui m'est soufflée par les grosses différences de "styles" de code que j'ai pu constater entre C++, C#/Java et Javascript, styles qui me semblent directement dépendant des outils.
En C++ où les classes et les méthodes sont à écrire deux fois (.h/.cpp en l'absence d'outils de refactoring), les classes comme les méthodes me semblent plus grassouillettes qu'en Java et C#.
En Javascript, je réfléchis à deux fois avant d'extraire une méthode ou de renommer une variable tant le risque d'amener des erreurs est grand en mode manuel (si un risque est non nul alors il est grand, corollaire de la loi de Murphy). C'est vrai les tests détecteront la régression s'ils sont complets, mais la différence avec les outils de refactoring Java/C# qui *garantissent* de laisser le code iso-fonctionnel est flagrante. Le remaniement n'est pas bloqué, il est plus ou moins freiné en fonction du courage du développeur. Ce qui prend 10 secondes en C#/Java coûte 3 minutes en javascript et amène des risques de régression : c'est un peu d'agilité perdue, sur la durée d'un projet ça compte beaucoup.
J'aimerais bien avoir le temps de confirmer/infirmer l'effet de la disponibilité d'outils automatique de remaniement sur le style du code en analysant la taille des méthodes et des classes de différents langages sur un large corpus de code, par exemple à partir de code.google.com.
Si quelqu'un se sent motivé...
Rédigé par : DenisDollfus | 23 juin 2009 à 22:29
En faveur des langages typés pour des projets d'envergure, il faut aussi considérer l'investissement considérable - et réussi - de Google dans Google Web Toolkit.
Rédigé par : DenisDollfus | 23 juin 2009 à 22:31