Newsletter Developpez.com

Inscrivez-vous gratuitement au Club pour recevoir
la newsletter hebdomadaire des développeurs et IT pro

Etes vous Scrum ou eXtreme Programming ?
Le débat fait rage dans la communauté Agile

Le , par Gordon Fowler, Expert éminent sénior
Etes-vous Scrum ou eXtreme Programming ?

Depuis quelques temps, le monde Agile semblent s'être scindé en deux. Et le débat fait de plus en plus rage sur la toile.

Certains pensent pourtant que cette dispute n'aurait pas lieu d'être.
Chaque méthode n'aurait pas le même objet ni le même but.

Scrum s'occuperait par exemple principalement de la gestion de projet :


Scrum – Image Wikipedia

Tandis que l'eXtreme Programming (XP) ne regarderait que l'activité de développement :


Cycle de XP – Image Wikipedia

Pourtant ce débat pourrait être révélateur d'une certaine évolution – positive - de la communauté Agile.

Quel est ce débat ?

Un "évangéliste" Agile, Tobias Mayer, vient écrire noire sur blanc qu'il "ne faut pas utiliser XP" (en vo : "Don't Do XP"). Scrum se suffirait à lui même, point ne serait besoin de lui rajouter l'eXtreme Programming... sauf à aimer la lourdeur.

Steve Freeman, un "avocat de XP" comme il se définit lui-même, ne l'entend pas de cette oreille et le fait savoir dans sa réponse au billet de Mayer : "accuser XP de bloquer les bonnes pratiques est just bizarre […] L'eXtreme Programming a donné à des équipes un ensemble de pratiques fiables qui ont parfaitement marché. Bien sûr, XP n'a pas révolutionné le monde parce qu'il ne convient pas à tous, notamment parce qu'il exige un degré de concentration et de compétences que de nombreuses équipes n'ont pas".

Ce qui est déjà en soit, une critique de XP.

Mais Steve Freeman, s'il ne voit pas XP comme la solution à tous les problèmes, pense surtout que Scrum est pratiquement inutile : "Tobias écrit que les bonnes pratiques de développement se répandaient doucement, mois je rétorque que sans XP on y serait encore. […] Je suspecte la plupart des équipes [Scrum] de ne jamais accepter de changer le code à moins que ce ne soit pour ajouter une fonctionnalité […] J'ai vu assez d'équipes qui utilisaient la méthode Scrum qet ui n'avaient aucun ensemble de pratiques cohérentes. […] ce qui pose la question de la limite de l'auto-gestion".

Derrière la virulence, Yves Hanoulle, programmeur, entrepreneur et coach spécialisé dans les méthodes Agiles, croit déceler dans ce débat l'émergence d'une nouvelle forme de maturité, pleine de promesses mais également d'incertitudes.

Pour lui, la communauté Agile est entrée dans la deuxième phase du cycle de développement (au sens biologique du terme) de Bruce Tuckman, cycle qui présuppose que tout groupe passe par quatre étapes successives : l'apprentissage / l'affrontement des idées / l'acceptation / l'étape de la performance pure.

"Il semblerait que les débats [sur les méthodes agiles comme pratique dans industrie IT] se multiplient. Pour moi, c'est la première fois que cela arrive avec cette intensité. […] Cela me rappelle beaucoup la phase d'affrontement du cycle de vie des équipes […] Donc d'un point de vue de coach je trouve que ces discussions, et là où elles nous mènent, sont vraiment très intéressantes. De plus dans ces débats, il n'y a pas clairement de leader. Ou pour exprimer ma véritable pensée : il n'y a pas encore de leader" écrit-il sur son blog.

Yves Hanoulle, qui est également un auteur modéré, insiste énormément sur le contexte. Pour lui, il n'y a pas de vérité absolue sur le sujet "Scrum contre XP". Des équipes ont commencé avec Scrum et ont réussi. D'autres l'ont fait avec XP.

Et beaucoup ont échoué avec les deux méthodes.

En fait, Scrum ou XP, la leçon importante semble être qu'il ne faut jamais oublier que les méthodes Agiles sont fondées sur l'apprentissage par l'expérimentation et, surtout, que toutes ses pratiques et recommandations doivent rester des moyens.

Jamais des fins.

Ce qui ne retire en rien à la question de savoir, dans cette phase "d'affrontement" très féconde, dans quel camp vous vous situez.

Sources :

Le Débat Scrum vs XP
Le billet de Tobias Mayer Don' Do XP
La Phase d'affrontement dans le monde Agile sur le blog de Yves Hanoulle

