Discussion :

[Arsene Newman]

L’esprit agile est-il en voie de disparaître ?
13 ans après la publication du manifeste agile, un développeur note l’échec des méthodes agiles

Tout professionnel de l’IT s’accorde à dire que le développement logiciel n’est pas une mince affaire. Par le passé, cela reposait essentiellement sur des méthodes et des processus de développement lourds, rigides et coûteux, qui conduisaient à des cycles de développement assez lents. En 2001 le manifeste agile a été publié. Ce dernier décrit une nouvelle approche, une nouvelle famille de méthodes de développement logiciel dites « méthodes agiles ».

Toutefois, ce manifeste décrit les grandes lignes pour des méthodes de développement axées sur le développeur, la collaboration étroite entre l’équipe de développement et le client ainsi que l’importance du feedback des utilisateurs.

13 ans plus tard, force est de constater que les méthodes agiles ont échoué. C’est en tout cas ce que pense Mike Hadlow, un développeur senior, dans un billet de blog. Mais alors pourquoi cet échec ? Une dérive, une incompréhension ou encore un abus serait à l’origine de l’échec, selon celui-ci.

Agile est en premier lieu un état d’esprit mettant au centre de la scène le développeur, chacun doit trouver son propre rythme en suivant un chemin balisé par des méthodes connues. Il ne s’agit donc pas de méthodes de management de l’équipe de développement ni de recourir d’une manière bête et disciplinée à certaines pratiques telles que les stand-up meeting journalier, à de courtes itérations de 2 semaines et à de micro deadlines trop rigides.

Une des conséquences de la mauvaise interprétation/application des concepts agiles est la désignation de chefs de projet non sensibles à l’aspect technique du développement logiciel, ces derniers étant alors initiés aux méthodes agiles en les considérant à tort comme des méthodes de management.

En effet quoi de mieux qu’un développeur pour en comprendre un autre ? Hors si les méthodes agiles se targuent d’être centrées sur le développeur et que le chef de projet n’est pas dans cette dynamique, cela conduira inévitablement à l’échec. Dans le cas contraire, cela relève de la chance ou d'autres facteurs, mais certainement pas de l’application d’une méthode agile.

Au final, il demeure clair que la réussite de la mise en œuvre d’une méthode agile passe en premier lieu par une bonne compréhension des aspects techniques du développement, de la capacité du chef de projet à sympathiser avec le développeur et à le motiver, faute de cela, les méthodes agiles subsisteront, mais l’esprit agile sera en perdition et finira par mourir.

Source : blog de Mike Hadlow

Et vous ?

Qu’en pensez-vous ?

[el_slapper]

Pas grand chose. En football, on se doute bien qu'aligner 11 chèvres avec la meilleure tactique du monde ne suffira pas à battre le PSG. En informatique, par contre, ça parait évident. Et, à la fin, c'est le PSG qui gagne.

