Discussion :

[gangsoleil]

Bonjour,

a/ les equipes auto ger�es se generent aussi d'elles memes du boulot (l'agilit� se traduit souvent par un refus de tout ce qui ne provient pas de l'equipe ! c'est plutot de la rigidit�).

b/ lorsqu'un client exprime un besoin (ex: technique), l'equipe de dev en fait souvent plus (et donc deroule des heures pas forcement vendues). Un peu comme si c'etait un test technique qu'il fallait relever. resultat vecu : on nous demande d'implementer une interface selon 2 protocoles => au final 5 protocoles techniques sont implement�s (derive des devs qui se sont faits plaisirs). Le client est content certes car on lui en donne plus que prevu; par contre nous on bouffe la culotte en consommant des heures non vendues.

Ce n'est pas parce que vous appliquez mal agile que la m�thode est pourrie.

Pour la demande client, il est normal, et m�me souhaitable, que l'�quipe se pose la question suivante : est-ce utile prendre un peu plus de temps pour faire une interface g�n�rique qui nous permettra de supporter d'autres protocoles ou non. Si la r�ponse est oui, alors il faut l'impl�menter.
Mais �a ne veut pas dire impl�menter d'autres protocoles.

Ont-ils livr� dans les temps, et en respectant les co�ts ? Si oui, pas grand chose � redire. Si non, il faut analyser pourquoi, et corriger.

[ZenZiTone]

Ce n'est pas parce que vous appliquez mal agile que la m�thode est pourrie.

+1.. Et c'est l� que beaucoup d'�quipes se vautrent. Mettre en place un backlog, des sprits et des daily ne suffit pas � faire de l'agilit�... L'agilit� est � la base, des concepts. En d�coule des m�thodes et des outils pour valoriser ces concepts. En th�orie, deux �quipes diff�rentes ne peuvent appliquer strictement la m�me m�thode suivant les affinit�s des membres de l'�quipe, des clients, des projets..

Beaucoup se leurrent dans l'id�e qu'appliquer la m�thode scrum permettra rapidement � �tre plus performant. L'agilit� est un �tat d'esprit, une mani�re d'aborder les projets.

[Luckyluke34]

<zip>

Je ne vois rien d'inputable aux m�thodes agiles dans tout �a.

Agile pr�conise au contraire une collaboration quotidienne avec le demandeur m�tier responsable du retour sur investissement du logiciel. C'est � peu pr�s l'inverse de "les devs font ce qu'ils veulent".

Sur l'aspect "jouer avec des technos" et le turnover, �a peut arriver sur n'importe quel type de projet.

[-]

Pour le TDD je suis en d�saccord complet, pour le reste ce monsieur a plut�t raison. L'agile mal appliqu� est un cancer.

[Saverok]

Pour le TDD je suis en d�saccord complet, pour le reste ce monsieur a plut�t raison. L'agile mal appliqu� est un cancer.

Peu importe la la m�thode et le sujet, lorsque c'est mal appliqu�, c'est le bordel.
Du coup, on peut �crire exactement le m�me type d'article � propos des travers du cycle V est d'une application merdique de celui-ci.

[Glutinus]

Peu importe la la m�thode et le sujet, lorsque c'est mal appliqu�, c'est le bordel.
Du coup, on peut �crire exactement le m�me type d'article � propos des travers du cycle V est d'une application merdique de celui-ci.

Les �normes travers du V ?
Les effets Tunnel avec les MOA qui jouent de la balalaika avec les utilisateurs, livrent leurs specs la veille de la mise en recette mais "on repousse pas la MEP".
Les MOA qui veulent pas entendre parler de "lignes", "colonnes", "fonctions" car "je suis pas technique"
Les chefs de projet qui oublient de prendre en compte des contraintes commes des livraisons de serveur
Les �quipes de production qui se sentent mal-aim�es des d�veloppeurs et vice et versa.
Les d�veloppeurs geek qui oublient qu'on d�veloppe par pour faire du code, mais pour cr�er des fonctionnalit�s qui seront utilis�es par des utilisateurs, � terme.

Et vous savez quoi ? Des probl�mes surviendront aussi en agile tant qu'on n'arrivera pas � communiquer entre �quipes.

