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. #21
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 585
    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 585
    Points : 15 563
    Points
    15 563
    Par défaut
    Citation Envoyé par Saverok Voir le message
    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.
    Je ne suis pas d'accord.
    Si on applique le cycle en V strict (je fais la conception à 100% avant d'écrire la moindre ligne de code), qu'on a les informations au début et après plus rien, il y a trop moyen de se planter.
    Je l'ai déjà dis, mais le client a mal exprimé ses besoins (il n'a pas demandé se dont il avait besoin, il a demandé des choses qu'il n'a pas besoin) et de toutes façons ses besoins ont changé pendant le développement.

    Le côté cool de Scrum c'est que régulièrement le client voit l'avancement du projet et peut donner des indications vers où se diriger.
    On commence par les fonctions principal, c'est la première chose qu'on doit montrer au client.
    Vous pouvez proposer des choses au client qui lui seront utile, mais auquel il n'avait pas pensé.

    Quelque part les méthodes agiles c'est un peu un tas de cycle en V itératif.
    Si on veut on peut faire un cycle en V par fonction, en quelque sorte...
    Keith Flint 1969 - 2019

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 973
    Points
    30 973
    Par défaut
    Merci à Saverok et Ryu d'appuyer mon point, chacun défendant sa paroisse à coup d'anecdotes. J'aurais tendance à penser comme Ryu, mais la réalité, c'est que tant qu'on a pas fait de mesures sérieuses et massives, on pisse tous dans des violons autant qu'on est.
    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.

  3. #23
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 585
    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 585
    Points : 15 563
    Points
    15 563
    Par défaut
    Non mais le cycle en V strict c'est de définir un truc au début et de s'y tenir jusqu'à la fin.
    Tu livres exactement ce que t'as dis que t'allais livrer... Donc c'est n'importe quoi !

    Vous imaginez comme c'est compliqué d’exprimer son besoin ?
    Il faut que le client soit fort pour savoir ce dont il aura besoin dans le futur.
    Et les avancées technologique ne seront pas prisent en compte.

    Je pense que le mieux c'est de la faire de la gestion de projet battarde, il faut des objectifs à court terme et des objectifs à moyen terme.
    Cycle en V strict et SCRUM strict c'est de la merde pour un projet informatique.
    Il faut faire de l'agile mais ne pas respecter le moindre détail de la méthode, il faut avoir un peu de liberté.
    Après je m'en fous je ne suis pas chef de projet.

    Le cycle en V c'est tip top pour construire un bâtiment en 1980
    Keith Flint 1969 - 2019

  4. #24
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2015
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Tarn (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2015
    Messages : 75
    Points : 190
    Points
    190
    Par défaut
    Il n'y a pas de bonne ou de mauvaises méthodes pour mener un projet à sa fin. Il y a des méthodes qui sont adaptées ou non pour chaque projet et pour chaque équipe. La méthode agile (ou n'importe quelle autre) peut fonctionner très bien sur le projet A avec l'équipe alpha et mener au désastre sur le même projet A avec l'équipe gamma.
    Le CP doit connaitre son équipe, ses qualités et surtout ses défauts, et trouver la bonne méthode à utiliser selon le projet.

  5. #25
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 585
    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 585
    Points : 15 563
    Points
    15 563
    Par défaut
    Citation Envoyé par pascal-od Voir le message
    La méthode agile (ou n'importe quelle autre) peut fonctionner très bien sur le projet A avec l'équipe alpha et mener au désastre sur le même projet A avec l'équipe gamma.
    Ouais mais au moins avec les méthodes un peu agile tu peux rectifier le tir si t'as loupé la première étape de conception...
    Si t'as un mauvais cahier des charges et que tu bases tout la dessus, ton logiciel ne va pas être terrible.
    Il faut au moins présenter régulièrement les avancées du projet au client pour qu'il puisse dire "En fait j'ai pas besoin de la fonction A, mais j'ai besoin d'une fonction B".
    Keith Flint 1969 - 2019

  6. #26
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2015
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Tarn (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2015
    Messages : 75
    Points : 190
    Points
    190
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    Ouais mais au moins avec les méthodes un peu agile tu peux rectifier le tir si t'as loupé la première étape de conception...
    Si t'as un mauvais cahier des charges et que tu bases tout la dessus, ton logiciel ne va pas être terrible.
    Il faut au moins présenter régulièrement les avancées du projet au client pour qu'il puisse dire "En fait j'ai pas besoin de la fonction A, mais j'ai besoin d'une fonction B".
    Si la conception du projet est mal faite il faut revoir la conception. Si le cahier des charges est mauvais c'est le cahier des charges qu'il faut revoir. Rassures-moi, on parle bien de réaliser un projet dans un cadre professionnel ?

  7. #27
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 585
    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 585
    Points : 15 563
    Points
    15 563
    Par défaut
    Citation Envoyé par pascal-od Voir le message
    Rassures-moi, on parle bien de réaliser un projet dans un cadre professionnel ?
    Les besoins sont parfois mal exprimés par le client, les besoins sont parfois mal compris par les développeurs.
    Il peut donc arriver qu'il y ait des erreurs dans le cahier des charges.

    En montrant le projet au client, il peut se rendre compte qu'il a demandé des choses dont ils n'a pas besoin et qu'il a oublié des choses dont il a besoin.
    De toute façon le besoin du client évolue pendant le développement.
    Des nouvelles idées apparaissent pendant le développement.

    Avec les méthodes agile le premier truc que tu montres au client c'est la fonction principale, donc c'est facile de bien orienter le projet.
    Keith Flint 1969 - 2019

  8. #28
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2015
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Tarn (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2015
    Messages : 75
    Points : 190
    Points
    190
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    Les besoins sont parfois mal exprimés par le client, les besoins sont parfois mal compris par les développeurs.
    Il peut donc arriver qu'il y ait des erreurs dans le cahier des charges.

    En montrant le projet au client, il peut se rendre compte qu'il a demandé des choses dont ils n'a pas besoin et qu'il a oublié des choses dont il a besoin.
    De toute façon le besoin du client évolue pendant le développement.
    Des nouvelles idées apparaissent pendant le développement.

    Avec les méthodes agile le premier truc que tu montres au client c'est la fonction principale, donc c'est facile de bien orienter le projet.
    Oui, oui je comprends très bien ce que tu veux dire.
    Mais choisir une méthode en particulier parce que ça permet de corriger les erreurs ou omissions faites en amont signifie pour moi que le problème se situe ailleurs.
    Le client n'a pas à savoir exprimer ses besoins, ce n'est pas son métier. C'est le prestataire à qui il fait appel qui doit être capable de l'amener à exprimer correctement ses besoins. Ensuite ce prestataire doit être capable d'expliquer le cahier des charges au client et s'assurer qu'il est bien en adéquation avec sa demande et ses besoins. C'est un travail préalable essentiel, pour lequel il faut prendre son temps.
    Ensuite une méthode, agile ou non, n'est qu'un cadre formel dont il faut savoir s'échapper pour mener à bien un projet.

  9. #29
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 585
    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 585
    Points : 15 563
    Points
    15 563
    Par défaut
    Citation Envoyé par pascal-od Voir le message
    Ensuite une méthode, agile ou non, n'est qu'un cadre formel dont il faut savoir s'échapper pour mener à bien un projet.
    Ouais, mais ce que je dis c'est que sur un point précis les méthodes agiles sont supérieurs au cycle en V, car le client suit le projet, test le projet, fait des retours et par conséquent il n'y a pas de surprise à la fin.
    Après le cycle en V a peut être des avantages sur certains points.

    Mais dans l'ensemble c'est moins motivant, comme les objectifs sont énorme, il peut arriver que les développeurs perdent de la motivation et finissent par rusher pour que la livraison soit prête à temps.
    Alors qu'avec SCRUM tu peux faire des petits sprints de 2 semaines, ça fait des objectifs plus court et des "récompenses" plus fréquentes (t'es content t'as atteint ton objectif).

    Mais sinon c'est ce que je dis, il ne faut pas suivre les méthodes de gestion de projet à la lettre.
    Keith Flint 1969 - 2019

  10. #30
    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 pascal-od Voir le message
    Mais choisir une méthode en particulier parce que ça permet de corriger les erreurs ou omissions faites en amont signifie pour moi que le problème se situe ailleurs.
    Pourquoi partir du principe qu'il y a un problème ?
    Il arrive assez souvent que volontairement, le besoin détaillé reste flou lors de la définition générale du besoin et cela n'a rien de spécifique à l'info.

    Lorsque tu fais construire une maison par exemple, tout n'est pas détaillée à l'avance.
    Tu as le gros oeuvre évidement.
    Tu sais où va se situer les pièces d'eau et la cuisine, par exemple, mais tu ne détailles pas leur aménagement dès le début du chantier.
    Les plans détaillées de la cuisine se font même le plus souvent une fois le gros oeuvre terminée car c'est du sur mesure et lors de la réalisation du gros oeuvre, une cloison peut parfaitement bouger de quelques centimètres.
    Je ne parle même des finitions telles que la couleur des murs et les revêtements de sol qui peuvent parfaitement être décidés au dernier moment.
    etc.

    Un projet info, c'est exactement la même chose.

    Citation Envoyé par pascal-od Voir le message
    Le client n'a pas à savoir exprimer ses besoins, ce n'est pas son métier.
    Bien sûr que si.
    C'est pas à ton boulanger de décider à ta place du type de pain et de la quantité que tu vas manger.

    En tant que client, tu sais que tu as besoin de pain et pour quel usage.
    Le boulanger est là pour t'aider à affiner le choix par le conseil et en te posant des questions pertinentes pour orienter et spécifier ton besoin.
    Mais au final, le besoin est bien le tien et c'est bien toi qui y met un point final ou pas.

    Pourquoi cela serait il différent en info ?

    Citation Envoyé par pascal-od Voir le message
    C'est le prestataire à qui il fait appel qui doit être capable de l'amener à exprimer correctement ses besoins. Ensuite ce prestataire doit être capable d'expliquer le cahier des charges au client et s'assurer qu'il est bien en adéquation avec sa demande et ses besoins. C'est un travail préalable essentiel, pour lequel il faut prendre son temps.
    Juste pour info : il existe énormément de situation où la MOA est interne à l'entreprise cliente.
    Tout le monde ne fait pas de la prestation tout azimut, y compris dans l'info.

    La plupart des mini projets que je réalise sont 100% interne à ma société.
    Le service métier qui exprime son besoin à la DSI est interne.
    La MOA qui spécifie le besoin est interne.
    Je suis un CP et RA interne et une partie de mon équipe, y compris quelques dev / concepteurs et architectes, est interne.

    Citation Envoyé par pascal-od Voir le message
    Ensuite une méthode, agile ou non, n'est qu'un cadre formel dont il faut savoir s'échapper pour mener à bien un projet.
    Inutile de s’échapper. Personne n'est prisonnier de quoique ce soit.
    Ce qu'il faut c'est s'adapté et la nuance est grande.

    La méthode à adopter n'est pas uniquement à sélectionner en fonction de l'équipe MOE mais à l'ensemble des acteurs du projet et cela va des utilisateurs, à la MOA, MOE et jusqu'à l'équipe d'exploitation et de déploiement.
    C'est bien beau de vouloir faire de l'itératif mais si la MOA et les utilisateurs ne sont pas disponibles pour tester et valider la solution à chaque fin de sprint, on va dans le mur.
    etc.

  11. #31
    Futur Membre du Club
    Femme Profil pro
    Chargé d'affaire
    Inscrit en
    novembre 2010
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chargé d'affaire

    Informations forums :
    Inscription : novembre 2010
    Messages : 7
    Points : 6
    Points
    6
    Par défaut On a qu'à faire SCRUM on a dit, mais SCRUM qu'on a dit déja ?
    Dans ma boite, la méthode SCRUM a plutôt été utilisée comme couverture à notre désorganisation

    Des cycles courts pour cacher que l'on changeait tout le temps d'objectif et qu'il fallait donc sans cesse recommencer, des équipes réduites pour cacher le manque de moyen,des sprints pour cacher que l'on était incapable de planifier et de prévoir des objectifs et une stratégie, et qu'il fallait donc tout traiter dans l'urgence.

    Beaucoup d'entreprises ne font que réparer toutes les catastrophes de la journée et leur sensation de courir en rond est juste une méthode moderne très tendance.

    A chaque plantage, on sortait la phrase : « il faut être agile ! », ce qui voulait juste dire «on est mauvais mais on est dans l'air du temps...»

    Le vrai succès vient de l'écoute des équipes, de la confiance, d'une bonne équipe, d'un bon capitaine. Au bout de 5 échecs et plusieurs démissions, n'hésitez pas à remettre en question le capitaine.

    Ha oui, j'oubliai de dire, ma boite n'a rien à voir avec la programmation, si ce n'est ceux des échecs.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 973
    Points
    30 973
    Par défaut
    Citation Envoyé par cihinel Voir le message
    [B]Dans ma boite, la méthode SCRUM a plutôt été utilisée comme couverture à notre désorganisation(.../...)
    Enfin, ça, c'est vrai de toutes les modes organisationnelles. La meilleure méthode du monde, appliquée par des gnous, ne donnera aucun résultat. Tiens, parallèle avec le football. La meilleur équipe d'Europe, en ce moment, semble être le Real Madrid, qui joue généralement en 4-4-2 diamant. Tu prends 10 tocquards et tu me rajoutes dans les buts, et on va prendre pilée sur pilée. Même si on joue en 4-4-2 diamant.

    L'organisation n'est qu'un choix de squelette, si les muscles(i.e. les gens qui bossent) ne suivent pas, il n'y aura jamais de résultat.
    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.

  13. #33
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 912
    Points
    2 912
    Par défaut
    A part générer du flamewars pour le plaisir, je vois vraiment pas l'intérêt de déterrer un billet de blog ouvertement provocateur et trollesque d'il y a plus de 2 ans.

    D'autant que celui-ci est un tissu d'absurdités fallacieux de bout en bout (il se le fait d'ailleurs copieusement rappeler dans les commentaires).

    Scrum, in accounting for all the engineer’s time in a tightly managed fashion
    Ben non, Scrum ne dit absolument rien sur la mesure du temps passé et encore moins le temps passé individuellement par chaque membre de l'équipe

    Scrum encourages “least amount of work possible” solutions 
    Cette phrase ne veut strictement rien dire si on ne met pas en face ce qu'on s'attend à obtenir une fois le travail, fut-il le moindre possible, fini. Or Scrum permet de spécifier tous les critères imaginables de qualité, de performance, etc. "The least amount of work" pour un produit en or massif peut donc très bien être une masse de travail considérable si c'est ça que le client exige.

    By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work. 
    Comprends pas. Les items ont beau être faisables par tout le monde, au bout du compte, c'est bien un dev en particulier (ou un binôme) qui l'a réalisé non ? Ou est la perte de fierté du travail effectué ?

    Scrum is highly intolerant to modification
    Une méthode qu'on peut modifier en tous points est-elle encore une méthode ? Le document décrivant l'intégralité du cadre fait une quinzaine de pages en tout et pour tout, et dedans il y a des parties prescriptives mais aussi des recommandations ou des choix laissés à l'implémenteur. On ne peut pas dire que beaucoup de process soient aussi légers.

    Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads
    Mauvaise pioche. Le Team Lead n'est pas dans Scrum. Le Product Owner, c'est le client. Cela laisse... un rôle, le Scrum Master, qui n'est pas un rôle de management.

    Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on?
    Ben non mais en même temps Scrum ne demande à personne de faire ça. Les estimations recommandées c'est sur les product backlog items (pas les tâches) et c'est à grosses mailles. Pas de tracking.

    Are they required to do bi-weekly sell-off meeting to justify their activities?
    Idem, ce n'est pas dans la méthode.

    It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding.
    Cette obsession du task tracking qui encore une fois n'est pas dans la méthode

    etc. etc.

  14. #34
    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 el_slapper Voir le message
    Enfin, ça, c'est vrai de toutes les modes organisationnelles. La meilleure méthode du monde, appliquée par des gnous, ne donnera aucun résultat. Tiens, parallèle avec le football. La meilleur équipe d'Europe, en ce moment, semble être le Real Madrid, qui joue généralement en 4-4-2 diamant. Tu prends 10 tocquards et tu me rajoutes dans les buts, et on va prendre pilée sur pilée. Même si on joue en 4-4-2 diamant.

    L'organisation n'est qu'un choix de squelette, si les muscles(i.e. les gens qui bossent) ne suivent pas, il n'y aura jamais de résultat.
    Ce qui me gêne avec ta métaphore c'est qu'elle suggère que tout est entre les mains de l'équipe opérationnelle et donc responsable de la réussite ou de l'échec du projet sans tenir compte de tout l'environnement autour.

    Pour reprendre ta comparaison, un club de foot, ce n'est pas juste les joueurs.
    Il y a tout le staff du club, les dirigeants, le club de formation, les infrastructures, les clubs de supporter, etc.
    Les joueurs sur le terrain ne sont que la partie visible de l'iceberg.

    Un projet info, c'est la même chose.
    On ne peut pas tout résumer aux dev et concepteurs et c'est particulièrement vrai dans le cas des projets en méthode Agile.
    Tu auras beau avoir une équipe d'experts en dev, si la MOA ne suit pas, que le CP est une quiche et que tu les installes dans un sous sol mal éclairé avec des chaises de merde et un PC qui compile le projet en 45min dès le premier sprint, ton projet ira dans le mur (et tu peux être sûr que tes dev vont donner leur lettre de dem les uns après les autres).

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 973
    Points
    30 973
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Ce qui me gêne avec ta métaphore c'est qu'elle suggère que tout est entre les mains de l'équipe opérationnelle et donc responsable de la réussite ou de l'échec du projet sans tenir compte de tout l'environnement autour.(.../...).
    Tu as 100% raison, mais ça ne fait que renforcer ma conclusion : une bonne méthode, ça ne sauve pas une situation où d'autres éléments sont défectueux. SCRUM est souvent vendu comme la solution miracle qui va sauver tous les projets informatiques de l'univers, alors que si il y a des manques par ailleurs(au niveau de l'équipe elle-même comme je l'ai souligné, ou au niveau de toute ce qu'il y a autour comme tu le soulignes fort justement), eh bien ça ne va rien sauver du tout.
    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.

  16. #36
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 368
    Points
    19 368
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Tiens, parallèle avec le football. La meilleur équipe d'Europe, en ce moment, semble être le Real Madrid, qui joue généralement en 4-4-2 diamant. Tu prends 10 tocquards et tu me rajoutes dans les buts, et on va prendre pilée sur pilée. Même si on joue en 4-4-2 diamant.
    Tu oublies l'arbitre. Pour avoir le même rendement que le Real Madrid il te faut le 4-4-2 diamant ET l'arbitre avec toi sinon ça marche beaucoup moins bien !
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  17. #37
    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 : 18
    Points
    18
    Par défaut Méthode SCRUM , mauvaise méthode ?
    Bonjour,
    Une méthode reste une méthode , c'est son contexte d'utilisation et son périmètre d'application qui font sa pertinence.
    Dire que Scrum est une mauvaise méthode , c'est comme dire que le WaterFall est une mauvaise méthode.
    Ca n'a pas de sens sans examen du contexte.
    Appliquez Scrum à tout ce qui à faire est stupide.
    Appliquer Scrum indistinctement avec tous les collaborateurs est stupide.
    Appliquer Scrum indistinctement à tout type de périmètre volumétrique l'est également.
    L'auteur de l'article ne met pas en perspective ces 3 aspects qui font de Scrum une méthode pertinente dans un contexte défini et une méthode certes intéressante, mais qui ne doit pas être appliquée dans d'autres contextes.
    La digression sur la motivation du personnel est discutable car aucun membre d'une équipe de réalisation bien formatée sur un projet bien mené ne souhaite revenir à une méthode plus classique V, WaterFall.
    La base de la base c'est que si c'est un clou à planter, il faut un marteau, s'il y a un écrou à visser , prenons une clé.

  18. #38
    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
    Une méthode reste une méthode , c'est son contexte d'utilisation et son périmètre d'application qui font sa pertinence.
    Dire que Scrum est une mauvaise méthode , c'est comme dire que le WaterFall est une mauvaise méthode.
    Ca n'a pas de sens sans examen du contexte.
    Oui et non.
    Il y a des méthodes qui sont nulles quelque soit le contexte.

    Citation Envoyé par orfraie Voir le message
    La digression sur la motivation du personnel est discutable car aucun membre d'une équipe de réalisation bien formatée sur un projet bien mené ne souhaite revenir à une méthode plus classique V, WaterFall.
    Je connais des développeurs qui restent adeptes du cycle en V même après avoir été formés à des méthodes Agile et avoir participé à des projets réalisés en Agile qui se sont bien déroulés.
    Le cycle en V a le mérite de rassurer les gens qui savent ainsi exactement où ils vont et comment ils y vont.

    Par exemple, je connais quelqu'un qui prend tjrs le même trajet pour aller travailler et ce, quoiqu'il arrive.
    Il utilise son GPS pour connaître son heure d'arrivée mais jamais il ne va changer d'itinéraire en cas de bouchon alors que son GPS lui propose des chemins alternatifs plus rapides.
    Il est dans son habitude et ça le rassure car il sait où sont les virages dangereux, les radars, etc.
    Changer d'itiniraire, c'est de l'inconnu et ça l'angoisse.

    Avec les méthodes Agiles, c'est un peu comme ça.
    On se donne la possibilité d'adapter l’itinéraire à chaque croisement et ça peu en effrayer certains.

  19. #39
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    8 585
    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 585
    Points : 15 563
    Points
    15 563
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Le cycle en V a le mérite de rassurer les gens qui savent ainsi exactement où ils vont et comment ils y vont.
    C'est quasi impossible d'avoir le cahier des charges parfait pour un projet qui sera peut être fini dans plusieurs années.
    Comment une entreprise pourrait correctement exprimer son besoin ?
    « Dans 2 ans j'aurais précisément besoin de ça : * »
    Le client ne sait déjà pas ce dont il a besoin aujourd'hui, alors comment pourrait-il savoir ce dont il aura besoin dans la futur ?

    Citation Envoyé par Saverok Voir le message
    On se donne la possibilité d'adapter l’itinéraire à chaque croisement et ça peu en effrayer certains.
    Je comprend que prendre une autre route c'est stressant, mais je ne comprend pas en quoi SCRUM c'est stressant.
    Moi perso c'est pareil, je préfère prendre un itinéraire plus long que je maîtrise qu'une route plus courte inconnue.

    Un des nombreux problèmes du cycle en V c'est qu'on se planter sur la destination.
    Donc ok t'es ton itinéraire tout tracé, mais il va dans le mauvais coin.
    C'est un peu prévoir son itinéraire sur une carte déprécié.
    Ou juste se planter d'adresse de destination.

    Il y a des avantages et des inconvénients dans chaque méthode.
    Perso je vois plus d’inconvénients dans le cycle en V que dans SCRUM (mais bon il n'existe pas que 2 méthodes de gestion de projet).
    Et de toute façon si on regarde sous un certains angle, SCRUM c'est un peu plein de petits cycle en V.
    Keith Flint 1969 - 2019

  20. #40
    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 Ryu2000 Voir le message
    Je comprend que prendre une autre route c'est stressant, mais je ne comprend pas en quoi SCRUM c'est stressant.
    Moi perso c'est pareil, je préfère prendre un itinéraire plus long que je maîtrise qu'une route plus courte inconnue.
    Tout dépend de comment elle est appliquée et des profils des différents participants. Le scrum peut être vu comme une continuité de dead line dont seul le fil rouge est visible. On ne sais pas en janvier sur quoi on va travailler en mars. Pour certains c'est stressant. Pour d'autre ça peut être l'inverse. On a pas tous les mêmes façons de travailler, penser, etc.. C'est d'ailleurs pour ça que les méthodes "agiles" sont sensé évoluer pour s'adapter aux équipes et aux projets. Et c'est aussi pour ça que ces méthodes sont beaucoup critiquées : elles n'apportent pas -dans un premier temps- les gains de productivité qu'elle vante.

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