Hello,

Dans mon équipe on travaille en méthode agile/scrum/kanban.
On a des dailys meeting, planning poker et tout le tralala...

Et plus le temps passe plus j'en deviens allergique. J'ai l'impression que les gens ont abandonné leur bon-sens au profit de ces méthodes. A croire que c'est une formule magique, qui fait que tout va fonctionner.
Clairement dans mon équipe je trouve que ça ne marche pas.
Il y a des trucs biens, mais dès que tu fais des propositions ou des critiques sur le système, on te réponds "On est agile "

Je suis le seul à trouver que parfois c'est débile de suivre ça à la lettre, et que c'est souvent plus un frein qu'autre chose ?

Je vois souvent ces termes là mais j'ai jamais compris en quoi ça consiste concrètement, tu peux expliquer vite fait

C'est juste qu'il y a plein d'entreprises qui appliquent betement une methodologie telle quelle, sans avoir compris la philosophie globale et le besoin d'adapter des processes generiques aux cas particuliers de ses projets/equipes.

Il y a plein de trucs qui ne marchent pas bien, et ne marcheront jamais bien, dans les methodologies abstraites : les gens qui savent faire de l'Agile savent adapter des hybrides á leurs problematiques, les autres se content de mettre en place ce qu'ils ont vu/lu dans un bouquin ou formation sans comprendre la logique sous-jacente.

Il faut repartir du paradigme et emprunter/moduler des outils aux cas concrets qu'on rencontre.

Je vois souvent ces termes là mais j'ai jamais compris en quoi ça consiste concrètement, tu peux expliquer vite fait

Pour faire simple, en deux mots : scrum/kanban/etc. sont des methodoligies (= ensemble de processes pour gerer les facons de travailler) qui implementent la philosophie Agile (= developpement iteratif qui vise á adapter en permanence pour un objectif qui evolue), le tout s'inscrivant dans le paradigme Lean (= approche de management/organisation qui vise á maximiser la valeur produit par une flexibilité permettant d'eliminer le superflu)

C'est TRES simplifié, et ca fera bondir qq puristes, mais ca suffit á donner une idee.

Le probleme vient du fait que bcp d'entreprises veulent etre "Agile" parceque c'est "tendance", sans reellement comprendre la motivation derriere le type d'organisation, et emploient des "coach Agile" qui n'y comprennent pas plus au paradigme et n'ont pour "experience" qu'une formation qui leur dit que "tels processes" c'est "mieux".

Ca conduit á des aberrations oú on implemente des facons de travailler á des cas concrets qui sortent du cadre de valadité de la methodologie "pure", ce qui frustre la direction comme les equipes.

Bcp cherchent á mettre en place un methodologie telle que presentée "parfaitement" dans des bouquins, au lieu de comprendre qu'il s'agit de panels d'outils conceptuel dans lesquels il faut piocher apres avoir analysé les besoins réels de son projet/equipe.

Une autre raison j'imagine c'est tout simplement... L'incompétence des gens ?

Quand on est pas très bon le plus simple c'est de se cacher derrière ce genre de méthode hyper normée, parce que "tout le monde le fait", sans jamais réfléchir et remettre le tout en question.

J'ai l'impression que ça arrive pas mal dans l'IT en général, avec tous ces techs qui suivent n'importe quel mode car tel boîte de la french tech a écrit un article medium sur pourquoi leur manière de faire est trop bien et il faut faire pareil

Non c'est juste que les trucs tendance en techno donnent accés à des fonds / credits suplémentaire, ce qui amene à des aberrations où tu as 7000 employés au lieu de 50 pour faire tourner twitter.

Il ne faut pas raconter n'importe quoi non plus, juste pour faire de "l'anti-tendance" ; le developpement iteratif et les methodologies Agile en general presentent plein d'avantages (si bien utilisé), et c'est meme indispensable dans plein de domaines oú on ne dispose pas de metrique quantifiable par avance (par exemple, aucune formule pour mesurer de facon precise "le fun" d'une mecanique de jeu vidéo avant d'avoir un proto entre les mains pour tester directement).

Le probleme etant que c'est souvent appliqué betement comme un standard de modernité, sans reflechir au fond.

Le 23 novembre 2022 à 00:58:39 RegleGraduee a écrit :
Clairement dans mon équipe je trouve que ça ne marche pas.

Pourquoi ?

Dans le milieu, on parle un peu "d'agile à la française" pour ne pas dire "l'arrache".
De nombreuses entreprises prennent SCRUM (ou d'autres méthodes basées sur le manifeste Agile) et en appliquent la souplesse sans en appliquer les contraintes.
Les exemples les plus gros sur SCRUM :
- modifier un sprint durant son cours
- embarquer des tickets qui ne respectent pas la Definition of Done (voire : il n'y a pas de Definition of Done)
- chiffrer en temps
- utiliser la rétrospective comme "défouloir" sans faire aucune action concrète
- chiffrer à la place de l'équipe de développement

Initialement, ce type de méthodo se base sur de la livraison itérative pour palier à l'effet tunnel classique des projets en cycle en V (fournir le cahier des charges => le client n'a aucune visibilité pendant X mois/années => lui livrer le produit final et constater que ça ne convient pas).
Le but annoncé est de réaliser de courtes phases de développement pour avoir une idée le plus vite possible de la fonctionnalité (et du logiciel au global) pour ainsi bien confirmer que la direction est bonne (et potentiellement réduire le time to market en réalisant un produit itératif).

J'ai eu deux très bonnes expériences en SCRUM et une majorité de moyennes/mauvaises. Tous les problèmes venaient du fait que le client ne se pliaient pas aux contraintes de la méthodo qui le concernaient et nous pressaient encore et toujours car "nous sommes AGILES".
C'est très dommage, je trouve, car bien appliquée, cette méthode permet de :
- responsabiliser chaque acteur du projet (dév, QA, client)
- favoriser la communication sans aller en réunionite (même si on peut discuter sur la fréquence des "rituels")
- se prendre des murs plus vite et donc adapter les fonctionnalités et produits plus vite
- avoir un ressenti d'accomplissement pour rapidement