[Jacti]

Il ne faut pas confondre TDD et les tests unitaires, au sens classique, qui eux sont indispensables car ils servent � mesurer le pourcentage de couverture du code.
Ecrire des tests unitaires avant d'�crire le code est tout simplement de la foutaise.

[St�phane le calme]

Agile est-il mort ? Pour un ing�nieur � Le d�veloppement "agile" avec lequel nous sommes coinc�s aujourd'hui est une blague �,
il souligne ses dysfonctionnements dans les processus de d�veloppement en entreprise

Depuis ses d�buts dans les ann�es 2000, l'agilit� a profond�ment transform� la mani�re dont les entreprises abordent la gestion de projets et le d�veloppement logiciel. Elle ne se r�sume pas � des pratiques ou des outils, mais repr�sente une philosophie bas�e sur des principes fondamentaux qui mettent l�accent sur la flexibilit�, la collaboration, et l�orientation client. Pourtant, plus de deux d�cennies apr�s la publication du Manifeste Agile, cette approche est � la crois�e des chemins : c�l�br�e pour ses succ�s, mais critiqu�e pour ses d�rives.

Aux origines de l�agilit� : une r�volution manag�riale

En 2001, dix-sept experts du d�veloppement logiciel se r�unissent � Snowbird, dans l�Utah, pour r�pondre � un probl�me majeur : les m�thodes traditionnelles de gestion de projet, comme le cycle en V ou la m�thode Waterfall, s�av�raient inefficaces face � des environnements incertains et changeants. Le r�sultat de cette rencontre fut le Manifeste Agile, un texte court, mais r�volutionnaire, articul� autour de quatre valeurs qui ont �t� d�clin�es en douze principes afin d'aider op�rationnellement les �quipes qui souhaitaient les suivre.

En s'appuyant sur leur exp�rience combin�e du d�veloppement logiciel, les dix-sept signataires du manifeste ont proclam� qu'ils attachaient de l'importance � aux individus et leurs interactions plut�t qu'aux processus et aux outils �, � � un logiciel fonctionnel plut�t qu�� une documentation exhaustive �, � � la collaboration avec les clients plut�t qu'� la n�gociation contractuelle � et � � l�adaptation au changement plut�t qu'� l'ex�cution d�un plan �. Cela signifie que les �l�ments � gauche du mot � plut�t � dans chaque citation sont r�put�s avoir plus de valeur que ceux � droite, bien qu'il y ait aussi de la valeur dans ces derniers. Ces quatre citations sont appel�es les quatre � valeurs � du manifeste agile.

Ces valeurs traduisent une rupture avec les approches rigides et une volont� de recentrer le travail sur ce qui g�n�re r�ellement de la valeur : les �quipes, les produits, et les besoins �volutifs des utilisateurs.

Un succ�s retentissant

L�agilit� a rapidement gagn� en popularit�, port�e par des m�thodologies comme Scrum, Kanban, ou Extreme Programming (XP). Ces frameworks apportaient des outils concrets pour impl�menter les principes agiles dans les organisations. Dans les ann�es 2010, l�agilit� a commenc� � s��tendre bien au-del� du d�veloppement logiciel, touchant des domaines tels que le marketing, les ressources humaines et m�me la gestion strat�gique.

L�agilit� aujourd�hui : succ�s et critiques

Malgr� ses nombreux succ�s, l�agilit� n�a pas �t� �pargn�e par les critiques. Si elle a permis � des entreprises comme Spotify ou Amazon d'atteindre des niveaux impressionnants d�innovation et de r�activit�, elle a �galement �t� victime de d�tournements et de d�rives qui en d�naturent l�esprit.

Les succ�s de l�agilit�

• Une meilleure gestion de l'incertitude : Les approches agiles permettent aux �quipes de s�adapter rapidement aux changements, en livrant r�guli�rement des incr�ments de valeur.
• Une collaboration renforc�e : Gr�ce � des pratiques comme les stand-ups quotidiens et les r�trospectives, l'agilit� favorise une communication transparente et continue entre les membres des �quipes.
• Un focus sur l�utilisateur : En impliquant le client tout au long du processus, l�agilit� garantit que les produits r�pondent r�ellement � leurs besoins.