Plus sérieusement(en en espérant ne pas voir des hordes d'antiparisiens venir m'étriper, à une époque, c'est l'OM qui était difficille à battre, à une autre l'OL, etc...), l'article pointé en lien est très bien. On est pas forçé d'être d'accord sur tout(il me semble un poil extrême sir les estimations), mais il me plait beaucoup, et il fait un état des lieux (hélas) fort précis. Sa liste à points est très interessante :

•(1)The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team.
•(2)The motivation and empowerment of programmers has a direct and strong relationship to the quality of the software.
•(3)Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.
•(4)The consequences of poor design decisions multiply rapidly.
•(5)It will usually take multiple attempts to arrive at a viable design.
•(6)You should make it easy to throw away code and start again.
•(7)Latency kills. Short feedback loops to measurable outcomes create good software.
•(8)Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy.
•(9)Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software.

Tous sont débatables, mais j'adore les points 3, 6 et 7. Que je vais réinterpréter en Français
(3) Les dates de livraisons en dur, spécialement quand elles sont innombrables, flinguent le projet. Perso, je peux comprendre qu'il faille livrer la gestion de l'Euro avant le 31 Décembre 2012. Mais quand une directrice de projet exige des preuves de progrès deux fois par jour, et par conséquent des respects de dates de livraisons systématiques et multiquotidiennes, on passe son temps à planifier, pas à bosser.
(6) Le code n'est pas sacré : il faut pouvoir tout balancer et tout recommencer sans avoir l'impression de se tirer une balle dans le pied. Mon opinion : on fait souvent fausse route, donc un demi-tour facile est essentiel.
(7) La latence tue. Des retours d'information rapides sont indispensables pour réaliser un bon projet. Toujours d'accord, toujours pour la même raison : on faut souvent fausse route, et mieux vaut s'en apercevoir au bout de 2 jours qu'au bout de 2 ans.

J'ajouterais juste qu'un manager non-technique peut être utile, mais à condition d'avoir parfaitement intégré son incompétence technique. Si il passe son temps à animer l'équipe, à chercher quels sont les obstacles et comment les aplanir, a vérifier que tout le monde reste dans le périmètre, et que globalement les gens avancent, alors il peut être très utile. J'en ai vu. Manque de pot, la plupart tentent de tout contrôler(pour asseoir leur pouvoir), et le résultat est celui décrit par le bloggueur.

[Traroth2]

Après avoir vu diverses tentatives plus ou moins honnêtes de mise en oeuvre de Scrum, force est de constater que c'est vrai. Le problème de base, c'est que l'agilité cherche à mettre le développeur au centre du processus de développement. Et ça, malheureusement, personne dans le management de la DSI, à fortiori de l'entreprise, n'en a envie. Le point de vue réel est de considérer les développeurs comme des pions interchangeables, des "ressources". Et là, en réalité, on est aux antipodes de l'agilité. Les méthodes agiles servent aussi de prétexte à tout un tas de mauvaises pratiques, par exemple l'absence de specs.

Typiquement : https://en.wikipedia.org/wiki/Avalanche_model

[transgohan]

J'en pense qu'Agile n'est pas prêt de disparaître du jour au lendemain.
Le seul problème de cette méthode c'est quand on ne joue pas le jeu.
Managers qui font du cycle en V, maitrise d'oeuvre qui fait du cycle en V et développeurs qui font de l'agile.
L'une des combinaison qui va faire échouer un projet...

Cela fait un an que nous avons quitté le cycle en V dans mon équipé pour partir sur de l'Agile (à la demande du PDG).
Nous avons vu de nombreuses améliorations de notre process et de notre qualité suite à l'application de ces méthodes.
Mais le boulet que l'on traîne c'est que les managers ont été formés après nous (voir pas du tout) et font toujours du cycle en V...
Et même s'ils sont formés ils n'adhèrent pas à la méthode car ils comprennent bien qu'ils ont un engagement qu'ils n'avaient pas avant...
Sont pas fous ! Si ça merde c'est leur faute maintenant.

Bref c'est le même principe que de tenter de parler chinois à un français.
S'il ne comprend pas le chinois c'est peine perdu...

Les méthodes agiles servent aussi de prétexte à tout un tas de mauvaises pratiques, par exemple l'absence de specs.

Ce n'est pas un problème des méthodes agiles selon moi mais un problème de mauvaise utilisation de ces méthodes.

[Carhiboux]

Merci d'avoir corrigé le titre, cela me piquait horriblement les yeux (oui je sais hôpital, charité, je fais aussi des fautes ).

Les principaux défauts des méthodes agiles à mon sens sont :

1) Que ça ne marche que sur les petites équipes. Au delà de ... allez... 6-7 personnes, c'est difficile à maintenir.

2) Que comme dit dans l'article, les chefs de projets confondent agilité avec méthodologie de management rigide.

3) Le client n'est pas toujours disposé à jouer le jeu. Le concept le séduit de prime abord, mais il se rends ensuite compte de la charge de travail hebdomadaire et il finit par ne plus forcément faire sa part. Alors que dans un projet classique, il travaillera tout autant, mais de manière moins planifiée... Mais il préférera souvent parce qu'il aura certainement l'impression d'être moins "contraint".

[niarkyzator]

Le problèmes des méthodes Agiles est simple : c'est avant tout basé sur le bon sens.

Or les managers / chefs de projets ne veulent pas de "bon sens", ils veulent des règles simples qu'on peut appliquer bêtement.

[Njörd]

Bonjour,

Je pense également qu'il faut laisser du temps pour que de nouvelles entreprises apparaissent sur notre marché (donc compter quelques 20 à 30 années pour que ce soit dans les mœurs, aussi bien du côté entreprise que côté client). Nouvelle entreprise, donc plus facile de mettre en place les méthodes agiles en partant de zéro.

