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 Scrum est-elle une méthode agile efficace ou un cancer pour les développeurs ?
Les propos d'un professionnel de l'informatique divisent la communauté

Le , par Stéphane le calme

77PARTAGES

13  1 
La « méthode » Scrum, qu'est-ce que c'est ?

La méthode Scrum, ou plus exactement le cadre de travail (framework) Scrum est de loin la méthode agile la plus utilisée dans le monde. Expérimentée en 1993, elle bénéficie aujourd’hui de nombreux retours d’expérience. Les conférences, communautés, formations, blogs, outils et ouvrages à son sujet ne manquent pas

Parler d’une « méthode » concernant Scrum n’est pas ce qu’il y a de plus approprié. Scrum ne se considère pas comme une méthode mais comme un cadre de travail (framework). Une méthode dit généralement « comment » faire les choses. Scrum ne dit pas comment réussir son logiciel, comment surmonter les obstacles, comment développer, comment spécifier, etc. Il se contente d’offrir un cadre de gestion de projet agile : des rôles, un rythme itératif, des réunions précises et limitées dans le temps, des artefacts (product backlog, sprint backlog, graphique d’avancement) et des règles du jeu.

Scrum repose sur un processus itératif et incrémental, où le produit est construit par petites étapes appelées sprints. Chaque sprint dure généralement de 2 à 4 semaines et produit une version fonctionnelle et potentiellement livrable du produit.

Scrum implique trois rôles principaux : le Product Owner, qui représente la voix du client et définit les priorités du produit ; le Scrum Master, qui facilite le processus Scrum et s’assure que l’équipe respecte les principes et les pratiques de la méthode ; et l’équipe de développement, qui réalise le travail technique nécessaire pour créer le produit.

Scrum se base également sur quatre événements clés : la planification du sprint, qui permet à l’équipe de définir ce qu’elle va réaliser pendant le sprint ; le stand-up quotidien, qui est une réunion courte où l’équipe fait le point sur son avancement et ses difficultés ; la revue du sprint, qui est une démonstration du produit réalisé pendant le sprint au Product Owner et aux parties prenantes ; et la rétrospective du sprint, qui est un moment d’amélioration continue où l’équipe identifie ses forces et ses axes d’amélioration.

Scrum utilise aussi des artefacts pour faciliter la communication et la transparence, tels que le backlog du produit, qui est une liste ordonnée des fonctionnalités souhaitées pour le produit ; le backlog du sprint, qui est une sélection des éléments du backlog du produit à réaliser pendant le sprint ; et l’incrément, qui est l’ensemble des fonctionnalités livrables à la fin du sprint. La méthode Scrum est une méthode flexible, adaptative et centrée sur la valeur, qui permet aux équipes de livrer des produits de qualité en tenant compte des changements et des retours du client.

Scrum est loin de faire l'unanimité

Santiago Valdarrama, enseignant en intelligence artificielle ayant 25 ans d'expérience dans le développement logiciel, a critiqué la méthode Scrum, qu’il considère comme un cancer pour les équipes de développement. Il raconte plusieurs anecdotes qui illustrent les problèmes qu’il a rencontrés avec Scrum, tels que :
  • L’utilisation du poker comme outil de planification, alors que c’est un jeu.
  • L’ajout de processus inutiles qui prennent plus de temps que le développement lui-même, comme les « cérémonies » (réunions quotidiennes, affinages, planifications, rétrospectives, etc.).
  • L’interdiction des ordinateurs portables et l’obligation de rester debout pendant les réunions.
  • La difficulté d’estimer la complexité des tâches avec des points de story, qui ne correspondent pas au temps réel ni à la valeur pour le client.
  • L’utilisation de tailles de t-shirt pour mesurer le logiciel.
  • La rédaction de contrats basés sur le nombre de points de story livrés, sans tenir compte des spécificités de chaque projet.
  • La pression exercée par le management, le scrum master, le product owner et le tech lead, qui ont des attentes contradictoires ou irréalistes.
  • Le recours à des indicateurs trompeurs comme la « vitesse de combustion » des points de story, qui ne reflètent pas la qualité du logiciel.