Les critiques envers l�agilit�

• La "superficialit� agile" : Dans de nombreuses organisations, l�agilit� est r�duite � un ensemble de c�r�monies ou d'outils (sprints, burn-down charts) sans r�elle compr�hension des principes fondamentaux.
• Une rigidit� paradoxale : Certains frameworks, comme SAFe (Scaled Agile Framework), sont per�us comme trop lourds et bureaucratiques, en contradiction avec l�esprit de flexibilit� promu par l�agilit�.
• La marchandisation : La multiplication des certifications agiles a cr�� une industrie lucrative, parfois d�connect�e des besoins r�els des �quipes et des entreprises.
• Une mauvaise int�gration culturelle : Dans des structures hi�rarchiques traditionnelles, les principes agiles peinent souvent � s�imposer face � des r�sistances au changement.

Les d�fis de l�agilit� � l��re moderne

L�agilit� se trouve confront�e � des enjeux nouveaux, li�s � l��volution rapide des environnements professionnels et technologiques.

1. La complexit� croissante des organisations : Dans les grandes entreprises, la mise en �uvre de l�agilit� � grande �chelle est souvent un d�fi. La coordination entre plusieurs �quipes, la gestion des interd�pendances, et la n�cessit� de satisfaire des parties prenantes multiples rendent l�application des principes agiles plus difficile.
2. La mont�e de l�intelligence artificielle : L��mergence de technologies comme l�intelligence artificielle (IA) ou le machine learning (ML) red�finit les cycles de d�veloppement. Comment concilier les approches agiles avec des disciplines o� l�exp�rimentation et la recherche prennent parfois le pas sur la livraison it�rative ?
3. Les attentes soci�tales : Dans un monde de plus en plus ax� sur la durabilit� et la responsabilit� sociale, l�agilit� doit �voluer pour inclure des pr�occupations �thiques et environnementales.

Pour un ing�nieur, Agile est mort

� Le d�veloppement "agile" avec lequel nous sommes coinc�s aujourd'hui est une blague - un d�sordre �touffant orchestr� par des imposteurs qui ne reconna�traient pas un logiciel de qualit� s'il les frappait au visage. Nous sommes noy�s sous le poids de chefs de produit, de managers et de propri�taires qui n'ont jamais �crit une ligne de code et qui, pourtant, dictent d'une certaine mani�re la mani�re dont les logiciels doivent �tre construits. Leurs rituels insignifiants et leurs r�unions interminables tuent la cr�ativit� et �touffent le progr�s, nous enlisant dans la bureaucratie.

� Alors que nous perdons du temps dans ces processus futiles, le paysage technologique �volue plus vite que ces soi-disant � experts agiles � ne peuvent organiser leur prochaine r�union inutile. L'intelligence artificielle se profile, pr�te � bouleverser l'industrie. Elle balayera non seulement les interm�diaires inutiles, mais aussi les ing�nieurs unidimensionnels qui mettent en �uvre des tickets Jira sans se poser de questions. Dans un monde domin� par l'IA, seuls survivront ceux qui allient une compr�hension technique approfondie � une vision fine de l'entreprise et du produit. Il est temps de repenser la fa�on dont nous collaborons et construisons des logiciels.

� La v�ritable collaboration ne peut �tre impos�e par des c�r�monies creuses ; elle na�t d'une passion authentique et d'une mission partag�e. Nous avons besoin d'ing�nieurs farouchement d�vou�s, de personnes qui saisissent � la fois les complexit�s du codage et la vision globale du produit. Nous avons besoin d'�quipes pointues et agiles qui pensent de mani�re ind�pendante et agissent sans h�sitation. Il est temps d'�liminer les couches de bureaucratie inutile et de faire confiance aux vrais experts, ceux qui construisent r�ellement les produits.

� Il ne s'agit pas de m�nager les susceptibilit�s ou de maintenir un statu quo bris�. Il s'agit de d�clencher une r�volution pour cr�er quelque chose qui fonctionne vraiment, quelque chose dont nous pouvons tous �tre fiers. Nous devons avoir le courage de tout remettre en question, de tirer les le�ons de nos �checs et de tracer une nouvelle voie. L'avenir appartient � ceux qui ont l'audace de s'adapter et d'innover, et non � ceux qui s'accrochent d�sesp�r�ment � des processus d�pass�s comme � un radeau de sauvetage

