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 !

Les d�veloppeurs devraient abandonner les m�thodes agiles selon Ron Jeffries
L'un des signataires du Manifeste Agile

Le , par Bill Fassinou

816PARTAGES

10  1 
Les d�veloppeurs devraient abandonner les m�thodes agiles
selon Ron Jeffries, l'un des signataires du Manifeste Agile

Ron Jeffries, un informaticien am�ricain de renom dit qu'on devrait abandonner les m�thodes agiles dans les entreprises. Son avis est d'autant plus important parce qu'il est l'un des 17 signataires du Manifeste pour le d�veloppement Agile de logiciels. Les m�thodes dites agiles sont un ensemble de propositions de d�marches et de pratiques pour la mise en �uvre d'un projet. Elles sont vite adopt�es par les entreprises surtout celles sp�cialis�es dans le d�veloppement d'applications informatiques. On voit alors appara�tre des alliances pour la promotion des m�thodes du Manifeste Agile : la Scrum Alliance, la Kanban Alliance... Des formations et des offres de projets agiles sont propos�es. Toutes ces solutions sont offertes pour assister les entreprises dans leur marche pour le d�veloppement. M�me si les m�thodes ne sont pas toujours bien respect�es, le fait de les essayer est toujours b�n�fique pour l'entreprise. Car cela leur aura permis d'avoir une vision globale sur l'�volution des projets et les aider dans leur prise de d�cision.

Cependant, les choses ne sont pas toujours aussi simples pour les d�veloppeurs et tous ceux qui participent � un projet agile. Erik Meijer, un d�veloppeur de l��cosyst�me .NET disait il y a quelques ann�es qu' � Agile est un cancer que nous devons �liminer de l�industrie �. Andy Hunt, l�un des 17 coauteurs du Manifeste Agile en 2001 n'a pas cach� aussi sa d�ception. Pour lui, Agile n'a pas atteint les objectifs escompt�s au d�part. Selon Amir Yasin, cofondateur et CTO de June (soci�t� US sp�cialis�e dans le recrutement des professionnels seniors de l�IT), � 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 �. C'est maintenant au tour de Ron Jeffries de donner son avis.


Lorsque les id�es sont mal appliqu�es, elles cr�ent souvent la confusion et entra�nent plus de travail � faire en peu de temps. Cela augmente par cons�quent la pression au sein de l'�quipe. Cet �tat de chose n'est pas toujours b�n�fique ni pour les d�veloppeurs ni pour l'entreprise. Car cela entra�ne plus d'erreurs et les objectifs sont de moins en moins atteints. Cette situation fait que plusieurs d�veloppeurs d�missionnent de leur poste et l'entreprise devient � coup s�r moins efficace avant que les m�thodes agiles ne soient adopt�es. Ron Jeffries dit qu�il partage la m�me pens�e que Kent Beck qui dit qu'il � voudrait que le monde soit s�r pour les d�veloppeurs �. Il dit �tre toujours un d�veloppeur et qu�il est �c�ur� de voir que les m�thodes du Manifeste Agile compliquent la t�che aux d�veloppeurs plut�t que de les aider. C�est aussi attristant de constater que l�entreprise n'obtient pas les r�sultats escompt�s.

Ron Jeffries estime qu�il est temps de passer � autre chose. Il conseille aux d�veloppeurs d�abandonner les m�thodes agiles. Selon lui, ce n'est pas les m�thodes qui sont en cause, mais plut�t la mani�re dont elles sont appliqu�es. Les d�veloppeurs devraient adopter les principes de base du Manifeste Agile ind�pendamment d�un framework ou d�une m�thode dans le d�veloppement d�application comme cela �tait pens� initialement par les signataires du Manifeste. Cela permet aux d�veloppeurs de s��panouir dans leur travail. Le logiciel �tant fonctionnel � tout moment, d�importants travaux d�extension peuvent �tre effectu�s dans un d�lai assez raisonnable. Au mieux, Ron Jeffries propose d'utiliser l'Extreme Programming qui tient compte de la gestion de projet dans la r�alisation de l'application.

Source : Ron Jeffries

Et vous ?

�tes-vous du m�me avis que Ron Jeffries ? Pourquoi ?
L'Extreme Programming ne va-t-il pas aussi conna�tre les m�mes probl�mes dans sa mise en pratique ?

Voir aussi

Un d�veloppeur estime qu'Agile est un � loup d�guis� en agneau �, le Waterfall 2.0, qu'en pensez-vous ?
CollabNet : l'adoption des pratiques agiles augmente en entreprise mais tr�s peu d'organisations auraient un haut niveau de comp�tence
La m�thode agile SCRUM est-elle une mauvaise m�thode de gestion de projet ? Oui r�pond un professionnel du secteur
Que faire pour minimiser l'impact des interruptions sur l'activit� de d�veloppement de logiciels ? Appliquer les m�thodes Agile ?
Vous avez lu gratuitement 1 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 22/05/2018 � 14:08
Citation Envoy� par clorr Voir le message
(.../...) il n'y a pas vraiment de m�thodo out-of-the-box qui puisse s'appliquer comme une recette magique.
�a.

