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

  1. #1
    Chroniqueur Actualités

    La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, selon Gene Bond
    La méthode Agile Scrum ne marche pas, elle fonctionne dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas,
    selon Gene Bond, directeur exécutif chez iiSM.ORG

    Scrum est une méthode Agile dédiée à la « gestion de projet ». Cette méthode de gestion est également appelée framework de management de projet. L’objectif de Scrum est d’améliorer la productivité d’une équipe. Elle est utilisée par plusieurs organisations à travers le monde, dont certaines ont témoigné de son efficacité. Cependant, d’après Gene Bond, directeur exécutif chez iiSM.ORG, une organisation dont la mission est de faire progresser la carrière des leaders du logiciel à tous les stades, la méthode Agile Scrum ne marche pas. Elle fonctionnerait dans seulement 15 % des cas, rencontrant donc un échec dans 85 % des cas. Voici un aperçu de son argumentation.

    Scrum est une méthode connue pour organiser le développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ». Scrum est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du Manifeste Agile. Toutefois, s’agit-il d’une méthode adaptée à tous les types d’entreprises ? Ou plutôt, Scrum fonctionne-t-il dans tous les cas d’utilisation ?


    Gene Bond, directeur exécutif chez iiSM.ORG

    Bond pense que non. « Oui, je comprends qu'Agile Scrum fonctionne bien pour 15 % des équipes qui le pratiquent. Mais comment appelle-t-on une chose quand elle échoue 85 % du temps ? Je crois que c'est ce qu'on appelle un échec », a-t-il déclaré. Selon lui, les créateurs de cette méthode l’ont fait dans un objectif précis, sans vraiment penser à toutes les sortes d’organisations qui étaient là ou qui ont vu le jour plus tard. Il estime que la taille unique ne correspond pas à toutes les équipes. Ce qui, dès le départ, aurait été clairement démontré par les créateurs de Scrum.

    « Agile Scrum n'a jamais été conçu comme une solution unique. C'est pourquoi le mouvement a été fondé par des programmeurs pratiques, des codeurs propres, des programmeurs extrêmes, des partisans du RAD et du RUP, eh oui, des défenseurs de Scrum. Dernièrement, nous avons ajouté au panthéon Agile la programmation allégée, qui est un ajout très apprécié », a-t-il déclaré. Selon Bond, aucune de ces solutions n’a malheureusement pas été conçue pour être universelle. Pour Bond, Scrum échoue, car la plupart des organisations le perçoivent comme la solution idéale quand leurs équipes commencent à rencontrer des problèmes d'efficacité.

    En d’autres termes, certaines organisations espèrent y trouver une solution magique pour la gestion du développement : des flux de création de logiciels qui peuvent être facilement mis à l’échelle, mais aussi des flux qui facilitent l'adaptation aux exigences changeantes tout en garantissant la responsabilité. De ce fait, les gens vendent Agile comme un concept (ce qui n'est pas souhaité), et ensuite livrent un type de Scrum contraint par le rôle. « En fait, Agile Scrum est si facile à conditionner et à consommer que presque tout le monde peut le vendre et le livrer », a déclaré Bond.


    Et selon lui, quelque chose qui est facile à vendre et à livrer et qui est très demandé ne peut être qu’un échec. En outre, il a aussi ajouté qu’il échoue, car de nombreuses entreprises croient qu’il suffit de copier ce que font les autres et qui marche et le tout est joué. Selon lui, cela ne marchera pas parce que les fondateurs d'Agile avaient raison : « il n'y a pas de taille unique ». Selon Bond, ce que ces derniers n’ont pas prévu ou sur lequel ils n’ont pas pu se mettre d’accord, c'est que pour que les gens adoptent sans peine Scrum, il devait être présenté sous forme de pratiques concrètes.

    Il ne devait pas se montrer sous forme de classes abstraites avec des méthodes virtuelles à définir selon le contexte. Toutefois, les partisans d’Agile ont trouvé le moyen de le rendre concret. Ils ont packagé et livré Agile Scrum. Mais selon Bond, il reste encore beaucoup à faire pour réaliser la promesse d'Agile qui est : la réalisation d'une utilisation judicieuse de pratiques de développement légères et de flux de travail qui s'adaptent avec souplesse aux besoins changeants et évolutifs des clients. Par ailleurs, Bond reconnaît qu’il existe bien des situations où Scrum marche bien.

    D’après son argumentation, Agile Scrum fonctionne étonnamment bien lorsqu'une équipe de développement itère directement avec un client via une série de courts sprints et dans certaines conditions. En premier, lorsque le client est engagé dans des revues de sprint et dans le processus d'apprentissage plus large consistant à découvrir quel est son besoin réel par rapport à son besoin perçu. Deuxièmement, en apprenant à connaître ses besoins, le client donne la priorité à la prochaine chose qui doit être construite ou résolue.

    Pour Bond, c’est à ce moment-là qu'Agile Scrum brille : avoir des clients qui sont engagés, et des équipes qui sont activées. Il n’est pas le seul qui croit que Scrum ne fonctionne pas. Pour ceux qui argumentent dans le même sens que lui, le véritable problème vient de la perception du besoin réel du client. Pour certains internautes, la plupart des clients ont toujours cru que toute la charge de travail incombe entièrement aux personnes qui créent le logiciel.

    En fait, ils estiment que lorsque les gens veulent des logiciels qui sont entièrement conçus pour eux, ils fournissent très peu d'effort ou ne fournissent pas du tout d'effort pendant les phases de planification et de développement. Il n'y a pas de magie dans le développement de logiciels où les développeurs connaissent soudainement vos processus/workflows/exigences exacts. D'après eux, c'est la principale raison de l’échec des méthodes de travail. Par contre, d’autres pensent que Scrum et d’autres méthodes agiles fonctionnent très bien.

    Selon eux, il suffirait de rester bien attentif dès que le processus de développement démarre. En plus de cela, il faut introduire dans ce processus de très petites équipes, mais pas beaucoup, des frais généraux bureaucratiques réduits, etc. Par ailleurs, ils estiment qu’il faut recommencer à zéro chaque fois que possible.

    Source : Billet de blog

    Et vous ?

    Quel est votre avis sur le sujet ?
    Êtes-vous ou pas du même avis que Gene Bond ? Que pensez-vous de ses arguments ?
    Quelle méthode Agile utilisez-vous et quelles sont les difficultés que vous rencontrez souvent ?

    Voir aussi

    Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ? Le point dans une étude comparative

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

    Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile

    « Agile est un cancer », pour Erik Meijer qui estime qu'il doit être banni une fois pour toutes
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé
    Résumé de l'article et façon internationale s'il vous plaît : "there is no silver bullet".

    Bien que je respecte et que je suis d'accord sur ce qui est dis, ça fait des années qu'on le crie et que (presque) personne, n'écoute.

  3. #3
    Membre éclairé
    Encore un qui se faire crucifier....
    Toute verité n'est pas bonne à dire...

  4. #4
    Membre éprouvé
    Comprendre les 12 principes du manifeste Agile , est largement suffisant , pour la pratique de cette méthodologie . Surtout pour une petite équipe de 2 a 5 personnes.
    Agile Scrum , est peut être plus orienté grandes équipes , mais reste quand même un concept pour vendre les logiciels dédiés a cette méthodologie et vendre du chef de projet .
    Beaucoup d’offres d’emploi, requière la connaissance de Agile Scrum . Mais sur le terrain , peux de pratique car peut de temps a consacrer aux réunions .
    Ne pas savoir n’est pas une faute si l’on cherche à combler ses lacunes.

    "Il n'y a pas d'obstacles infranchissables , il y a des volontés plus ou moins énergiques voilà tous" Jules Vernes

  5. #5
    Membre actif
    85% de foirade? Je sais pas d'où il tire ces chiffres mais à vite de pif ça correspond à la proportion de structures qui ne comprennent pas Scrum et/ou qui l'implémentent mal ou partiellement. Organiser des dailies et livrer toutes les 3 semaines ne suffit pas a augmenter l'efficacité d'une équipe, il faut souvent revoir l'organisation (de la structure j'entends, pas uniquement de l'équipe de dev) ce que les entreprises sont rarement pretes a faire (trop de gens ont trop a perdre). Une fois les conditions nécessaires a la mise en place de Scrum (ou de toute autre méthode agile) réunies, il n'y a aucune raison que ça foire...
    Développeur / Formateur
    Tutoriels AngularJS / Node.js sur ma chaîne Youtube : http://www.youtube.com/user/DevDuFutur

  6. #6
    Membre averti
    Cette méthode Agile est la combinaison savante de 'management à la mode' et de 'technique d'animation pour CE1/CE2'. Le best-of c'est vraiment le chiffrage par 'point d'effort', c'est un canular de qualité.

    Ce qui fait le succès des projets ce sont des individus qui le compose, à la fois ceux qui réalisent, ceux qui mènent et ceux qui exigent. Mélanger de la terre dans un sens ou dans un autre, ca aura toujours le goût de terre !

  7. #7
    Membre expert
    Citation Envoyé par JackIsJack Voir le message
    Cette méthode Agile est la combinaison savante de 'management à la mode' et de 'technique d'animation pour CE1/CE2'. Le best-of c'est vraiment le chiffrage par 'point d'effort', c'est un canular de qualité.
    C'est surtout qu'elle est vendue comme ça et souvent qu'elle est utilisée comme ça en entreprise...

    Citation Envoyé par JackIsJack Voir le message
    Ce qui fait le succès des projets ce sont des individus qui le compose, à la fois ceux qui réalisent, ceux qui mènent et ceux qui exigent. Mélanger de la terre dans un sens ou dans un autre, ça aura toujours le goût de terre !
    Oui mais là, quand on commence à travailler avec des gens compétents, on n'est plus dans le management !!! Que vont devenir tous les scrum master et compagnie ? Déjà que le chômage va remonter, faut pas déconner non plus !

  8. #8
    Membre habitué
    Pour moi une méthode agile à plusieurs avantage que l'on peut constater dans la pratique :
    • Permettre aux clients de prioriser ses demandes.
    • Identifier les fonctions accessoires que l'on peut remettre à une itération future
    • Agir rapidement en cas de changements de prio (évolution du marché du client par exemple)
    • Ne pas attendre des mois avant que le client puisse commencer à manipuler et donc avoir un retour concret rapidement.
    • Ne pas repousser les tests fonctionnels et techniques à la fin de la conception (tests qui peuvent remettre en cause des choix fondamentaux)
    • Travailler sur des users stories (ou des choses moins formelles) qui permettent d'avoir du concret et pas avec une spec avec des manques, des erreurs, obsolète, que les dev ne lisent pas ^^...
    • Parfois les clients ont des demandes qui font exploser le devis alors que peut être ils peuvent s'en passer. Pouvoir dire on fait 2 ou 3 itérations avec ça et ça pour tant d'€ et ensuite on verra si vous avez le budget pour ajouter d'autres choses.


    Le gros inconvénient du cycle en V c'est l'effet tunnel et je pense qu'une méthode agile permet de dépasser ça et c'est déjà un gros plus.
    Ça serait intéressant de voir d'où viennent ces 85% d'échec et ce qui différencie les contextes dans lesquels ces projets on été menés.

  9. #9
    Membre extrêmement actif
    Citation Envoyé par Bill Fassinou Voir le message
    [B][SIZE=4]Mais selon Bond, il reste encore beaucoup à faire pour réaliser la promesse d'Agile qui est : la réalisation d'une utilisation judicieuse de pratiques de développement légères et de flux de travail qui s'adaptent avec souplesse aux besoins changeants et évolutifs des clients. Par ailleurs, Bond reconnaît qu’il existe bien des situations où Scrum marche bien.
    Il suffit de faire des réunions régulièrement avec le client afin de lui montrer où en est le projet, comme ça il peut orienter le projet afin qu'il réponde à ses besoins.
    Il faut aussi livrer des versions alpha pour que le client puisse tester et faire un retour.
    C'est important l'agilité dans la gestion de projet informatique, si tu prends un cahier des charges et que tu livres exactement ce qu'il y a dessus 2 ans après, ça ne répondra pas du tout aux besoins du client.
    Avec les réunions régulières les développeurs et le client il n'y a pas de quiproquo, ils sont tous sur la même ligne. Le client peut exprimer précisément ce qu'il veut et le développeur peut expliquer précisément ce qu'il va faire.

    Citation Envoyé par Bill Fassinou Voir le message
    Pour Bond, c’est à ce moment-là qu'Agile Scrum brille : avoir des clients qui sont engagés, et des équipes qui sont activées. Il n’est pas le seul qui croit que Scrum ne fonctionne pas. Pour ceux qui argumentent dans le même sens que lui, le véritable problème vient de la perception du besoin réel du client. Pour certains internautes, la plupart des clients ont toujours cru que toute la charge de travail incombe entièrement aux personnes qui créent le logiciel.

    En fait, ils estiment que lorsque les gens veulent des logiciels qui sont entièrement conçus pour eux, ils fournissent très peu d'effort ou ne fournissent pas du tout d'effort pendant les phases de planification et de développement. Il n'y a pas de magie dans le développement de logiciels où les développeurs connaissent soudainement vos processus/workflows/exigences exacts. D'après eux, c'est la principale raison de l’échec des méthodes de travail. Par contre, d’autres pensent que Scrum et d’autres méthodes agiles fonctionnent très bien.

    Selon eux, il suffirait de rester bien attentif dès que le processus de développement démarre. En plus de cela, il faut introduire dans ce processus de très petites équipes, mais pas beaucoup, des frais généraux bureaucratiques réduits, etc. Par ailleurs, ils estiment qu’il faut recommencer à zéro chaque fois que possible.
    Pour qu'un projet agile fonctionne il faut que le client et les développeurs communiquent correctement. Une réunion toutes les 2 semaines peut suffire (et parfois elle durera moins d'une heure) et il faut peut-être un livrable tous les 3 ou 6 mois.
    En gros les développeurs montrent au client ce qui a été réalisé depuis la précédente réunion, ensuite les développeurs et le client se mettent d'accord sur les tâches à réalisées pour la prochaine réunion.
    Le client test le logiciel et remonte les problèmes ou les idées d'amélioration. Lors de la réunion les développeurs posent des questions au client afin de mieux comprendre ses besoins.

    C'est important que le client voit ce qui est en train d'être développé, comme ça il peut dire "il y a écrit ça dans le cahier des charges, mais en fait ce n'est pas du tout ça qu'il nous faut".
    Les besoins du client sont mal exprimés et aussi bien ils vont évoluer pendant le développement du projet.

    La méthode Scrum n'est peut-être pas la meilleure méthode agile de gestion de projet, mais ça peut être intéressant de s'en inspirer vaguement.
    Le tableau est sympa, ça fait un peu :
    - tâche à réalisées
    - tâches en cours de réalisation
    - tâches réalisées qu'il faut tester (normalement il faut qu'un autre développeur test si la tâche a correctement été réalisée)
    - tâches résolues
    Keith Flint 1969 - 2019

  10. #10
    Membre régulier
    Rigidité agile
    Demander de l'agilité dans une organisation et avec des individus rigides, des procédures et des normes dans tous les sens, un nombre de projets obscène et j'en passe, c'est peut-être un tout petit peu normal que ça merde. Mais bon, on aime tellement les baguettes magiques.

  11. #11
    Membre expert
    Je fais partie des 85%
    J’ai du intervenir sur 4-5 projets où on «*appliquait*» cette méthode à chaque fois c’est pas respecté, des daily de 45min, des tâches ajoutées en court de sprint.
    L’estimation des tâches en point est souvent une aberration aussi, etc ...
    Mon Covid Tracker alias Coronavirus : https://covid.ovh/
    Application 1km qui permet de calculer la distance d'1km autour de son domicile :
    Apps Android
    Apps IOs

  12. #12
    Membre habitué
    Bâti autour d'un noble idéal, cet outil de pilotage / planification est transformé en indicateur de productivité. Dans un monde ultra concurrentiel, où la performance de chacun est individuelle, tout comme la prime, cela ne pouvait pas en être autrement. Tout est question de rendement, à celui qui réussit le plus de sprints, termine premier.

    Cela rassure de pouvoir mettre des deadline, même si ces dates de fin sont scientifiquement inventées avec la méthode du doigt mouillé.

    Cette méthode branchouille à la mode, vendue à toute les sauces, devenue l'alpha et l'omega, restera comme ses ancêtres, toujours dépendante du management, critère prépondérant dans le bon déroulement du projet.

    Les hommes > la méthode

  13. #13
    Membre éprouvé
    On a toujours fait du cycle en V mais pour autant on a toujours pris en compte les changements des clients meme en cours de route. J'ai jamais vu une boite qui faisait du cycle en V pur et dur (ou on remet en cause des choses a la fin). Depuis quelques années on fait du scrum, nos projets ne sont pas de meilleures qualités, on repousse les sprints et les sujets non finis donc au final on explose les budgets de manière phenomenale.
    Je n'ai jamais eu l'effet tunnel sur projet cycle en V car on attend jamais la fin pour identifier/remonter/rectifier les problèmes ou si les besoins semblent pas nets.
    Avec Scrum par contre on a tendance a ne pas finir les sprints, c'est pas grave on prolonge dans le suivant.
    Beaucoup de temps passé en stand up meeting (les 15 min c'est toujours plus proche des 45 min); on a des salles remplies de post it. En debut de projet tout le monde est content on se fait plaisir a faire des tableaux a gogo. Au fur et a mesure de l'avancement, comme les personnes travaillent sur plusieurs sujets (cad le projet en cours mais doivent aussi assurer le SAV de leurs autres logiciels) ben les SUM sont de moins en moins populaires, les gens delaissent au profit des urgences des autres projets.
    Bref le scrum est un echec sur tous nos projets. Pourtant on en a vu passer des scrum master (a un moment le critere de selection c'était recruter des gens qui bossent sur projets open source). On a multiplié les outils, plus les formations associées, les plannings poker qui sont une farce, velocité etc. tout ce langage inutile pour mesurer l'efficacité des gens. Les gens sont bons quand ils savent exactement ce qu'ils doivent faire.
    Personnellement je n'y crois pas; la seule methode qui fonctionne c'est le bon sens. Derouler des process parce que c'est ecrit dans la methode, ca coute.

  14. #14
    Membre averti
    Je préfère la méthode à pierre, parce que gilles sa méthode .....

  15. #15
    Modérateur

    Vouloir appliquer 1 méthode absolument n'est juste pas possible pour la majorité. Chaque équipe est unique et donc chaque équipe fonctionne différemment. Il faut savoir piocher dans chaque méthode pour en extraire ce qui nous convient.

    Scrum c'est pas mal de masturbation, avec du vocabulaire qui fait cool mais au final on brasse aussi pas mal de vent j'ai l'impression. Perso j'ai autre chose à foutre tous les jours que de passer 15 à 30 min en réunion (parce que les SU meeting ca ne tiens jamais dans le délai impartit) pour finalement ne rien apprendre de nouveau. Une bonne équipe elle saura communiquer au bon moment sans avoir a se forcer.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  16. #16
    Modérateur

    Citation Envoyé par JackIsJack Voir le message
    Ce qui fait le succès des projets ce sont des individus qui le compose, à la fois ceux qui réalisent, ceux qui mènent et ceux qui exigent. Mélanger de la terre dans un sens ou dans un autre, ca aura toujours le goût de terre !
    Cequi fait le succès des projets ce sont les Hommes et la façon dont ils s'impliquent et coopèrent ; laméthode agile est un outil formidable pour ces deux points:

    L'implication est plus grande, car on donne la parole à chaque intervenant, on lui demande son avis. Exemples:

    - le développeur, habituellement simple exécutant à qui on dit 'tu dois faire ça en tant de temps', là on lui demande d'estimer lui-même sa charge pour telle tâche. Il se sent estimé (on lui demande son avis) et s'engage (il aura à coeur de finir une tâche qu'il a lui-même estimée dans les temps.

    - idem pour les clients, à qui ont demandera de s'impliquer dans les choix et les priorisations.

    La coopération vient également d'elle-même car le découpage n'est plus tant par couche que par objectif inter-disciplinaire.

    Le vrai problème c'est que la méthode Agile demande une certaine rigueur, et une capacité à désapprendre certains réflexes antérieurs ; quand je lis que les stand-up dérivent vers 45 minutes chez certain, y'a pas besoin de creuser plus pour comprendre qu'ils critiquent non pas l'échec de la méthode agile mais l'échec de son application déviante dans leur projet. Ca s'apprend, il faut du temps.

    En la matière, le principal écueil que j'ai pu observer (en dehors des meetings qui ne savent pas s'arrêter), c'est au niveau des chefs de projets IT ; l'agile pour eux, c'est avant tout accepter de perdre une part de leur prérogatives: la priorisation des tâches IT (qui passe côté product owner) et surtout l'estimation, qui passe côté devs. Vu que ce sont des grosses parties de leur taf jusque là, ils ont l'impression qu'on leur pique leur boulot (et la reconnaissance qui va avec); c'est dur à accepter au départ ; là aussi, ça s'apprend avec le temps.
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  17. #17
    Membre confirmé
    Je ne sais pas si on peut dire que la methode agile SCRUM ne marche pas 85% du temps...

    Si on file une pelle au manager d'un type qui creuse des tranchées à main nue, en lui disant que ça ira plus vite avec, et que le manager se met à donner des coups de pelle au gars qui creuse, est ce qu'il faut conclure que la pelle ne marche pas ?

    Allons ... tout le monde sait que pour trouver un metier dans le secteur, il faut connaitre les buzz words. Connaitre la technologie sert si peu.
    On ne va pas commencer à expliquer ce que veut dire "stateless", si l'on veut prouver que l'on sait ce que veut dire REST, à un type qui à la base veut juste entendre que c'est un truc que l'on fait avec un framework à la mode (qu'il a évidement choisi parce qu'il est un décisionnaire top level) ...

  18. #18
    Membre chevronné
    Parce que la question de la méthode reste toujours prioritaire sur la question des hommes, parce que plus simple à résoudre. Du moins dans l'esprit des technocrates.
    Une méthode, une check list, des trainings à la méthode et c'est parti - bonus sur la musique de teletubby et l'ambiance babyfoot.

    La réalité c'est que pour dialoguer avec un client il y a une connaissance à avoir du client et de son métier. Et c'est sous-estimé si pas négligé.

    Ce n'est pas le choix d'une méthode projet qui fait la réussite d'un projet, ni encore la specification. C'est la compréhension par ceux qui livrent et codent l'application de son usage. C'est ça la clef de la réussite d'un projet. Rien de plus, rien de moins.

    Croire qu'on fait des applications pro avec des gens sans connaissance du domaine c'est soit avoir un temps immense devant soit, des moyens énormes et ne pas avoir d'urgence.

    Les équipes afonctionnelles (pour faire un néologisme qui pourrait exister) qui n'auraient pas besoin de user stories ou de specs, c'est comme les soit disantes architectures agnostiques : ça n'existe que dans la tête des gens qui n'ont jamais eu ni à mettre en prod leur code, ni a en assumer les conséquences financières, ni à les écrire.

    A la fin du code c'est comme écrire un livre : il faut un sujet, et de la connaissance/recherche sur le sujet. Tout dépend de si on comprend vraiment la réalité de partir de zéro, et surtout de la qualité qu'on souhaite délivrer.

    Le mirage de l'agile / scrum / n'est pas tant méthodologique mais prouve surtout que changer la méthode ne résoud pas les question existantes.
    Dès lors, la logique dirait plutôt : la question n'est donc pas la méthode.

    Quand a sous tendre que l'agile ne fonctionne pas, ce sont surtout les entreprises qui se disent agiles qui ne fonctionnent pas.
    https://www.zdnet.fr/actualites/sncf...y-39892677.htm

    Globalement, si effectivement le retour doit être mesuré sur la base des projets des grands groupes, ils échouaient hier et échoueront demain : ils s'en moquent, il n'ont pas de rationalisation à l'argent.

    Ceux qui réussissent leurs applications et travaillent de façon rigoureuse, n'ont juste pas le temps pour de genre de masturbation métaphysique et para-informatique.
    Les consultants de la meilleure façon de faire sont plus nombreux que les experts malheureusement.

    On oublie souvent l'essentiel : qu'une équipe a besoin de comprendre son travail et d'avoir du travail. Faire des workshops, des meetings, des scrums machin, des scrums bidules, non seulement c'est infantilisant, mais en plus c'est chronophage : les gens structurés n'ont pas besoin de ces tautologies pour travailler; ils le font implicitement.

    C'est donc juste une espérance de forme d'efficience tout au plus, mais qui oublie grandement où s'en trouve l'origine. Bref l'homme.

  19. #19
    Membre expert
    C'est comme dans un combat, il faut mettre en opposition l'agilité et la force : 100% d'agilité avec une force ridicule c'est comme envoyer pleins de pichenettes sans même provoquer la moindre chatouille

    Trop de force sans agilité, c'est être super lent et avoir des difficultés à porter un coup, mais on fait beaucoup de dégâts (le projet avance beaucoup).

    D'un côté on touche tout le temps mais on ne fait aucun dégât, et de l'autre on ne touche jamais... même résultat, rien n'avance, le projet stagne, l'ennemi à abattre est encore debout !

    L'idéal serait de se déplacer avec beaucoup d'agilité, et au moment voulu, de concentrer idéalement sa force, est-ce transposable en méthodologie de projet ? Peut-être
    K

  20. #20
    Membre extrêmement actif
    Il me semble que dans son article Gene Bond ne critique que la méthode SCRUM et pas l'agilité en générale.
    SCRUM n'est qu'une méthode agile parmi tant d'autres.
    Keith Flint 1969 - 2019