� Ce manifeste est un cri de guerre pour tous ceux qui en ont assez des dysfonctionnements actuels. Il s'adresse � ceux qui croient que les ing�nieurs qualifi�s sont les v�ritables moteurs de l'innovation et les cr�ateurs de produits significatifs. Nous devons nous lib�rer des cha�nes des m�thodologies obsol�tes et adopter une approche plus dynamique, dirig�e par les ing�nieurs, du d�veloppement de logiciels. L'avenir m�me de notre industrie d�pend de notre volont� de nous adapter, d'innover et de collaborer v�ritablement, et pas seulement d'accomplir les rituels vides des pratiques dites "agiles" �.

� Agile est un cancer �, pour Erik Meijer, qui estime qu'il doit �tre banni une fois pour toutes

Erik Meijer, un d�veloppeur c�l�bre de l��cosyst�me .NET, qui s�est notamment fait remarquer par la cr�ation de LINQ et ses travaux sur le langage C#, Visual Basic, Volta et le framework Reactive Extensions (Rx), a fait des d�clarations acerbes contre Agile, lors d�une conf�rence en Finlande : � Agile est un cancer que nous devons �liminer de l�industrie �, a d�clar� celui-ci.

Meijer critique surtout le fait que l�application de l�agilit� dans des projets fait � beaucoup plus parler sur le code, que d��crire le code �. Erik Meijer s�en prend particuli�rement � la m�thode Scrum, qui entraine des � interruptions inutiles �. Selon celui-ci, les � Scrum Meeting � sont des interruptions ennuyeuses, au mieux des m�canismes de contr�le subtil utilis�s par les gestionnaires pour conduire une �quipe, en donnant l�illusion d�un leadership partag�. � Nous devons cesser Scrum et Agile. Nous sommes des d�veloppeurs. Nous devons �crire du code �, a affirm� Meijer.

Meijer continue sa diatribe en s�attaquant aux TDD. � C�est tellement ridicule. Pensez-vous que vous pouvez mod�liser les �checs r�els qui se produisent pendant la phase de production ? �, s�est interrog� Meijer, avant de r�pondre. � Non. � Il pr�conise un cycle o� le logiciel est d�ploy�, et les erreurs fix�es lorsqu�ils sont d�couverts.

Il faut noter que le cr�ateur de Ruby On Rails, David Heinemeier Hansson, s��tait aussi attaqu� aux TDD, en affirmant que les tests unitaires n��taient pas b�n�fiques.

Au-del� de ces remarques, Meijer s�insurge �galement par rapport au fait que le terme � Agile � a �t� d�tourn� et est d�sormais d�nu� de tout sens. Il a fini sa pr�sentation en citant Dave Thomas, l�un des signataires du manifeste agile : � Le mot �Agile� a �t� d�tourn� au point ou il est devenu vide de sens. Et ce qui passe pour une communaut� agile est devenu une ar�ne pour les consultants et les entreprises qui veulent vendre leurs produits et services �

Capital One supprime tous les profils Agile de ses effectifs et plus de 1 100 personnes ont �t� touch�es

Apr�s de nombreuses ann�es d'investissement dans les m�thodes Agile pour amorcer � convenablement � sa transformation num�rique, Capital One pense d�sormais � r�organiser ses �quipes et se s�pare des professionnels en m�thodes Agile. Une personne au courant de l'affaire a d�clar� � Bloomberg que plus de 1 100 employ�s ont �t� touch�s par cette d�cision. Ces travailleurs ont �t� invit�s � postuler pour d'autres postes au sein de la banque, des centaines de postes �tant ouverts dans toute l'entreprise. Selon des documents d�pos� par Capital One, la soci�t� comptait plus de 55 000 employ�s au troisi�me trimestre clos le 20 septembre 2022.

