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 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

5PARTAGES

5  1 
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 ?

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

Avatar de Faiche
Membre confirmé https://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.
20  0 
Avatar de zeyr2mejetrem
Membre chevronné https://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.
17  1 
Avatar de gmeyer
Membre à l'essai https://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 !
11  0 
Avatar de Traroth2
Membre émérite https://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...
9  0 
Avatar de MenshaKaine
Membre régulier https://www.developpez.com
Le 17/07/2012 à 11:14
Analysons cette phrase:

« 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.
On trouve sémantiquement les mots:
rébellion, taches indésirables, horaires

Il s'agit bien encore de présenter les développeurs comme des empêcheurs de tourner en rond ou plus tot comme des gens qui n'aime pas qu'on les presse comme des citrons !

De plus, on associe ce mouvement au développeur ... sont-il les seules à participer à la création de produits informatiques ?
D 'où un développeur doit-il tous faire ? Est-il le seul à fournir de la plus-value ? Est-il le seul à connaitre son produit ? Et les autres font quoi ?

Je me demande qui a commandé cette enquête !

Mon observation du monde de l'IT m a montré que peu de gens ont une démarche produit ... maintenant agile, cycle en V, ... y-a-t-il un processus idéal ? Un processus qui remplace les hommes compétents et de bonne volonté ?

Merci et bonne journée.
5  0 
Avatar de gl
Rédacteur https://www.developpez.com
Le 17/07/2012 à 22:00
Citation Envoyé par Drawingrom Voir le message
Pourquoi faire la distinction entre anomalie et évolution et ne pas simplement faire évoluer le programme ?
Généralement pour savoir qui assume le coût, le client ou toi.
5  0 
Avatar de p1xl_01
Membre régulier https://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?
4  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 16/07/2012 à 17:42
Citation Envoyé par Grimly Voir le message
J'ai déjà vu le projet Agile à la "définition fonctionnelle uniquement et surtout pas technique". J'ai fait mes propres parties communes avec documentations (vu que les autres n'en avaient pas). Performances multipliés par 100 juste par le fait que les outils étaient bien utilisés par mes collègues et pas utiliser certaines anciennes fonctions des bourrins pour ouvrir des sessions pour récolter des infos dans un seul champ (sur des milliers d'enregistrements ).

Et non je ne suis pas dieu. On s'est rendu compte bien plus tard que mes fonctions existaient déjà. On ne savais juste pas qu'elle étaient là.
Une rumeur très répandue voudrait que les méthodes agiles seraient contre la documentation. C'est totalement faux. Simplement, elles préfèrent une documentation minimaliste plutôt que des PDF et des Powerpoint vendus au kilo. De préférence de la documentation embarquée dans le code, façon Javadoc ou Doxygen. L'avantage, c'est que ça a plus tendance à rester à jour. Parce que le PDF de 200 pages, il restera comme il est pendant 10 ans et, une fois obsolète, induira plus en erreur qu'il ne donnera d'informations.
4  0 
Avatar de Faiche
Membre confirmé https://www.developpez.com
Le 16/07/2012 à 17:51
Citation Envoyé par Traroth2 Voir le message

Je pense que les méthodes agiles viennent clairement d'un ras-le-bol de la part de la communauté des développeurs
[...]
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.
Non non, ni "par les développeurs" ni "pour les développeurs". Ne pas confondre l'outil et l'objectif.

Le but c'est de livrer le meilleur produit dans le meilleur budget/temps.

Les "taches parasites" c'est un coût, un risque. Il y a donc des outils dans l'agile qui permettent de s'en abstraire (standup de 5 min le matin plutot que réunion de 2h hébdomadaire, management visuel plutot que reporting et réunions ...)

Et d'expérience, une direction marketing sera bien plus intéressée par l'agile que la DSI. Parce que la méthode agile remet le business en avant, comme enjeu principal.

@Grimly : Un projet c'est un ensemble de besoins fonctionnels. Chaque développement entrepris doit avoir une valeur directement pour le client. On ne paye pas pour un socle d'entreprise, on paye pour une fonctionnalité.
Maintenant s'il y a des outils qui doivent être réutilisés, il est de ton devoir de le communiquer.

Pour ça repose toi sur les standups, les retros et un wiki. Mais ce qui te permettra le mieux de réussir, c'est de binomer de temps en temps.
Dans mes différents projets, on a mis en place une validation de code croisée avant de livrer chaque story. C'est le créneau idéal pour comparer les pratiques et arriver à un standard.
4  0 
Avatar de Shinzul
Membre averti https://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 ...
4  1