Lire aussi :

La rubrique Conception (actu, tutos, forums) et le forum Méthodes Agiles de Développez.com

Méthodes Agiles : Peut-on à la fois être Scrum master et développeur sur un même projet ?

Et vous ? :

Etes vous plutôt Scrum ou plutôt eXtreme Programming ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de mongeolive mongeolive - Membre à l'essai http://www.developpez.com
le 03/11/2009 à 8:46
Citation Envoyé par h472009  Voir le message
Ce que je connait a propos de l'eXtreme programming c'est qu'elle se concentre plus sur la rapidité de production, en réduisant la longueur du cycle de developpement.

Mais, cette vision est implementé dans les société (selon mon expérience) en reduisant surtout le temps de la conception/rédaction des specs, ce qui en fin de compte (surtout pour les grands projets) rend le code tenataculeux, difficile a maintenir, et parfois même, ne correspond pas aux besoins des utilisateurs

Typiquement, il s'agit là pour moi d'une mauvaise compréhension et d'une mauvaise application de l'eXtreme Programming, qui essaye de calquer les méthodes d'XP sur un cycle en V ou un développement en cascade classique.

XP est une méthode agile, et ne contient donc pas à proprement parler de phase de rédaction de spécifications ou de conception, puisque ces préoccupations sont prises en compte tout au long de la vie du projet. Ceux qui croient que XP c'est une cascade sans spécifications ni conceptions, se trompent lourdement. XP, ce n'est pas juste une phase de codage, ça c'est la définition que peuvent en donner les gens qui n'ont jamais lu Kent Beck ni aucun ouvrage sur XP.

Si le code devient tentaculeux et difficile à maintenir, alors c'est que XP n'est pas appliqué. Idem, si le code ne correspond pas aux besoins des utilisateurs, alors XP n'est pas appliqué. Ce n'est pas XP, c'est tout simplement autre chose (un gros foutoir à mon avis).

J'en ai déjà vu des chefs de projet et des responsables qualité qui croyaient tout savoir sur XP sans jamais avoir étudié la méthode. Un bon conseil : lisez Kent Beck, vous saurez enfin réellement ce que c'est que l'eXtreme Programming, et vous en apprendrez beaucoup sur les objectifs et les principes des méthodes agiles en général.

