Les méthodes agiles sont-elles une arnaque ?
Les méthodes agiles sont-elles une arnaque ?
Les développeurs les préfèrent pour éviter de planifier et de documenter selon un rapport de Voke
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 ?
:fleche: Etes-vous d’accord avec ce rapport de Voke ? Pourquoi avez-vous adopté une méthode agile ?
L'agilité n'est pas une méthode !
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 !
Intent : moyen de garder la doc synchronisée
Je pense qu'un des problèmes majeurs avec la doc est de la garder à jour.
C'est toujours pénible d'avoir à penser à remettre à jour la doc au fur et à mesure des avancées du projet, et au final, comme elle est souvent désynchronisée, elle finit par être presque abandonnée (ou pire, elle est faite juste parce que ca fait parti des livrables, mais sans réel envie qu'elle soit utile).
Et avec les méthodes agiles, comme on livre de plus en plus souvent, cette désynchro est de pire en pire.
Et je trouve justement que le projet OpenSource Intent a bien ciblé ce problème et propose une solution assez sympa pour régler ça.
C'est un projet assez jeune mais on voit déjà à quoi ça va ressembler : http://www.eclipse.org/intent/
J'ai assisté à présentation du leader du projet et la vidéo vient d'être mise en ligne : http://t.co/e9xa5PQv
En gros, on peut à la fois avec de la doc dans une syntaxe WikiStyle, du code, des modèles de conception, et l'outil se charge tout seul de savoir si des désynchros ont eu lieu et aide à maintenir tout ça en cohérence.
Dans un contexte agile, je pense que ca aide pas mal.