Moxie Marlinspike : Agile tue l'innovation en confinant les développeurs dans des boîtes noires d'abstraction

Les développeurs devraient abandonner les méthodes agiles
selon Ron Jeffries, l'un des signataires du Manifeste Agile

Ron Jeffries, un informaticien américain de renom dit qu'on devrait abandonner les méthodes agiles dans les entreprises. Son avis est d'autant plus important parce qu'il est l'un des 17 signataires du Manifeste pour le développement Agile de logiciels. Les méthodes dites agiles sont un ensemble de propositions de démarches et de pratiques pour la mise en œuvre d'un projet. Elles sont vite adoptées par les entreprises surtout celles spécialisées dans le développement d'applications informatiques. On voit alors apparaître des alliances pour la promotion des méthodes du Manifeste Agile : la Scrum Alliance, la Kanban Alliance... Des formations et des offres de projets agiles sont proposées. Toutes ces solutions sont offertes pour assister les entreprises dans leur marche pour le développement. Même si les méthodes ne sont pas toujours bien respectées, le fait de les essayer est toujours bénéfique pour l'entreprise. Car cela leur aura permis d'avoir une vision globale sur l'évolution des projets et les aider dans leur prise de décision.

Cependant, les choses ne sont pas toujours aussi simples pour les développeurs et tous ceux qui participent à un projet agile. Erik Meijer, un développeur de l’écosystème .NET disait il y a quelques années qu' « Agile est un cancer que nous devons éliminer de l’industrie ». Andy Hunt, l’un des 17 coauteurs du Manifeste Agile en 2001 n'a pas caché aussi sa déception. Pour lui, Agile n'a pas atteint les objectifs escomptés au départ. Selon Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau ». C'est maintenant au tour de Ron Jeffries de donner son avis.

Pièce jointe 381887

Lorsque les idées sont mal appliquées, elles créent souvent la confusion et entraînent plus de travail à faire en peu de temps. Cela augmente par conséquent la pression au sein de l'équipe. Cet état de chose n'est pas toujours bénéfique ni pour les développeurs ni pour l'entreprise. Car cela entraîne plus d'erreurs et les objectifs sont de moins en moins atteints. Cette situation fait que plusieurs développeurs démissionnent de leur poste et l'entreprise devient à coup sûr moins efficace avant que les méthodes agiles ne soient adoptées. Ron Jeffries dit qu’il partage la même pensée que Kent Beck qui dit qu'il « voudrait que le monde soit sûr pour les développeurs ». Il dit être toujours un développeur et qu’il est écœuré de voir que les méthodes du Manifeste Agile compliquent la tâche aux développeurs plutôt que de les aider. C’est aussi attristant de constater que l’entreprise n'obtient pas les résultats escomptés.

Ron Jeffries estime qu’il est temps de passer à autre chose. Il conseille aux développeurs d’abandonner les méthodes agiles. Selon lui, ce n'est pas les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. Les développeurs devraient adopter les principes de base du Manifeste Agile indépendamment d’un framework ou d’une méthode dans le développement d’application comme cela était pensé initialement par les signataires du Manifeste. Cela permet aux développeurs de s’épanouir dans leur travail. Le logiciel étant fonctionnel à tout moment, d’importants travaux d’extension peuvent être effectués dans un délai assez raisonnable. Au mieux, Ron Jeffries propose d'utiliser l'Extreme Programming qui tient compte de la gestion de projet dans la réalisation de l'application.

Source : Ron Jeffries

Et vous ?

:fleche: Êtes-vous du même avis que Ron Jeffries ? Pourquoi ?
:fleche: L'Extreme Programming ne va-t-il pas aussi connaître les mêmes problèmes dans sa mise en pratique ?

Voir aussi

:fleche: Un développeur estime qu'Agile est un « loup déguisé en agneau », le Waterfall 2.0, qu'en pensez-vous ?
:fleche: CollabNet : l'adoption des pratiques agiles augmente en entreprise mais très peu d'organisations auraient un haut niveau de compétence
:fleche: La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui répond un professionnel du secteur
:fleche: Que faire pour minimiser l'impact des interruptions sur l'activité de développement de logiciels ? Appliquer les méthodes Agile ?

Citation:

---

Envoyé par Bill Fassinou