Le problème, bien souvent, c'est le changement. On rechigne toujours. Dans les entreprises ayant déjà leur culture et leur façon de fonctionner, ça me paraît très difficile (mais pas impossible) de mettre en place les méthodes agiles. Rien que les jeux de pouvoir suffisent à empêcher le changement.

[antoinev2]

C'est comme beaucoup de belles théories : l'objectif est noble mais la nature de l'homme reprend vite le dessus.

D'après ce que j'ai vu, l'agilité est un superbe prétexte pour les MOA et les clients pour justifier le manque ou l'absence de leur méthodologie, de leur suivi.
Le dev agile signifie à leurs yeux "je peux demander à mon développeur tout ce que je veux et changer d'avis aussi souvent que je veux, il se débrouille pour appliquer."
En cas d'échec, qui est responsable? Le dev qui n'a pas su être "agile".

[ange]

Je viens de voir passer "le bon sens" ....
J'ai pratiqué les méthodes "agiles" comme xP ou Rad au début et je trouvais qu'elle avaient du sens parce que très orientées technique. Mais lorsqu'une méthode arrive et parle de "bon sens" alors là !!!!!!!
C'est quoi le bon sens ? Et celui de qui ? Une petite définition :
"Le bon sens est l'intermédiaire entre l'ignorance et la connaissance bien assurée. Il est la raison sans raisons. Entre la sphère théorique où l'on s'entend rarement sur le sens d'un mot ou d'une idée et la sphère pratique où l'on doit agir, le plus souvent sans être assuré de pouvoir le faire en connaissance de cause, il y a un vide. Le bon sens comble ce vide. Il est la «la saine et droite raison», dit le Littré et plus loin: «le sens commun, l'intelligence et la lumière avec laquelle naissent la plupart des gens.» Le bon sens est de nos jours défini comme la raison en tant qu'elle remplit le vide laissé par la science: «capacité de bien juger, sans passion, en présence de problèmes qui ne peuvent être résolus par des raisonnements scientiques» (Le petit Robert)."
Pour ma part je préfère une connaissance même si elle n'est pas super bien assurée qu'un truc qui navigue entre ignorance et connaissance... parc que bien souvent ça va pencher vers le premier !!
Donc quand une méthodo arrive avec ce genre de concept ... je craint le pire !
Sans compter qu'un des autres grands concepts fondateurs qui m'amuse est : "courage"

[beeboo]

Mon expérience perso : dans la plupart des projets, le problème principal c'est le "chef de projet", peu importe la méthode.

[spyserver]

D'après ce que j'ai vu, l'agilité est un superbe prétexte pour les MOA et les clients pour justifier le manque ou l'absence de leur méthodologie, de leur suivi.
Le dev agile signifie à leurs yeux "je peux demander à mon développeur tout ce que je veux et changer d'avis aussi souvent que je veux, il se débrouille pour appliquer."
En cas d'échec, qui est responsable? Le dev qui n'a pas su être "agile".

Tout à fait d'accord ! Dans mon projet, notre client a exactement ce comportement, non sincèrement mieux vaut un cycle en V que du "mauvais" Agile, soit 90% des projets.

[LSMetag]

J'ai eu la chance de travailler plusieurs fois en mode Agile, et ça se passait bien. Il faut juste que tout le monde joue le jeu.

Le chef de projet et les développeurs doivent être au diapason. Le développeur a des objectifs larges et on peut prendre 5 minutes chaque matin avec le chef de projet pour faire un point rapide sur avancement, problèmes,...
Mettre un lead-développer dans chaque équipe est utile pour guider les autres développeurs et éviter des erreurs. Il peut ensuite aider les développeurs à synthétiser l'état des tâches pour le point quotidien avec le CP.

J'aime l'agilité car je suis focalisé sur la satisfaction client et la qualité du produit. Mais par contre, le développeur doit pouvoir expliquer clairement au client quand il y a des contraintes à ce qu'ils demandent (il a le droit de dire "Je réfléchis à la question et je vous rappelle"). Et le client doit pouvoir accepter les éventuelles contraintes et discuter en toute intelligence. Le Lead-Developer peut être une étape de validation en cas d'incertitude du développeur contacté. Le CP est avisé au point quotidien suivant ou, si la demande est importante, on peut le solliciter immédiatement.

Evidemment, le client a tout à fait le droit de solliciter le chef de projet pour une deuxième discussion sur le problème ou même se plaindre d'un développeur.