Le développeur affirme qu’il croit en l’agilité, mais que Scrum n’est pas agile. Il dit avoir essayé plusieurs variantes de Scrum avec des formateurs et des certifiés, mais que le résultat a toujours été le même : ça n’a pas marché. Il conclut que Scrum est un cancer qui va détruire 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 ».

Des réactions diverses à ses déclarations

Konrad Banachewicz, Principal Data Scientist chez IKEA, a applaudi cette sortie : « J'aimerais pouvoir vous voter plusieurs fois. J'ai une haine brûlante pour Scrum et je crois que chacun de ses créateurs mérite d'être puni ».

À quoi ça sert? Absolument rien? Pas exactement, pense l'internaute qui répond au pseudonyme mwint :

J'ai développé une vision plus nuancée de Scrum depuis que je travaille en tant qu'entrepreneur pour une entreprise de logiciels de taille moyenne, mais à côté de leurs équipes de développement normales.

J'avais l'habitude de penser que Scrum se résumait à un lot de réunions inutiles, qui enlève la vie et la productivité du processus de développement.

Maintenant, après l'avoir vu d'un point de vue adjacent (mais non soumis à celui-ci), je pense que c'est une série de réunions qui sucent la vie et qui ne servent qu'à une chose : emmener les développeurs qui ne peuvent pas ou ne veulent pas voir l'image d'ensemble de l'entreprise/de l'architecture et en tirer un travail utile.

La plupart d’entre nous ici ne faisons pas partie de cette catégorie. Je parierais que la majorité des lecteurs ne peuvent s’empêcher de chercher à comprendre l’entreprise, où s’inscrit cette pièce, avec quoi elle interagit. Pour nous, tout préciser d’avance ne sert à rien. Estimer des choses est irritant car nous avons besoin de flexibilité pour prendre des décisions intelligentes pendant le développement. Les réunions rétro sont des mensonges car on ne peut pas dire « arrête avec tout ça et laisse-moi travailler ».

Mais si vous essayez de créer un processus qui peut prendre des développeurs juniors (pas juniors en termes de mandat, mais juniors dans les qualités ci-dessus) et produire un résultat qui évolue presque linéairement avec le nombre de développeurs, cela fonctionne en quelque sorte.

Je dirais qu'il est bien préférable d'embaucher 6 développeurs qui peuvent passer d'un problème commercial à une solution technique dans leur tête, sans toute la cérémonie, au lieu de 40 développeurs qui ne peuvent pas et 6 Product Managers pour lancer les débats.

Mais je peux aussi voir comment une entreprise se retrouve là : traverser une année d'embauche difficile, ou même simplement prendre quelques mauvaises décisions d'embauche, et maintenant vous avez des personnes dans l'équipe qui ont besoin d'être accompagnées et supervisées. C’est ça la mêlée ; cela ressemble à de la microgestion parce que c'est le cas. Cela force les développeurs juniors à devenir productifs - peut-être 5 % de ce que vous obtiendriez d'un développeur senior sans Scrum, mais c'est quelque chose de non négatif.

En le lisant, certains pourraient penser qu'il sous-entend que Scrum est ennuyeux si vous êtes un développeur compétent et expérimenté. C'est en tout cas ce qui ressort des propos de u/Own_Spare_544 :

Pour le contexte, mon parcours est que je suis un scientifique titulaire d'un doctorat qui travaille dans l'analyse de données scientifiques et le développement de logiciels. Je possède à la fois une expertise en la matière dans nos produits ainsi que des compétences techniques en développement de logiciels. J'ai été soudainement placé dans une équipe Scrum lors d'une réorganisation et je travaille dans cet environnement depuis 5 mois. Après la transition Scrum, mon rôle est celui d'un développeur de base travaillant sur le produit.

