Discussion :

[foetus]

L'alternative à l'agilité ce serait de livrer le logiciel final, qui correspondrait exactement au cahier des charges, du coup le logiciel ne répondrait pas aux nouveaux besoins du client.

Il y a 2 autres méthodes pour les projets industriels : cycle en V et WaterFall (<- il me semble que c'est elle qui n'existe pas d'après certains)

Mais il n'y a pas vraiment d'alternatives aux méthode agiles dans le sens où avec les projets industriels, tu passes des mois à caler et à valider le cahier des charges avant de te lancer.
Après, tu as l'effet tunnel : l'équipe de développeur passe tout son temps jusqu'à la livraison seule sur le projet.

Tu vois 1 application mobile ou 1 site où tu passes X mois pour le concevoir … surtout que ce sont des développements très très changeants

D'ailleurs, la différence entre les méthodes agiles, c'est le cahier des charges justement :

• l'eXtrem Programing (XP) : pas de cahier des charges (donc pas du tout sérieux pour les ESNs)s, basée sur 12 principes (comme par exemple "test first", "pair programming") Et le client code.
• Scrum : c'est + basé sur le management du projet (donc très sérieux pour les ESNs). Des documents remplacent le cahier des charges ("product backlog" par exemple)
• Kaban, connais pas

[escartefigue]

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 !

[JackIsJack]

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...

[boumchalet]

3 principes :
- Qualité
- le client tire les besoins
- Générer de la valeur à chaque incrément

L’agilité a prouvé sa supériorité par rapport au management par contrainte (cycle en v)

=> il ne faut pas penser outils ou méthode mais au but à atteindre

[DOliv]

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.

[devnino]

Scrum dans l’état actuel n’est pas agile.

[pboulanger]

Bien géré Scrum peut permettre une amélioration notamment dans la communication entre le métier et les dévs.

Le souci est que nombres de société ont une hiérarchie complexe/lourde, des équipes dédiés (avec des murailles de Chine) et des petits chefs qui défendent leurs prés carrés: ça c'est un frein au bon fonctionnement de l'agilité. Ce rajoute à cela une volonté d'économie, là où il y avait des chefs de projets, des chefs de produits on a mis des scrum masters, product owners et autres qui ont un titre, des responsabilités mais pas le salaire d'une chef (on ampute toute une partie de la masse salariale dans des grands groupes).

Ensuite vient le contrôle, l'agilité vient avec des outils et des KPI: on a donc des éléments permettant une mesure (biaisée) de la productivité.

A mon sens, Scrum est bien pour de petites équipes sans dépendances externes dans un système hiérarchisé complexe (comme les startups).

[blbird]

Je suis assez d'accord sur le fait que l'agilité ne marche bien que dans des conditions bien spécifiques, qui ne dépendent pas que de ceux impliqués dans la gestion de projet.

Un autre point noir pour moi, c'est l'analyse globale en Cas d'Usages basés sur les besoins utilisateurs uniquement. Je n'ai vu que de mauvaises analyses dans ce sens, qui oublient trop souvent beaucoup de choses : impact des besoins fonctionnels et de la solution technique utilisée, ergonomie globale de l'application, ... Qui plus est, reprendre un "cahier des charges" basés sur des cas d'usages est un enfer, autant pour la difficulté de lecture que pour la compréhension générale.

[totozor]

Un autre point noir pour moi, c'est l'analyse globale en Cas d'Usages basés sur les besoins utilisateurs uniquement. Je n'ai vu que de mauvaises analyses dans ce sens, qui oublient trop souvent beaucoup de choses : impact des besoins fonctionnels et de la solution technique utilisée, ergonomie globale de l'application, ... Qui plus est, reprendre un "cahier des charges" basés sur des cas d'usages est un enfer, autant pour la difficulté de lecture que pour la compréhension générale.

Et rédiger des cahiers des charges par cas d'usage est un enfer aussi. C'est en partie mon travail ou plutot ça devrait l'être. On ne le fait pas dans quasiment tous les petits projets "pas trop managé".
Les problèmes que nous avons avec cette méthode sont simples :
_ Certains cas d'usage sont incompatibles mais il est possible qu'on s'en rende compte un peu tard et la responsabilité tombe sur le dev' qui doit satisfaire deux cas à qui on a vendu qu'ils existeront.
_ Les cas d'usage scindent la logique de travail utilisateurs et la rendent illisible. On se retrouve avec des application qui répondent à chaque cas mais ne sont pas forcément intuitif pour l'utilisateur.

[vertex.3F]

3 principes :
- Qualité
- le client tire les besoins
- Générer de la valeur à chaque incrément

L’agilité a prouvé sa supériorité par rapport au management par contrainte (cycle en v)

=> il ne faut pas penser outils ou méthode mais au but à atteindre

je suis assez d'accord avec ça

pour moi le refactoring contribue à rendre l'agilité supérieure : la priorisation des user stories engendre de la dette qu'on a besoin de rembourser en permanence (maintien d'un code clair), et il faut sans cesse lutter aussi contre l'erosion du design (survient assez ineluctableblent au fil des increments)

de mon experience, dans les methodes non-agiles, le refactoring etait mal compris et vu comme du rewriting, jamais on n'acceptait de rembourser ladite dette avant d'ajouter des features

cela etant, je lis aussi sur ce fil qu'avec les methode non agiles on n'est pas obligé d'agir comme des bourrins !!! et j'approuve ! lors de mes missions nous pouvions decouper en lots, coder des tests automatisés (unitaires, integration, end-to-end...), livrer regulierements avec une CI/CD, ...

A mon avis, du moment qu'on le veut, on peut garder le controle sur la valeur et la qualité quelle que soit la methode ( conduite de projet )

Apres les querelles de chapelles, l'un des principaux soucis des methodes c'est la credulité doublée d'optimisme de ceux qui peuvent croire qu'on fera du bon boulot sans moyens humains... d'ou le nombre considerable de plantages de projets, toutes methodes confondues (delai ou couts ou contenu ou les 3)

ça ne sert à rien de nous étriper sur le sujet

[vertex.3F]

Je suis assez d'accord sur le fait que l'agilité ne marche bien que dans des conditions bien spécifiques, qui ne dépendent pas que de ceux impliqués dans la gestion de projet.

Un autre point noir pour moi, c'est l'analyse globale en Cas d'Usages basés sur les besoins utilisateurs uniquement. Je n'ai vu que de mauvaises analyses dans ce sens, qui oublient trop souvent beaucoup de choses : impact des besoins fonctionnels et de la solution technique utilisée, ergonomie globale de l'application, ... Qui plus est, reprendre un "cahier des charges" basés sur des cas d'usages est un enfer, autant pour la difficulté de lecture que pour la compréhension générale.

c'est pas faux

une mauvaise business analysis aura des conséquences facheuses sur le projet, qu'il soit conduit en agilité ou pas

[Stéphane le calme]

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é

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 ?

[kmedghaith]

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é.

[Ryu2000]

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.

[francoisref]

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.

[francoisref]

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.

[Ryu2000]

le résultat ne sera pas du Scrum.

Ben ouais !
Je ne veux pas de Scrum, je veux ma méthode agile.

[PomFritz]

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...

[eloibru]

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

[axel1818]

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..