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 !

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 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.
7  0 
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...
7  0 
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é).
7  1 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 15/10/2015 à 18:05
Citation Envoyé par Traroth2 Voir le message
Voila revers de la médaille des délais au doigt mouillé décidé "en haut lieu" (c'est à dire par des gens qui n'y comprennent rien) : le cahier des charges - lettre au père Noël. Voila encore un domaine où l'agilité a complètement raté sa cible. Je ne vois pas en quoi moi, développeur, je devrais avoir mon mot à dire concernant le contenu du cahier des charges. Les gens du métier doivent savoir ce dont ils ont besoin. Ils sont là pour ça ! Je ne vois en quoi il y a là quelque chose à négocier. On est entre professionnels, pas sur un champs de course ! Le type qui dit "bon, pour raccourcir le délai, finalement ce bidule, on n'en aura pas besoin", pour moi, il a déjà complètement raté, professionnellement. Pourquoi demander qu'on développe un truc dont il n'a pas besoin ? Un cahier des charges doit toujours contenir le minimum nécessaire pour obtenir une application utilisable. Et là, on a un délai minimal. Ensuite, en se basant sur le retour des utilisateurs et sur un calcul de rentabilité, on peut enrichir. Supprimer l'effet tunnel ne devrait pas être seulement l'affaire de la DSI. Dans la vraie vie, la MOA demande tout ce qui lui passe par la tête. C'est lamentable.
Désolé pour toi, mais la réalité est toute autre : un cahier des charges vise effectivement à expliciter les besoins, mais hélas on ne vit pas dans un monde formel où les règles sont connues à l'avance, et donc complètement prédictible ou tout au moins complètement formalisable. Pour établir un cahier des charges, il faut savoir de quoi le client a besoin, mais le client lui-même ne sait pas forcément ce dont il a besoin. Il a éventuellement un (souvent plusieurs) problème(s) bien cerné(s), mais n'a justement pas la compétence pour savoir ce qui résoudrait ce(s) problème(s), autrement il le réglerait lui même. De l'autre côté, il y a le dév, qu'on estimera être super compétent parce que c'est un pro, qui connaît donc son domaine sur le bout des doigts mais n'a jamais fait face aux problèmes que connaît le client, puisque ce sont des problèmes spécifiques au domaine du client et non à celui du dév. Et comme on ne trouve ni baguette magique en supermarché ni expert extrasensoriel sur le marché de l'emploi, pour établir le cahier des charges il faut que le client et le dév se mettent ensemble autour de la table et discute des problèmes du premier et des solutions que le second peut apporter. À cela, il faut ajouter qu'expliciter ce qu'on sait n'a rien de trivial, on fait d'ailleurs la différence entre :
- ce qu'on sait savoir (known knowns)
- ce qu'on sait ne pas savoir (known unknowns)
- ce qu'on ne sait pas savoir (unknown knowns)
- ce qu'on ne sait pas ne pas savoir (unknown unknowns)