Je suis désolé de la réaction, mais de voir que des poncifs de ce genre puissent encore exister à propos des méthodes agiles ça me met hors de moi (c'est du vécu ).
Avatar de Patriarch24 Patriarch24 - Membre expérimenté http://www.developpez.com
le 05/11/2009 à 11:55
Je pense juste qu'il faut eviter de choisir une méthode comme SCRUM si on sait d'avance que le CDC est instable. A l'inverse, il faut éviter de choisir une méthode comme XP si on sait d'avance qu'on doit garantir une date de sortie.

Faux. Dans un cas comme dans l'autre, l'ensemble des exigences n'est pas fixé (méthode agile). Quant à la date de sortie, bien sûr qu'elle peut être fixée, dans ce cas c'est l'ensemble de fonctionnalités implémentées qui change.

Les méthodes agiles se basent sur plusieurs paramètres pour ajuster la composition du produit livré. C'est un type de méthode où l'organisation est bien plus importante que le process en lui-même.

Pour en revenir à la question initiale, j'ai voté Autres. Les deux méthodes utilisées ensembles forment, à mon avis, un outillage puissant en terme de gestion de projet (Scrum) + développement (XP). À chacun de modeler son process selon ses besoins.
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 05/11/2009 à 12:12
Citation Envoyé par Patriarch24  Voir le message
Faux. Dans un cas comme dans l'autre, l'ensemble des exigences n'est pas fixé (méthode agile). Quant à la date de sortie, bien sûr qu'elle peut être fixée, dans ce cas c'est l'ensemble de fonctionnalités implémentées qui change.

Je n'ai jamais dit que c'etait une obligation. Je dis juste que ces 2 processus ne sont pas centrés sur le meme probleme. Il suffit de regarder les 2 images du post #1.

SCRUM :
  • mélée quotidienne
  • Sprint 3 ou 4 semaines
  • Produit potentiellement livrable


XP :
  • Scénarii utilisateur
  • scénarii de test
  • nouveau scénario utilisateur
  • approbation client
  • spécification


SCRUM est un process centré sur la "livraison dans les temps", alors que XP est centré sur la "gestion du contenu". C'est une observation objective.
Avatar de h472009 h472009 - Membre habitué http://www.developpez.com
le 10/11/2009 à 10:41
Citation Envoyé par mongeolive  Voir le message
Typiquement, il s'agit là pour moi d'une mauvaise compréhension et d'une mauvaise application de l'eXtreme Programming, qui essaye de calquer les méthodes d'XP sur un cycle en V ou un développement en cascade classique.

Peu être que c'est vrai, mais a ma vision des choses, faire de la conception au fur et a mesure de développement peut agir mal sur la qualité du produit.
Citation Envoyé par mongeolive  Voir le message
XP est une méthode agile, et ne contient donc pas à proprement parler de phase de rédaction de spécifications ou de conception, puisque ces préoccupations sont prises en compte tout au long de la vie du projet. Ceux qui croient que XP c'est une cascade sans spécifications ni conceptions, se trompent lourdement. XP, ce n'est pas juste une phase de codage, ça c'est la définition que peuvent en donner les gens qui n'ont jamais lu Kent Beck ni aucun ouvrage sur XP

Peut etre Kent Beck donne une autre definition, mais beaucoup d'autres livres et auteurs, voient en XP un developpement qui ne donnent aucune importance à la coception/rédaction des spéc, voire même de conseiller d'eviter une telle approch, alors qui croire??!!!!
Citation Envoyé par mongeolive  Voir le message
Si le code devient tentaculeux et difficile à maintenir, alors c'est que XP n'est pas appliqué. Idem, si le code ne correspond pas aux besoins des utilisateurs, alors XP n'est pas appliqué. Ce n'est pas XP, c'est tout simplement autre chose (un gros foutoir à mon avis).

peut être que c'est vrai...mais pourquoi cela arrive beaucoup lors de l'application de l'XP??!!!
Citation Envoyé par mongeolive  Voir le message
J'en ai déjà vu des chefs de projet et des responsables qualité qui croyaient tout savoir sur XP sans jamais avoir étudié la méthode. Un bon conseil : lisez Kent Beck, vous saurez enfin réellement ce que c'est que l'eXtreme Programming, et vous en apprendrez beaucoup sur les objectifs et les principes des méthodes agiles en général.

et moi aussi j'en connait beaucoup, voire la plupart d'eux, qui ne croient pas à une telle approche, mais je te promet que je vais lire ce que dit Beck de l'XP (j'ai déjà procuré son livre "Extreme Programming Explained: Embrace Change ", peut être qu'il pourra me convaincre
Citation Envoyé par mongeolive  Voir le message
Je suis désolé de la réaction, mais de voir que des poncifs de ce genre puissent encore exister à propos des méthodes agiles ça me met hors de moi (c'est du vécu ).

il n'y a pas de quoi, on est là pour discuter et apprendre plus chacun de l'autre, et je te promet, une fois le livre lu, si ma vision est fausse, je vais l'avouer et voire te remercier
Avatar de rad_hass rad_hass - Membre expérimenté http://www.developpez.com
le 10/11/2009 à 11:23
Citation Envoyé par h472009  Voir le message
Peu être que c'est vrai, mais a ma vision des choses, faire de la conception au fur et a mesure de développement peut agir mal sur la qualité du produit.

Ah bon ? Je serais curieux que tu m'explique comment il peut nuire à la qualité du produit, si une vrai conception est mise en place.

Le problème d'un cycle classique en V c'est qu'on fait une conception initial sur un besoin qu'on croit fixe et fini dans le temps, en ignorant toute problématique qui se présentera dans le future ... Alors que d'accepter qu'on ne peut pas dicter la conduite d'un projet de A à Z avant d'avoir commencer, c'est se donner la liberté de faire évoluer l'architecture, la conception et l'implémentation du projet ... Et ceux pour mieux répondre au besoin du client, du projet et des problématiques qu'on rencontre ...

Es tu d'accord qu'un projet se construit en amant, pendant et même après son implémentation ?
XP ne dit pas qu'il ne faut pas faire de la conception, il dit que comme la conception est une étape importante d'un projet, on le fera tout le temps ...
Ne pas faire de la conception c'est ne pas pratiquer XP.

Citation Envoyé par h472009  Voir le message
peut être que c'est vrai...mais pourquoi cela arrive beaucoup lors de l'application de l'XP??!!!

Qu'entends tu de l'application de l'XP ?
A 10%, à 20% à 50% ou à 100% ? Combien de ces équipes faisait un refactoring régulier de l'application ? Combien avait une couverture de code supérieur à 60% par le test ? Combien pratiquer un vrai développement itératif et incrémental ?
Avatar de h472009 h472009 - Membre habitué http://www.developpez.com
le 10/11/2009 à 12:28
Citation Envoyé par rad_hass  Voir le message
Ah bon ? Je serais curieux que tu m'explique comment il peut nuire à la qualité du produit, si une vrai conception est mise en place.

Je pense que cela nous permettra moins de gérer l'interaction entre les différents modules conçus, car on aura pas une vision global sur le tout, et l'équipe de test/intégration aura beaucoup de boulot a faire, et surtout beaucoup d'allées/retours, pour garantir la maturité du produit.

Citation Envoyé par rad_hass  Voir le message
Qu'entends tu de l'application de l'XP ?
A 10%, à 20% à 50% ou à 100% ? Combien de ces équipes faisait un refactoring régulier de l'application ? Combien avait une couverture de code supérieur à 60% par le test ? Combien pratiquer un vrai développement itératif et incrémental ?

là tu as raison, dire que j'applique une méthode, ou je suis certifié telle certif, ne veux absolument pas dire que tu respecte dans tous tes projets l'intégralité des processus de cette méthodologie.

En tout les cas, je me documenterai plus a propos de l'XP, afin de voire de prés comment ses auteurs prévoientt réellement le cycle de vie du projet...en attendant portez vous bien
Avatar de Heziva Heziva - Membre régulier http://www.developpez.com
le 10/11/2009 à 13:48
Bonjour,

Il y a un passage qui me fait bondir quand je te lis...
l'équipe de test/intégration aura beaucoup de boulot a faire

L'xp recommande l'intégration continue et le test driven developpement. J'ai du mal à comprendre comment tu applique XP avec une équipe de test/intégration séparée. A moins que ce soit elle qui ait la charge de détailler les specs et d'écrire les tests de recette automatisés.

L'approche "bottom-up" d'xp est souvent critiquée, expliquant que cela mène à une architecture incohérente. C'est vrai, chaque pratique d'XP prise indépendamment a de gros défauts. Pour éviter cette explosion, xp propose :
- Intégration continue
On ne repousse pas l'intégration d'une fonctionnalité. On l'intègre dès que possible. Comme celle ci est testé automatiquement, il ne doit pas y avoir de régression forte.
- Keep It Simple and Stupid (ou You Ain't Gonna Need It)
On garde le code le plus simple possible. Aucune duplication n'est acceptée.
- Constant refactoring
Test Driven Developpement, c'est test, code, refactor. On refactorise à chaque étape, pour s'assurer de garder un tout cohérent. C'est peut être ici que la valeur "Courage" est la plus marquée.
- Pair programing et Collective Code Ownership
Pour s'assurer que toute partie du code est strictement simple, on effectue une revue de code permanente.

Ces pratiques ont également des défauts, qui sont compensés par d'autres pratiques. La première chose qui bloque rapidement lors de l'adoption d'XP, c'est souvent les cycles de développements très courts qu'elle adopte. On se retrouve rapidement avec de nombreuses régressions. On se rend compte que l'intégration n'est pas continue et que les tests ne sont pas si automatisés que ça...
Avatar de lepinekong lepinekong - Membre actif http://www.developpez.com
le 07/01/2010 à 22:52
Citation Envoyé par pseudocode  Voir le message
Bien sur, on peut toujours adapter les process, que ce soit SCRUM ou XP.

Mais tout de meme, SCRUM est basé sur l'existence d'un Backlog "Produit" (sous entendu complet) qui va être trié par priorité. Donc toute modification sur le CDC produit va necessiter de modifier le backlog, et potentiellement de devoir recoder certaines parties du logiciel qui ont déjà été codées. On se rapproche de l'idée de "constant refactor" de XP.

Je pense juste qu'il faut eviter de choisir une méthode comme SCRUM si on sait d'avance que le CDC est instable. A l'inverse, il faut éviter de choisir une méthode comme XP si on sait d'avance qu'on doit garantir une date de sortie.

La prémisce même de toute méthode agile, quelle qu'elle soit, est justement de s'opposer au Waterfall en disant que les requirements ne peuvent pas être connus à l'avance. Le Backlog Produit n'a pas à être complet, on doit tendre à ce qu'il soit le plus complet possible car Manager par définition c'est Gérer et Gérer c'est Prévoir. Les Stakeholders du Projet qui tiennent le porte-monnaie sont essentiellement intéressés par le coût / délai. Ce n'est pas parce que c'est agile qu'on a l'éternité
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 07/01/2010 à 23:45
Citation Envoyé par lepinekong  Voir le message
La prémisce même de toute méthode agile, quelle qu'elle soit, est justement de s'opposer au Waterfall en disant que les requirements ne peuvent pas être connus à l'avance.

Les 2 méthodes XP et Scrum s'inspirent de l'enchainement Besoin->Exigence->Design->Code->Test du Waterfall. L'agilité vient du fait que ces 2 méthodes font des boucles "très courtes" et "corrigent le tir" avant de faire la boucle suivante

Les Exigences sont forcément connues à l'avance, sinon comment faire pour coder ?

Mais c'est vrai qu'il n'est pas nécessaire d'avoir l'intégralité des besoins/exigences pour coder. Cela dit, on accepte le risque que l'arrivée de nouveaux besoins/exigences puisse bouleverser le projet (architecture, planning, ...)
Avatar de lepinekong lepinekong - Membre actif http://www.developpez.com
le 08/01/2010 à 0:40
Citation Envoyé par pseudocode  Voir le message
Les 2 méthodes XP et Scrum s'inspirent de l'enchainement Besoin->Exigence->Design->Code->Test du Waterfall. L'agilité vient du fait que ces 2 méthodes font des boucles "très courtes" et "corrigent le tir" avant de faire la boucle suivante

Le Manifeste Agile s'oppose explicitement à la méthode Waterfall: ils avaient même créé un site de parodie contre. En vérité la méthode Waterfall n'a jamais existé (je ferai un article là-dessus mais ceux qui ont lu l'article originel de l'auteur devrait le relire). La philosophie du Waterfall est 0 BOUCLE: tout en ligne droite, on est capable de tout planifier et figer après chaque étape. A la rigueur le cycle en V c'est UNE boucle parce que la remontée du cycle en V permet des corrections. Mais une boucle c'est très insuffisant, il faut n boucles.

Les méthodes agiles admettent fondamentalement l'incertitude, le waterfall la nie. Pour image un peu tiré par les cheveux sans doute dire que l'une s'inspire de l'autre c'est comme si tu disais la mécanique quantique s'inspire de la mécanique de Newton alors que la mécanique quantique introduit le principe d'incertitude
Avatar de pseudocode pseudocode - Rédacteur http://www.developpez.com
le 08/01/2010 à 9:28
Citation Envoyé par lepinekong  Voir le message
Le Manifeste Agile s'oppose explicitement à la méthode Waterfall: ils avaient même créé un site de parodie contre. En vérité la méthode Waterfall n'a jamais existé (je ferai un article là-dessus mais ceux qui ont lu l'article originel de l'auteur devrait le relire). La philosophie du Waterfall est 0 BOUCLE: tout en ligne droite, on est capable de tout planifier et figer après chaque étape. A la rigueur le cycle en V c'est UNE boucle parce que la remontée du cycle en V permet des corrections. Mais une boucle c'est très insuffisant, il faut n boucles.

Les méthodes agiles admettent fondamentalement l'incertitude, le waterfall la nie. Pour image un peu tiré par les cheveux sans doute dire que l'une s'inspire de l'autre c'est comme si tu disais la mécanique quantique s'inspire de la mécanique de Newton alors que la mécanique quantique introduit le principe d'incertitude

Je ne sais pas l'experience que tu as dans le domaine du dev logiciel.

Personnellement, je n'ai jamais rencontré de méthodologie qui permette de coder sans avoir réfléchi au préalable a la structure du code (design). Cette structure émanant d'une vue d'ensemble du programme (architecture). Cette vue d'ensemble répondant à des exigences fonctionnelles (specification). Ces exigences fonctionnelles permettant l'accomplissement de scénarios (besoins).

J'ai beau regarder tous les documents sur les méthodologies agiles, aucune ne contredit ce que j'ai marqué ci-dessus. Pour moi, ces méthodologies révolutionnent surtout la "gestion de projet", et pas tellement celle d' "analyse et conception". D'ailleurs, à la lecture de ton message je vois que tu parles surtout du "processus projet".
Offres d'emploi IT
Architecte / expert microsoft H/F
Sogeti France - Rhône Alpes - Lyon, Grenoble
Testeurs techniques h/f
Sogeti France - Rhône Alpes - Lyon (69000)
Développeur php h/f
SENSIOLABS - Ile de France - Clichy (92110)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil