L'esprit agile est-il en voie de disparaître ?
13 ans après la publication du manifeste agile, un développeur note l'échec des méthodes agiles

Le , par Arsene Newman, Expert éminent sénior
Tout professionnel de l’IT s’accorde à dire que le développement logiciel n’est pas une mince affaire. Par le passé, cela reposait essentiellement sur des méthodes et des processus de développement lourds, rigides et coûteux, qui conduisaient à des cycles de développement assez lents. En 2001 le manifeste agile a été publié. Ce dernier décrit une nouvelle approche, une nouvelle famille de méthodes de développement logiciel dites « méthodes agiles ».

Toutefois, ce manifeste décrit les grandes lignes pour des méthodes de développement axées sur le développeur, la collaboration étroite entre l’équipe de développement et le client ainsi que l’importance du feedback des utilisateurs.

13 ans plus tard, force est de constater que les méthodes agiles ont échoué. C’est en tout cas ce que pense Mike Hadlow, un développeur senior, dans un billet de blog. Mais alors pourquoi cet échec ? Une dérive, une incompréhension ou encore un abus serait à l’origine de l’échec, selon celui-ci.

Agile est en premier lieu un état d’esprit mettant au centre de la scène le développeur, chacun doit trouver son propre rythme en suivant un chemin balisé par des méthodes connues. Il ne s’agit donc pas de méthodes de management de l’équipe de développement ni de recourir d’une manière bête et disciplinée à certaines pratiques telles que les stand-up meeting journalier, à de courtes itérations de 2 semaines et à de micro deadlines trop rigides.

Une des conséquences de la mauvaise interprétation/application des concepts agiles est la désignation de chefs de projet non sensibles à l’aspect technique du développement logiciel, ces derniers étant alors initiés aux méthodes agiles en les considérant à tort comme des méthodes de management.

En effet quoi de mieux qu’un développeur pour en comprendre un autre ? Hors si les méthodes agiles se targuent d’être centrées sur le développeur et que le chef de projet n’est pas dans cette dynamique, cela conduira inévitablement à l’échec. Dans le cas contraire, cela relève de la chance ou d'autres facteurs, mais certainement pas de l’application d’une méthode agile.

Au final, il demeure clair que la réussite de la mise en œuvre d’une méthode agile passe en premier lieu par une bonne compréhension des aspects techniques du développement, de la capacité du chef de projet à sympathiser avec le développeur et à le motiver, faute de cela, les méthodes agiles subsisteront, mais l’esprit agile sera en perdition et finira par mourir.

Source : blog de Mike Hadlow

Et vous ?

Qu’en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de el_slapper el_slapper - Expert éminent sénior http://www.developpez.com
le 17/03/2014 à 15:38
Pas grand chose. En football, on se doute bien qu'aligner 11 chèvres avec la meilleure tactique du monde ne suffira pas à battre le PSG. En informatique, par contre, ça parait évident. Et, à la fin, c'est le PSG qui gagne.