� la place, les ing�nieurs et les chefs de produit devront utiliser naturellement les routines Agile. � Le r�le Agile dans notre organisation technique �tait essentiel pour nos premi�res phases de transformation, mais � mesure que notre organisation m�rissait, la prochaine �tape naturelle �tait d'int�grer les processus de livraison Agile directement dans nos pratiques d'ing�nierie de base �, a d�clar� Capital One. Depuis des ann�es, l'entreprise investit dans la technologie du cloud qui, selon elle, lui permettra d'am�liorer ses produits et son ratio d'efficacit�, une mesure clef de la rentabilit� qui indique combien il en co�te pour produire un dollar de revenu.

� Les d�cisions qui affectent nos associ�s, en en particulier celles qui impliquent des suppressions de r�les, sont incroyablement difficiles. Cette annonce n'est pas une r�flexion sur ces personnes ou sur le travail qu'elles ont accompli au nom de notre organisation technologique. Leurs contributions ont �t� essentielles � la maturation de notre mod�le de fourniture de logiciels et � notre transformation technologique globale �, a d�clar� la soci�t� dans le communiqu�. Les suppressions de postes interviennent �galement � un moment o� les entreprises technologiques et les entreprises financi�res r�duisent leurs effectifs et ralentissent les embauches.

Source : Agile is dead

Et vous ?

Les valeurs du Manifeste Agile sont-elles toujours pertinentes dans les organisations modernes ? Selon vous, Agile est-elle d�pass�e ? Est-elle devenue un probl�me pour les �quipes d'ing�nierie ?

� votre avis, Agile contribue-t-elle � l'accumulation de la dette technique ? Pourquoi ?

Comment �quilibrer la libert� d�action des �quipes avec les contraintes strat�giques ou budg�taires des entreprises ?

L�agilit� est-elle compatible avec des environnements o� la hi�rarchie reste tr�s marqu�e ?

Quels sont les plus grands d�fis que vous avez rencontr�s dans l�application des pratiques agiles dans votre organisation ?

L�agilit� est-elle toujours adapt�e dans des secteurs hors IT, comme la finance, l�industrie ou le marketing ?

Quelle alternative proposez-vous � Agile ? Pourquoi ?

Voir aussi :

� Agile tue l'innovation en confinant les d�veloppeurs dans des bo�tes noires d'abstraction qui limitent la cr�ativit� et la compr�hension des syst�mes sous-jacents �, affirme l'un des d�veloppeurs de Signal

[sevyc64]

� Agile est un cancer �, pour Erik Meijer,

Enti�rement d'accord avec ce monsieur.

[pyros]

Toute les personnes qui critiquent l'agile critiquent en fait l'impl�mentation "cargo culte" d'agile.

Ils se pleignent des c�r�monie, des organigramme, de la pression de d�livrer � chaque sprint, du ticketing a outrance, des outils et j'en passe. Mais je n'ai jamais vue personne se plaindre de devoir adresser la dette technique en continue, d'avoir des retours client r�gulier, d'�tre en capaciter de livrer rapidement, d'avoir une communication direct, etc...

Je rappel les principe de l'agilit�:

• 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

Toutes les critiques concernent les parties de droite, ce que l'agilit� est justement cens�e �viter.

[jeromejerome]

Je suis dans une entreprise qui se dit agile et qui applique une m�thodologie de travail en waterfall. Le daily scrum ne sert qu'� fliquer les salari�s. Le PO fait du secr�tariat. Pour critiquer agile il faut l'avoir compris. Le commentateur qui veut s'adonner � la passion du code, c'est gentil, moi aussi j'ai des passions, mais la r�alit� du projet c'est pas des scribouillards d'un c�t� et des codeurs de l'autre. La r�alit� s'est une �quipe qui fait une pour r�aliser un projet et le PO a besoin du dev. Agile le dit lui m�me plus d'interaction moins de processus et d'outils, les artefacts agile sont des outils dont on peut se passer le cas �ch�ant. M�me avec l'IA, l'agilit� est possible tout d�pend de l'attendu fix�.
Agile n'est pas mort mais les patrons et les managers le font grave souffrir.

[Eye_Py_Ros]

Critiquer l'agile devient un marronnier de l'actu informatique. Apr�s plusieurs exp�riences, voici mon analyse :