Erik Meijer, un développeur de l’écosystème .NET disait il y a quelques années qu' « Agile est un cancer que nous devons éliminer de l’industrie ». Andy Hunt, l’un des 17 coauteurs du Manifeste Agile en 2001 n'a pas caché aussi sa déception. Pour lui, Agile n'a pas atteint les objectifs escomptés au départ. Selon Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau ». C'est maintenant au tour de Ron Jeffries de donner son avis.
(...)
Ron Jeffries estime qu’il est temps de passer à autre chose. Il conseille aux développeurs d’abandonner les méthodes agiles. Selon lui, ce n'est pas les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. Les développeurs devraient adopter les principes de base du Manifeste Agile indépendamment d’un framework ou d’une méthode dans le développement d’application comme cela était pensé initialement par les signataires du Manifeste. Cela permet aux développeurs de s’épanouir dans leur travail. Le logiciel étant fonctionnel à tout moment, d’importants travaux d’extension peuvent être effectués dans un délai assez raisonnable. Au mieux, Ron Jeffries propose d'utiliser l'Extreme Programming qui tient compte de la gestion de projet dans la réalisation de l'application.

---

Moi je pense qu'il ne faut suivre aucun protocole (agile ou pas) à la lettre.
Il faut une gestion de projet un peu batarde, en prenant les bonnes idées à gauche à droite.

Ok l'agile ça peut être nul, mais on ne va pas faire du cycle en V strict quand même !? (dans la plupart des cas, les projets évoluent pendant le développement)

Citation:

---

Envoyé par Bill Fassinou

:fleche: Êtes-vous du même avis que Ron Jeffries ? Pourquoi ?

---

Les développeurs font ce qu'ils veulent...
Si ils ont un bon résultat avec leur gestion de projet agile pourquoi en changer ?

Citation:

---

Envoyé par Bill Fassinou

:fleche: L'Extreme Programming ne va-t-il pas aussi connaître les mêmes problèmes dans sa mise en pratique ?

---

L'Extreme programming c'est un truc de 1999, c'est pas forcément mieux que Scrum ou Kanban...
Ça me semble même plus compliqué et lourd que le reste.

Personnellement je déteste les arguments d'autorité du genre

Citation:

---

Son avis est d'autant plus important parce qu'il est l'un des 17 signataires du Manifeste pour le développement Agile de logiciels.

---

Sa me donne envie de faire l'exacte contraire de ce qu'on me dit.

Si une équipe projet fonctionne bien (quelque soit la méthode choisie) pourquoi changer ?

Il y a beaucoup de regrets dans ces explications, mais hélas, on ne peut que lui donner raison quand il dit "Lorsque les idées sont mal appliquées".
Trop de SSII et d'incompétents se sont emparés de l'Agilité et lui ont porté atteinte (petite digression totalement hors sujet : je prévois exactement le même futur aux micro-services ...).

Et je suis totalement d'accord avec la conclusion :

Citation:

---

Il conseille aux développeurs d’abandonner les méthodes agiles. Selon lui, ce n'est pas les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. Les développeurs devraient adopter les principes de base du Manifeste Agile indépendamment d’un framework ou d’une méthode dans le développement d’application comme cela était pensé initialement par les signataires du Manifeste.

---

J'ai vu énormément de projets gérés, pilotés et managés avec une mentalité "à l'ancienne" sur laquelle on a ajouté des principes agiles.

Et ça c'est le bordel, ça n'améliore rien, on ajoute au contraire toujours plus de process et de complexité sur le développeur.

A l'inverse, j'ai vu des projets pensés agiles, où malgré la complexité technique et fonctionnelle du projet, on obtient un projet où tout va presque bien, et où le développeur peut travailler en toute sérénité.

Il faut juste savoir être critique et améliorer ce qui doit l'être.

Quand on voit que même les crédits bancaires sont devenus "agiles", on comprend que la méthode est depuis longtemps dévoyée par son succès marketing. Beaucoup de gens dans les hiérarchies parlent d'agilité sans avoir compris que dans l'agile, c'est la base qui doit rester maitresse de l'organisation.

L'autre chose, c'est que Scrum ou Kanban marchent pas trop mal sur du court terme, mais sur des gros projets, il n'y a pas vraiment de méthodo out-of-the-box qui puisse s'appliquer comme une recette magique.