Cela devient insupportable. Il ne s’agit pas d’un seul problème, mais de la confluence de plusieurs à la fois :
  • Les tickets sont digérés par le Product Manager et le Scrum Master. Nous n'avons aucune contribution sur ce sur quoi nous travaillons, ni aucun retour sur la façon dont cela est mis en œuvre, créant ainsi un scénario de « cuisinier à la chaîne »/chaîne de montage.
  • Nous organisons des standups quotidiens où nous examinons chaque ticket dans JIRA et déplaçons les dates cibles/échéances de +/- 1 jour à la fois et grillons les gens sur leurs progrès. Cela prend 45 minutes à 1 heure par jour.
  • Le chef de produit protège les parties prenantes de l'équipe, mais protège également l'équipe des parties prenantes, nous n'avons donc pas de discussions sur la situation dans son ensemble.
  • Les tâches sont décomposées en éléments de petite taille, généralement par le PM/SM, de sorte qu'il n'y a pas de véritable entrée sur quoi, quand et comment quelque chose est fait.
  • Nous ne sommes pas autorisés à accomplir des tâches qui durent plus d'une journée, ce qui décourage d'essayer de résoudre des problèmes complexes en général.
  • Parce que tout est microgéré, aucune tâche n’est réellement nécessaire. Une personne titulaire d'un baccalauréat en informatique pourrait effectuer n'importe laquelle de ces tâches.
  • Les tâches de sprint sont modifiées quotidiennement dans ces stand-ups, ce qui perturbe encore davantage ma capacité à réfléchir à quelque chose de profond ou de difficile, ou à diriger moi-même mon travail.
  • Les PM/SM ne se soucient pas des considérations techniques car ils ne se soucient que d'ajouter de nouvelles fonctionnalités à un rythme rapide, et aucun d'eux n'a d'expertise en développement logiciel.
  • Chaque fois que le travail de l'équipe est démontré, c'est le fait d'une seule personne, donc fondamentalement, aucun membre de l'équipe n'est reconnu par les parties prenantes.
  • Nous planifions des sprints de 2 semaines, puis changeons constamment les priorités, y compris le premier jour du sprint.
  • En raison de la pression, les membres de l'équipe se battent pour savoir qui pourra clôturer son ticket le plus rapidement.
Au refrain du « Vous vous y prenez mal », David Sabine a rétorqué :

C'est épuisant de lire des histoires comme celle-ci – des équipes de personnes faisant des choses bizarres et rejetant la faute sur Scrum. … C'est à la mode de blâmer Scrum. [Mais] à moins que chacun des individus assume la responsabilité de l’amélioration de son équipe et de son environnement de travail, ces problèmes persisteront longtemps après que Scrum soit devenu le bouc émissaire à la mode.
Mais l'internaute répondant au pseudonyme xedrac n'est pas d'accord : « J’ai pris la parole dans de nombreuses rétrospectives, mais quand rien ne change, c’est difficile de les prendre au sérieux. Quel est l’intérêt d’une rétrospective si vos retours sont simplement ignorés ? »

Sources : réponses à la publication de Santiago Valdarrama (1, 2)

Et vous ?

Quel analyse faites-vous des propos de ces professionnels ?
Quelle est votre expérience personnelle avec Scrum ? Avez-vous rencontré des difficultés ou des bénéfices en utilisant cette méthode ?
Quels sont les facteurs qui influencent la réussite ou l’échec d’un projet Scrum ? Quels sont les rôles et les responsabilités des différents acteurs du projet ?
Quelles sont les alternatives à Scrum que vous connaissez ou que vous utilisez ? Quels sont leurs avantages et leurs inconvénients par rapport à Scrum ?
Comment améliorer la pratique de Scrum dans votre contexte ? Quelles sont les bonnes pratiques ou les pièges à éviter ?

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

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 kmedghaith
Membre confirmé https://www.developpez.com
Le 07/09/2023 à 11:32
La méthode Scrum est-elle une méthode agile efficace ou un cancer pour les développeurs
Question toute en nuance qui va générer un débat tout aussi nuancé.
2  0 
Avatar de Ryu2000
Membre extrêmement actif https://www.developpez.com
Le 07/09/2023 à 12:22
Nous ne sommes pas obligé de suivre SCRUM à la lettre.
Il est possible de faire son propre système de gestion de projet agile.
Par exemple :
Modifier les postes product owner/scrum master.
Supprimer des réunions, garder juste un stand-up meeting de 5 minutes chaque jour et une réunion en fin de SCRUM.