Le cahier des charges s'établit sur la base de ce qu'on sait, c'est à dire les deux premiers points : le premier permettra d'identifier les besoins déjà connus, le second identifiera les travaux de veille techno à effectuer. Cependant, il reste les deux derniers points. Et notamment le 3e, qui est au sujet de ce dont on ne se rend pas compte qu'on le sait. Cette partie là concerne notamment toutes les connaissances qu'on a fini par automatiser, à tel point qu'on l'a oublié et que ça nous paraît évident. C'est notamment ce qui est à la source des biais de raisonnement, mais aussi un des principaux problèmes en ingénierie des exigences : le client ne dit pas tout, pas forcément parce qu'il veut cacher des choses, mais simplement parce qu'il ne voit pas l'intérêt de le dire, tellement ça lui paraît évident (le dév est donc censé déjà le savoir, inutile donc de l'écrire). En fait, c'est même plus vicieux que ça, car on ne parle pas là de quelque chose qui viendrait à l'esprit du client et qu'il se dirait "oh, il doit être au courant, je passe", mais bien de quelque chose qui ne passe même plus par la case conscience. De la même manière que quand on marche, on ne se rend même plus compte qu'on met un pied devant l'autre, ça vient juste "comme ça" (alors qu'on est bien passé par une phase d'apprentissage où il fallait faire attention à bien s'appuyer sur un pied avant de bouger l'autre et de faire suivre le corps).

Bien entendu, le 4e point (unknown unknowns) n'est pas en reste non plus : souvent, le client viendra avec une idée préconçue de ce qu'il lui faut, alors qu'il n'a pas les compétences pour ça. Mais de par les connaissances qu'il a lui, il pense que telle ou telle chose pourra résoudre son problème. Et c'est de là que démarre le cahier des charges : pas du problème à résoudre, mais de l'idée préconçue que le client a de la solution. Or, souvent le client n'a tout simplement pas idée de ce qui se fait de mieux, voire il ne connaît pas suffisamment la solution qu'il a en tête pour se rendre compte qu'en fait il est à côté de la plaque. Le cahier des charges pourra être rédigé de la meilleure des façons, si la solution proposée ne résout pas le problème, le projet échouera lamentablement (et le dév dira que c'est la faute du client de ne pas savoir et le client la faute du dév de ne pas comprendre).

Avec ça, on comprend aisément pourquoi il vaut mieux avoir un contact entre client et dév qui soit direct, ce que prônent les méthodes agiles. Seulement, le dév ne connaît/comprends pas (en général) l'intégralité du problème du client (après tout c'est pas son domaine), et le cahier des charges se focalisant sur la solution à implémenter on fait face à une situation où les deux parties ont une connaissance incomplète et doive donc s'aligner. Le dév doit essayer d'identifier le problème du client en fonction de la solution qu'il demande, ce qui n'a rien d'évident vu que ça peut être une solution foireuse, et demander des précisions sur pourquoi le client veut telle ou telle fonctionnalité. En face, le client n'est pas forcément capable de dire tous les tenants et aboutissant (on n'est pas tous pédagogues), on n'est donc jamais sûr d'avoir la meilleure vision du problème, et donc jamais sûr de la pertinence de la solution proposée. C'est une des raisons principales pourquoi des projets en Waterfall peuvent foirer et qu'on prône l'agile quand c'est possible : la solution établie dans le cahier des charges peut ne pas être la bonne, et donc on privilégie les remises en question pour éviter l'échec final.

Donc non, personne n'est "censé savoir". Chacun sait des choses, et c'est en combinant et discutant qu'on établit les besoins et priorités. C'est pas comme à l'école où les questions sont bien choisies et ne reste alors qu'à choisir la bonne réponse. En dehors de l'école, il faut aussi savoir chercher les bonnes questions, et c'est tout un art.
6  0 
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...
6  1 
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.
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 14/10/2015 à 17:31
Ben oui. C'est toujours pareil : l'équipe qui a gagné la coupe du monde jouait en 4.2.3.1, donc plein d'équipes amateurs se sont mises à jouer en 4.2.3.1. Avec des résultats moins impressionnants. Est-ce surprenant?

Enfin, les crétins qui lisent le petit manuel et ensuite se proclament empereur du monde et emmènent leur organisation à sa perte, c'est vieux comme le monde.

Après, éviter leurs travers ne suffit pas à garantir le succès d'un projet. Avoir des gens compétents et humbles ne suffit pas toujours à assurer le succès d'un projet. Avoir un sponsor réaliste qui ne demande pas de refaire Amazon, en mieux, en 4 jours(mon père a reçu une offre de ce genre, et les 4 jours étaient payés 999€), c'est bien, mais ça ne suffit pas toujours à réussir le projet.

Notre putain de métier est difficile. Ce n'est pas le seul. On peut aligner des superstars du football et ne pas gagner la ligue des champions pendant des décennies. Comme bien d'autres, notre métier est difficile. Certaines théories peuvent être des outils utiles pour se planter moins souvent. Mais ça ne sont jamais que des outils. Dès lors qu'ils sont élevés au rang de religion, ils deviennent toxiques. Ça n'a rien de spécifique à l'agile.

Ma conclusion, c'est que les équipe compétentes, elles, sont plus fortes avec agile que sans. Les autres seront toujours des catastrophes, et ça c'est vrai depuis que le monde est monde.
4  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 26/10/2015 à 11:27
Citation Envoyé par RedGuff Voir le message
Agile place les commerciaux au dessus des développeurs, et c'est pour cela qu'il y a des problèmes
Je suis pas d'accord avec cette affirmation.
Agile place le produit au centre de tout plutôt.

Mais j'aimerais beaucoup connaître ton expérience (malheureuse) qui te fait penser cela.
Raconte nous tes soucis avec ton commercial.
Mais je sens que ce cher monsieur à corrompu l'Agilité pour utiliser les développeurs.
4  0 
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).
3  0 
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" ?
3  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web