Alléluia !

Citation:

---

Envoyé par clorr

(.../...) il n'y a pas vraiment de méthodo out-of-the-box qui puisse s'appliquer comme une recette magique.

---

ça.

Quand le donneur d'ordres n'a aucun contact avec la réalité, quand le recruteur ne connait que le coût des gens, quand le chef de projet est incapable de sortir de schémas de pensée préétablis, quand le développeur est quelconque, quand le testeur manque de flair, et que tout ce petit monde essaye de refaire google maps en mieux en 6 mois, comment dire..... Je ne sais pas quelle méthode ils vont choisir, mais je sais déjà qu'ils vont l'accuser de leur échec.

Les gens qui ont signé le manifeste agile étaient des pointures. Des gens à la frontière du progrès, à l'époque. Qui travaillaient dans d'excellentes conditions. Ils n'ont pas pu imaginer que dans de mauvaises mains, tout ceci puisse terminer abominablement mal. Leur méthode fonctionne, quand elle est appliquée correctement.

Mais depuis les années 1970, le vrai point de blocage est toujours le même : on choisit les gens n'importe comment, sur de mauvais critères, à tous les postes, et on espère naïvement que la méthode perlimpinpin va permettre à 11 chèvres de gagner la ligue des champions.

Citation:

---

Envoyé par Bill Fassinou

Ron Jeffries estime qu’il est temps de passer à autre chose. Il conseille aux développeurs d’abandonner les méthodes agiles.

---

Pas vraiment. Il recommande aux développeurs d'abandonner Agile, qu'il définit comme

"the many instances, approaches, and processes that use the word “agile” to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to “Faux Agile” for emphasis"

Citation:

---

Envoyé par Bill Fassinou

il est écœuré de voir que les méthodes du Manifeste Agile compliquent la tâche aux développeurs plutôt que de les aider.

---

Là c'est carrément un gros contresens, ce n'est pas "les méthodes du manifeste agile" mais la façon dont elles sont interprétées et appliquées en entreprise, ce qui change tout.

"their organization is doing “Agile” wrong: they’re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend"

La tonalité de la news DVP ne me parait pas rendre justice à la précision du contenu du billet de Jeffries - même si à sa décharge, le titre volontairement sensationnaliste et provocateur n'aide pas. Pour moi, il appelle plus à un "protestantisme agile" qu'on pourrait résumer par :

Résistez à la pression de "l'Agile dévoyé" qu'on vous impose, en rejetant toute méthode étiquetée Agile mais en restant fidèle aux pratiques fondatrices de l'agile manifesto.

Toute ressemblance avec une religion est purement fortuite :roll:.

Le problème c'est comme toujours...l'humain ;).

Citation:

---

Si une équipe projet fonctionne bien

---

Qu'est-ce qu'une équipe qui fonctionne bien? Est-ce que ça existe?

Je troll un peu car, j'imagine que tu veux dire qu'il ne faut pas chercher la méthode parfaite quand ça fonctionne. Ben c'est un peu en sois le principe d'une méthode Agile :D
Je veux dire par là qu'une méthode agile se doit d'évoluer par touche successive plutôt que de faire des super plan décidé par des managers. La méthode agile est bonne dans sa remise au centre du développement (avec donc une meilleur prise en compte des contraintes informatique) et dans l'évolution progressive qui évite de tout casser y compris ce qui fonctionnait bien. Mais cela ne fait bien sûr pas tout. Il faut évoluer mais en douceur tester de petites évolutions. Aller lentement mais sûrement. Pour moi, c'est ça l'esprit de la méthode Agile.

En informatique tout est possible mais tout a aussi un coup. Ce qui est simple pour l'utilisateur ou pour le manager ne l'est pas forcément pour le développeur. Pire ce qui a priori paraît simple pour le développeur s'avère parfois complexe. Alors si le développeur peut obtenir un léger changement en cours de route on répond rapidement au problème simplement.

Citation:

---

Envoyé par KnifeOnlyI

Si une équipe projet fonctionne bien (quelque soit la méthode choisie) pourquoi changer ?

---

