IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La méthode agile Scrum serait un cancer
Selon un enseignant en intelligence artificielle

Le , par Jade Emy

389PARTAGES

18  1 
Scrum est un cancer. Santiago, un enseignant en intelligence artificielle, écrit des logiciels depuis 25 ans, et selon lui, rien ne rend une équipe logicielle inutile comme le fait Scrum. Voici ce qu'il rapporte :

Quelques anecdotes :

  1. Ils ont essayé de me convaincre que le poker est un outil de planification, pas un jeu ;
  2. Si vous voulez être plus efficace, vous devez ajouter des processus, et non les supprimer. Ils nous ont fait assister aux "cérémonies", un nom fantaisiste pour un tas de réunions : stand-ups, groomings, planification, rétrospectives, et Scrum de Scrums. Nous avons passé plus de temps à parler qu'à agir ;
  3. Les ordinateurs portables sont interdits en réunion. Nous devions rester debout. Nous faisions circuler un ballon pour que tout le monde reste attentif ;
  4. Nous avons passé plus de temps à estimer les story points qu'à écrire des logiciels. Les story points mesurent la complexité, pas le temps, mais nous devions décider combien de story points correspondaient à un sprint ;
  5. J'ai dû utiliser la taille des t-shirts pour estimer les logiciels ;
  6. Nous avons mesuré le coût de livraison d'un story point, puis nous avons rédigé des contrats dans lesquels les clients payaient pour un lot de "500 story points" ;
  7. La direction a perdu la tête lorsqu'elle a découvert que les 500 story points d'un projet n'étaient pas les mêmes que les 500 story points d'un autre projet. Nous avons tenu de nombreuses réunions pour régler ce problème ;
  8. Imaginez que vous ayez un manager, un scrum master, un product owner et un tech lead. Vous deviez répondre à chacun d'entre eux et à aucun simultanément ;
  9. Nous avons payé des personnes qui nous ont dit si nous "brûlions des points" assez rapidement. Les story points n'étaient-ils pas une question de complexité plutôt que de temps ? Peu importe.



Je crois en la méthode Agile, mais ce n'est pas le cas.

Nous avons fait appel à des formateurs Scrum professionnels. Nous avons payé des membres de notre équipe pour qu'ils soient certifiés. Nous avons essayé Scrum de cette façon et de cette autre façon. Nous avons passé des années à le faire.

Le résultat était toujours le même : cela ne fonctionnait pas.

Scrum est un cancer qui va dévorer votre équipe de développement. Scrum n'est pas fait pour les développeurs. C'est un outil de plus pour que les managers aient l'impression de contrôler la situation.

Mais les meilleurs de Scrum sont ceux qui vous regardent dans les yeux et vous disent : "Si cela ne fonctionne pas pour vous, c'est que vous vous y prenez mal. Scrum, c'est tout ce qui fonctionne pour votre équipe."

Bien sûr que c'est le cas.


Source : Santiago

Et vous ?

Trouvez-vous le témoignage de Santiago crédible ou pertinent ?
Pensez-vous que le témoignage de Santiago reflète de mauvaises utilisations de Scrum ou que Scrum est bien un "Cancer" en tant que tel.
Quel est votre avis sur Scrum ?

Voir aussi :

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

La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas, selon Gene Bond, directeur exécutif chez iiSM.ORG

La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui, répond un professionnel du secteur

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Antjac
Membre chevronné https://www.developpez.com
Le 30/08/2023 à 7:41
Pour ma part, j'essaie d'adapter la méthode en fonction du contexte (entreprise, collaborateurs, nature du projet). Actuellement dans mon entreprise on va faire en fonction de la situation.
Par exemple, Dans le cas d'une période où l'essentiel des tickets va être des bugs isolés, on va travailler en Kanban. Pas de planification, juste une priorisation des tickets faite par les PO et les devs piochent dedans. Daily meetings classiques et on livre régulièrement des releases. Ça s'arrête là