Le plus gros probl�me d'Agile c'est ceux qui l'utilisent sans comprendre comment on con�oit du logiciel.

- Si vous concevez une base logicielle d'abord et que le reste des impl�mentations est modulaire, faire de l'agile c'est fun et cool. Vous pouvez faire de l'extr�me dev, inclure l'utilisateur et le client dans la boucle et r�ussir a envoyer en prod de la fonctionnalit� chaque semaine avec un taux de r�le back tr�s faible (par ce que le client n'a pas document� son environnement et que certaine fonctionnalit� c'est au doigt mouill� ).

- Si vous ne savez pas concevoir de logiciel et que vous commencez par trier les post it et voter par lequel commencer, car vous �tes un bon manager super sympa, team building et compagnie. C'est l'�chec assur�, a chaque sprint vous serez en train de r��crire int�gralement la solution ou faire un creepi pasta pour avoir un semblant de fonctionnalit� qui arrive a fonctionner ensemble avec une dette technique exponentielle et des stories qui consomme toujours plus de points les unes que les autres jusqu'au turn over des �quipes par ce qu�une fonctionnalit� simple devient un enfer � int�grer.
Et passer le reste du temps � expliquer au client pourquoi �a ne marche pas que ce n�est pas de votre faute, mais que c'est agile le coupable et chialer pour avoir des sous.

On ne commence pas le dev juste avec une liste de course utilisateur. On commence le dev par poser les bases d'une archi qui va permettre d'accueillir l'agile (apr�s avoir pris connaissance des besoins m�tier en large et en travers sur le moment).
Voil� ce qui manque � + de 90% des projets agile par ce que le management n'a jamais d�pass� le tuto du zero en termes de dev .
Ajouter un post it ne va pas faire spawn par magie une fonctionnalit� dans un logiciel.

Le jour ou les gens ajouteront en 1re �tape d'un projet Agile, poser le minimum viable, fondation, kernel appli (ou autre nommage qui plaira) avant de lancer la course....
les choses prendront une tournure diff�rente.
Accuser une m�thode par ce que l'on ne comprend rien / ne ma�trise pas ce que l'on fait .... soyons honn�te, c'est plus un pb d'incomp�tence qu'autre chose.

Aucune m�thode n'est magique, aucune par une incantation secr�te ne permet d'invoquer le produit que l'on est cens� concevoir.
Mais bon, les managers en carton a bon dos, les PO sorties d'�cole de commerce qui veulent expliquer la vie au dev .....

Une m�thode ce n�est pas une recette de cuisine, c'est plus la logistique avec lequel on va ex�cuter la recette de cuisine.
La recette de cuisine est (presque) propre � chaque projet.
Agile, ce n�est pas une architecture projet, c'est une m�thode de travail.
c'est peut �tre la chose la plus importante � dire

Tout comme le cola et l'Orangina on leur recette (secr�te ), mais pourrait th�oriquement �tre produit dans la m�me usine.

Ceux qui parle de je vais utiliser mvc pour mon projet, je vais faire mon projet en agile, je vais utiliser la derni�re techno � la mode par ce que c'est sur demain tout fonctionnera uniquement avec �a c'est l'avenir (tout en �tant "junior dans le dev").... n'ont jamais amener un projet � terme.






-----
Pour nous le combat, le plus dur, reste � faire comprendre dans les projets pourraves que ce n�est pas agile qui va faire dispara�tre la dette technique et les bugs comme par enchantement.
Encore moins lors de MCO sur un legacy � chier d'une solution qui aurait jamais du exister, car c'est une aberration et corriger chaque bug un par un est une qu�te sans aucun sens.
� moins que vous soyez un Mozart du code.

Pour les projets neufs, que les Dev commencent � prendre un peu d'audace et s'assure que leur 1er sprint soit de poser les bases du projet par l'ajout d'un sprint "app kernel" et ne pas passer 3h philosophique c'est quoi le meilleur post it que l'on va faire en 1er par ce qu'il faut pr�senter le ppt � 15h en pl�ni�re

[pyros]

Agile, ce n�est pas une architecture projet, c'est une m�thode de travail.

