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

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)

Envoy� par Bill Fassinou

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

Envoy� par Bill Fassinou

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

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 :

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 !

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.

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"

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 .

Le probl�me c'est comme toujours...l'humain .

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

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.