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

466PARTAGES

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