Dans un cas où il y a plutôt des nouveaux développements, on fonctionne sur un sprint backlog préparé à l'avance par les PM et PO avec une priorisation au sein de celui-ci. Lors du premier jour du sprint, on va faire une estimation (en temps) et déjà une affectation à un développeur qui aura une capacité en temps déterminé (en fonction de son contrat, de ses congés sur la periode et de ses potentielles autres activités, typiquement un dev au 35h sans rien de particulier, ça va être 4h30 ou 5h par jour environ).
Quand plus aucun développeur n'a de capacité, le sprint est considéré comme rempli et toutes les autres tâches non affectées sont reléguées dans le backlog.

Chaque jour, on fait le daily meeting assez classiquement, ce qui permet de réajuster, de communiquer sur les difficultés ou au contraire d'aider les autres si l'un est plus en peine et à la fin du sprint, démonstration faite par un membre de l'équipe à l'équipe (devs, testeurs, po, PM, direction et toutes personnes intéressées) et échange rétrospectif après. Je trouve que dans mon contexte, cette méthode (pas forcément scrum) fonctionne assez bien.
8  0 
Avatar de escartefigue
Modérateur https://www.developpez.com
Le 31/08/2023 à 7:07
Citation Envoyé par foetus Voir le message
Après, tu as l'effet tunnel : l'équipe de développeur passe tout son temps jusqu'à la livraison seule sur le projet.
C'est caricatural : le cycle en V n'interdit pas les validations intermédiaires lors de la recette avec avenants au cahier des charges qui permettent d'ajuster les développements. Fort heureusement, on n'attend pas d'être en production pour corriger certains défauts !
8  0 
Avatar de Jacti
Membre habitué https://www.developpez.com
Le 30/08/2023 à 15:35
Je ne suis pas très bien placé pour discuter de la méthode agile Scrum car j'étais (je suis retraité) dans le domaine des systèmes complexes à logiciel prépondérant : avionique, spatial, systèmes militaires, énergie, centrales nucléaires, etc. où l'utilisation de ce genre de méthode est totalement exclue car inadéquate. Cependant j'ai eu de nombreuse occasions de discuter avec des développeurs de tous horizons en donnant des cours de langages de programmation (principalement C++ et Java mais aussi C, ADA, Lisp). L'immense majorité m'ont en effet affirmé que ce genre de méthode ne fonctionnait pas ou alors seulement pour de très petits projets (5 à 10 KLS) et un nombre restreint de développeurs.
Ces méthodes agiles (et pas seulement Scrum) sont totalement inapplicables pour des projets comme les robots martiens ou le transport d'énergie (RTE) par exemple.
Je pense qu'effectivement ces méthodes ne marchent pas dans au moins 85% des cas.
Pour tous ceux qui voudraient s'instruire avec de vraies méthodes de développement logiciel, je conseille la lecture de https://www.nasa.gov/sites/default/f...handbook_0.pdf (gratuit) et les normes IEEE (dont je suis membre) telles que https://innovate.ieee.org/ieee-softw...ing-standards/ (payant)
5  0 
Avatar de thanos
Membre à l'essai https://www.developpez.com
Le 30/08/2023 à 15:50
Ce n'est pas la faute de scrum mais la responsabilité d'un management incompétent (pléonasme). Celui-ci imagine s'en servir pour reprendre la main avec l'aide de "consultants" qui tiennent plus du gourou que de l'expert. De l'agilité tout est tordu. Exemples classiques : rajouter des tâches au sprint en cours sans en retirer, isoler complètement les devs du client et les obliger à passer par des intermédiaires dépassés etc... 😅
5  0 
Avatar de JackIsJack
Membre éclairé https://www.developpez.com
Le 31/08/2023 à 7:45
Cette méthode supprime la notion d'engagement à la fois au plan individuel (car toute l'équipe est responsable, c'est à dire souvent personne en pratique) et vis à vis du client en supprimant le fait qu'il puisse obtenir un livrable donné à une date précise. Comment peut-on prendre au sérieux cette histoire ? De base, la méthode supprime les moyens même pour juger de son efficacité. C'est une chose que les aléas soient nombreux dans l'IT, mais ils existent aussi dans le bâtiment, l'aérospatial... Et le planning et les responsabilités individuelles sont la base. Ensuite, cette méthode laisse penser que l'on puisse créer un projet par morceau, petit à petit, et faire des démos sur des morceaux de foetus et cela avec le client. En somme, on mélange complètement l'étape de conception et de réalisation, on fait les plans et la maison en même temps, et cela dans un domaine avec des interdépendances cachées par milliers...
6  1 
Avatar de totozor
Expert confirmé https://www.developpez.com
Le 30/08/2023 à 7:38
Rappel préliminaire : je ne suis pas développeur et ne travaille pas dans une entreprise ou le développement logiciel est le coeur de métier.

