Etes vous plutôt Scrum ou eXtreme Programming ? [Débat]

Waterfall

===>[]

Idem, je ne comprends pas cette idée de vouloir opposer à tout prix Scrum et XP. Scrum est tout à fait complémentaire aux pratiques d'ingéniérie décrites dans XP, qu'on soit conscient de faire de l'XP ou pas quand on les pratique. D'ailleurs la troisième réponse du sondage pourrait être "Scrum et XP (dans le même projet)".

Pour l'anecdote, il faut tout de même noter qu'XP inclut des pratiques de gestion de projet ET des pratiques d'ingénierie alors que Scrum est un framework qui ne s'occupe que de conduite de projet/produit informatique.

PS : on écrit eXtreme programming et non pas eXtrem comme on le voit souvent

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.

Pour moi, c'est le résumé.

Quelqu'un sans talent et sans volonté fera le meme (mauvais) travail quelque soit la methode ; de meme quelqu'un qui applique betement un process.

Il n'existe pas de process magique qui va faire disparaitre les risques sans prises de décisions.

Concernant XP vs Scrum, XP est résolument orienté developpement logiciel tandis que Scrum est veritablement independant du domaine (meme si on en parle le plus souvent dans le cadre du developement logiciel). On peut les opposer mais si on le fait, c'est pour le sport plutot que pour en retirer un benefice quelconque dans un projet...

Opposer XP et Scrum ? Je ne suis pas sur que le débat soit réel. Il manque très certainement une case "Je fais les deux sur le même projet". Qui doit probablement correspondre à beaucoup d'équipes Scrum.

Scrum est un ensemble de pratiques de pilotage de projet. On créé les histoires utilisateurs, on les priorise, puis on les organise en sprint. Plusieurs réunions sont préconisées. L'équipe est auto-gérée.

XP est un ensemble de pratiques de développement. You Ain't Gotta Need It (ou Keep It Simple and Stupid) vous indique de ne pas faire de "réutilisable". XP impose le Test Driven Developpement. Avoir une intégration en continue fait partie de la méthode. Certes, XP propose également le "Planning game", qui peut marcher sur les plates bandes de Scrum, mais ce n'est pas obligatoire.
XP pousse à l'extrême des pratiques de bon sens. Cette méthode propose un package de pratiques qui compensent les défaut les unes des autres.

XP ou Scrum ou les deux. Là est plus la question. D'ailleurs, le "don't do XP" exprime simplement le fait que, selon l'auteur, suivre un package de pratiques qui n'ont pas évolués depuis 12 ans est une mauvaise idée. Il faut inspecter pour trouver les bonnes pratiques qui vous correspondent. Il faut inventer votre XP à vous...

Pour moi, Scrum et XP sont deux cycles de vie de développement, mais leur approche (et leur finalité) sont différentes:

- Scrum à une approche temporelle du développement : ce qui reste à faire, ce qui est en cours, ce qui est terminé.

- XP à une approche fonctionnelle du développement : le produit que le client souhaite avoir, le produit que l'équipe a développé, les modifications à apporter.

En conséquence, Scrum est adapté si la gestion de projet est conduite par le délai. En contre-partie, il faut avoir un cahier des charges (backlog) clair dés le départ (minimum de modif pendant le developpement). XP est adapté si la gestion de projet est conduite par les demandes du client. En contre-partie, le délai de la livraison finale est incertain (dépendant des demandes et des refactors necessaires)

Bref, c'est plus une problématique de contraintes de gestion de projet qu'une problématique sur les méthodes.

Envoyé par Heziva

You Ain't Gotta Need It (ou Keep It Simple and Stupid) vous indique de ne pas faire de "réutilisable".

Ce n'est pas tout à fait ce que je comprends de "You Ain't Gotta Need It". L'explication donnée pour cette pratique est :
"Always implement things when you actually need them, never when you just foresee that you need them."

Soit :
"Implémentez toujours les choses dont vous avez besoin immédiatement, et pas quand vous envisagez d'en avoir besoin plus tard".

XP ne dit pas de ne pas faire de "réutilisable", mais simplement de ne pas faire ce dont vous n'avez pas besoin immédiatement. J'insiste sur ce point, car j'ai vu de nombreuses personnes qui ne connaissent pas la méthode se méprendre sur XP, en pensant qu'il s'agit de "coder salement, coder rapidement" et surtout sans jamais rien concevoir.

Je pense que ce n'est pas du tout le cas. Au contraire, XP insiste sur une très haute qualité du code produit et des pratiques qui permettent de conserver cette qualité comme le refactoring. Penser qu'XP encourage le développement sale et rapide, ou sans conception, est pour moi une erreur.

Des pratiques de modélisation rapide pour les méthodes agiles existent : http://www.agilemodeling.com/.
Il ne s'agit évidemment pas de pondre des documents de conception de 300 pages, mais plutôt de réaliser des conceptions rapides pour les éléments de développement de l'itération en cours.

En ce qui concerne Scrum et XP, je pense aussi qu'il est préférable de retirer de ces pratiques les meilleurs éléments pour des projets spécifiques. Je ne comprends pas qu'il puisse exister une "guerre" entre ces méthodes, qui me semblent assez similaires sur certains points et complémentaires sur d'autres.

Bonjour,

Moi je ne trouve aucune raison intéressante d'opposer l'une et l'autre des méthodologies, je pense qu'il faut simplement être agile dans le choix des pratiques à utiliser

Envoyé par pseudocode