L'un des principes fondamentaux de l'Agile est l'amélioration continue.
Cela concerne absolument tous les aspects du projet qu'il s'agisse de la qualité du code, de l'orga des réunions, des docs produits, de l'organisation dans l'équipe, la méthode de gestion de projet choisie, etc, etc, etc

Bref, il est important de dresser un bilan objectif à l'issue de chaque projet afin d'en déterminer les points positifs de ceux à améliorer / corriger.
On ne doit jamais se reposer sur ses lauriers et tjrs se remettre en question.
Même si le projet est un succès, cela n'empêche pas d'effectuer cette synthèse ==> bien au contraire, identifier clairement quelles ont été les clés de cette réussite est primordiale afin de savoir le reproduire et de le communiquer au reste de la DSI.

Le seul pb que l'on rencontre dans ma boite avec les methodes agiles c'est qu'on est dans la pensée positive systématiquement alors qu'on a rencontre pleins de depassements imprevus :
- fonctionnalités codées par les devs (pour se faire plaisir car non demandées par le client) et non vendues (devs en mode agile hors le projet n'a pas ete vendu ainsi),
- archi SOA/micro service et au final de gros soucis de perfs - mais les architectes nous rassurent que le code et les TU/couverture de code sont nickels et conformes a l'etat de l'art (actuel)
(les devs se justifient par des pbs de BDD et d'infra hors cela fait 20 ans qu'on fait le meme genre d'appli dans des infras bien moins couteuses/complexes avec 0 problemes (une 100aine de projets a ce jour))
Comme on est dans des technos dans l'ere du temps bien on dira que le bilan est du coup biaisé,

On se cache les yeux sur la vraie realité et les depassements ahurissants des couts/delais (x3).
Officiellement dans les equipes de dev c'est une reussite (en pratique le client demande des penalités voir est pret a aller jusqu'a annuler le projet).
Donc assez difficile a vivre car on navigue entre le mensonge et la mauvaise fois (on ne PEUT PAS dire que la methode et les technos sont en cause, alors c'est la faute de qui/quoi ??) - personne a priori.
Incapables de reconnaitre qu'il y a des pbs; pensee positive coute que coute (et ca mine pas mal les autres equipes ne fonctionnant pas dans ce mode là car ils sont plus lucides de la realité du projet - hors aspect communication qui est soignée).

Cycle en V ou méthode Agile le fond du problème reste et resteras l'incompétence de la MOA (le client ou son représentant) qui n'est que rarement capable d'exprimer un besoin correctement, la faute à une horde de cadre, chef de projet, produit, qui sont autant éloigné du besoin (le problème) que de l'outil (le développeur).

La grosse différence c'est que la responsabilité du résultat produit est imputé au développeur dans la méthode agile (c'est pas écrit dans la méthode, c'est mon triste constat), la MOA et MOE se décharge de toute leur responsabilité sur le technique qui supporte toute la charge du projet. Un projet agile ça se passe comme ça :

Client : J'ai besoin d'une table
MOA : on a besoin d'une table
MOE : Fait une table
Développeur : j'ai fait une table
MOE : il a fait une table
MOA : voilà votre table
Client : mais la table passe pas ma porte ...
MOA : faut que la table passe la porte (voyons c'est évident)
MOE : La table doit passer la porte !
Développeur : Voilà, la table passe la porte :|
.
.
.

Un bonheur pour les SSII, un cauchemar pour les développeurs qui subissent tout (et encore j'ai réduit de beaucoup le nombre d'intermédiaire). Au moins l'avantage du cycle en V, c'est qu'on rédige un cahier des charges technique pour le dev (chose inexistante aujourd'hui) à partir d'un cahier des charges fonctionnels étonnamment rare.

Pour ma part, nous travaillons uniquement en cycle en V avec nos prestataire de service, la charge de travail est plus conséquente, mais les projets sont mieux faits et plus courts. Pour de l'interne, nous essayons de mettre en contact directement développeurs et les services en besoin, cela reste compliqué, on cherche pas des développeurs experts full-stack, mais des humains avec une certaine sociabilité capable de comprendre le métier, le besoin et d'y répondre, mais c'est très compliqué à trouver.

Par pitié, s'il vous plaît, continuez l'Agile, sans formation, sans conception, sans méthode, sans outils, sans moyens, sans assurance qualité, à la bite et au couteau!
Utilisez des langages illisibles comme C++ ou Java. Surtout ne documentez rien ...

:-)

Plus vous continuez, plus j'aurai du travail à réparer toutes ces bêtises.

Sans rire, c'est tellement difficile d'arriver à faire passer le message que de travailler avec méthode, en structurant son architecture et sa conception, en documentant le cahier des charges, en programmant de telle sorte que le source est l'équivalent d'un dossier de conception, en générant la majorité du source, en modélisant les performances et l'architecture, en testant, en mesurant la qualité et l'entropie logicielle (dette technique) et en corrigeant les défauts dès leur apparition, en utilisant des langages puissants et protecteurs, finalement, on va beaucoup, beaucoup plus vite, tout en produisant de la bien meilleure qualité....

Toutes les disciplines de l'ingénieur travaillent comme cela : la mécanique, la chimie, la physique, la construction, etc. Pourquoi l'informatique y échappe-t-elle?

Rapide et agile, ça n'a rien à voir.

Chaque projet a ses particularités et ne correspond pas à toutes les méthodes, le problème n'est pas vraiment les méthodes mais leur choix ou adaptation pour projet ...

Agile dans les sociétés de service, ça ressemble plutôt à une tentative de cadrer le bordel avec de la rubalise.

On commence à voir arriver les premiers projets agiles d'il y a quatre ou cinq ans pour une v2 et là : pas de doc, pas vraiment de spéc. du code pas structuré, mais comme pour le modèle de BDD un assemblage de légo. Du coup, il faut expliquer au client qu'on fait tabula rasa. Bref, les projets agiles que j'ai vu jusqu'à présent ressemblent à des projets de stagiaires.

Quelqu’un ici a dit espérer ne pas « revenir » à du cycle en V pur. Alors, juste une remarque : en France, on a l’habitude de parler du « cycle en V », parce que c’est celui qu’on nous donne en modèle pendant les études.

À ce jour, je n’ai encore jamais vu ce fameux cycle en V appliqué complètement dans une entreprise.
En réalité, ce que j’observe, c’est plutôt ce que les anglophones appellent le modèle « waterfall ». La différence ? Dans le « V », il y a écriture du plan de test en même temps que la phase de spec/conception/…/dev associée, en préparation de la phase de TU/TV/recette/… qui est en face dans la branche remontante du V.
Curieusement (vu l’âge de cette méthode), cela n’est pas sans rappeler le BDD, le TDD… ;-)