Oui, mais cette m�thode m�thode de travail peut �tre utilis� pour concevoir une architecture.
Cf cette conf vachement int�ressante qui balaye un peu le principe du "Il faut � tout prix faire des fondation solide avant de faire les features:

[DrHelmut]

C'est vrai que c'est devenu un marronnier de taper sur l'agilit�, les m�thodes agiles ou scrum en particulier, alors qu'au final le probl�me d�crit n'est pas l�.

�videment que certaines organisations manageriales d�tournent le modele, ce n'est pas nouveau. Il y a bien des directeurs qui comparent la productivit� de leurs �quipes en regardant... Le nombre de story points r�alis�s chaque trimestre par �quipe 😆
J'ai m�me connu des bo�tes il y a plus de 10 ans ou les devs avaient leur prime index�s sur la r�ussite des sprint goal ET la completion de chaque sprint...

Bref, tout �a pour dire que taper sur la th�orie alors que le probl�me vient des gens qui l'interpr�te mal voire la d�tourne, et de ce fait s'�cartent totalement de l'agilit� et de ses principes fondateurs, faut arr�ter, c'est fatiguant et contre-productif.

[Jacti]

Le d�veloppement "agile" est la plus grande fumisterie de l'informatique.
C'est � la fois comique et triste de voir que des informaticiens puissent prendre cette approche au s�rieux.
Je suis enti�rement d'accord avec Erik Meijer qui dit que "Agile est un cancer que nous devons �liminer de l'industrie".
Je n'ai, pour ma part, jamais cru � cette pseudo-m�thode qui n'est praticable que pour des "projets" de deux mois, au mieux. Je suis conscient d'�tre un peu radical mais c'est pour mieux "secouer le cocotier"
Soyons un peu s�rieux et pratiquons des m�thodes �prouv�es :
https://swehb.nasa.gov/display/SWEHBVD
https://fr.wikipedia.org/wiki/ISO/CEI_12207

PS : Je suis conscient d'�tre un peu radical mais c'est pour mieux "secouer le cocotier"

[vivid]

C'est bizarre me je me m�fie de tout ce qui est pompeux, je sais pas pourquoi
du bon sens.. ajuster le tir, c'est quand m�me intellectuellement plus gratifiant, que d'appliquer une recette a la lettre.

[pyros]

Le d�veloppement "agile" est la plus grande fumisterie de l'informatique.
C'est � la fois comique et triste de voir que des informaticiens puissent prendre cette approche au s�rieux.
Je suis enti�rement d'accord avec Erik Meijer qui dit que "Agile est un cancer que nous devons �liminer de l'industrie".
Je n'ai, pour ma part, jamais cru � cette pseudo-m�thode qui n'est praticable que pour des "projets" de deux mois, au mieux. Je suis conscient d'�tre un peu radical mais c'est pour mieux "secouer le cocotier"
Soyons un peu s�rieux et pratiquons des m�thodes �prouv�es :
https://swehb.nasa.gov/display/SWEHBVD
https://fr.wikipedia.org/wiki/ISO/CEI_12207

PS : Je suis conscient d'�tre un peu radical mais c'est pour mieux "secouer le cocotier"

Houuu, �a sent le vieu papi r�ac qui jure que par le cycle en V et la hi�rarchie pyramidal

Blague � part, ce type de process marchent dans des industries lourdes et quand tu connais � l'avance tes contrainte. Mais sur des industrie plus l�g�re o� le cient change d'avis toutes les 2 semaines avec un march� tr�s dynamique, tu peux pas passer 6 mois � �crire un cahier des charges.

Au passage, les booster d'ariane 6 ont �t� con�us en cycle agile, avec des cycle de 3 mois. Avant ils �taient sur des cycle de 5 ans, et passer en cycle court leur a permis de sortir de l'roni�re o� ils �taient embourb� depuis 10 ans.

Agile est un outils, au m�me titre que waterfall, cycle en V, etc... Quand tu as un clou, tu utilise un marteau. Quand tu as une vis, tu utilise un tourne-vis.

[gblaquiere]

�a me fait penser a un pr�sident qui disait: la d�mocratie est le pire des r�gimes a l'exception de toutes les autres.