Plus sérieusement(en en espérant ne pas voir des hordes d'antiparisiens venir m'étriper, à une époque, c'est l'OM qui était difficille à battre, à une autre l'OL, etc...), l'article pointé en lien est très bien. On est pas forçé d'être d'accord sur tout(il me semble un poil extrême sir les estimations), mais il me plait beaucoup, et il fait un état des lieux (hélas) fort précis. Sa liste à points est très interessante :
•(1)The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team.
•(2)The motivation and empowerment of programmers has a direct and strong relationship to the quality of the software.
•(3)Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.
•(4)The consequences of poor design decisions multiply rapidly.
•(5)It will usually take multiple attempts to arrive at a viable design.
•(6)You should make it easy to throw away code and start again.
•(7)Latency kills. Short feedback loops to measurable outcomes create good software.
•(8)Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy.
•(9)Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software.

Tous sont débatables, mais j'adore les points 3, 6 et 7. Que je vais réinterpréter en Français
(3) Les dates de livraisons en dur, spécialement quand elles sont innombrables, flinguent le projet. Perso, je peux comprendre qu'il faille livrer la gestion de l'Euro avant le 31 Décembre 2012. Mais quand une directrice de projet exige des preuves de progrès deux fois par jour, et par conséquent des respects de dates de livraisons systématiques et multiquotidiennes, on passe son temps à planifier, pas à bosser.
(6) Le code n'est pas sacré : il faut pouvoir tout balancer et tout recommencer sans avoir l'impression de se tirer une balle dans le pied. Mon opinion : on fait souvent fausse route, donc un demi-tour facile est essentiel.
(7) La latence tue. Des retours d'information rapides sont indispensables pour réaliser un bon projet. Toujours d'accord, toujours pour la même raison : on faut souvent fausse route, et mieux vaut s'en apercevoir au bout de 2 jours qu'au bout de 2 ans.

J'ajouterais juste qu'un manager non-technique peut être utile, mais à condition d'avoir parfaitement intégré son incompétence technique. Si il passe son temps à animer l'équipe, à chercher quels sont les obstacles et comment les aplanir, a vérifier que tout le monde reste dans le périmètre, et que globalement les gens avancent, alors il peut être très utile. J'en ai vu. Manque de pot, la plupart tentent de tout contrôler(pour asseoir leur pouvoir), et le résultat est celui décrit par le bloggueur.
Avatar de Traroth2 Traroth2 - Expert éminent http://www.developpez.com
le 18/03/2014 à 10:57
Après avoir vu diverses tentatives plus ou moins honnêtes de mise en oeuvre de Scrum, force est de constater que c'est vrai. Le problème de base, c'est que l'agilité cherche à mettre le développeur au centre du processus de développement. Et ça, malheureusement, personne dans le management de la DSI, à fortiori de l'entreprise, n'en a envie. Le point de vue réel est de considérer les développeurs comme des pions interchangeables, des "ressources". Et là, en réalité, on est aux antipodes de l'agilité. Les méthodes agiles servent aussi de prétexte à tout un tas de mauvaises pratiques, par exemple l'absence de specs.

Typiquement : https://en.wikipedia.org/wiki/Avalanche_model
Avatar de transgohan transgohan - Expert confirmé http://www.developpez.com
le 18/03/2014 à 11:01
J'en pense qu'Agile n'est pas prêt de disparaître du jour au lendemain.
Le seul problème de cette méthode c'est quand on ne joue pas le jeu.
Managers qui font du cycle en V, maitrise d'oeuvre qui fait du cycle en V et développeurs qui font de l'agile.
L'une des combinaison qui va faire échouer un projet...

Cela fait un an que nous avons quitté le cycle en V dans mon équipé pour partir sur de l'Agile (à la demande du PDG).
Nous avons vu de nombreuses améliorations de notre process et de notre qualité suite à l'application de ces méthodes.
Mais le boulet que l'on traîne c'est que les managers ont été formés après nous (voir pas du tout) et font toujours du cycle en V...
Et même s'ils sont formés ils n'adhèrent pas à la méthode car ils comprennent bien qu'ils ont un engagement qu'ils n'avaient pas avant...
Sont pas fous ! Si ça merde c'est leur faute maintenant.

Bref c'est le même principe que de tenter de parler chinois à un français.
S'il ne comprend pas le chinois c'est peine perdu...

Les méthodes agiles servent aussi de prétexte à tout un tas de mauvaises pratiques, par exemple l'absence de specs.

Ce n'est pas un problème des méthodes agiles selon moi mais un problème de mauvaise utilisation de ces méthodes.
Avatar de Carhiboux Carhiboux - Expert éminent http://www.developpez.com
le 18/03/2014 à 11:06
Merci d'avoir corrigé le titre, cela me piquait horriblement les yeux (oui je sais hôpital, charité, je fais aussi des fautes ).

Les principaux défauts des méthodes agiles à mon sens sont :

1) Que ça ne marche que sur les petites équipes. Au delà de ... allez... 6-7 personnes, c'est difficile à maintenir.

2) Que comme dit dans l'article, les chefs de projets confondent agilité avec méthodologie de management rigide.

3) Le client n'est pas toujours disposé à jouer le jeu. Le concept le séduit de prime abord, mais il se rends ensuite compte de la charge de travail hebdomadaire et il finit par ne plus forcément faire sa part. Alors que dans un projet classique, il travaillera tout autant, mais de manière moins planifiée... Mais il préférera souvent parce qu'il aura certainement l'impression d'être moins "contraint".
Avatar de niarkyzator niarkyzator - Membre confirmé http://www.developpez.com
le 18/03/2014 à 11:16
Le problèmes des méthodes Agiles est simple : c'est avant tout basé sur le bon sens.