Franchement, dans certaines boîtes, je serais plus rassuré de voir un vrai cycle en V, plutôt que la fausse agilité pilotée par le budget qu’on nous fait subir. Et pourquoi pas du cycle en V incrémental (ceux qui ont fait Génie Informatique doivent connaître). Ce serait bien plus adapté aux désirs du management, tout en conservant un développement itératifs en cycles courts et bon nombre des bénéfices de l’agilité.

Tout ceci étant dit, je préfère malgré tout l’agilité implémentée correctement : tous les clients que j’ai vu en bénéficier en étaient très contents, et avec une qualité finale exceptionnelle.

N.B. Super, Developpez.net ! les espaces insécables qui deviennent des étoiles… :-/ J’adore revenir sur tout mon texte faire la guerre des étoiles :-p

Le gros avantage de l’agile est l’iteration et la valeur apportée au client finale. Fini l’effet tunnel ! Mais d’experience pas tous les projets sont eligibles à être menés en Agile ! Faut faire de l’Agile parce que c’est la mode
Je ne pense pas que l’Agile est fini, mais c’est vrai que parfois l’implementation ne suit pas la definition.

Comme dit plus haut meme dans les cycles dit en 'V' en 30 ans je n'ai jamais connu d'effet tunnel et cela en acceptant pourtant des changements/evolutions tout au long du projet. Les seuls projets ou ont est souvent emmerdés c'est les contrats avec les boites anglo saxones. Tu fais exactement ce qui est dans le contrat (meme si c'est debile voir inutile). On a vecu le cas a plusieurs reprises. On avait identifié des choses specifiées pas coherentes; donc proposition de modification pour aller vers le mieux; et bien non, refus categorique, aller au bout du contrat, puis redemarrer un autre contrat pour faire les adaptations.
Bref du nawak mais bon tant qu'ils paient, faire/defaire/refaire c'est du boulot.