Pour moi, Scrum et XP sont deux cycles de vie de développement, mais leur approche (et leur finalité) sont différentes:

- Scrum à une approche temporelle du développement : ce qui reste à faire, ce qui est en cours, ce qui est terminé.

- XP à une approche fonctionnelle du développement : le produit que le client souhaite avoir, le produit que l'équipe a développé, les modifications à apporter.

En conséquence, Scrum est adapté si la gestion de projet est conduite par le délai. En contre-partie, il faut avoir un cahier des charges (backlog) clair dés le départ (minimum de modif pendant le developpement). XP est adapté si la gestion de projet est conduite par les demandes du client. En contre-partie, le délai de la livraison finale est incertain (dépendant des demandes et des refactors necessaires)

Bref, c'est plus une problématique de contraintes de gestion de projet qu'une problématique sur les méthodes.

Je trouve intéressante ton analyse, mais ce qui me pose problème c'est le fait de dire que SCRUM n'est pas adapté avec une gestion de projet qui est conduite par les demandes du client, je pense que la participation du Product owner dans le projet et le fait que le backlog n'est pas dans un état figé mais que le product owner peut le faire évoluer, font que SCRUM n'est pas incompatible avec cette approche.

Envoyé par rad_hass

Je trouve intéressante ton analyse, mais ce qui me pose problème c'est le fait de dire que SCRUM n'est pas adapté avec une gestion de projet qui est conduite par les demandes du client, je pense que la participation du Product owner dans le projet et le fait que le backlog n'est pas dans un état figé mais que le product owner peut le faire évoluer, font que SCRUM n'est pas incompatible avec cette approche.

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.

eXtreme programming est une methode qui ne croit pas a la conception...chose que je voit trés mal en tant que qualiticien...

Scrum est bonne, mais je préfere la CMMI, elle est meilleur et concerne toutes les processus du cycle de developpement du logiciel.

Envoyé par pseudocode

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.

Bien que je suis d'accord avec toi, je pensais que le fait d'avoir un backlog qui évolue dans le temps, surtout en terme de nouvelles entrées n'était pas une condition d'échec, et qu'il était tout de même possible de l'adapter. Donc pour toi ce n'est pas acceptable qu'on est un backlog de produit qui n'est pas fini et qui peut être compléter au fur et à mesure ?

Imaginons un projet dans lequel on fait des évolutions par lots (un projet sur plusieurs années) et que le besoin du client évolue d'années en années (disant même tout les 6 mois, ce qui n'est pas choquant pour du Web et quand on a plusieurs pays et plusieurs clients potentiels en cible), SCRUM serait inadapté ? Ou peut être adapté à ce contexte ?

Envoyé par h472009

eXtreme programming est une methode qui ne croit pas a la conception...chose que je voit trés mal en tant que qualiticien...

Qu'est ce qui te pousse à dire cela ?

Envoyé par rad_hass

Bien que je suis d'accord avec toi, je pensais que le fait d'avoir un backlog qui évolue dans le temps, surtout en terme de nouvelles entrées n'était pas une condition d'échec, et qu'il était tout de même possible de l'adapter. Donc pour toi ce n'est pas acceptable qu'on est un backlog de produit qui n'est pas fini et qui peut être compléter au fur et à mesure ?
Imaginons un projet dans lequel on fait des évolutions par lots (un projet sur plusieurs années) et que le besoin du client évolue d'années en années (disant même tout les 6 mois, ce qui n'est pas choquant pour du Web et quand on a plusieurs pays et plusieurs clients potentiels en cible), SCRUM serait inadapté ? Ou peut être adapté à ce contexte ?

Non, je ne dis pas que ce n'est pas acceptable. Je dis juste qu'il n'est peut-être pas nécessaire de prendre (et adapter) un process de type SCRUM si tu n'es pas dans une approche "orienté délai".

Le fait que le produit dans SCRUM soit toujours "potentiellement livrable" est une contrainte très forte. Cette contrainte existe car le produit peut être commercialisé à tout moment, en particulier dès qu'on est dans la fenêtre d'opportunité (= fonctions+date).

Si tu n'as pas ce besoin de "livraison à tout moment", je ne vois pas l'intérêt de se poser une contrainte aussi forte de produit toujours "potentiellement livrable".

D'ou ma remarque : prendre un process qui correspond aux contraintes de gestion de projet. Ca implique d'avoir correctement identifié ces contraintes : date, complétude, qualité, performance, ...

Envoyé par rad_hass

Qu'est ce qui te pousse à dire cela ?

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

Je pense que le Scrum et Xprogramming peuvent cohabiter ensemble, mais par expérience, chaque entreprise à une manière de fonctionner qui fait que c'est très difficile de respecter cela ne serait-ce qu'a 80%. Pourquoi ? Il y a des paramètre extérieur, les clients, la politique IT, la structure qui fait que nous pouvons l'utiliser.
Personnellement, au boulot nous utilisons la méthode AGILE mais nous sommes confronter à des problèmes d'ordre effectif et politique de l'entreprise qui est mondial. Nous maitrisons pas tout (comme mon orthographe ) , donc nous sommes obligé d'utiliser une méthode un peut snake.

Envoyé par h472009

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 ).

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.

Envoyé par Patriarch24

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.

Envoyé par mongeolive

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.

Envoyé par mongeolive

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??!!!!

Envoyé par mongeolive

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??!!!

Envoyé par mongeolive

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

Envoyé par mongeolive

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