IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Agile est un cancer », pour Erik Meijer,
Qui estime qu'il doit être banni une fois pour toutes

Le , par Hinault Romaric

446PARTAGES

4  2 
Erik Meijer, un développeur célèbre de l’écosystème .NET, qui s’est notamment fait remarquer par la création de LINQ et ses travaux sur le langage C#, Visual Basic, Volta et le framework Reactive Extensions (Rx), a fait des déclarations acerbes contre Agile, lors d’un événement.

Les méthodes agiles sont de plus en plus adoptées par les équipes de développeurs. Elles se positionnent comme une meilleure alternative au cycle de développement en cascade, qui ne répond plus aux exigences des organisations qui évoluent rapidement. Elles sont donc considérées comme une recette pour accélérer le processus de développement, tout en réduisant le taux de bogues dans les applications.

Les méthodes agiles sont unies par le Manifeste agile qui doit son succès à la description de 4 valeurs essentielles, facilement compréhensibles pour les développeurs, à savoir :

  • Les individus et leurs interactions priment sur les processus et les outils.
  • Du logiciel qui fonctionne prime sur une documentation exhaustive.
  • La collaboration avec les clients plutôt que la négociation contractuelle.
  • L’adaptation au changement prime sur le respect des plannings.


Cependant, l’agilité ne fait pas l’unanimité auprès des développeurs. Lors d’une conférence en Finlande, Erik Meijer a eu des propos très durs envers Agile. « Agile est un cancer que nous devons éliminer de l’industrie », a déclaré celui-ci.

Meijer critique surtout le fait que l’application de l’agilité dans des projets fait « beaucoup plus parler sur le code, que d’écrire le code ». Erik Meijer s’en prend particulièrement à la méthode Scrum, qui entraine des « interruptions inutiles ».

Selon celui-ci, les « Scrum Meeting » sont des interruptions ennuyeuses, au mieux des mécanismes de contrôle subtil utilisés par les gestionnaires pour conduire une équipe, en donnant l’illusion d’un leadership partagé. « Nous devons cesser Scrum et Agile. Nous sommes des développeurs. Nous devons écrire du code », a affirmé Meijer.

Meijer continue sa diatribe en s’attaquant aux TDD. « C’est tellement ridicule. Pensez-vous que vous pouvez modéliser les échecs réels qui se produisent pendant la phase de production ? », s’est interrogé Meijer, avant de répondre. « Non. » Il préconise un cycle où le logiciel est déployé, et les erreurs fixées lorsqu’ils sont découverts.

Il faut noter que le créateur de Ruby On Rails, David Heinemeier Hansson, s’était aussi attaqué aux TDD, en affirmant que les tests unitaires n’étaient pas bénéfiques.

Au-delà de ces remarques, Meijer s’insurge également par rapport au fait que le terme « Agile » a été détourné et est désormais dénué de tout sens. Il a fini sa présentation en citant Dave Thomas, l’un des signataires du manifeste agile : « Le mot ‘Agile’ a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services »

Sur ce point, il a été rejoint par un autre conférencier. Nic Ferrier architecte dans une entreprise de développement qui utilise Agile, a affirmé qu’Agile est en partie victime de son succès. Selon lui, lorsque les méthodes agiles ont conduit aux premiers bons résultats, les entreprises ont commencé à développer des outils qui prennent en charge ces méthodes. Dès lors, elles ont commencé à véhiculer l’idée qu’Agile est un outil que l’on peut acheter.

Un avis d’ Erik Meijer, certes tranché, mais qui reflète la frustration d’un passionné du code, qui souhaite par-dessus tout consacrer son temps à sa passion : écrire du code.

Source

Et vous ?

Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ?

Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?

Agile freine-t-il l’écriture du code ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 19/01/2015 à 11:30
Le problème, c'est que "Agile" est une manière de penser, pas une méthode.

Les gens qui n'ont pas cette manière de penser et qui appliquent la méthode, fatalement, ont de mauvais résultats.

Un autre cas peut être destructeur : certains dans la structure sont agiles, tandis que d'autres sont restés à l'ancienne méthode. Résultat, tout le monde doit se plier à l'agile sans être prêt, et on casse tous les projets(vécu).
16  1 
Avatar de sebbod
Membre averti https://www.developpez.com
Le 19/01/2015 à 11:45
Cette méthode aide énormément et je trouve que l'on devrait l'adopter à partir du moment où l'on fait du développement en équipe (plus de 1 développeur).

-J'ai un PO qui rédige des US parfaite (Mais au début ça n'était pas le cas, nous avons corriger le tir pour obtenir du PO ce que nous avions besoins pour développer c'est ça aussi la méthode AGILE, ce remettre en question)

