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 
Envoyé par Traroth2