Garder le tableau :
- À réaliser
- En développement
- À valider
- Terminé

Réaliser un processus itératif et incrémental, avec des sprints de 2 semaines et voilà.

====
L'agilité c'est très bien, peut-être que Scrum n'est pas la meilleure méthode agile, mais il y a des trucs sympa à l'intérieur.
3  2 
Avatar de Ryu2000
Membre extrêmement actif https://www.developpez.com
Le 08/09/2023 à 9:37
Citation Envoyé par francoisref Voir le message
le résultat ne sera pas du Scrum.
Ben ouais !
Je ne veux pas de Scrum, je veux ma méthode agile.
3  2 
Avatar de francoisref
Membre à l'essai https://www.developpez.com
Le 08/09/2023 à 9:33
Citation Envoyé par Ryu2000 Voir le message
Nous ne sommes pas obligé de suivre SCRUM à la lettre.
Il est possible de faire son propre système de gestion de projet agile.
Page 14 du scrum guide 2020 :
Note de fin
Scrum est gratuit et offert dans ce guide. Le cadre de travail Scrum, tel que décrit ici, est immuable. Bien
que la mise en œuvre uniquement de certaines parties de Scrum soit possible, le résultat ne sera pas du
Scrum. Scrum n'existe que dans sa totalité et peut fonctionner comme un conteneur pour d'autres
techniques, méthodologies et pratiques.
0  0 
Avatar de eloibru
Membre à l'essai https://www.developpez.com
Le 15/09/2023 à 9:55
je suis assez d'accord avec l'article.
scrum en tant que tel est une bonne méthodologie, mais comme chaque méthodologie c'est à elle de s'adapter à l'entreprise et non pas à l'entreprise de s'adapter à la méthodologie.
dans ma boite actuelle, toutes les semaines, on a :
- le daily (possiblement 3 par jour)
- une matinée complète de réunion à 35 personnes pour revoir le backlog (4 personnes max qui ont qqch à dire).
- lors des pocker planning, on doit estimer en sotry point, c'est tellement facile de comparer la création d'une table et la création d'un écran.
- pas de retrospective

tous les 15 jours, une journée complète de réunion (démo, planning, ..).

En dehors de ces réunions, aucune communication.

Quand j'ose dire que ce n'est pas efficace, on me renvoie vers certains articles scrum disant que c'est la bonne manière de faire.

