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 !

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

26PARTAGES

8  0 
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 ?

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

Avatar de el_slapper
Expert éminent sénior https://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.
9  0 
Avatar de antoinev2
Membre averti https://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".
8  0 
Avatar de niarkyzator
Membre confirmé https://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.
6  0 
Avatar de transgohan
Expert éminent https://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.
5  0 
Avatar de beeboo
Membre confirmé https://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.
5  0 
Avatar de Traroth2
Membre émérite https://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
4  0 
Avatar de xelab
Membre expérimenté https://www.developpez.com
Le 24/03/2014 à 15:28
Citation Envoyé par el_slapper Voir le message

Imaginons que je sois grand chef. Qu'est-ce qui serait le plus confortable pour moi? Laisser les grouillots faire en priant pour que ça marche, ou décider tout seul et mener ce petit monde à la baguette?
En fait c'est les 2, mais dans cet ordre: "décider tout seul, mener ce petit monde à la baguette et laisser les grouillots faire (= se démerder) en priant pour que ça marche".
4  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 18/03/2014 à 14:23
Rien de bien nouveau sous le soleil. En 2008 et 2009, on dressait déjà le constat d'un échec massif de l'agilité car les aspects techniques n'étaient pas pris en compte, "Flaccid Scrum"...) Le mouvement Software Craftsmanship s'est construit à la même époque en réponse à cette tendance.

Le problème quand on dit "les méthodes agiles ont échoué" c'est que
1) on suppose que toutes les méthodes sont les mêmes à la base alors qu'il en existe de très différentes, dont certaines qui incluent des pratiques techniques et n'ont pas été si largement appliquées (XP pour ne pas le citer) et
2) on personifie des process alors que ceux qui ont échoué, c'est plutôt les gens qui ont essayé de les mettre en application sans comprendre les concepts sous-jacents ou "parce que c'est à la mode", sans même se demander si l'agilité répondait à leurs problèmes en premier lieu...

J'ai l'impression que l'auteur se tire une balle dans le pied avec ce titre, car il accepte le déplacement de l'étiquette "agile" sur un package qui n'a plus grand chose à voir avec l'esprit du manifeste d'origine. C'est un peu comme s'il appliquait son précepte "You should make it easy to throw away code and start again." à l'agilité. Je ne suis pas fan de jeter ainsi le bébé avec l'eau du bain, car oui il y a des équipes qui réussissent avec Agile, et accepter qu'on vide ainsi une approche de son sens, c'est renoncer un peu trop facilement à mon goût.
3  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 18/03/2014 à 14:53
Citation Envoyé par leminipouce Voir le message
Les consultants qui vont et viennent d'une ESN à une autre sont petit à petit passés par une case agile ou semi-agile. Parfois même y ont trouvé un intérêt... et cherche à le reproduire. Les décideurs savent qu'ils peuvent tirer des bénéfices de l'agilité et ne veulent pas rester en marge de ce qui se fait dans le monde, dans les grandes entreprises, dans les structures qui marchent.
On voit aussi de l'agile appliqué de la sorte :
Toute tache dure 2 semaines au maximum --> Si le dev dit qu'il faut 10-12 jours, c'est 2 semaines. S'il dit qu'il faut 20 jours, on coupe le truc en deux, et on fait 2 taches de 10 jours. S'il repond 50, on fait 5 taches. Et avec 9 femmes, on fait un bebe en un mois, c'est bien connu.
Stand-up réunion tous les matins, ou chacun dit ce qu'il a fait la veille et ce qu'il fera dans la journée. --> Hier, j'ai chercher comment contourner le probleme machin. Heureusement, il y a la reunion de ce matin pour que je vous en parle, car je ne suis pas allé voir le specialiste du truc pour avancer, j'ai preferé merder dans mon coin. Et j'oublie aussi celui qui te raconte sa vie pendant la reunion.
Et bien sur des aller-retour avec le client --> Ah oui, mais le developpeur ne parle pas au client, tout doit absolument passer par le chef de projet, qui reformule (quitte a ne plus poser la bonne question) et envoie et transfert la reponse.

C'est là tout le problème et un des points cruciaux de l'agilité. Reconnaître la valeur du développeur. Ou, en d'autres termes, pour le CP qui ne comprend rien à la technique, être capable de l'avouer/le reconnaître et faire confiance au dév.
C'est toi qui parle de SSII et de reconnaitre la valeur du developpeur, avec des chefs de projets competents qui sont capables d'avouer qu'ils ne savent pas quelque chose et de faire confiance a l'analyse du developpeur ? Nous n'avons pas connu les memes SSII !
3  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 18/03/2014 à 21:48
Nous sommes donc d'accord : avec un bon chef de projet, on mene a bien un projet, Agile ou pas. Et avec un mauvais, toute methodologie ne va que faire perdre du temps a une equipe qui doit s'auto-organiser pour combler les manques du CdP.

Dans les deux cas, Agile ne change pas grand chose.

Et ce que j'entends aujourd'hui autour d'Agile, c'est de la part de "cheffaillons" qui ne font que des conneries, mais qui arrivent bien a vendre les termes Agile, Scrum, Scrum-Master, ou n'importe quel buzz-word. Et c'est ca qui me derange : le probleme ne vient probablement pas d'Agile, qui est plutot a mon sens une bonne chose, mais c'est devenu tellement n'importe quoi que oui, pour moi, c'est malheureusement devenu a jeter.

Pour les exemples que j'ai pris, c'est malheureusement du vecu.
3  0