Le risque est évidemment quand le client abuse. C'est pour ça qu'il doit y avoir tout de même des specs, des deadlines par lots et que les demandes clientes supplémentaires soient consignées et datées. Mais le fait d'avoir une souplesse sur les specs permet d'anticiper d'éventuelles erreurs provoquées par celles-ci.

Les fois où j'ai travaillé en cycle en V, je trouve que ça passait moins bien. Beaucoup moins de réactivité, rapports plus froids (voire conflictuels) avec le client, objectif "rentabilité à court terme", facturation au bug (donc quand le développeur en signale, les CP et clients (MOA et MOE) n'aiment pas),... C'est énervant de se voir interdire de corriger des bugs, voire de se voir répondre "Ce n'est pas un bug, il n'est pas dans le bugtracker". Le qualité globale du produit était à mon sens moins bonne, avec beaucoup plus de "hotfix" et les clients nous voyaient à peine comme des êtres humains (de l'aveu de notre manager) si bien qu'on leur a envoyé une photo de groupe.

Je ne cherche que des jobs en mode agile, car je m'y sens beaucoup mieux.

[transgohan]

C'est comme beaucoup de belles théories : l'objectif est noble mais la nature de l'homme reprend vite le dessus.

D'après ce que j'ai vu, l'agilité est un superbe prétexte pour les MOA et les clients pour justifier le manque ou l'absence de leur méthodologie, de leur suivi.
Le dev agile signifie à leurs yeux "je peux demander à mon développeur tout ce que je veux et changer d'avis aussi souvent que je veux, il se débrouille pour appliquer."
En cas d'échec, qui est responsable? Le dev qui n'a pas su être "agile".

Oui c'est un échec du dev, c'est en effet lui qui n'a pas su être agile...
En effet, la charge de la tâche est estimée par le DEV !
Le fait de prendre ou non la tâche dans le sprint est aussi de la responsabilité du DEV !
Bref si à la fin il s'est engagé sur cela et qu'il n'a pas réussi sa mission c'est donc de sa faute.

Et il n'y a pas de "on peut rien refuser à à la MOA", on peut leur prouver par tout un tas d'indicateurs que ce qu'ils demandent n'est pas réalisable dans le temps demandé.
Il n'y a qu'à la MOA des débiles, mais là ce sont eux qui ne jouent pas le jeu et on ne peut pas y faire grand chose...

"MOA> Construit moi un moteur d'avion.
Développeur> Mais... Je ne suis pas mécanicien ???
MOA> Rien à f**tre. Construis moi un moteur d'avion."

[Traroth2]

Ce n'est pas un problème des méthodes agiles selon moi mais un problème de mauvaise utilisation de ces méthodes.

Ah oui, complètement. Il faut quand même en tenir une couche pour ne pas se rendre compte que des specs, c'est indispensable (mais pas suffisant) pour qu'un projet ait la moindre chance de bien se passer.

[antoinev2]

Ah oui, complètement. Il faut quand même en tenir une couche pour ne pas se rendre compte que des specs, c'est indispensable (mais pas suffisant) pour qu'un projet ait la moindre chance de bien se passer.

Oui voilà, finalement c'est sans doute plus un problème de personne que de méthodologie.

Oui c'est un échec du dev, c'est en effet lui qui n'a pas su être agile...
En effet, la charge de la tâche est estimée par le DEV !
Le fait de prendre ou non la tâche dans le sprint est aussi de la responsabilité du DEV !
Bref si à la fin il s'est engagé sur cela et qu'il n'a pas réussi sa mission c'est donc de sa faute.

Tu parles de sprint, donc d'application de la méthode, mais combien de MOA, décideurs, clients (et commerciaux!) connaissent et savent comment appliquer la méthode?
Ils ont entendu parler d'agilité, de post-it, d'effet tunnel et de réactivité, rarement plus.
Les MOA dont je parle se cachent derrière le concept d'agilité pour justifier l'absence de méthode.
Quand bon nombre de points de l'application restent flous, parce qu'on a posé la question au chef de projet qui n'a pas de réponse, on dit qu'il faut être agile. C'est pratique...