Ca fait 6 mois/1 an qu'on me vend pas mal la "méthode agile", ce qui me laissais quelque peu dubitatif parce qu'on nous l'avais présentée peu de temps après le covid et le présentateur se présentait plus comme un gourou qui veut tout agiliser sans écouter nos demandes et notre contexte. Mais il s'avère que certaines équipes opérationnelles s'y sont mis et que ça semble bien fonctionner.
Ce que je trouve rassurrant chez nous est que les équipes qui encadrent les lancements de projets agiles préfèrent faire peu de projet concluants que beaucoup de projet avec une "couche de peinture" agile. Certains projets agiles ont été lancés et la méthode a été abandonnée parce que inefficace (je ne sais pas pourquoi). Bref tout ça me rend oprimiste sur l'arrivée de l'agile chez nous.

Il n'en reste pas moins que ça semble très dépendant des encadrants et/ou des formateurs. Parce que ça semble bien prendre mais la première présentation qu'on avait eu avait convaincu tout le monde de fuir la méthode comme la peste.
3  0 
Avatar de francoisref
Membre à l'essai https://www.developpez.com
Le 07/09/2023 à 14:29
C'est une chose normale que de critiquer. Mais dans ce que je lis ici, il n'y a presque rien qui relève de scrum.
Scrum ne parle pas de story points.
Scrum définit clairement les rôles et leurs attributions.
Le Daily est du Scrum, mais pas le 'stand-up" (c'est du XP).
Les cérémonies ne sont pas de nouveaux processus. Elles sont les moments où l'équipe s'aligne.

Scrum n'est pas une méthode. Scrum est un cadre.

Pour mieux savoir ce qu'est Scrum, il y a le guide, qui est la seule source officielle. La version française fait 15 pages en comptant les en-tête et sommaire.
3  0 
Avatar de PomFritz
Membre confirmé https://www.developpez.com
Le 13/09/2023 à 0:53
Citation Envoyé par francoisref Voir le message
Page 14 du scrum guide 2020 :
Note de fin
Scrum est gratuit et offert dans ce guide...
... avec ses rituels occultes puissants, provoque votre chance, fait survenir des opportunités de business et vous permet de réaliser des affaires florissantes
Faut vraiment être bête pour ne pas en profiter à ce prix! Des petits bouts de code code vite torchés dans une ambiance ludique...
3  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 30/08/2023 à 12:38
J'ai pas de mal avec les méthodes mais j'ai beaucoup de mal avec les gens qui cherchent à les refourguer comme des charlatans revendent leurs remèdes anti-calvitie.

Chaque problème son approche, et qu'on ne me fasse surtout pas croire cet immonde mensonge comme quoi la hiérarchie est mise de côté pour le Scrum. Sur le papier, peut-être. Concrètement, ca n'a jamais été le cas pour moi.
2  0 
Avatar de DOliv
Membre du Club https://www.developpez.com
Le 31/08/2023 à 9:21
Ce post est une révélation pour moi. C'est exactement ce que j'ai toujours pensé sans être capable d'analyser mon sentiment avec autant de clarté.
C'est exactement ça : un cancer. Qui fait long feu; au bout de très nombreuses années et des sommes faramineuses, tu te retrouve avec un produit inextricable, impossible à faire évoluer et qu'il faut vendre absolument avant qu'il ne meure.
2  0