Pour moi, scrum, c'est le daily à max 2 minutes par personnes
la démo, qui doit être bien préparée, avec un agenda du jour clair et précis.
un sprint planning
une rétrospective utile avec des points d'actions
des équipes réduites ou il doit y avoir une communication active
0  0 
Avatar de axel1818
Candidat au Club https://www.developpez.com
Le 15/09/2023 à 11:14
Mettez le donneur d'ordre (moa) et le développeur dans la meme pièce pour travailler ensemble sur le projet.
Le développeur comprend bien pourquoi il se fait engueuler par le donneur d'ordre. ( cela marche pas, t 'as oublié cela... )
Le donneur d'ordre comprend vite pourquoi ce n 'est pas possible ou que son truc est nul. ( c est pas possible, on recevra les données que le lendemain de l action )
Les reunions (si on peut dire) entre ces 2 parties débouchent toujours sur une décision( alors je fais quoi ?)
le budget sera dépassé ( normal on paufine le 0 bug) et des fonctionnalités seront rajoutées en cours de route ( c 'est la partie agilité de type direct du projet).
Mais à la fin, il y aura toujours un super truc approuvé par les 2 parties !
de temps en temps, l' utilisateur final gueule, mais c 'est aprés la finalisation et il n 'était pas dans la pièce pendant la construction du bazar sauf si le donneur d 'ordre est l utilisateur où l on revient au point précédent. Si il gueule vraiement fort, on améliorera dans une nouvelle version.
Bizarrement quand cela se passe de cette façon cela fonctionne bien..
2  2 
Avatar de shenron666
Expert confirmé https://www.developpez.com
Le 17/09/2023 à 23:58
Citation Envoyé par francoisref Voir le message
Page 14 du scrum guide 2020 :
Note de fin
Scrum est gratuit et offert dans ce guide. Le cadre de travail Scrum, tel que décrit ici, est immuable. Bien
que la mise en œuvre uniquement de certaines parties de Scrum soit possible, le résultat ne sera pas du
Scrum. Scrum n'existe que dans sa totalité et peut fonctionner comme un conteneur pour d'autres
techniques, méthodologies et pratiques.
c'est bien ce que Ryu2000 a indiqué
Citation Envoyé par Ryu2000 Voir le message
Nous ne sommes pas obligé de suivre SCRUM à la lettre.
Il est possible de faire son propre système de gestion de projet agile.
en ce qui me concerne, le problème n'est pas la méthode
c'est son application
tantôt soi-disant "à la lettre"
tantôt adaptée à la sauce de tout un chacun
jamais respectée comme il faut
0  0 
Avatar de ddoumeche
Membre extrêmement actif https://www.developpez.com
Le 19/09/2023 à 18:40
Citation Envoyé par eloibru Voir le message
je suis assez d'accord avec l'article.
scrum en tant que tel est une bonne méthodologie, mais comme chaque méthodologie c'est à elle de s'adapter à l'entreprise et non pas à l'entreprise de s'adapter à la méthodologie.
dans ma boite actuelle, toutes les semaines, on a :
- le daily (possiblement 3 par jour)
- une matinée complète de réunion à 35 personnes pour revoir le backlog (4 personnes max qui ont qqch à dire).
- lors des pocker planning, on doit estimer en story point, c'est tellement facile de comparer la création d'une table et la création d'un écran.
- pas de retrospective
Scrum n'est pas adapté aux grosses équipes, pas plus que les projets informatiques en général. Au delà de 8-10 personnes, le temps perdu en interactions croit géométriquement, et le meilleur moyen de couler un énorme projet est de rajouter des développeurs.
Réorganisez-vous en plusieurs équipes de 5 à 10, ou en binômes.
Utilisez le planning poker pour discuter des problèmes techniques entre développeurs, mais si chacun est un spécialiste de sa partie du programme uniquement, cela ne sert à rien. Décorrélez les services des IHMs pour augmenter la granularité et obtenir une meilleur estimation.

Citation Envoyé par eloibru Voir le message
tous les 15 jours, une journée complète de réunion (démo, planning, ..).

Quand j'ose dire que ce n'est pas efficace, on me renvoie vers certains articles scrum disant que c'est la bonne manière de faire.

Pour moi, scrum, c'est le daily à max 2 minutes par personne
la démo, qui doit être bien préparée, avec un agenda du jour clair et précis.
4 équipes de 9 personnes faisant un daily meeting = (9-1)*2 = 16 minutes de "perdues" par personne et par jour

35 personnes faisant un daily meeting = (35-1)*2 ~= 1h10 de perdues par personnes et par jour.
35 personnes regardant le/la démo du collègue = 1/2 journée de perdue par personne par semaine.
Exercice : Faites le calcul du nombre de postes de travail que représentent ces 1h10 perdus par personne et par jour.

Voila ce que c'est que d'avoir des experts juniors envoyés par la SSII du coin. J'en ai connu, c'était des marchant de tapis.

Ici, on n'a jamais rien adopté de manière puriste, que ce soit ISO 9126, ou Scrum qui a des qualités mais beaucoup de défauts. On a toujours eu des équipes en compétition les unes avec les autres mais capable d'apporter des solutions à des problèmes, et se partager.
Et quand quelque chose n'allait pas, il y avait toujours un ingénieur pour la ramener et faire un scandale.
0  0