Un développeur estime qu'Agile est un « loup déguisé en agneau », le Waterfall 2.0,
Qu'en pensez-vous ?

Le , par Michael Guilloux

0PARTAGES

4  0 
Agile a été applaudi dans la communauté des développeurs avec ses promesses garantissant un processus de développement conduit par les ingénieurs plutôt que par l’entreprise. Mais quelques années plus tard, Agile fait de moins en moins l’unanimité au sein des développeurs. Le concept semble avoir manqué le but initialement annoncé au vu des témoignages d’un nombre croissant de développeurs y compris des célèbres.

En janvier dernier, Erik Meijer, un développeur 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 ouvertement fustigé Agile lors d’un événement. Pour ce dernier, « Agile est un cancer que nous devons éliminer de l’industrie ».

En mai dernier, Andy Hunt, l’un des 17 co-auteurs du Manifeste Agile en 2001, a rejoint les rangs de ceux qui pensent que la pratique d’Agile n’a pas atteint ses promesses. Il s’est indigné de la manière dont le concept Agile s’est détourné du droit chemin et a donc proposé une nouvelle méthode pour corriger cela. Bref ! Il y a de quoi se demander si Agile, dans la pratique, permet de corriger les problèmes connus dans les méthodes traditionnelles dites en cascade (Waterfall).

D’après le développeur Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), Agile ne résout pas du tout les problèmes du modèle Waterfall. Pour lui, Agile n’est rien d’autre le Waterfall 2.0, la nouvelle version du modèle de développement en cascade, et peut s’avérer encore pire que les méthodes traditionnelles. « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau », a écrit Yasin dans un billet de blog.

Agile a fait des promesses impressionnantes, comme un développement conduit par les ingénieurs, afin que les décisions importantes ne soient pas prises sans les développeurs. Mais selon le CTO de June, dans la réalité, Agile et Waterfall partagent la même idée du développement conduit par l’entreprise. Les décisions techniques sont pilotées par la direction et imposées aux développeurs. « Le résultat final est le même Waterfall. Seul le nom a changé », explique-t-il. Il ajoute encore qu’Agile est plus toxique que les méthodes en cascade, car il rend le développeur beaucoup plus responsable du résultat sans lui donner l’autorité qui va avec sa responsabilité.

« Agile est un marteau » et « vous êtes le clou », poursuit Amir Yasin en s’adressant aux développeurs. Il pense qu’Agile n’est seulement profitable qu’aux sociétés de conseil, qui doivent faire un prototype rapide pour un client qui ne sait pas vraiment ce qu’il veut, et qui facturent sur une base temporelle. Ces dernières sont ainsi prêtes à accepter n’importe quelle idée avec laquelle vient le client, étant donné que cela signifie un délai plus long, donc plus de revenus.

Il s’insurge aussi contre le fait que les sociétés de conseil « Agile » se cachent derrière ce concept pour vendre du Waterfall dans un nouvel emballage sans être pointées du doigt en cas d’échec. Si le projet s’est bien passé, tant mieux. Mais si « votre projet a échoué ; ce n’est pas Agile, c’est vous. Vous l’avez juste mal appliqué, et vous auriez gagné en le faisant bien », explique Yasin, pour décrire la réalité.

Agile semble en effet beaucoup plus facile en théorie. A cet effet, Amir Yasin estime qu’Agile n’est pas agile. Il pense donc que vous deviendrez plus agiles en commençant par vous débarrasser de tout ce qui vous lie à ce concept considéré comme une alternative au modèle Waterfall. C’est-à-dire votre scrum master, votre coach Agile ou encore la société de conseil qui essaie de vous rendre plus Agile.

Il suggère que les équipes de développement suivent leur propre voie avec des méthodes qui font participer tout le monde, mais qui n’accordent pas la priorité au délai dans les discussions. Il insiste sur le fait que tout le monde doit participer, et si des personnes doivent être exclues, il faut exclure les gestionnaires. Il suggère également de livrer le logiciel seulement quand il est prêt, ni avant, ni après. Le coût de livraison du mauvais produit est beaucoup plus élevé que le coût de prolongement des délais pour livrer le bon produit, rappelle-t-il.

Source : Medium

Et vous ?

Qu’en pensez-vous ?

Forum ALM

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

