Les méthodes agiles sont-elles une arnaque ?
Les développeurs les préfèrent pour éviter de planifier et documenter selon un rapport de Voke

Le , par Hinault Romaric, Responsable .NET
Présentées comme des méthodes de développement permettant de concevoir une application en impliquant au maximum le client, les méthodes agiles sont de nos jours de plus en plus adoptées dans les équipes de développement.

Ces méthodes tentent de résoudre les défauts des anciennes méthodes de gestion de projets en définissant quatre valeurs fondamentales : l’interaction avec les personnes plutôt que les processus et les outils ; des logiciels opérationnels plutôt qu'une documentation exhaustive ; la collaboration avec le client plutôt que la négociation contractuelle, la réactivité face au changement plutôt que le suivi d’un plan.

Derrière l’adoption grandissante des méthodes agiles se cacherait autre chose que le souhait de répondre au mieux aux besoins du client. Selon une étude du cabinet d’analyse Voke, les développeurs préfèrent les méthodes agiles pour éviter de planifier et de créer la documentation.

L’étude menée auprès de plus de 200 entreprises et experts IT a permis à Voke de faire ressortir seulement quatre observations détaillées décrivant le succès des méthodes agiles, avec 40% d’utilisateurs de ces méthodes qui n’ont identifié aucun avantage de celles-ci.

« Le mouvement Agile pourrait très bien être simplement soit une rébellion du développeur contre les taches indésirables et les horaires, ou tout simplement un moyen de vendre des services, y compris formation et certification Agile » conclut Voke.

Source : Le rapport de Voke (accessible après inscription)

Et vous ?

Etes-vous d’accord avec ce rapport de Voke ? Pourquoi avez-vous adopté une méthode agile ?


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


 Poster une réponse

Avatar de p1xl_01 p1xl_01 - Membre régulier http://www.developpez.com
le 16/07/2012 à 15:23
Salut

En quoi les méthodes Agile n'impliquent pas la rédaction d'une documentation?
Avatar de vaild vaild - Membre actif http://www.developpez.com
le 16/07/2012 à 15:23
... avis partagé. Je suis persuadé qu'à l'origine il s'agit effectivement d'un principe permettant au développeur d'être au plus prêt de son client, pour répondre au mieux et au plus vite à ses besoins.

Le contre-coup nous permettant d'être exemptés d'une partie des contraintes non-techniques, qui nous permet de nous recentrer sur l'essentiel en limitant les interruptions parfois malvenues de planification et prévision est bien sûr un bonus à ne pas négliger, mais je pense que ce n'est pas la raison de la création des méthodes agiles...
Avatar de forthx forthx - Membre confirmé http://www.developpez.com
le 16/07/2012 à 15:45
de mon expérience (j'ai adopté ces méthodes sur demande de mon chef de projet, initialement) il y a toujours beaucoup de doc, de réunions et d'heures sup. J'airais tendance a dire, dans le contexte dans lequel je l'ai vécu que les méthodes agiles apporte plus de souplesses dans le travail, ce qui permet de mettre plus de pression sur le développeur. Je n’aurai jamais fait 50h par semaines payé 35 si on m'avais dit de pointer a 8 et 17h, et sans une ambiance de travail me permettant d’être heureux au boulot.

Par contre j'ai connu une autre situation bien moins efficace ou on a essayer de faire marcher "certaines" méthodes agiles sur de la maintenance applicative, sans aucun membre de l’équipe de conception. (le projet ayant été conçu selon la bonne vielle méthode traditionnelle) Et effectivement a la place du client je n'aurais pas été satisfait.

Mon avis en général c'est qu’avec une bonne équipe, de la motivation et de la bonne volonté, l’agilité peu apporter énormément car elle laisse la liberté d’innover (aussi bien dans la gestion de l’équipe que du projet) avec un feedback. Si on est dans un projet en appliquant a la lettre la "méthode" trouvé dans un livre, ce n'est plus vraiment de l’agilité. Même si certains le revendiquent.
Avatar de alex.buisson alex.buisson - Membre du Club http://www.developpez.com
le 16/07/2012 à 15:52
Voila pour moi les personnes sondées... 200 Chef de projet de l'"ancienne école" accros du cycle en V et du Gant ! qui ont très certainement vu dans l'avènement des méthodes agile une attaque sur leur périmètres.

C'est vrai que les méthodes agiles paraissent plus souple, mais c'est complément faux. Il s'agit de vrai méthodes de bout en bout définissant clairement les rôles et les responsabilités de chacun. Ces Process combinés à l'usage de bonnes pratiques comme celles de l'XP, ont à mon sens révolutionner l'industrie du développement. Et ces méthodes sont de plus en plus appliquées et pour moi leur adoption est directement issue des échecs des anciennes méthodes.
Avatar de coolspot coolspot - Membre confirmé http://www.developpez.com
le 16/07/2012 à 15:52
Et ben si les méthode AGILE sont un moyen habile de faire faire au salarié 50h au lieu de 35, il faut en effet les interdire au plus vite. Car faire du travail gratuit, c'est du vol
Avatar de gmeyer gmeyer - Membre à l'essai http://www.developpez.com
le 16/07/2012 à 16:02
L’agilité n’est pas une méthode. Selon moi, c’est plutôt une philosophie qui conduit à observer nos métiers selon un angle précis, guidé par des principes fondateurs simples :
  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

Naturellement, des “méthodes” ou “frameworks” existent (Lean, Scrum, Kanban…), et sont nécessaires pour cadrer les pratiques, voire même pour faire adhérer aux principes sous-jacents de manière opérative.
Mais en fin de compte, la mâturité des équipes reste très faible sur l'agilité, et les SSII retardataires qui ne font que surfer la vague, noient encore plus le message d'origine à grands coups de marketing...
Pour celles et ceux que cela intéresse, j'ai posté un article il y a quelques semaines sur ce sujet :
Camarades agilistes, indignez-vous !
Avatar de Faiche Faiche - Membre confirmé http://www.developpez.com
le 16/07/2012 à 16:34
Comme on dit sur internet : "this post gave me cancer"

L'agile c'est pas une solution miracle qui va faire que tout va fonctionner et c'est la fête. Ce n'est certainement pas non plus l'anarchie. Et ce n'est pas un modèle en V rebrandé.

En gros, vous savez que c'est la merde quand vous entendez : "je suis chef de projet scrum master" ou "c'est de l'agile on fait pas de specs" ou encore "vous êtes en retard alors que vous faites de l'agile !".

Le modèle en V c'est un modèle théorique. Pour qu'il fonctionne, il faut que tout le monde soit parfait. Oh et que le monde arrete de tourner le temps qu'on sorte l'application.

Ce modèle plait aux "corporates" (chef de projet, personnel transverse et autres superviseurs) parce qu'il permet de mettre la tête dans le sable pendant 95% du projet, en n'envoyer que des rapports dans le vert (bon pour le bonus). Il ne reste plus que 5% de panique à la fin.

L'agile, c'est la volonté de regarder un projet informatique avec les yeux d'un adulte. On ne peut pas prédire l'avenir. Tout le monde se plante. Le monde change, les besoins aussi. Il peut arriver n'importe quoi.
L'agile c'est de dire "on sait qu'il y a des problèmes, et qu'on ne peut pas les prévoir. Ce qu'on peut faire, c'est limiter les risques au maximum".

Oui, l'agile c'est fait pour limiter les risques.

Exemple d'un risque : dans une grande société audiovisuelle, il y a eu un grand projet en interne sur plusieurs années pour gérer tout ce qui a trait à la publicité. On va passer sur les problèmes, sur les retard, ou sur l'ergo cauchemard. Le fait notable et marquant est le suivant : après 3 ans dans le pipe, à investir des millions, le projet sort enfin... Un mois avant l'application de la loi interdisant la publicité sur ce support.

S'ils avaient fait de l'agile, ils n'auraient pas changé la loi. Le projet aurait été mis à la poubelle au même moment. Par contre, vu qu'il y aurait eu des livraisons en prod régulière (2 semaines ou un mois), certaines parties de l'application auraient pu être utilisées pendant 2 ou 3 ans avant d'être obsolètes.

Les specs wiki, les test fonctionnels automatisés en avance de phase, le tdd, les équipes réduites, les user stories, le kanban, les rétrospective, le backlog, le pair programming, les standups, la communication avec le client... Tout ça, ce sont des outils de l'agile qui permettent de limiter un risque.

Pour répondre plus directement à la question : montrez moi un développeur qui n'est pas content de l'agile, je vous montre un projet qui n'est pas agile.
Avatar de Shinzul Shinzul - Membre averti http://www.developpez.com
le 16/07/2012 à 17:01
L'adoption des méthodes agiles peut être poussée par les développeurs mais généralement il s'agit plutôt d'une pression managériale ou business.

Le problème de ce type d'intégration au sein des équipes est que les clients n'entendent que ce qui les intéresses dans les méthodes agiles (entendre par la de la réactivité et une réponse rapide aux besoins).
Malheureusement, ceux-ci ne veulent pas se plier aux contraintes que l'agile impose et gardent leurs ancienne méthode en demandant plus de réactivité et de livraison aux équipes de dev.

Donc pour moi l'agile, si c'est vraiment appliqué, ne pose aucun problème aux développeurs, elles permettent même un gros gain mais elles demande une éducation des clients et de l'implication. Si les méthodes ne sont pas vraiment appliquées, elles deviennent effectivement un problème pour l'équipe à qui on demande d’être plus réatif et plus "agiles" sans amélioration réelle des méthodes de travail ...
Avatar de zeyr2mejetrem zeyr2mejetrem - Membre chevronné http://www.developpez.com
le 16/07/2012 à 17:07
Je suis assez d'accord avec Faiche.

Le problème n'est pas le concept, mais l'implémentation du concept.

Qui n'a pas travaillé avec un "Pointy-Haired Boss" qui interprète l'agilité uniquement comme une absence de documents ou de cadre contractuel qui permettrait au client de lui coller un papier sous le nez en lui disant "Ce n'était pas les termes du contrat, vous avez fait de la m***, je paie pas !!" ?

Qui n'a pas travaillé avec un client dont l'émissaire était une grosse feignasse qui trouve dans l'agilité l'excuse pour ne pas donner les billes pour mener le projet à bien (pas par malveillance mais parce que ça lui imposerai de faire autre chose que de blablater de façon interminable dans des réunions pour bosser et produire un document) ?

Le problème de l'agilité réside dans le fait qu'il prône une communication entre individus, donc plus verbale.
Cette communication laisse moins de traces et donc il est plus facile de se planquer quand on est un gros glandeur.

J'ai connu des projets menés à l'ancienne qui ont très bien marché.
J'ai connu des projets agiles où la dynamique était telle qu'on avait même pas l'impression qu'il y avait une conduite de projet et où ca a cassé la baraque.

A chaque fois l'élément commun était la bonne volonté et la qualité de l'équipe.

Hélas, j'ai aussi souvent connu l'inverse.
  • Chef de projet "Scrum Master XP+" injoignable et inexistant ou omniprésent, inflexible et avec un QI de moineau blond lobotomisé.
  • Représentant client qui n'a rien à péter du projet parce qu'il sait que de toute façon tout faire capoter lui apportera moins d'emm*** que de mener à bien. (Si si, ca se voit souvent chez les gros clients)
  • Développeurs glandeurs (si si, ca existe ) où hermétiques à tout changements.
Avatar de Traroth2 Traroth2 - Expert éminent http://www.developpez.com
le 16/07/2012 à 17:17
Juste une chose : pour ce que j'ai pu en voir, ce rapport est payant. Je veux bien aller jusqu'à m'inscrire sur leur site, mais de là à sortir 126,03 € pour un rapport (en fait, il s'agit de 2 rapports, donc 252.06 €), faut pas déconner !