Or les managers / chefs de projets ne veulent pas de "bon sens", ils veulent des règles simples qu'on peut appliquer bêtement.
Avatar de Njörd Njörd - Membre averti http://www.developpez.com
le 18/03/2014 à 11:24
Bonjour,

Je pense également qu'il faut laisser du temps pour que de nouvelles entreprises apparaissent sur notre marché (donc compter quelques 20 à 30 années pour que ce soit dans les mœurs, aussi bien du côté entreprise que côté client). Nouvelle entreprise, donc plus facile de mettre en place les méthodes agiles en partant de zéro.

Le problème, bien souvent, c'est le changement. On rechigne toujours. Dans les entreprises ayant déjà leur culture et leur façon de fonctionner, ça me paraît très difficile (mais pas impossible) de mettre en place les méthodes agiles. Rien que les jeux de pouvoir suffisent à empêcher le changement.
Avatar de antoinev2 antoinev2 - Membre averti http://www.developpez.com
le 18/03/2014 à 11:40
C'est comme beaucoup de belles théories : l'objectif est noble mais la nature de l'homme reprend vite le dessus.

D'après ce que j'ai vu, l'agilité est un superbe prétexte pour les MOA et les clients pour justifier le manque ou l'absence de leur méthodologie, de leur suivi.
Le dev agile signifie à leurs yeux "je peux demander à mon développeur tout ce que je veux et changer d'avis aussi souvent que je veux, il se débrouille pour appliquer."
En cas d'échec, qui est responsable? Le dev qui n'a pas su être "agile".
Avatar de ange ange - Membre à l'essai http://www.developpez.com
le 18/03/2014 à 11:42
Je viens de voir passer "le bon sens" ....
J'ai pratiqué les méthodes "agiles" comme xP ou Rad au début et je trouvais qu'elle avaient du sens parce que très orientées technique. Mais lorsqu'une méthode arrive et parle de "bon sens" alors là !!!!!!!
C'est quoi le bon sens ? Et celui de qui ? Une petite définition :
"Le bon sens est l'intermédiaire entre l'ignorance et la connaissance bien assurée. Il est la raison sans raisons. Entre la sphère théorique où l'on s'entend rarement sur le sens d'un mot ou d'une idée et la sphère pratique où l'on doit agir, le plus souvent sans être assuré de pouvoir le faire en connaissance de cause, il y a un vide. Le bon sens comble ce vide. Il est la «la saine et droite raison», dit le Littré et plus loin: «le sens commun, l'intelligence et la lumière avec laquelle naissent la plupart des gens.» Le bon sens est de nos jours défini comme la raison en tant qu'elle remplit le vide laissé par la science: «capacité de bien juger, sans passion, en présence de problèmes qui ne peuvent être résolus par des raisonnements scientiques» (Le petit Robert)."
Pour ma part je préfère une connaissance même si elle n'est pas super bien assurée qu'un truc qui navigue entre ignorance et connaissance... parc que bien souvent ça va pencher vers le premier !!
Donc quand une méthodo arrive avec ce genre de concept ... je craint le pire !
Sans compter qu'un des autres grands concepts fondateurs qui m'amuse est : "courage"
Avatar de beeboo beeboo - Membre confirmé http://www.developpez.com
le 18/03/2014 à 11:50
Mon expérience perso : dans la plupart des projets, le problème principal c'est le "chef de projet", peu importe la méthode.
Avatar de spyserver spyserver - Membre averti http://www.developpez.com
le 18/03/2014 à 12:24
D'après ce que j'ai vu, l'agilité est un superbe prétexte pour les MOA et les clients pour justifier le manque ou l'absence de leur méthodologie, de leur suivi.
Le dev agile signifie à leurs yeux "je peux demander à mon développeur tout ce que je veux et changer d'avis aussi souvent que je veux, il se débrouille pour appliquer."
En cas d'échec, qui est responsable? Le dev qui n'a pas su être "agile".

Tout à fait d'accord ! Dans mon projet, notre client a exactement ce comportement, non sincèrement mieux vaut un cycle en V que du "mauvais" Agile, soit 90% des projets.
Offres d'emploi IT
Front-end developer H/F
Mirakl - Ile de France - Paris 16e
Développeur Open Erp sous Python
REIBEL CONSULTANTS - Languedoc Roussillon - Béziers (34500)
Consultant décisionnel h/f
MCNEXT - Ile de France - Paris (75002)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil