La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui
Répond un professionnel du secteur
Le 2018-04-22 19:12:29, par Victor Vincent, Expert éminent sénior
Scrum est une méthode de développement agile qui a été créé dans le but d’obtenir de meilleurs résultats dans les meilleurs délais. Elle se fonde sur plusieurs principes, des rôles fixes, des réunions officielles et des listes. Scrum permet de mener à bien des projets dont les besoins sont difficiles à quantifier dès le début. C’est l’une des principales forces qui ont contribué à sa popularité. Elle comporte cependant des inconvénients comme toute méthode. Scrum est adaptée aux équipes de petite taille, par conséquent des difficultés peuvent être rencontrées s’il s’agit de projets dont la taille de l’équipe est assez importante.
Scrum présente le risque de voir les fonctionnalités s’étendre indéfiniment ou « Scope Creep ». À moins qu’une date de fin soit définie de manière formelle, les parties prenantes peuvent être tentées de rajouter des fonctionnalités. Par ailleurs, si une tâche n'est pas bien définie, l'estimation des coûts et du temps du projet ne sera pas exacte. Dans ce cas, la tâche peut être répartie sur plusieurs sprints.
La méthodologie Scrum est étiquetée comme « carrée ». En effet, elle ne supporte pas des modifications dans son principe. On peut lire sur le guide officiel que « les rôles, les artefacts, les événements et les règles de Scrum sont immuables et bien que l'implémentation de certaines parties de Scrum soit possible, le résultat n'est pas Scrum. Scrum n'existe que dans son intégralité et fonctionne bien comme un conteneur pour d'autres techniques, méthodologies et pratiques. »
Ce manque de flexibilité peut être constaté par exemple dans la définition du PBI « Product Backlog Item », qui est sous la responsabilité du Product Owner. En cas de manque de communication, les membres de l’équipe n’auront pas la possibilité d’apporter des améliorations à la définition des produits. Le guide de Scrum ne définit pas formellement une méthode de gestion des bogues, de réduction de la dette technique.
Le fait d’imposer un système de gestion de temps constitue également une contrainte. Tous les événements sont conditionnés dans le temps. Une fois qu'un Sprint commence, sa durée est fixe et ne peut être raccourcie ou allongée. Le Daily Scrum est fixé sur une durée de 15 min. Ce mode de fonctionnement ne favorise pas, une gestion de temps propre à chaque membre de l’équipe et par conséquent réduit les possibilités d’innovation et d’optimisation.
Enfin la méthode SCRUM s’adapte difficilement aux outils de gestions de tâches (JIRA, TFS,…) qui imposent des interprétations très bureaucratiques de Scrum. Ce qui induit une perte de temps pour les développeurs. Vis-à-vis des développeurs, le fait de splitter les tâches en petits éléments qui peuvent théoriquement être complétés par n’importe qui dans l’équipe réduit le sentiment de fierté et d’appropriation de la réalisation des tâches. Tous ces points faibles de la méthode ont poussé Adam Ard, un professionnel de la programmation, à affirmer que Scrum est une mauvaise méthode pour la gestion de projet agile.
Source : Billet de blog
Et vous ?
Voir aussi
Scrum présente le risque de voir les fonctionnalités s’étendre indéfiniment ou « Scope Creep ». À moins qu’une date de fin soit définie de manière formelle, les parties prenantes peuvent être tentées de rajouter des fonctionnalités. Par ailleurs, si une tâche n'est pas bien définie, l'estimation des coûts et du temps du projet ne sera pas exacte. Dans ce cas, la tâche peut être répartie sur plusieurs sprints.
La méthodologie Scrum est étiquetée comme « carrée ». En effet, elle ne supporte pas des modifications dans son principe. On peut lire sur le guide officiel que « les rôles, les artefacts, les événements et les règles de Scrum sont immuables et bien que l'implémentation de certaines parties de Scrum soit possible, le résultat n'est pas Scrum. Scrum n'existe que dans son intégralité et fonctionne bien comme un conteneur pour d'autres techniques, méthodologies et pratiques. »
Ce manque de flexibilité peut être constaté par exemple dans la définition du PBI « Product Backlog Item », qui est sous la responsabilité du Product Owner. En cas de manque de communication, les membres de l’équipe n’auront pas la possibilité d’apporter des améliorations à la définition des produits. Le guide de Scrum ne définit pas formellement une méthode de gestion des bogues, de réduction de la dette technique.
Le fait d’imposer un système de gestion de temps constitue également une contrainte. Tous les événements sont conditionnés dans le temps. Une fois qu'un Sprint commence, sa durée est fixe et ne peut être raccourcie ou allongée. Le Daily Scrum est fixé sur une durée de 15 min. Ce mode de fonctionnement ne favorise pas, une gestion de temps propre à chaque membre de l’équipe et par conséquent réduit les possibilités d’innovation et d’optimisation.
Enfin la méthode SCRUM s’adapte difficilement aux outils de gestions de tâches (JIRA, TFS,…) qui imposent des interprétations très bureaucratiques de Scrum. Ce qui induit une perte de temps pour les développeurs. Vis-à-vis des développeurs, le fait de splitter les tâches en petits éléments qui peuvent théoriquement être complétés par n’importe qui dans l’équipe réduit le sentiment de fierté et d’appropriation de la réalisation des tâches. Tous ces points faibles de la méthode ont poussé Adam Ard, un professionnel de la programmation, à affirmer que Scrum est une mauvaise méthode pour la gestion de projet agile.
Source : Billet de blog
Et vous ?
Voir aussi
-
transgohanExpert éminentMoi je dirai plutôt que cette méthode a ses défauts comme toute autre méthode.
S'il existe plusieurs méthodes c'est justement parce qu'aucune n'est parfaite.
Chaque méthode va s'appliquer plus facilement à un contexte et à un projet particulier. Voir à une équipe.
Donc génériquement je répondrai que non, elle n'est pas une mauvaise méthode de gestion de projet, car tout dépend du projet.
Elle apporte des avantages par rapport à d'autres méthodes, mais effectivement aussi des inconvénients.le 22/04/2018 à 19:33 -
MimozaMembre avertiL'avis de ce «professionnel» est tout personnel. Il a peu être eu une mauvaise expérience avec cette méthode mais la plus part (voir tous) les inconvénients qu'il décrit relève d'expériences très personnelles et qui AMHA l'ont été avec une mauvaise pratique de Scrum. On peut trouver des centaines/milliers d'autre «professionnel» qui diront exactement l'inverse.
Bref un avis parmi tant d'autre, a ne surtout pas prendre comme parole de vérité.le 22/04/2018 à 21:10 -
SaverokExpert éminentJe n'ai jamais rencontré aucun méthode parfaite que je puisse appliquer à la lettre du début à la fin d'un projet.
Comme dit par d'autre, chaque projet est différent de même pour les équipes métiers, le client, l'équipe de dev ainsi que du CP.
Ce qui compte avant tout, c'est que le CP soit à l'aise avec la méthode qu'il décide d'appliquer car c'est lui qui en sera le garant et animera l'ensemble des intervenant autour de cette méthode.
Personnellement, je pioche un peu dans toutes les méthodes et j'en garde ce qui m'intéresse.
Mieux encore, j'applique certaines choses à certains stades du projet et pas à d'autres et de même d'un projet à l'autre.
Bref, je m'adapte à la situation.
Concernant SCRUM spécifiquement, je lui trouve pas mal de qualité mais un défaut majeur : l'équipe doit être constituée principalement voir exclusivement de développeurs et concepteurs confirmés.
C'est trop complexe pour des juniors.
Avoir en tête que chaque fonctionnalité peut être constamment remise en question implique de développer un code particulièrement générique / adaptatif pour limiter au maximum les impact.
Ce type de gymnastique n'est pas aisé pour des débutants.
Et je ne sais pas pour vous, mais je n'ai pas eu ce luxe très souvent sur les projets auxquels j'ai participé...le 23/04/2018 à 11:32 -
jyves69Membre à l'essaiLes méthodes de gestion de projet, pour moi, c'est comme les couverts :
On doit utiliser celui qui est le plus adapté ! (sinon, on sait ce que ça donne de ne pas en utiliser....)
Critiquer une fourchette parce que c'est une fourchette n'a aucun sens.
Maintenant, connaître plusieurs méthodes permet de choisir la meilleure, adaptée à l'équipe, au client, au projet, au contexte... Car si on n'a qu'un marteau, on voit tous ses problèmes en forme de clou !
captainedidou => Pourquoi l'agilité n'est pas utilisé en dehors de l'IT ? =>FAUX, j'ai mis en place avec succès l'agilité dans plusieurs autre domaines (Electronique, Marketing, ...). A votre disposition pour vous apporter tous complément.
Le fait est, qu'aujourd'hui, l'IT est de domaine qui utilise le plus de méthodes. Tant mieux ! A vous de jouer pour utiliser la meilleur méthode.le 23/04/2018 à 18:16 -
MadmacMembre extrêmement actifLa méthode est presque secondaire. Parce que les principales causes de délai et dépassement de coût sont:
- Les changements du cahier de charge, en cour de projet.
- Les deuxièmes cause est le cas où l'entreprise a sous-estimé le niveau de difficulté du projet.
- Enfin des projets qui sont tenté avec des technologies ou des versions qui ne sont pas mature.
En général, si on part le projet en partant des bases de données ont peut établir si le projet est réalisable, selon les critère du cahier de charge, très tôt.le 22/04/2018 à 20:35 -
captaindidouInactifJe n'ai jamais entendu autant de critiques à propos d'une méthode de développement que sur les méthodes agiles. Et cela ne date pas d'hier. Chaque année sur ce site, par exemple, des voix s'élèvent.
Pourquoi donc si elles sont si efficaces, elles ne sont pas reprises dans tous les secteurs de l'ingénierie ? Pourquoi seule l'informatique l'a adoptée ?
Je trouve aussi étrange les commentaires qui consistent à se borner à dire : "S'il critique la méthode, c'est parce qu'elle a été mal appliquée." Combien de fois, on l'a entendu. Faute de preuve, ce sont des propos gratuits. En tous cas qui n'ont pas beaucoup de valeur.le 23/04/2018 à 11:31 -
JCD_31Membre avertiC'est bien là le problème. C'est qu'on a pas forcément le choix. La plupart du temps, les méthodes et technologies sont imposées par des gens qui n'y comprennent rien...le 24/04/2018 à 8:48
-
el_slapperExpert éminent séniorDe mon expérience, en info de gestion, on doit frôler les 10% : évolutions réglementaires et migrations techniques clairement identifiées. J'en ai fait. Rien de tel qu'un bon GANTT qui détaille tout ce qu'il y a à faire, dans ce cas-là, avant de mettre les mains dans le cambouis.
Mais dans les +90% de projets restants.....le 14/05/2018 à 10:38 -
el_slapperExpert éminent séniorà commencer par l'auteur de l'article. Je ne suis pas un fan de SCRUM(euphémisme), mais certaines circonstances peuvent en faire une méthode efficace. Le gars, il a essayé dans un contexte précis, ça s'est planté pour des raisons pas forcément claires, et il en déduit que c'est toujours de la merde. C'est comme si un entraineur de football disait que le 4-4-2 c'est de la merde parce-que le Brésil en 98 a perdu 3-0 contre la France en jouant en 4-4-2.
Donc, j'insiste, l'auteur de l'article n'y connait rien. On ne détermine pas la valeur d'une méthode largement utilisée par des expériences purement personnelles, ou par de beaux raisonnements. On le fait en faisant des statistiques, ce qui manque cruellement à l'article. Je suis à peu près sur que les projets SCRUM se plantent aussi souvent(mais pas plus souvent) que les autres, mais j'adorerais avoir des chiffres pour confirmer - ou infirmer - mon intuition.le 24/04/2018 à 13:44 -
Ryu2000Membre extrêmement actifC'est un truc qu'on retrouve dans tous les topics de ce genre, en même temps c'est précisé dans le titre :
C'est juste l'avis d'un type random qui a écrit un message sur son blog...
Il ne faut pas y accorder trop d'importance, ce n'est que son point de vue personnel, ce n'est pas la vérité absolue.
Il y a des points qu'il n'aime pas dans SCRUM et il en fait part.le 24/04/2018 à 15:21