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

571PARTAGES

4  2 
� Agile est un cancer �, pour Erik Meijer
qui estime qu�il doit �tre banni une fois pour toutes

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 ?
Vous avez lu gratuitement 4 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.

Une erreur dans cette actualit� ? Signalez-nous-la !

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 chevronn� 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 Tr0n33
Membre actif https://www.developpez.com
Le 09/10/2015 � 17:17
Par exemple, nous venons de livrer 2 gros projets avec des d�lais tr�s serr�s. A livrer au m�me moment pour 2 clients diff�rents. Pas question de passer 20h par mois et par projet en r�union. Pendant que je suis en train de taper la discute sur la beaut� de mon code, y a personne derri�re mon PC pour programmer � ma place. Et les 20h de r�union o� j'ai pas cod�, j'ai pas envie de les rattraper le soir apr�s le bureau ou le week-end pour rester dans les d�lais.
Ca me rappelle un client connu �a. Ca code, �a code, �a code avec des d�lais serr�s, des m�thodes de travail d'un autre temps, fond� sur "fait des heures et pisse du code, on gagne � mort en productivit�; vas y ! vite on a des d�lais serr�s; vas y petit faut que tu nous r�solves tout t'es un champion". Ca marche du tonnerre effectivement... Tr�ves de blagounettes, ne me dis pas que tu ne te rends pas compte de l'utilit� d'un planning poker et d'une modeste r�union de 10 minutes le matin pour coordonner l'ensemble des t�ches ? J'aurais limite l'impression d'un troll l�.

Comment un d�veloppeur peut faire de la gestion de projet sans avoir la formation qui va avec ? Faut que l'on m'explique comment on arrive � vendre �a au client...
En fait, tu r�sumes ton m�tier � te mettre derri�re un IDE et �crire des lignes de code en fonction des sp�cifications qu'on t'a donn�. Personnellement j'appelle �a un ouvrier d�veloppeur. Je n'ai pas du tout la m�me vision que toi du mot "ing�nieur en d�veloppement" qui n�cessite des connaissances en abstraction, en conception, en mod�lisation, en chiffrage et en complexit� de ce qui va �tre d�velopp�. Ces 5 �l�ments n'ont rien � voir avec la gestion de projet et sont du ressort d'un "bon" d�veloppeur. Dans les arguments d�j� d�velopp�s, beaucoup �voquait les probl�mes de management ou de d�mocratisation de la profession. Personnellement, dans toutes les entreprises o� j'ai pu mettre les pieds, ce sont avant tout des individus avec les qualit�s que je cite qui sont recherch�s. Ecrire du code (dans l'informatique de gestion par exemple) n'est pas une t�che qui n�cessite un bac+2 ou une embauche de cadre. Le statut de cadre de beaucoup d'informaticiens vient du fait que le d�veloppement n'est pas la seule corde � leur arc.
6  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