Avatar de transgohan
Expert éminent https://www.developpez.com
Le 14/10/2015 à 13:07
Je ne serai pas autant catégorique, cela dépend de comment on applique les méthodes Agile.
Si seuls les développeurs sont impliqués dans l'Agile en effet ce n'est pas la bonne chose à faire (et c'est malheureusement majoritairement appliqué ainsi).
Avatar de Bono_BX
Membre confirmé https://www.developpez.com
Le 14/10/2015 à 13:33
Il pense donc que vous deviendrez plus agiles en commençant par vous débarrasser de tout ce qui vous lie à ce concept considéré comme une alternative au modèle Waterfall. C’est-à-dire votre scrum master, votre coach Agile ou encore la société de conseil qui essaie de vous rendre plus Agile.

Il suggère que les équipes de développement suivent leur propre voie avec des méthodes qui font participer tout le monde, mais qui n’accordent pas la priorité au délai dans les discussions. Il insiste sur le fait que tout le monde doit participer, et si des personnes doivent être exclues, il faut exclure les gestionnaires.
Oh que oui ! La programmation est l'affaire ... des programmeurs. Combien de projets échouent à cause de gestionnaires qui n'y connaissent rien et nous mettent des bâtons dans les roues ?
Par contre, ce n'est pas Agile qu'il faut remettre en cause : quelque soit la méthode choisie, les mêmes personnes produiront les mêmes problèmes. Ce que soulève Amir Yasin est très juste, mais il se trompe de cible : ce sont les compétences des participants au projet à remettre en cause, pas la méthodologie.

De part mon expérience, je peux affirmer qu'une bonne équipe arrivera à un bon résultat quelque soit la méthode choisie, et une équipe de bras cassés ira toujours dans le mur même avec la meilleure méthode au monde.
Personnellement, je préfère Agile, mais je ne cracherai pas sur le Waterfall qui a aussi connaît de gros succès.
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 14/10/2015 à 13:43
En fait, je suis plutôt d'accord, malheureusement. Dans la pratique, l'agilité ne sert à rien si c'est toujours la direction ou le marketing qui font les plannings.
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 14/10/2015 à 13:45
Citation Envoyé par Bono_BX Voir le message
Oh que oui ! La programmation est l'affaire ... des programmeurs. Combien de projets échouent à cause de gestionnaires qui n'y connaissent rien et nous mettent des bâtons dans les roues ?
Par contre, ce n'est pas Agile qu'il faut remettre en cause : quelque soit la méthode choisie, les mêmes personnes produiront les mêmes problèmes. Ce que soulève Amir Yasin est très juste, mais il se trompe de cible : ce sont les compétences des participants au projet à remettre en cause, pas la méthodologie.

De part mon expérience, je peux affirmer qu'une bonne équipe arrivera à un bon résultat quelque soit la méthode choisie, et une équipe de bras cassés ira toujours dans le mur même avec la meilleure méthode au monde.
Personnellement, je préfère Agile, mais je ne cracherai pas sur le Waterfall qui a aussi connaît de gros succès.
Je ne pense pas que ça soit les compétences dont il parle, mais bien les intentions. Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.
Avatar de Bono_BX
Membre confirmé https://www.developpez.com
Le 14/10/2015 à 13:54
Citation Envoyé par Traroth2 Voir le message
Je ne pense pas que ça soit les compétences dont il parle, mais bien les intentions. Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.
Mais justement, imposer des délais aux équipes techniques, ça n'a rien à voir avec l'Agile, ça se fait aussi en Watrefall, avec les mêmes conséquences. Si tu penses aux itérations de 2 - 3 semaines (j'extrapole sur ce que tu dis ), les users stories doivent être suffisamment concises pour rentrer dans une itération, sinon on les redécoupe ; il n'y a donc pas vraiment de délais imposé.
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 14/10/2015 à 14:59
Citation Envoyé par Michael Guilloux Voir le message
Il suggère également de livrer le logiciel seulement quand il est prêt, ni avant, ni après. Le coût de livraison du mauvais produit est beaucoup plus élevé que le coût de prolongement des délais pour livrer le bon produit, rappelle-t-il.
L'effet tunnel est désastreux, comment peux-tu en arriver à le justifier ?

Oui, les livraisons intermédiaires ont un coût mais c'est un coût nécessaire.
Il est important de pouvoir montrer que le projet avance et d'identifier le plus tôt possible les mauvais choix lors des spec.
Combien de fois on écrit quelque chose en théorie génial et qui s'avère désastreux une fois en pratique ?
Cela est aussi vrai pour la technique que pour les AMOA.

Citation Envoyé par Traroth2 Voir le message
Tant qu'on continuera à imposer les délais aux équipes techniques, l'agilité sera plus nuisible qu'utile, et malheureusement, ça n'est pas près de changer.
Le hic c'est que c'est un peu une obligation.
Dire au client "ça sera livré quand ça sera terminé" n'est tout simplement pas possible.
Un projet informatique est rarement seul.
Derrière, il peut y avoir des tas de choses à coordonner : une campagne marketing, de la formation, etc.
Sans parler du budget...
Avatar de JackJnr
Membre confirmé https://www.developpez.com
Le 14/10/2015 à 15:04
Citation Envoyé par Michael Guilloux Voir le message
Il s’est indigné de la manière dont le concept Agile s’est détourné du droit chemin
Je n'ai pas lu l'article d'origine, mais ne vaudrait-il pas mieux dire "dont le concept Agile a été détourné du droit chemin" ?
Avatar de palnap
Membre actif https://www.developpez.com
Le 14/10/2015 à 15:21
Ce que les SSII soi-disant "agiles" ne comprennent pas (et ne veulent pas comprendre) c'est que l'agilité ne se limite pas à l'équipe de développement. Toute la structure doit devenir agile elle aussi et répondre aux besoins de l'équipe de dev. Tant que les commerciaux et autres directeurs de projets continueront à s'interposer entre les devs et les clients (imposer des dead lines, des fonctionnalités inutiles mais couteuses, ou rien que faire l'intermédiaire entre les 2), ça ne pourra pas marcher !

Il faut aussi accepter de payer plus cher une équipe agile car elle a plus de responsabilités, et il faut des développeurs aguerris (pas des stagiaires ou des débutants facturés comme des experts) car le maillon le plus faible de la chaine peut mettre en péril l'équipe.

Donc +1 avec ce qui a été dit plus haut, le problème ce n'est pas la méthodologie mais les équipes, et j'ajouterai la rigidité des entreprises elles-mêmes...
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 14/10/2015 à 15:46
En un mot, pareil.

Avec un peu plus de détails, je plussoie au fait qu'une méthode, au même titre qu'un outil, n'est ni bonne ni mauvaise. C'est ceux qui les appliquent qui font les bons ou les mauvais choix, ceux qui en font la pub qui donnent les bons ou les mauvais tuyaux, etc. C'est facile de mettre les échecs des uns et des autres sur le dos d'une méthode, mais n'est-ce pas la plus grande preuve d'irresponsabilité ?

On a tenté d'appliquer telle méthode et ça a foiré. Bon. Maintenant, il y a ceux qui vont chercher ce qui a foiré et tenter de le corriger (changer de méthode, l'appliquer autrement, changer des membres de l'équipe, l'organiser autrement, etc.), et ceux qui vont passer leur temps à se plaindre et à chercher des coupables (et si toute l'équipe est comme ça, ce sera forcément la méthode la coupable, ce qui est stupide car on ne peut pas lui faire "payer", or c'est bien là le but de la responsabilité).
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 14/10/2015 à 16:53
Agile a fait des promesses impressionnantes, comme un développement conduit par les ingénieurs, afin que les décisions importantes ne soient pas prises sans les développeurs. Mais selon le CTO de June, dans la réalité, Agile et Waterfall partagent la même idée du développement conduit par l’entreprise. Les décisions techniques sont pilotées par la direction et imposées aux développeurs. « Le résultat final est le même Waterfall. Seul le nom a changé », explique-t-il. Il ajoute encore qu’Agile est plus toxique que les méthodes en cascade, car il rend le développeur beaucoup plus responsable du résultat sans lui donner l’autorité qui va avec sa responsabilité.
Citation Envoyé par Agile Manigesto - Principe N°11

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
En effet, si les décisions techniques sont pilotées par la direction, on corrompe ce principe de l'Agilité.
L'auto-organisation est un élément très important dans l'agilité.

Comment peut on alors dire "Agile, ça marche pas, c'est trop nul", si on ne respecte déjà pas l'ensemble de ses règles.
Comme si un parachutiste disait que son parachute ne marche pas alors qu'il n'a pas tiré sur la poignée: logique, on s'écrase

Et on peux pas dire que les 'règles' soient nombreuses et compliquées à comprendre : 12 principes à respecter.
Un équipe qui a vraiment compris le sens de l'agilité, mettra Scrum (ou autre méthode parfaite pour commencer) au placard et fera pleinement de l’amélioration continu de ses pratiques avec pour seule guide ces 12 principes.

Par contre, là où je suis plutôt d'accord, c'est que l'Agilité deviens tellement un effet de mode, que forcement on retrouve dans plein d'entreprise de très mauvaise mise en place et de mauvais consultant 'expert' catch-agile, ....
Mais voyez qui on retrouve sur les conférences agiles de France: la question de la légitimité des experts que l'on ne voit jamais se pose.
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web