Quand le donneur d'ordres n'a aucun contact avec la r�alit�, quand le recruteur ne connait que le co�t des gens, quand le chef de projet est incapable de sortir de sch�mas de pens�e pr��tablis, quand le d�veloppeur est quelconque, quand le testeur manque de flair, et que tout ce petit monde essaye de refaire google maps en mieux en 6 mois, comment dire..... Je ne sais pas quelle m�thode ils vont choisir, mais je sais d�j� qu'ils vont l'accuser de leur �chec.

Les gens qui ont sign� le manifeste agile �taient des pointures. Des gens � la fronti�re du progr�s, � l'�poque. Qui travaillaient dans d'excellentes conditions. Ils n'ont pas pu imaginer que dans de mauvaises mains, tout ceci puisse terminer abominablement mal. Leur m�thode fonctionne, quand elle est appliqu�e correctement.

Mais depuis les ann�es 1970, le vrai point de blocage est toujours le m�me : on choisit les gens n'importe comment, sur de mauvais crit�res, � tous les postes, et on esp�re na�vement que la m�thode perlimpinpin va permettre � 11 ch�vres de gagner la ligue des champions.
8  0 
Avatar de OuftiBoy
Membre �prouv� https://www.developpez.com
Le 14/08/2024 � 20:38
Bonjour � tous.

Nous voici donc avec une discution commenc�e en 2018 et qui "repart" en 2024. Int�ressant... Je n'avais pas particip� � l'�poque, car la discussion ressemblait plus � une guerre de religion qu'a autre chose.

J'ai maintenant une certaine exp�rience, et des m�thodes, j'en ai vu passer, du moins "th�oriquement".

Sans penser avoir "la solution" � la difficult� de r�ussir un projet "logiciel", j'ai, au fil du temps, remarqu� plusieurs choses. Je les cite en vrac.

- La "comp�tence" ou "formation" des "d�veloppeurs" a grandement diminu� depuis qlq d�c�nies. Je ne sais pas � quoi cela est d� exactement, c'est juste une constatation que j'ai faite. D'autres n'ont peut �tre pas ce ressentiment, et peut-�tre que cela d�pend du domaine dans lequel on bosse.

- Faire appel � la sous-traitance a toujours �t� un fiasco. Un sous-traitant n'est pas l� pour touver une "bonne solution" � un projet, mais � prendre tous les raccourcis possible pour livrer "au plus vite" quelque chose qui "ressemble" � une solution. Que cette solution puisse ou pas "�voluer" dans le temps long ne fait pas partie des pr�occupations. C'est m�me le contraire, afin de se rendre "indispensable" au "client", s'assurant la/les mises � jour.

- De plus en plus (�a doit �tre l'�poque qui veut �a), des mots magiques "sortent du lot" (pour l'instant c'est l'IA), et il faut utiliser ces nouvelles "religions" pour se sentir exister ou �tre "� la pointe du progr�s".

- De plus en plus de couches se sont gliss�es entre le besoin et la r�alisation de ce besoin. Au point de parfois m�me "inventer un besoin" pour justifier le r�le d'un "Poste".

- Pour monter en salaire, l'exp�rience n'est pas valoris�e, et la seule solution et de soit changer de bo�te, soit grimper dans la hi�rarchie de l'entreprise. Et l�, �a devient plus un jeu politique que technique, et les "camas" des "camas" auront toujours l'avantage, ce n'est plus une question de comp�tence.

- Tr�s vite arrive le "principe de peters", � savoir que l'on arr�te de monter lorsque l'on est arriver � un point ou l'on n'est plus comp�tent. Un bon d�veloppeur (pour gagner plus), tente de passer chef de projet, l� ou il sera �ventuellement m�diocre. L'entreprise perd un "bon d�veloppeur" et gagne un "mauvais chef de projet". Il suffirait d'augmenter le salaire des "bons d�veloppeurs" pour �viter la chose, mais sauf dans une entreprise o� le "logiciel" est au coeur du m�tier, "l'informaticien" ne sera jamais valoris�, c'est juste une "ressource" comme disent les RH, pensant qu'on remplace un "d�veloppeur" par un autre "d�veloppeur" comme on change une chaise par une autre.

- On complexifie inutilement les "porbl�mes a solutionner", mais aussi "la mani�re dont on les solutionne".

Les m�thodes permettent au "superviseur" du projet � avoir des graphiques et des "choses" a montrer � ses sup�rieurs. Un projet ne profite pas plus d'une m�thode que d'une autre.