Sur le fond, je pense qu'affirmer que les mauvaises pratiques qui découlent d'une mauvaise application des méthodes agiles peuvent vraiment constituer une critique valable de celles-ci, je ne suis pas sûr que ça soit bien sérieux.

Ce qui constitue pour moi le coeur des méthodes agiles :

  • Cycle de développement court
  • Développement itératif
  • Implication de représentants métiers du début à la fin du projet
  • Outillage du code avec des tests automatisés
  • Adaptation au changement en cours de route


Contrairement à beaucoup d'idées reçues, les méthodes agiles bien appliquées nécessitent de la discipline. Un des principes de l'XP, par exemple, est que le code doit toujours être le plus simple possible, sans duplication de code. Pour ce faire, le refactoring doit être constant ! Il faut constamment factoriser, maintenir à niveau, maintenir les tests, etc. Ce n'est pas forcément facile.

Je pense que les méthodes agiles viennent clairement d'un ras-le-bol de la part de la communauté des développeurs envers les méthodes anciennes dont le but était surtout de permettre à la hiérarchie de se rassurer, mais qui ne permettait pas de produire du logiciel de qualité. Ça ne veut pas dire que les méthodes agiles sont forcément plus simples à appliquer.

Oui, les méthodes agiles sont conçues, à mon avis, pour permettre aux développeurs de se consacrer sur leur travail, au lieu de devoir se consacrer à d'innombrables tâches parasites, mais je ne vois pas en quoi ça constitue un problème.

De par mon expérience, je sais que les méthodes agiles ne sont pas faciles à appliquer dans des entreprises qui n'ont pas une culture d'ingénierie très forte. Les commerciaux, les gens du marketing, les gens du métier ne sont pas faciles à convaincre, parce que effectivement ces méthodes sont conçues pour répondre aux besoins des développeurs, et que ça, souvent , ça déplait. Mais les logiciels qui ne fonctionnent pas bien, ça déplait aussi.
Le résultat, ce sont des méthodes agiles mal appliquées, et ça, ça débouche souvent sur des catastrophes :

http://en.wikipedia.org/wiki/Avalanche_model

Dans l'entreprise où je bosse, ils prétendent appliquer la méthode Scrum. En fait, ça veut effectivement dire qu'on travaille sans spec. Mais ça, ce n'est pas du Scrum, où le backlog constitue bel et bien une spec. Ils font de la Rache, en fait...
Offres d'emploi IT
Expert python - H/F
Skill Hunter - Languedoc Roussillon - Montpellier (34000)
Développeur Junior Java JEE
Editeur de Logiciel - Ile de France - Neuilly-sur-Seine
Architecte technique généraliste (infrastructure) H/F
Cegedim Outsourcing - Ile de France - Évry (91090)

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