-J'ai un SM qui sait ce faire oublier mais qui est là quand on a une question. On est un peu tous SM (Scrum Master je précise parce que je lis dans tes penses gros dégoutant) finalement dans l'équipe

-Le daily scrum du matin c'est bien mangés en ;-) franchement discuter tous les matins 2 minutes/personne des problèmes de la veille et des choses à faire dans la journée, je trouve qu'on gagne en clarté, en efficacité et sa force la cohésion d'équipe et l’entraide car si y'en a un qui galère sur un truc les autres sont force de proposition pour l'aider à trouver des solutions ou on peut aussi faire du "Pair programming" ce qui une fois de temps en temps ne fait pas de mal et permet de débloquer certaine situation ou/et aussi de former une nouvelle personne.

Bref j'ai développé pendant 10 ans tout seul et j'aimais ça.
Et maintenant ça fait 3 ans que je suis dans l'équipe à Gilles ;-)
Etant plutôt solitaire de nature je préfère développer en solo mais la vie ne nous laisse pas toujours le choix et finalement j'ai appris à aimer la méthode AGILE.

Donc merci à lui
11  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 19/01/2015 à 11:14
Les méthodes agiles, pratiquées sérieusement et honnêtement, ça peut sans doute donner des bons résultats. Cela dit, je ne saurais être vraiment affirmatif : dans toutes les boites que j'ai pu voir où on prétendait faire de l'agile, ce n'était qu'un prétexte pour ne pas faire de specs, pour permettre à la maitrise d'ouvrage de changer constamment d'avis ("embrasser le changement", ok, mais en principe, c'est que le besoin a réellement changé, pas simplement que le client n'est pas foutu de savoir ce qu'il veut !), ne pas documenter le code, coder à l'arrache (KISS mal compris), etc.

Le problème de fond, c'est que les principes agiles mal compris permettent de justifier énormément de mauvaises pratiques ancestrales du monde informatique. Et ils ne s'en privent pas !
10  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 19/01/2015 à 11:15
A chaque méthode ses défauts.

Personnellement j'ai rencontré plus de soucis avec les méthodes non Agiles en industrie, ou on ne corrigeait pas les bugs/lenteur non bloquant simples avant des mois.

Cela donnait des utilisateurs mécontent.

en gros ces histoires sont souvent liée au process ( Parfois une application non critique utilise les mêmes process de dev qu'une application vitale).

Il ne faut pas qu'un process lourd nuise à la qualité et la réactivité d'un SI.

De plus limiter le turn-over permet d'avoir des développeurs qui connaissent mieux leur contexte métier et l'entreprise, cela limite drastiquement les impacts, mais c'est sur en embauchant plus 70% de dev "jetables" c'est pas facile...

De plus Microsoft qui sort une beta de Visual Studio toute les 3 semaines doit surement utiliser beaucoup les méthodes agiles, et VS est plutôt bon.
10  1 
Avatar de fiftytwo
Membre émérite https://www.developpez.com
Le 19/01/2015 à 10:56
Ce sujet tombe bien car je me demande de plus en plus quelque chose a propos d' Agile.

Est ce que cette methologie est devenue un autre bvuzzword parmi tant dautres dans l' ÍT ? comme ''Big data'' ou ''cloud'' ou ''virtualisation''

Je ne parle pas de ses bons / mauvais cotes , mais plus du fait que beaucoup de boites disent adopter et suivre ces methologies , mais en fait , connaissant la culture de certaines entreprises , je vois deja ce que cela donne avec les frameworks comme ITIL , Prince 2 ou Cobit dans la realite ou les bouquins , certaines boitent appliquent de maniere efficace tandis que dautres , en manque de perormances , recuperent un truc dont un font une grosse blague qui y ressemble vaguement , avec plein de gens pour se donner des titres pompeux alors quils ne font pas 1/3 du travail qui devrait etre fait.

Je me dis que beaucoup dequipes ne font que suivre ce que le manager a decide et qui souvent seloigne dagile et le travail final nen est pas plus qualitatif.

Car

Ais je tort ?
8  0 
Avatar de Haseo86
Membre éclairé https://www.developpez.com
Le 19/01/2015 à 11:53
Si sa passion c'est de pisser du code H24, grand bien lui fasse, mais je ne crois pas que ce soit de cette façon qu'on obtienne de bons logiciels.
La méthode Agile comme n'importe quelle autre a ses défauts, mais je ne comprends pas qu'on puisse reprocher aux développeurs de passer du temps à réfléchir sur leur code et à en discuter. Ca me parait bien mieux que de foncer tête baissée et d'avoir un codeur qui reste dans sa bulle.

Maintenant je le rejoins un peu sur les TDD, je ne comprends pas cette méthode de travail.
8  0 
Avatar de LSMetag
Expert confirmé https://www.developpez.com
Le 19/01/2015 à 12:02
Erik Meijer, c'est le genre de personnes qui pour moi sont un cancer pour une entreprise.

J'ai vu ce que ça donnait les cycles en V. Plus jamais. A chaque fois, j'y ai vu un manque de respect pour l'utilisateur final des solutions. Car c'est un cadre qui n'est pas dedans qui va décider à sa place.

Au moins, dans l'agile, dès qu'on voit un bug, on le corrige. Dès qu'on a une question ou une remarque, on appelle la personne concernée, plutôt que de passer par 3 intermédiaires pour qu'au final la question se perde.

Le matin, on prend 5/10 minutes pour discuter avec le chef de projet pour indiquer où l'on en est, ce qu'on a fait, et parler de l'ordre du jour. Autrement c'est quoi ? Des chiffres dans un logiciel de BugTracking, des indicateurs abstraits ?

L'agilité est là aussi pour se corriger ou corriger rapidement le tir. Et je ne parle pas que pour les développeurs mais aussi pour les demandeurs, qui parfois aussi se plantent. Et elle n'empêche pas de faire de bonnes spécifications. Elle permet de les modifier rapidement c'est tout. Et après, on vérifie tout et donne (si elle n'y est pas déjà) une cohérence à tout ça.

Evidemment comme dit plus haut, "Agile" ne fait pas tout. Il faut que le personnel ait le concept "agile" dans la peau, qu'il soit impliqué dans ses projets, qu'il s'entende,... On peut se planter tout autant en "Agile" qu'autrement si l'équipe, et surtout son Chef, est mauvaise.

Bref, je m'arrête là, mais tout ce que j'ai fait en agile et forfaitaire a toujours beaucoup mieux fonctionné que les fameux trucs contractuel et figés. Je me suis d'ailleurs fait virer à cause d'une grosse baisse de charge due à des contractuels qui avaient mal anticipé la charge et les demandes...
Si on avait été en agile, on aurait au moins pu continuer à corriger des bugs, ajouter des fonctionnalités souhaitées par les utilisateurs au lieu d'attendre les ordres venant d'en haut (et qui ne sont pas venus...)

Peut-être qu'avec une méthode agile appliquée de façon efficace, on aurait pu éviter le bug de l'an 2000. Je suis sûr qu'il a dû être signalé dans plusieurs entreprises, dont les décideurs n'ont pas tenu compte...
8  0 
Avatar de fiftytwo
Membre émérite https://www.developpez.com
Le 19/01/2015 à 14:35
Citation Envoyé par sebbod Voir le message
mais j'essaye d'appliquer la méthode AGILE à la maison pour parler au moins une fois par jour de ce qui va et de ce qui ne va pas avec ma compagne ce qui me fait 2 expériences avec la même méthode
Et quand tu as oublie de faire la vaisselle , vider les poubelles ou sortir le chien tu fais un sprint ??

Citation Envoyé par Bono_BX Voir le message
chefs de projet non techniques (genre parachuté / j'ai-vu-de-la-lumière-je-suis-rentré). Et là, c'est dans les faits quasi-impossible
La ou je suis jpasse jen ai vu plein des comme ca , manager , TL , ou CDP ( un mec qui en 6 ans de carriere change 4 fois de boites , passe un pseudo MBA et devient manager , un autre qui etait admin windows senior ya meme pas un an et est devenu manager dune quarantaine de personnes , un mec qui etait second dans un resto qui est reparti faire ses etudes et est devenu SDM , un mec du helpdesk qui en deux ans est devenu team leader et qui est passe manager car le manager sest fait vire etc ....... )

Mon prefere , cest mon ancienne TL , qui ne connaissait rien a exchange , je crois quelle bossait dans un kindergarden avant dentrer a ibm , elle a occupe un poste de quality analyst pendant un an avant detre mute au poste de team leader . Quand je lui ai demande en quoi consistait son poste de quality analyst , elle m'a repondu '' ben j'analysait la qualite " -> parachutage et copinage font bon menage chez bigblue

Du coup je me marre quand je vois les profils requis pour certains postes , et meme si je ne cale pas a 100% je tente quand meme car generalement ce poste sera surement file a un/une touriste , alors autant me le donner : quelqu un de motive sera a ce poste , ca me feras avancer ma carriere et au moins jaurais un challenge intellectuel .

Mon objectif pour les prochaines annees : apprendre a vendre du vent et faire de la politique

Citation Envoyé par Bono_BX Voir le message
Mon avis personnel sur l'Agile est que cette méthode est une amélioration, une grosse amélioration, mais qu'une amélioration : si l'on a une équipe de bras cassés ou de personnes non formées ou peu impliquées, le projet sera un échec quelque soit la méthode employée.:
Ok , donc pour agile , cest pareil que de donner un piano Steinway a Kristina Hu (alias the UnsungHeroine) , Beethoven , David Guetta ou un Chimpanze , cela restera toujours un piano , avec lequels ils feront de la merde , du bruit ou un chef doeuvre
7  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 19/01/2015 à 14:02
Citation Envoyé par santana2006 Voir le message
Pour moi Agile n'est pas une méthodologie, n'est pas un standard, n'est pas un outil. Agile c'est un esprit/attitude/framework organisationnel, propre à chaque projet, et à chaque entreprise. par nature elle n'est pas standarisable car pas toujours forcément liée à des indicateurs ou données mesurables. C'est propre au contexte.
Le problème aujourd'hui, c'est que beaucoup d'entreprises veulent appliquer une méthode Agile comme on exécute une recette de gateau : on reproduit point par point ce qui a été fait à côté, avec un coach Agile bien sur, et hop, ça fait des chocapics (ou de la choucroute si on préfère).

Je ne vois que peu d'entreprises qui cherchent à voir quelle méthode appliquer (Scrum, XP, autre, peu importe), quelles sont leurs limites, pourquoi elles iront bien ou non, comment les équipes vont réagir, est-ce que ça s'applique à eux, ...

Prends une équipe dans laquelle il y a beaucoup de caractères forts et indépendants, et essaye d'imposer XP avec le codage à deux : il y a de fortes chances pour que ça passe mal, chacun voulant tirer la couverture à soi. De même, les réunions de 10 minutes le matin lorsque tu as des gens qui arrivent à 7h et d'autre à 10h, ce n'est pas forcément super productif...

Or c'est bien ce qui se passe dans la plupart des entreprises que j'ai vu.
5  0 
Avatar de kolodz
Modérateur https://www.developpez.com
Le 19/01/2015 à 16:10
@Hinault Romaric : Voici la vidéo d'origine : http://reaktor.fi/blog/erik-meijer-s...-eating-world/
http://vimeo.com/110554082

Remarque :
Au-delà de ces remarques, Meijer s’insurge également par rapport au fait que le terme « Agile » a été détourné et est désormais dénué de tout sens. Il a fini sa présentation en citant Dave Thomas, l’un des signataires du manifeste agile : « Le mot ‘Agile’ a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services »
Qui finit par :
Donc, je pense qu'il est temps de mettre à la retraite le mot "Agile"
Il est dommage de cité les propos des 10 premières minutes d'une présentation de 45 minutes. En particulier quand ceux-ci sont destiné à faire réagir l’audience...

Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ?
Il est vrai que beaucoup d'entreprise utilise le mot "Agile" sans même avoir lu une définition. Et applique la nouvelle méthodologie en vogue. Pour eux, cela change juste le nombre de réunion. C'est d'ailleurs ce que l'explique dans l'un de mes billets : [Agile]Le daily meeting et la dérive du "flicage à la journée".
Donc, si vous voulez mon avis allez lire le billet !

Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
Il fait une critique globale de la structuration de l'entreprise qui ne prends pas en compte les "feedback" de l'environnement. D'ailleurs, Agile n'est pas le sujet principal de sa présentation. Si il y a un thème récurant, c'est "subtle controle". Où le cas de l'Agile n'est que le dernier exemple en date.
Le propos et ses arguments sont juste. Il n'y a pas de doute. Cependant, l'organisation en couche n'est peut-être pas la seule alternative au défaut qu'il observe et critique dans l'organisation actuel.

Deux des phrases qu'il cite me semble importante à relever dans le discours général.
When 9 peoples agrees,it's the tenth man's responsability is to disagree no matter how imporbable the idea.
L'idée étant que si nous somme tous convaincu d'être dans le vrai. Un jour ou l'autre, on va très probablement aller dans le mur. Aujourd'hui, tout le monde est pro "Agile", il joue donc le rôle de la 10ième personne.

Context, not Control
Dire ce qui doit être fait. Ce n'est pas au manager de dire comment.

La critique du TDD :
Il critique le TDD par rapport au Chaos Money. Ce qui n'est pas faut si tu es suffisamment confiant pour pousser ton code en production directement et débrancher un serveur pour voir ce qui se passe. Les tests...
Cependant, l'idée dernier le TDD est aussi de réfléchir à ce qu'on veux comme résultat, indépendamment de l'implémentation. Et cette phase de réflexion

Agile freine-t-il l’écriture du code ?
Il est pour un système hiérarchique en couche, ou chaque partie fait son job et ne s'occupe pas de ce que fait la couche du dessus. Comme les hiérarchie religieuse et militaire. Ce qui me semble être un bon point se sa faveur. Si on s'occupait moins de faire des repporting pour les M+42, on ferai plus de chose à notre niveau. Mais encore une fois l'Agile, n'est pas sa cible principale.

Il me semble que serait plus important de relevé les 3 points de sa conclusions/ouvertures d’horizon:

  • Il y a trop d'amateur dans notre travail. Pourquoi y-a-t-il des livres "Apprendre Java en 24 heures" ? Croirait-on un livre "Apprendre la chirurgie en 24 heures" ?
  • On(Développeur) devrait s'améliorer en communication. (Prendre des douches tout ça...)
  • On(Développeur) devrait avoir plus de valeur pour notre travail et nos outils de travail, ne pas se plaindre que la licence est à 60€, que c'est trop cher. (Un couteau de chef cuisinier étant à 300€...). Car on dévalue notre propre travail.


Cordialement,
Patrick Kololdziejczyk.

PS : Il critique le "ribbon" Office et je suis à 100% avec lui.

Note : Certains poste avant même d'avoir le temps de se faire un avis sur le sujet, car la présentation/conférence de cette personnes fait 45 minutes. Pas sûr que toutes les personnes soit allez voir la source, donc.
Donc le premier qui me cite pour faire une critique sur le sujet : Merci de regarder l'ensemble de la vidéo. Et ajoute le mot "banane" dans ton message. (c'est mon check)

Citation Envoyé par fiftytwo Voir le message
Est ce que cette methologie est devenue un autre bvuzzword parmi tant dautres dans l' ÍT ? comme ''Big data'' ou ''cloud'' ou ''virtualisation''
...

Ais je tort ?
Tu n'as pas trot. Mais, ce que je constate, c'est qu'on est de plus en plus à réagir sur le Buzz et non sur le fond.

Le cas que présente @sebbod comme étant en opposition avec l'avis de Erik Meijer est en réalité en accord avec ce qu'il dit !

PS²: Réponse simpliste qui est deux fois plus longue que le poste initial...

Citation Envoyé par Haseo86 Voir le message
Si sa passion c'est de pisser du code H24, grand bien lui fasse, mais je ne crois pas que ce soit de cette façon qu'on obtienne de bons logiciels.
La méthode Agile comme n'importe quelle autre a ses défauts, mais je ne comprends pas qu'on puisse reprocher aux développeurs de passer du temps à réfléchir sur leur code et à en discuter. Ca me parait bien mieux que de foncer tête baissée et d'avoir un codeur qui reste dans sa bulle.
Dommage que tu n'ai pas regardé ou lu ce qu'il explique, car ce n'est pas ce qu'il dit.

Citation Envoyé par LSMetag Voir le message
Erik Meijer, c'est le genre de personnes qui pour moi sont un cancer pour une entreprise.

J'ai vu ce que ça donnait les cycles en V. Plus jamais. A chaque fois, j'y ai vu un manque de respect pour l'utilisateur final des solutions. Car c'est un cadre qui n'est pas dedans qui va décider à sa place.
...
L'agilité est là aussi pour se corriger ou corriger rapidement le tir. Et je ne parle pas que pour les développeurs mais aussi pour les demandeurs, qui parfois aussi se plantent. Et elle n'empêche pas de faire de bonnes spécifications. Elle permet de les modifier rapidement c'est tout. Et après, on vérifie tout et donne (si elle n'y est pas déjà) une cohérence à tout ça.
Encore une fois, pas ce qu'il dit. D'ailleurs, il est pour la mise en production direct et donc pour les "hotfix". (On ne peux pas corrigé le tire plus rapidement...) C'est pour cela qu'il cite une personne qui dit qu'on ne devrait plus utiliser le mot "Agile". Car pour beaucoup trop, cela ne représente pas, ce que c'est sensé représenter.

Citation Envoyé par Saverok Voir le message
Erik Meijer ne critique pas vraiment l'Agile, mais plutôt la façon dont il est mis en place dans la plupart des entreprises et je partage, sur cet aspect, plutôt son avis.
...
16ième message pour voir une personne qui est allée voir la source et se faire son propre avis sur ce qu'il dit !
6  1