Jamais compris et je comprendrai JAMAIS ce qu’est la methode AGILE

Le 01 septembre 2023 à 12:09:30 :

Le 01 septembre 2023 à 12:05:09 :

Le 01 septembre 2023 à 12:01:33 :

Le 01 septembre 2023 à 11:59:11 :
C'est une méthodologie de travail avec des règles et des principes.
Après les sociétés le font toujours à leur sauce, voir le font pas du tout et se disent "agile" quand même pour être à la mode.

Oui une méthodologie j’avais compris, mais c’est la méthodologie en question et son UTILITÉ qui m’échappe. Ils faisaient comme les dev avant AGILE ?

Le cycle en V pour la plupart, ce qui peut être casse couille car ça implique que conception soit complètement terminée AVANT le début des devs.
Ce qui est quasiment impossible sur des gros projets.

L'agilité permet d'être.... Agile. Donc d'arranger la direction prise en fonction des difficultés et des infos trouvées pendant la création du projet

Ca y est ça commence, je comprends rien

On dirait du VENT, et les arguments qui vont avec me font penser à ceux des adeptes d’une secte qui essaient de s’autopersuader que tout leur délire à un sens

À croire que les devs sont tous confrontés à des projets de difficultés insoupçonnées alors que la plupart du temps ils bossent sur des trucs hyper classiques

Je trouve que son explication est la meilleure du topax, avec le crayon qui explique les déboires de la mauvaise application en entreprise.

Ce sont des concepts de gestion de projet. Si tu n'es pas familier avec une quelconque méthode de gestion de projet, normal que tout te paraisse fumeux.
Je suppose que le cycle en V t'est tout aussi nébuleux

Le 01 septembre 2023 à 12:09:30 :

Le 01 septembre 2023 à 12:05:09 :

Le 01 septembre 2023 à 12:01:33 :

Le 01 septembre 2023 à 11:59:11 :
C'est une méthodologie de travail avec des règles et des principes.
Après les sociétés le font toujours à leur sauce, voir le font pas du tout et se disent "agile" quand même pour être à la mode.

Oui une méthodologie j’avais compris, mais c’est la méthodologie en question et son UTILITÉ qui m’échappe. Ils faisaient comme les dev avant AGILE ?

Le cycle en V pour la plupart, ce qui peut être casse couille car ça implique que conception soit complètement terminée AVANT le début des devs.
Ce qui est quasiment impossible sur des gros projets.

L'agilité permet d'être.... Agile. Donc d'arranger la direction prise en fonction des difficultés et des infos trouvées pendant la création du projet

Ca y est ça commence, je comprends rien

On dirait du VENT, et les arguments qui vont avec me font penser à ceux des adeptes d’une secte qui essaient de s’autopersuader que tout leur délire à un sens

À croire que les devs sont tous confrontés à des projets de difficultés insoupçonnées alors que la plupart du temps ils bossent sur des trucs hyper classiques

c'est pas compliqué.
Méthode Agile : ton projet évolue au fil du temps, tu en sais pas si demain ton client veut un bouton rouge ou bleu, peut-être qu'il faudra encore changer la couleur du bouton après.
Méthode en V : ton projet n'évolue pas, tu passes un ou deux ans sur ton projet et tu sais depuis la minute 1 que ton client veut un bouton bleu. Si il veut finalement un bouton rouge il faudra attendre la fin du projet.

Hilarant les non devs qui veulent venir nous expliquer notre métier

"Mais gneugneu c'est toujours pareil votre taf" ferme ta gueule Corentin

Juste du bullshit pour dire qu'on répartit correctement les tâches entre les devs, qu'on adapte son temps, qu'on est structuré, et qu'on est prêt à prendre en compte les changements demandés par le client.

Tout le reste, c'est de l'enrobage

Et je suis dev

Le 01 septembre 2023 à 12:07:05 :
C'est une méthode de travail inventée par les dev pour les dev, de façon à faciliter leur travail en ayant des cycles de développement courts et à avoir des feedbacks clients le plus tôt possible.

Regarde le manifeste agile, c'est un ensemble de principes (sorte de recommandations) afin de promouvoir l'entraide et la coopération dans le but de développer un produit de qualité.

Ca c'est la théorie.

En pratique c'est un business (cf certifications bullshit), on place des coach agiles (branleurs) et des secrétaires (Scrum master) uniquement dans le but de te fliquer. Les courbes servent juste à mettre la pression sur les dev et pas à évaluer l'avancée du produit (management par la courbe => on t'engueule si la courbe est pas belle.. sans regarder l'évolution du produit globalement au bout du sprint).

Les réunions servent à rien, on infantilise les dev alors qu'on devrait les payer ce à quoi ils sont bons : à développer. Et si chacun faisait correctement son métier (écrire des specs / tickets) y'aurait pas besoin de X réunions pour savoir quoi faire.

Bref, si tu vois ça et que quelqu'un essaie de te convaincre que c'est bien (Scrum master et coach qui n'ont jamais développé ), considère qu'il connait rien à l'info et qu'il sait probablement pas qui a signé le manifeste agile (des dev ).

Tien écrit par un co-signataire du manifeste agile et co-fondateur d'XP :
https://ronjeffries.com/articles/018-01ff/abandon-1/

l'agilité c'est pas pour les dev, c'est inspiré des méthodes de travail en Asie et utilisé en Asie a l'usine ( automobile par exemple)

J'ai fait le calcul. Je travaille depuis 8 ans. Les sprint retrospectives sont censées avoir un retour sur investissement et améliorer des aspects du développement. En 8 ans, je dirais que 99% des retros ont été strictement inutiles.

J'ai donc perdu 8 * 47 * 1,5h = 574 heures pour RIEN

Sans compter le context switching qui te fait perdre plus que ça en réalité. Heureusement avec le télétravail on peut maintenant bosser pendant ces "cérémonies" (réunions forcées).

Le pire ce sont les devs qui se complaisent dans ce système, qui kiffent les meetings où ils peuvent rien foutre pendant 1h/1h30.

Le 01 septembre 2023 à 13:03:03 :
Hilarant les non devs qui veulent venir nous expliquer notre métier

"Mais gneugneu c'est toujours pareil votre taf" ferme ta gueule Corentin

Tu lui donnes le clavier et lui demandes de te montrer. En général ça part voir qqn d'autre illico

En gros au lieu de livrer un truc fini et d'avoir 36 trucs à changer parce que le client voulait que la feature marche autrement que comme ton chef de projet l'a expliqué, tu fais ta petite feature 1/36, tu valides, puis la 2/36... Et ainsi de suite.

Par contre, tu passes de 3-5 réunions pour modifs majeures à une réunion par semaine (et encore, dans cetraines boites c'est une tous les jours) pour faire etat de l'avancement de ton trente-sixième de projet, le faire valider, et passer au suivant.

Le temps perdu à refaire une grosse feature, tu le perds en petites réunions inutiles, mais le chef de projet se sent UTILE.

Le 01 septembre 2023 à 11:59:50 :
C'est l'inverse d'une méthode à Bernard

J'ai ris