En fait, la seule chose qui compte pour qu'un projet r�ussisse, c'est la communication entre les membres de l'�quipe, savoir dire "non", savoir expliquer pourquoi ce "non", privil�gier le bons sens, et s'en tenir au principe KISS. Il faut �galement savoir garder les gens l� o� ils sont le plus utiles � l'entreprise, et donc ne pas privil�gier la mont�e dans la hi�rarchie pour la mont�e en salaire.

Avec le temps, j'en suis arriver � la conclusion qu'il ne faut pas de "m�thode", ni de "documentation" (souvent g�n�r�e automatiquement et pas � jour, un code source clair, limpide et simple vaut 1000x toutes les documentations), mais �norm�ment d'�change et d'int�raction, pour comprendre les probl�mes (qui n'en sont peut-�tre pas). Une fois un probl�me bien cern�, impl�menter une solution limpide et le plus simplement possible.

Perso, je garde � jour un simple document, �volutif, dans lequel se trouve (1) ce que l'on fait, (2) pourquoi on le fait, et (3) comment on l'a fait. Le comment on l'a fait est mixte de "probl�me/solution" (expliquer le probl�me, et comment on le r�sout).

B�V et Peace & Love.
6  0 
Avatar de Bono_BX
Membre confirm� https://www.developpez.com
Le 22/05/2018 � 10:08
Il y a beaucoup de regrets dans ces explications, mais h�las, on ne peut que lui donner raison quand il dit "Lorsque les id�es sont mal appliqu�es".
Trop de SSII et d'incomp�tents se sont empar�s de l'Agilit� et lui ont port� atteinte (petite digression totalement hors sujet : je pr�vois exactement le m�me futur aux micro-services ...).

Et je suis totalement d'accord avec la conclusion :

Il conseille aux d�veloppeurs d�abandonner les m�thodes agiles. Selon lui, ce n'est pas les m�thodes qui sont en cause, mais plut�t la mani�re dont elles sont appliqu�es. Les d�veloppeurs devraient adopter les principes de base du Manifeste Agile ind�pendamment d�un framework ou d�une m�thode dans le d�veloppement d�application comme cela �tait pens� initialement par les signataires du Manifeste.
5  0 
Avatar de Kihm� Xs
Membre confirm� https://www.developpez.com
Le 22/05/2018 � 12:23
J'ai vu �norm�ment de projets g�r�s, pilot�s et manag�s avec une mentalit� "� l'ancienne" sur laquelle on a ajout� des principes agiles.

Et �a c'est le bordel, �a n'am�liore rien, on ajoute au contraire toujours plus de process et de complexit� sur le d�veloppeur.

A l'inverse, j'ai vu des projets pens�s agiles, o� malgr� la complexit� technique et fonctionnelle du projet, on obtient un projet o� tout va presque bien, et o� le d�veloppeur peut travailler en toute s�r�nit�.

Il faut juste savoir �tre critique et am�liorer ce qui doit l'�tre.
5  0 
Avatar de Luckyluke34
Membre �m�rite https://www.developpez.com
Le 22/05/2018 � 17:19
Citation Envoy� par Bill Fassinou Voir le message
Ron Jeffries estime qu�il est temps de passer � autre chose. Il conseille aux d�veloppeurs d�abandonner les m�thodes agiles.
Pas vraiment. Il recommande aux d�veloppeurs d'abandonner Agile, qu'il d�finit comme

"the many instances, approaches, and processes that use the word �agile� to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to �Faux Agile� for emphasis"

Citation Envoy� par Bill Fassinou Voir le message
il est �c�ur� de voir que les m�thodes du Manifeste Agile compliquent la t�che aux d�veloppeurs plut�t que de les aider.
L� c'est carr�ment un gros contresens, ce n'est pas "les m�thodes du manifeste agile" mais la fa�on dont elles sont interpr�t�es et appliqu�es en entreprise, ce qui change tout.

"their organization is doing �Agile� wrong: they�re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend"

La tonalit� de la news DVP ne me parait pas rendre justice � la pr�cision du contenu du billet de Jeffries - m�me si � sa d�charge, le titre volontairement sensationnaliste et provocateur n'aide pas. Pour moi, il appelle plus � un "protestantisme agile" qu'on pourrait r�sumer par :

R�sistez � la pression de "l'Agile d�voy�" qu'on vous impose, en rejetant toute m�thode �tiquet�e Agile mais en restant fid�le aux pratiques fondatrices de l'agile manifesto.
5  0 
Avatar de Terin
Membre habitu� https://www.developpez.com
Le 24/05/2018 � 12:27
Cycle en V ou m�thode Agile le fond du probl�me reste et resteras l'incomp�tence de la MOA (le client ou son repr�sentant) qui n'est que rarement capable d'exprimer un besoin correctement, la faute � une horde de cadre, chef de projet, produit, qui sont autant �loign� du besoin (le probl�me) que de l'outil (le d�veloppeur).

La grosse diff�rence c'est que la responsabilit� du r�sultat produit est imput� au d�veloppeur dans la m�thode agile (c'est pas �crit dans la m�thode, c'est mon triste constat), la MOA et MOE se d�charge de toute leur responsabilit� sur le technique qui supporte toute la charge du projet. Un projet agile �a se passe comme �a :

Client : J'ai besoin d'une table
MOA : on a besoin d'une table
MOE : Fait une table
D�veloppeur : j'ai fait une table
MOE : il a fait une table
MOA : voil� votre table
Client : mais la table passe pas ma porte ...
MOA : faut que la table passe la porte (voyons c'est �vident)
MOE : La table doit passer la porte !
D�veloppeur : Voil�, la table passe la porte
.
.
.

Un bonheur pour les SSII, un cauchemar pour les d�veloppeurs qui subissent tout (et encore j'ai r�duit de beaucoup le nombre d'interm�diaire). Au moins l'avantage du cycle en V, c'est qu'on r�dige un cahier des charges technique pour le dev (chose inexistante aujourd'hui) � partir d'un cahier des charges fonctionnels �tonnamment rare.

Pour ma part, nous travaillons uniquement en cycle en V avec nos prestataire de service, la charge de travail est plus cons�quente, mais les projets sont mieux faits et plus courts. Pour de l'interne, nous essayons de mettre en contact directement d�veloppeurs et les services en besoin, cela reste compliqu�, on cherche pas des d�veloppeurs experts full-stack, mais des humains avec une certaine sociabilit� capable de comprendre le m�tier, le besoin et d'y r�pondre, mais c'est tr�s compliqu� � trouver.
5  0 
Avatar de d_d_v
Membre exp�riment� https://www.developpez.com
Le 06/06/2024 � 9:18
Agile ou pas, ce qu'il faut � un moment, ce sont des sp�cifications �crites quelque part. J'ai l'impression que la m�thode agile est un pr�texte pour na jamais �crire de documentation technique. Je ne comprend m�me pas comment on peut penser que �a peut fonctionner.
Comment vous pouvez savoir si tel comportement dans le logiciel est normal ou pas s'il n'est document� nulle part. C'est encore pire quand le turnover est important: ceux qui d�tenaient la connaissance se sont barr�s et les nouveaux arrivants se d�brouillent comme ils peuvent.
6  1 
Avatar de pyros
Membre exp�riment� https://www.developpez.com
Le 06/06/2024 � 17:12
J'aimerai connaitre, parmis la part des projets "Agile" ayant �chou�, quels sont les projets vraiment Agile et quels sont les projets ou un caoch agile grassement pay� s'est point� en d�roulant son template et en collant des r�unions � tour de bras parce que c'est marqu� dans le Scrum Guide...

On s'est mis � faire de l'agile car les m�thodes de gestion projet classique type Waterfall ou cycle en V ne s'adaptaient pas aux projets portant sur des techno emergente ou des march� inconnue. Il y a beaucoup de projet o� on ne sait juste pas ce que le logiciel est cens� faire et o� m�me le client n'es sais foutre rien, (quoi qu'il puisse en penser). C'est l� qu'Agile a un int�ret. Il permet de piloter un syst�me cahotique par it�ration successive.

Pour un system connue, contrain et un march� stable comme l'a�ronautique, le m�dical, etc... Agile a beaucoup moins d'int�ret. Il faut arr�ter de vouloir trouver une formule magique qui marche partout.
5  0 
Avatar de KnifeOnlyI
Membre r�gulier https://www.developpez.com
Le 22/05/2018 � 9:30
Personnellement je d�teste les arguments d'autorit� du genre

Son avis est d'autant plus important parce qu'il est l'un des 17 signataires du Manifeste pour le d�veloppement Agile de logiciels.
Sa me donne envie de faire l'exacte contraire de ce qu'on me dit.

Si une �quipe projet fonctionne bien (quelque soit la m�thode choisie) pourquoi changer ?
4  1 
Avatar de clorr
Membre averti https://www.developpez.com
Le 22/05/2018 � 12:24
Quand on voit que m�me les cr�dits bancaires sont devenus "agiles", on comprend que la m�thode est depuis longtemps d�voy�e par son succ�s marketing. Beaucoup de gens dans les hi�rarchies parlent d'agilit� sans avoir compris que dans l'agile, c'est la base qui doit rester maitresse de l'organisation.

L'autre chose, c'est que Scrum ou Kanban marchent pas trop mal sur du court terme, mais sur des gros projets, il n'y a pas vraiment de m�thodo out-of-the-box qui puisse s'appliquer comme une recette magique.
3  0