+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 3 123 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2013
    Messages
    320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2013
    Messages : 320
    Points : 8 744
    Points
    8 744
    Billets dans le blog
    1

    Par défaut La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui

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

    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.

    Nom : Screen Shot 2018-04-22 at 19.07.08.png
Affichages : 13133
Taille : 126,0 Ko

    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 ?

    Pensez-vous que Scrum est une mauvaise méthode pour la gestion de projet agile ? Pourquoi ?

    Voir aussi

    Le département américain de la défense adopte agile et la méthode Scrum sous les conseils de Jeff Sutherland inventeur de Scrum

    Project Open 4.0 disponible. La solution open source de gestion de projets s’intègre mieux avec SharePoint et introduit le support de Scrum

  2. #2
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 500
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 500
    Points : 7 014
    Points
    7 014

    Par défaut

    Moi 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.
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  3. #3
    Membre éclairé Avatar de Madmac
    Homme Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    juin 2004
    Messages
    593
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 593
    Points : 802
    Points
    802

    Par défaut

    La 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.
    intel i7
    OpenSuse Leap 42.2
    Plasma et Cinnamon

  4. #4
    Membre actif
    Profil pro
    Inscrit en
    juin 2006
    Messages
    116
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 116
    Points : 275
    Points
    275

    Par défaut Avis vraiment très personnel …

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

  5. #5
    Candidat au Club
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    novembre 2017
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : novembre 2017
    Messages : 3
    Points : 3
    Points
    3

    Par défaut

    "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"
    Oooooh, pauvres choux...
    Nan mais sérieux, ce "sentiment de fierté" devrait venir UNIQUEMENT de la propreté du code realisé. L'"appropriation" d'une tâche signifie presque toujours un code dégueu et abscons compréhensible uniquement par son géniteur

  6. #6
    Candidat au Club
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    novembre 2017
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : novembre 2017
    Messages : 3
    Points : 3
    Points
    3

    Par défaut

    Citation Envoyé par Mimoza Voir le message
    L'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é.
    Ouais, tout pareil d'accord.

  7. #7
    Membre habitué
    Profil pro
    Inscrit en
    mars 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 85
    Points : 129
    Points
    129

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Moi 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.
    Entièrement d'accord. Cela dépend du contexte.

    Cela fait 8 ans que je fais de l'agile. Les 6 première années, j'ai fonctionné en SCRUM et cela convenait parfaitement. Depuis 2 ans, je suis sur un projet aussi SCRUM mais dont la méthode ne fonctionne pas, où je tombe dans certains des travers cités par l'auteur. Du KANBAN aurait été mieux approprié, par exemple.
    Ce n'est pas une généralité.
    Je noterais aussi un très gros point à soulever qui fait que la méthode fonctionne ou non : la motivation et les objectifs des parties prenantes.

  8. #8
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    265
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 265
    Points : 525
    Points
    525

    Par défaut

    Hum, ce professionnel ne me semble pas très compétent dans le domaine de l'Agilité, pour donner ce genre d'opinion ...
    La principale réponse à ses remarques est la compétence du chef de projet / Scrum Master et de son équipe.

    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.
    Comme dans toute méthode, en fait. On ne fait pas de développement pour le plaisir, mais parce qu'il y a un besoin ; pourquoi ? Parce qu'un dev, ça a un coût. Donc tant qu'il y a un besoin et du budget, on fait le dev. C'est au métier de définir son besoin, et un bon chef de projet doit être capable de le challenger dessus.

    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.
    Même chose, cela se produit quelque soit la méthode. L'avantage de l'Agile, c'est que ça apparaît plus vite, justement parce que la tâche s'étale sur plusieurs sprints. C'est aussi un gros point fort, via la vélocité : si on déborde, que l'on a mal chiffré, ça va faire chuter la vélocité, représentant les événements imprévus et, grâce aux points de complexité, ce risque sera pris en compte lors des futurs chiffrages.

    La méthodologie Scrum est étiquetée comme « carrée ». En effet, elle ne supporte pas des modifications dans son principe.
    Dans "chef de projet", il y a "chef", et dans "Scrum Master", il y a "Master". Coco, c'est à toi de t'imposer et de changer ce qui ne te convient pas. Voir ma remarque du début.

    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.
    C'est quoi le rapport avec la choucroute ? Il faudra que je lise l'article original, la traduction est peut être ambigüe.

    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.
    Heu ... non, ce sont des outils paramétrables avec des templates de base. Encore un problème de compétence, pas de méthode.

    Quand à l’orgueil des devs ... qu'ils grandissent un peu (et je précise que j'en suis un) !

  9. #9
    Membre confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    190
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 190
    Points : 579
    Points
    579

    Par défaut

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

  10. #10
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 1 986
    Points : 7 142
    Points
    7 142

    Par défaut

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

  11. #11
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    265
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 265
    Points : 525
    Points
    525

    Par défaut

    Citation Envoyé par captaindidou Voir le message
    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 ?
    Très bonne remarque ; précisément parce que les méthodes agiles ont été conçues pour l'informatique, et rien d'autre. A l'origine, le cycle en V vient des secteurs d'ingénierie "traditionnels" (BTP, génie civil), et l'agile est une tentative de combler les manques de ces méthodes aux spécificités de l'informatique.

    Citation Envoyé par captaindidou Voir le message
    Je trouve aussi étrange les commentaires qui consistent à se borner à dire : "S'il critique la méthode, c'est parce que ça l'a été mal appliqué." 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.
    L'inverse est aussi vrai : a-t-il des preuves que les méthodes agiles sont mauvaises ?

    Traînant ma bosse dans le développement depuis pas mal de temps, j'ai vu des projets réussir et échouer avec les méthodes traditionnelles comme agile ; c'est pour cela que je pense que le première cause, c'est la compétence, pas la méthode.
    Je ne suis pas un grand fan de Scrum (je lui préfère XP, que j'ai même tendance à adapter), mais je n'ai jamais vu non plus de bon argumentaire de ceux disant que c'est une mauvaise méthode. La vérité se trouve entre les deux, et l'agile étant par définition non rigide, il faut savoir l'adapter au besoin.

    Citation Envoyé par Saverok
    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.
    C'est pour cela que l'on préconise le pair-programming, l'idéal étant au moins un confirmé. Malheureusement, aujourd'hui on lui préfère les code review, ce qui est au final beaucoup moins productif, malgré les apparences.

  12. #12
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    3 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 3 344
    Points : 5 376
    Points
    5 376

    Par défaut

    Citation Envoyé par Victor Vincent Voir le message
    Pensez-vous que Scrum est une mauvaise méthode pour la gestion de projet agile ? Pourquoi ?
    En tout cas c'est mieux que le cycle en V

    Si on applique la méthodologie à la lettre, ok c'est peut être pas top.
    Mais si on est moins strict on peut faire quelque chose de géniale avec SCRUM.

    Il y a beaucoup de retour du client, on comprend bien son besoin, il y a des objectifs à court terme, c'est plus motivant qu'une gestion pas agile, la pire gestion de projet ce serait "Tiens voilà le cahier des charges, je reviens dans 2 ans chercher le produit fini" et le client se rend compte qu'il a demandé des choses qu'il ne veut pas et qu'il a oublié des choses dont il a besoin, et de toute façon le besoin a changé en 2 ans.

    L'important c'est d'être un peu agile dans sa gestion de projet, après on est pas obligé d'être ultra strict dans l'application de la méthode.

    Essayez de respecter ça à fond :
    Extreme programming
    "Alors il entrait le type et il disait une baguette pas trop cuite" Émile.
    «You may be black, you may be white, you may be Jew or Gentile. It don't make a difference in our house. And this is fresh!»

  13. #13
    Membre habitué
    Profil pro
    Inscrit en
    mars 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 85
    Points : 129
    Points
    129

    Par défaut

    Citation Envoyé par Saverok Voir le message
    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é...
    C'est aussi quelque chose que j'ai remarqué. La présence de confirmés dans une équipe SCRUM fait que la méthode fonctionne mieux, contrairement à KANBAN, par exemple.
    Il y a aussi en amont de la réalisation : SCRUM nécessite que chaque tache soit estimée pour pouvoir faire la vélocité de sprint. Je peux vois assurer qu'un Sprint Planning avec des juniors ne sachant pas estimer engendre des débats sans fin. Je ne compte plus le nombre de fois où j'ai lâché l'affaire là dessus pour que ça aille plus vite...

    Citation Envoyé par Bono_BX
    Très bonne remarque ; précisément parce que les méthodes agiles ont été conçues pour l'informatique, et rien d'autre. A l'origine, le cycle en V vient des secteurs d'ingénierie "traditionnels" (BTP, génie civil), et l'agile est une tentative de combler les manques de ces méthodes aux spécificités de l'informatique.
    ça marche aussi dans d'autres domaines mais pas officiellement. J'ai testé les principes des méthodes agiles dans le domaine de l'artisanat et ça a plutôt bien fonctionné

  14. #14
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 553
    Points : 3 731
    Points
    3 731

    Par défaut

    Citation Envoyé par Bono_BX Voir le message
    Très bonne remarque ; précisément parce que les méthodes agiles ont été conçues pour l'informatique, et rien d'autre. A l'origine, le cycle en V vient des secteurs d'ingénierie "traditionnels" (BTP, génie civil), et l'agile est une tentative de combler les manques de ces méthodes aux spécificités de l'informatique.
    C'est pas vraiment vrai. Peut etre le terme "agile" est directement associé à l'informatique, mais la philosophie derrière existe dans d'autre domaine et depuis des dizaines d'années. Un exemple parfait est l'utilisation du Kanban. Mais ca va etre dur d'évangiliser en présentant un "vieux" truc de 70 ans comme une méthode révolutionnaire .

  15. #15
    Futur Membre du Club
    Homme Profil pro
    Coach Agile
    Inscrit en
    avril 2018
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Coach Agile
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : avril 2018
    Messages : 1
    Points : 7
    Points
    7

    Par défaut Couteau ou fourchette ?

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

  16. #16
    Membre habitué
    Profil pro
    Inscrit en
    mars 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 85
    Points : 129
    Points
    129

    Par défaut

    Citation Envoyé par jyves69 Voir le message
    Les 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 ....)
    C'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...

  17. #17
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 011
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 011
    Points : 21 734
    Points
    21 734

    Par défaut

    Citation Envoyé par JCD_31 Voir le message
    C'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...
    à 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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  18. #18
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    3 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 3 344
    Points : 5 376
    Points
    5 376

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    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.
    C'est un truc qu'on retrouve dans tous les topics de ce genre, en même temps c'est précisé dans le titre :
    Citation Envoyé par Victor Vincent Voir le message
    La méthode agile SCRUM est-elle une mauvaise méthode de gestion de projet ? Oui, répond un professionnel du secteur
    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.
    "Alors il entrait le type et il disait une baguette pas trop cuite" Émile.
    «You may be black, you may be white, you may be Jew or Gentile. It don't make a difference in our house. And this is fresh!»

  19. #19
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 553
    Points : 3 731
    Points
    3 731

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    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.
    C'est surement vrai, on pourait meme se poser la question de l'utilité d'une méthodologie. N'est-ce pas juste un moyen d'avoir une cohérence dans une équipe, cohérence qui impacte forcément sur le bon déroulement du projet?

  20. #20
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 1 986
    Points : 7 142
    Points
    7 142

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    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.
    De part mon expérience personnelle, les risques d'échec avec les méthodes Agile (SCRUM ou autres) sont plus importants qu'avec les méthodes classiques du genre cycle en V.
    Pour commencer, je précise que pour moi, les critères de réussite d'un projet tiennent en 3 points : satisfaction des utilisateurs (et non des donneurs d'ordres), le planning et le budget (dans cet ordre de priorité).
    Si l'un des 3 points n'est pas au moins partiellement atteint, je considère, à titre personnel, que le projet est un échec.

    Avec les méthodes Agile, on définit les spécificités détaillées au fur et à mesure du développement.
    On ne démarre qu'avec une trame générale que l'on spécifie à chaque itération.
    Cela implique de bien définir le contenu des sprints et d'avoir un product owner qui maîtrise parfaitement son sujet et déjà là, ce n'est pas gagné.
    Idem côté développeurs / concepteurs, ils doivent avoir en permanence en tête que les fonctionnalités qu'ils développent peuvent être remises en cause à tout moment et ils doivent veiller à mettre en oeuvre le code le plus générique possible pour éviter de devoir tout réécrire à chaque fois et là encore, ce n'est pas si simple.
    Lorsque l'on combine ces 2 points, on constate bien que les risques de dérives sont nombreux et qu'on peut se retrouver à la fin du nombre de sprint définit en ayant consommé 100% du budget avec une application inutilisable car avec les fonctions principales non totalement développées car le poduct owner aura passé trop de temps à peaufiner une fonction en délaissant les autres ou encore que les temps de dev s'allongent au fil des sprints car le code mis en place lors des premières itérations étaient trop spécialisés...
    Le scrum master doit alors être particulièrement vigilant à garder toujours le cap et ce n'est pas évident car cela implique de cadrer le product owner qui est, le plus souvent, le client et ce dernier refuse / accepte mal, le plus souvent, qu'un prestataire lui donne des directives / le rappel à l'ordre / lui fixe des objectifs / ...

Discussions similaires

  1. Réponses: 4
    Dernier message: 18/05/2016, 23h32
  2. la classe Action est-elle une classe abstraite?
    Par mrjeronimo dans le forum Struts 1
    Réponses: 2
    Dernier message: 21/05/2008, 11h29
  3. ismissing est'elle une commande JS ?
    Par bruno.rotrou dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 06/04/2008, 12h02
  4. hp est-elle une bonne marque
    Par babafredo dans le forum Ordinateurs
    Réponses: 4
    Dernier message: 07/03/2008, 14h29
  5. Acer est-elle une bonne marque?
    Par SirTurbo dans le forum Ordinateurs
    Réponses: 6
    Dernier message: 30/12/2007, 17h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo