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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Méthodes Discussion :

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


Sujet :

Méthodes

  1. #41
    Membre à l'essai
    Homme Profil pro
    indépendant
    Inscrit en
    mai 2016
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : indépendant

    Informations forums :
    Inscription : mai 2016
    Messages : 11
    Points : 17
    Points
    17
    Par défaut
    [QUOTE=Saverok;10226080]Oui et non.
    Il y a des méthodes qui sont nulles quelque soit le contexte.

    Vrai !
    Et côté équipe, j'ai dit ...d'une équipe de réalisation bien formatée...
    Et ce que vous dites est encore vrai sauf qu'il faut limiter / éliminer les collaborateurs qui préfère " se rassurer plutôt que s'adapter "
    dès le début des Sprints.

  2. #42
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 459
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 8 459
    Points : 15 179
    Points
    15 179
    Par défaut
    Citation Envoyé par ZenZiTone Voir le message
    pas en janvier sur quoi on va travailler en mars.
    C'est pas forcément le cas, parfois il y a une collection de tâches et tu sais qu'un jour tu devras les réaliser, donc t'as des mois et des mois de travail en attente.
    Au moins SCRUM est beaucoup plus motivant que le Cycle en V, parce que t'atteints souvent tes objectifs.
    Alors que le Cycle en V c'est trop gros, du coup les développeurs se font chier, et il y a des gros rushs avant les livraisons.

    En gros c'est un peu comme celui qui fait une petite vaisselle à chaque fois qu'il cuisine ou mange (SCRUM) et celui qui attend une semaine pour faire toute la vaisselle d'un coup (Cycle en V).
    Je trouve que c'est cool d'avoir des objectifs proches.

    Citation Envoyé par ZenZiTone Voir le message
    C'est d'ailleurs pour ça que les méthodes "agiles" sont sensé évoluer pour s'adapter aux équipes et aux projets.
    Toutes les méthodes de gestion de projet doivent s'adapter, ça n'a pas de sens d'appliquer la marche à suivre à la lettre.
    Il faut bricoler un peu.
    Essayer d'utiliser ça ^^ :
    Extreme programming

    Le cycle en V c'est très bien si tu veux construire un immeuble en 1980, mais peut être pas aussi bien pour développer un logiciel en 2018.
    Au final les chefs de projet font du Cycle en V un peu agile.
    Parce que le Cycle en V strict c'est l'enfer.
    Tu dois avoir fais tellement de choses avant de pouvoir écrire la moindre ligne de code...

    Je préfère la logique "On se dépêche de développer une fonction principale pour la montrer au client, ensuite on pourra étoffer autour, à chaque réunion le client pourra nous préciser l'évolution de son besoin".
    Keith Flint 1969 - 2019

  3. #43
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    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 : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par orfraie Voir le message
    il faut limiter / éliminer les collaborateurs qui préfère " se rassurer plutôt que s'adapter "
    dès le début des Sprints.
    Le hic est que tu ne choisis pas forcément ton équipe dans son ensemble.
    Tu composes avec les personnes que tu as de dispo.
    Et c'est dans ces moments là que le rôle de manager du CP prend tout son sens en accordant une attention particulière à ces collaborateurs qui ont besoin d'éléments de réassurance.

  4. #44
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 239
    Points : 5 198
    Points
    5 198
    Par défaut
    @Ryu2000 : Là où je travaille aussi, le cycle en V serait une mauvaise idée, mais il ne faut pas généraliser si vite. Pense aux systèmes embarqués critiques comme dans l'automobile et l'aérospatial. On ne va pas déployer sur le terrain des avions agiles au fur et à mesure que la conception avance. « Oups, désolé pour le crash de l'avion : il y a eu une petite régression lors de la dernière release. »

  5. #45
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    octobre 2013
    Messages
    1 563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Industrie

    Informations forums :
    Inscription : octobre 2013
    Messages : 1 563
    Points : 3 400
    Points
    3 400
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Pense aux systèmes embarqués critiques comme dans l'automobile et l'aérospatial. On ne va pas déployer sur le terrain des avions agiles au fur et à mesure que la conception avance.
    Ceci est, pour moi, une mauvaise interprétation de l'implémentation de la méthode SCRUM. Quand on parle de "livraison", on ne parle pas forcément de mise en production. Il peut seulement s'agir d'une mise à disposition d'un élément fonctionnel de la future solution.

  6. #46
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 459
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 8 459
    Points : 15 179
    Points
    15 179
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    @Ryu2000 : Là où je travaille aussi, le cycle en V serait une mauvaise idée, mais il ne faut pas généraliser si vite. Pense aux systèmes embarqués critiques comme dans l'automobile et l'aérospatial. On ne va pas déployer sur le terrain des avions agiles au fur et à mesure que la conception avance. « Oups, désolé pour le crash de l'avion : il y a eu une petite régression lors de la dernière release. »
    Ouais enfin bon normalement il y a des tests de non régression...
    Si c'est un système sensible il faut que ce soit extremement testé.
    Sinon ça peut finir comme ça :
    Pourquoi Ariane 5 avait-elle explosé en plein vol ?
    Mais voilà, Ariane 5 était plus véloce : son accélération pouvait atteindre la valeur 300 (qui vaut 100101100 en binaire et nécessite 9 bits). Ainsi, la variable codée sur 8 bits a connu un dépassement de capacité puisque son emplacement mémoire n'était pas assez grand pour accepter une valeur aussi grande, il aurait fallu la coder sur un bit de plus, à savoir 9, ce qui nous aurait fait 2^9=512 comme valeur limite, alors suffisant pour coder la valeur 300.
    Bon à la limite pour une fusée je veux bien que le cycle en V peut être adapté, vu qu'on peut tout bloquer des années avant.
    Mais la majorité des projets sont beaucoup moins sensible et peuvent évoluer.
    Le Cycle en V dans une entreprise ça ferait que t'arrives à la livraison après 3 ans de développement et on te dit "ça fait 2 ans qu'on a plus du tout besoin de ça".
    Les besoins évoluent généralement.

    De toute façon quasiment personne ne fait du Cycle en V strict, la gestion de projet c'est un peu plus du bricolage, il y a des libertés quand même.
    Parce que le cycle en V c'est lourd, si tu découvres un problème il faut repartir de loin.
    Si les tests unitaires sont mauvais il faut refaire la conception détaillée et le codage.
    Si les tests d'intégration sont mauvais il faut refaire la conception architecturale, la conception détaillée et le codage.
    Si les tests de validation sont mauvais il faut refaire les spécifications, la conception architecturale, la conception détaillée et le codage.
    Si la recette est mauvaise il faut refaire l'analyse des besoins, les spécifications, la conception architecturale, la conception détaillée et le codage.

    Le Cycle en V c'est bien quand les besoins sont bien exprimés, bien compris et ne changent jamais.
    Ça ne représente pas la majorité des projets

    Après SCRUM c'est pas la solution miracle non plus...
    Mais je trouve que mettre un peu d'agilité dans la gestion de projet ça fait généralement pas de mal...
    Personnellement je vois plus d'avantage dans l'agile que dans l'ultra rigide comme le Cycle en V.
    Keith Flint 1969 - 2019

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 664
    Points : 30 892
    Points
    30 892
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    (.../...)
    Le Cycle en V c'est bien quand les besoins sont bien exprimés, bien compris et ne changent jamais.
    Ça ne représente pas la majorité des projets (.../...)
    De 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.....
    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.

  8. #48
    Candidat au Club
    Homme Profil pro
    Conseil en assistance à maîtrise d'ouvrage
    Inscrit en
    juin 2018
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Conseil en assistance à maîtrise d'ouvrage
    Secteur : Transports

    Informations forums :
    Inscription : juin 2018
    Messages : 1
    Points : 3
    Points
    3
    Par défaut
    D'une façon globale, mon ressenti est que Agile / Scrum est une bonne méthode sur des projets de petit ou périmètre moyen et surtout partant d'une feuille blanche :
    Ce sera parfait pour monter un site web e-commerce ou un nouvel IHM, par exemple.

    Ce sera nettement plus compliqué pour monter un SI d'entreprise où les décisions d'architecture technique et fonctionnelle prises dès le départ vont fortement impacter les possibilités à terme.
    Même chose sur une refonte (totale ou partielle) de SI, pour laquelle il faudra préalablement faire une revue de règles fonctionnelles, éventuellement faire évoluer celles-ci et s'intégrer dans un environnement technique et fonctionnel contraignant impliquant une phase d'étude en amont non négligeable, peu compatible avec une méthode par itération.

    Agile / Scrum, c'est souvent vu sous l'angle "on a le droit de se tromper" voire parfois "Je sais pas trop ce que je veux, on va voir ce que les techos vont me proposer" => c'est trop souvent le paravant des fonctionnels qui ne font pas leur boulot

  9. #49
    Membre à l'essai
    Homme Profil pro
    Coach Agile
    Inscrit en
    avril 2018
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    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 : 3
    Points : 10
    Points
    10
    Par défaut Scrum?
    L'Agilité à tout prix => NON !
    On doit faire de l'Agile (Scrum, Kanban, etc.) quand il y a des zones de flou.
    Si on sait exactement ce qu'il faut faire, que la techno est sèche, qu'il n'y a aucune interprétation, => Pas besoin de faire en Agile.
    Faire en Agile coûte plus cher ! (Et oui, les rétro, Daily, ...ça coûte...)
    Et l'Agilité n'est "rentable" que si ce que l'on est en train de construire a des zones de flou. L’agilité permettra de s'adapter.

    Pour répondre à la problématique de grands projets, grandes équipes... il faut aller chercher des framework à l'échelle : SAFe, LeSS, ... car Scrum n'est pas fait pour une équipe de plus de 9 personnes.

    C'est bien parce qu’on veut faire de l'Agile à tout prix, que l'on va payer au prix fort le "l'agilité, ça marche pas".

Discussions similaires

  1. Réponses: 4
    Dernier message: 19/05/2016, 00h32
  2. la classe Action est-elle une classe abstraite?
    Par mrjeronimo dans le forum Struts 1
    Réponses: 2
    Dernier message: 21/05/2008, 12h29
  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, 13h02
  4. hp est-elle une bonne marque
    Par babafredo dans le forum Ordinateurs
    Réponses: 4
    Dernier message: 07/03/2008, 15h29
  5. Acer est-elle une bonne marque?
    Par SirTurbo dans le forum Ordinateurs
    Réponses: 6
    Dernier message: 30/12/2007, 18h49

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