Là où ça rejoint ce que dit Traroth2, c'est qu'on n'a pas non plus :
de communication entre tous les acteurs impliqués (plusieurs directions chez le client, plusieurs applications impactées donc plusieurs MOA, plusieurs TMA...)
de recette ("Mais on n'en a pas besoin...")
de bonne volonté de tous les acteurs (entre ceux qui sont incompétents, ceux qui n'ont aucun intérêt à ce que le projet aboutisse et ceux pressés de facturer...)

[Luckyluke34]

Rien de bien nouveau sous le soleil. En 2008 et 2009, on dressait déjà le constat d'un échec massif de l'agilité car les aspects techniques n'étaient pas pris en compte, "Flaccid Scrum"...) Le mouvement Software Craftsmanship s'est construit à la même époque en réponse à cette tendance.

Le problème quand on dit "les méthodes agiles ont échoué" c'est que
1) on suppose que toutes les méthodes sont les mêmes à la base alors qu'il en existe de très différentes, dont certaines qui incluent des pratiques techniques et n'ont pas été si largement appliquées (XP pour ne pas le citer) et
2) on personifie des process alors que ceux qui ont échoué, c'est plutôt les gens qui ont essayé de les mettre en application sans comprendre les concepts sous-jacents ou "parce que c'est à la mode", sans même se demander si l'agilité répondait à leurs problèmes en premier lieu...

J'ai l'impression que l'auteur se tire une balle dans le pied avec ce titre, car il accepte le déplacement de l'étiquette "agile" sur un package qui n'a plus grand chose à voir avec l'esprit du manifeste d'origine. C'est un peu comme s'il appliquait son précepte "You should make it easy to throw away code and start again." à l'agilité. Je ne suis pas fan de jeter ainsi le bébé avec l'eau du bain, car oui il y a des équipes qui réussissent avec Agile, et accepter qu'on vide ainsi une approche de son sens, c'est renoncer un peu trop facilement à mon goût.

[leminipouce]

Qu’en pensez-vous ?

Précisément l'inverse !
Je pense au contraire que l'esprit agile est en train de prendre. Mais je reste lucide en citant un bon vieil adage français : Rome ne s'est pas faîte en un jour.
Petit historique pour rire :

• 2001 : rédaction du manifest agile.
• 2002 : je commence les cours. On m'y parle de cycle en V, des méthodes Merise et MACAO (une méthode itérative) mais pas d'agilité. Bien que MACAO s'inspire d'XP, la notion même d'agilité n'est pas abordé.
• 2007/2008 : je réalise mon premier projet en mode agile avec Scrum.
• ~2011/2012 (si je ne me trompes pas) : l'agilité rentre dans les gênes de boîtes avec un fort rayonnement. Je pense par exemple à Xebia en France, mais ils ne sont pas les seuls. D'autres structures, plus petites, moins connues prennent également cette direction.
• 2013 : appel d'offres publiques du Ministère de l'agriculture qui prévoit l'agilité comme méthode de travail dans ce marché.
• ...

Il reste énormément de gens qui ne connaissent pas l'agilité ou n'y comprenne rien. D'autres qui y sont tout simplement réfractaires. Après 10, 15, 20 ans ou plus à travailler d'une façon, difficile de se remettre en cause, d'accepter de nouveau préceptes, de nouvelles façon de travailler, ... Difficile aussi de reconnaître que les méthodes existantes et utilisées par le passé ont conduit à de nombreux échecs !

Mais aujourd'hui, les jeunes qui sortent des écoles savent ce qu'est l'agilité. La culture informatique parle d'agilité. Les consultants qui vont et viennent d'une ESN à une autre sont petit à petit passés par une case agile ou semi-agile. Parfois même y ont trouvé un intérêt... et cherche à le reproduire. Les décideurs savent qu'ils peuvent tirer des bénéfices de l'agilité et ne veulent pas rester en marge de ce qui se fait dans le monde, dans les grandes entreprises, dans les structures qui marchent. Les ESN cherchent un modèle qui soit économiquement plus intéressant, plus fiable, ... Bref même s'il faut du temps, je pense que l'agilité est en train de s'inviter, progressivement à la table de nombreux projets et croit, doucement, au fil des échecs et des réussites.

(6) Le code n'est pas sacré : il faut pouvoir tout balancer et tout recommencer sans avoir l'impression de se tirer une balle dans le pied. Mon opinion : on fait souvent fausse route, donc un demi-tour facile est essentiel.
(7) La latence tue. Des retours d'information rapides sont indispensables pour réaliser un bon projet. Toujours d'accord, toujours pour la même raison : on faut souvent fausse route, et mieux vaut s'en apercevoir au bout de 2 jours qu'au bout de 2 ans.

Justement, le manifeste Agile apporte des réponses à ces 2 problématiques :

La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

J'ajouterais juste qu'un manager non-technique peut être utile, mais à condition d'avoir parfaitement intégré son incompétence technique. Si il passe son temps à animer l'équipe, à chercher quels sont les obstacles et comment les aplanir, a vérifier que tout le monde reste dans le périmètre, et que globalement les gens avancent, alors il peut être très utile. J'en ai vu. Manque de pot, la plupart tentent de tout contrôler(pour asseoir leur pouvoir), et le résultat est celui décrit par le bloggueur.

C'est là tout le problème et un des points cruciaux de l'agilité. Reconnaître la valeur du développeur. Ou, en d'autres termes, pour le CP qui ne comprend rien à la technique, être capable de l'avouer/le reconnaître et faire confiance au dév.

[gangsoleil]

Le problème quand on dit "les méthodes agiles ont échoué" c'est que
1) on suppose que toutes les méthodes sont les mêmes à la base alors qu'il en existe de très différentes, dont certaines qui incluent des pratiques techniques et n'ont pas été si largement appliquées (XP pour ne pas le citer) et
2) on personifie des process alors que ceux qui ont échoué, c'est plutôt les gens qui ont essayé de les mettre en application sans comprendre les concepts sous-jacents ou "parce que c'est à la mode", sans même se demander si l'agilité répondait à leurs problèmes en premier lieu...

J'ai l'impression que l'auteur se tire une balle dans le pied avec ce titre, car il accepte le déplacement de l'étiquette "agile" sur un package qui n'a plus grand chose à voir avec l'esprit du manifeste d'origine. [...] Je ne suis pas fan de jeter ainsi le bébé avec l'eau du bain, car oui il y a des équipes qui réussissent avec Agile, et accepter qu'on vide ainsi une approche de son sens, c'est renoncer un peu trop facilement à mon goût.

Il y a des equipes qui reussissent avec Agile ne veut pas dire pour autant que ce terme n'est pas galvaudé aujourd'hui. Oui, aujourd'hui les entreprises "font de l'agile" parce que c'est vendeur aupres des clients, et non plus parce que ce sont des bonnes pratiques qu'il pourrait etre bon de chercher a appliquer au sein de l'entreprise pour obtenir de meilleurs resultats.

En ce sens, je suis d'accord avec l'auteur pour dire qu'on devrait jeter Agile, ce qui ne veut pas dire qu'il faut jeter les vrais principes qui forment sa base ou une partie de ce que c'est sensé être.

[Et pour chipoter, XP est plus vieux qu'Agile, donc jeter Agile ne veut pas dire jeter l'XP]

[leminipouce]

Il y a des equipes qui reussissent avec Agile ne veut pas dire pour autant que ce terme n'est pas galvaudé aujourd'hui. Oui, aujourd'hui les entreprises "font de l'agile" parce que c'est vendeur aupres des clients, et non plus parce que ce sont des bonnes pratiques qu'il pourrait etre bon de chercher a appliquer au sein de l'entreprise pour obtenir de meilleurs resultats.

En ce sens, je suis d'accord avec l'auteur pour dire qu'on devrait jeter Agile, ce qui ne veut pas dire qu'il faut jeter les vrais principes qui forment sa base ou une partie de ce que c'est sensé être.

[Et pour chipoter, XP est plus vieux qu'Agile, donc jeter Agile ne veut pas dire jeter l'XP]

J'ai tendance à ne pas être d'accord avec ça. Il faut du temps pour que l'Agilité s'implante correctement et soit utilisée correctement. C'est clair que j'ai vu des projets Agile qui ne l'était pas du tout. Mais parce que le terme est de plus en plus utilisé, je pense que son application va aller dans le bon sens. Bien sûr, je me fais un peu Mme Irma sur le coup, mais je me dis qu'entre les étudiants qui sortent de l'école, ceux qui ont eu une expérience réussi, ceux qui ont fait une formation, lu un bouquin ou deux, etc... les principes s'appliquent de plus en plus, de mieux en mieux. Mais il reste encore beaucoup de chemin à parcourir.

[LSMetag]

En réponse à certains, c'est vrai que j'ai travaillé avec des méthodes qui à mes yeux fonctionnaient : UP et XP

Après les SCRUM et cie, c'est pour moi une trait d'union des Cycles en V et de l'Agile, où j'ai l'impression qu'on cumule les mauvais aspects des 2 mondes.