Et pour l'agilit� ? C'est la pire des m�thodes a l'exception de toutes les autres?

Sinon on fait quoi a la place?

[esperanto]

Les succ�s de l�agilit�

• [...]
• Un focus sur l�utilisateur : En impliquant le client tout au long du processus, l�agilit� garantit que les produits r�pondent r�ellement � leurs besoins.

C'est une blague?

Avant, j'avais un contact direct avec les utilisateurs. Ils m'appelaient, on parlait m�tier, ils me d�crivaient leurs besoins et les id�es qu'ils avaient, je r�fl�chissais sur le plan technique et je les rappelais pour d�finir ce qui �tait possible ou pas.
Aujourd'hui toute id�e doit �tre soumise au business analyst qui va en parler au functional analyst qui va en parler au technical analyst qui va en parler � mon chef de projet qui va ouvrir un ticket JIRA avec une spec dans un document word o� tous les interm�diaires ont bien pris soin de garder leurs track changes histoire que ce soit bien lisible.

• Une collaboration renforc�e : Gr�ce � des pratiques comme les stand-ups quotidiens et les r�trospectives, l'agilit� favorise une communication transparente et continue entre les membres des �quipes.

Non, les stands up quotidiens, �a consiste � donner le num�ro des tickets achev�s et en cours (m�me si l'info se trouve d�j� dans JIRA) pour tout autre chose il faut r�clamer une r�union suppl�mentaire sinon on est accus� de faire d�border le stand up.
Ou alors, avant de me dire que je n'ai rien compris je voudrais que DrHelmut m'explique comment convaincre mon manager � l'origine de la m�thode que c'est lui qui n'a rien compris...

Nous sommes noy�s sous le poids de chefs de produit, de managers et de propri�taires qui n'ont jamais �crit une ligne de code et qui, pourtant, dictent d'une certaine mani�re la mani�re dont les logiciels doivent �tre construits.

Meijer critique surtout le fait que l�application de l�agilit� dans des projets fait � beaucoup plus parler sur le code, que d��crire le code �.

C'est bien cela. Non seulement je n'ai plus acc�s aux utilisateurs dont pourtant le m�tier m'int�ressait (m�me si je restais pour ma part sur la partie technique) mais en plus je dois me coltiner un manager qui est encore moins int�ress� par le m�tier des utilisateurs, et qui veut juste conna�tre le nombre de story points affect�s � chaque ticket.
C'est pourtant ce gars-l� qui va d�cider du nombre et de la nature des couches de l'application, et de tous les outils "n�cessaires" (dont les tests unitaires cit�s par ailleurs). Au final parfois il m'arrive de mettre une heure � corriger un bug et trois � remplir toutes les applications de gestion (qui bien que provenant du m�me �diteur vont mal communiquer entre elles) parce que je dois mettre la m�me information � trois endroits et dans trois formats diff�rents. Ce qui ne dispense �videmment pas de r�p�ter une quatri�me fois pendant le stand up qui est suppos� int�resser tout le monde.

Encore une �tape et j'apprendrai que soi disant je ne fous rien de la journ�e (ou alors j'aurais presque envie d'installer ce truc pour leur montrer l'�tendue du d�sastre de la m�thodologie...)

[KlmIsgonnaRockYou99]

Piloter en Agile demande �* mon sens d’avoir une expérience solide en développement mais pas seulement. Beaucoup de soft skills en jeu pour que la recette aboutisse.
Une méthode s’impose peu importe laquelle. C’est comme une architecture projet, elle s’adapte au produit. Pas l’inverse. Et les options sont légions.
Confondre management et méthodes est hélas apparemment très courant. Et les PO en papier qui se transforment en secrétaires comme j’ai pu le lire, sont certainement ceux qui faute d’xp se replient sur leur fonction plutôt que remplir leur rôle de facilitateur et de vulgarisateur entre toutes les parties prenantes du produit.
Peut être que c’est obsolète, peut être que c’est generationel ou culturel. Mais comme le bon sens commun n’existe pas et que les ressorts de la communication entre humains (oui les devs sont aussi humains) restent excessivement complexes, on a pas trouvé mieux pour le moment.
Mes 2 centimes.