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

Actualités Discussion :

Le fondamentalisme sous agile nuit à la santé des entreprises

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

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

    Informations forums :
    Inscription : Août 2011
    Messages : 283
    Points : 18 071
    Points
    18 071
    Par défaut Le fondamentalisme sous agile nuit à la santé des entreprises
    Le fondamentalisme sous agile nuit à la santé des entreprises
    Selon le PDG d’un éditeur de logiciels adepte des méthodes agiles

    Mars Cyrillo est le PDG de CI&T, entreprise spécialisée dans le développement logiciel pour le compte de quelques grands noms du top 100 des entreprises. Aujourd’hui, il revient sur le développement agile, lequel a été adopté par son entreprise au cours de l’année 2005, après avoir utilisé pendant de longues années une autre approche de développement : RUP (Rational Unified Process).

    L’un des premiers constats que fait Cyrillo est : « Nous admettons qu’au début, nous avons pris trop à la lettre le manifeste agile. Nous sommes alors devenus une sorte de fondamentaliste qui veut suivre et implémenter d’une manière stricte la philosophie en l’imposant à ses clients ».

    Puis il évoque d’autres constats qui sont venus s’agglutiner au premier, suite au développement de l’entreprise : « Nous avons réalisé que nous nous dupions en pensant que nous pouvions suivre à la lettre le manifeste. Nous étions plus fragiles qu’agiles. » Et « le défi était de savoir comment rendre l'information et les processus de décision effectifs dans un environnement où il est tout simplement impossible d'avoir toutes les parties prenantes dans des réunions quotidiennes. »

    Ainsi, pour le CEO de CI&T et sur la base des valeurs agiles qui mettent en avant chacun deux points de vue opposés (un point de vue à gauche et un second à droite), un suivi à la lettre de ces valeurs conduit à une sorte de fondamentalisme où les équipes de développement se concentrent uniquement sur le premier point de vue, délaissant le second. Or, les signataires du manifeste mettent l’accent sur le premier sans oublier l’importance du second.

    Cette situation mène par exemple certains fondamentalistes à ne pas documenter leur programme, même si cela est nécessaire dans certaines situations (valeur n° 2) ou encore à ne pas fixer clairement de deadlines, évoquant pour cela la valeur n° 3, où il est question de collaboration avec le client, plus que de négociation contractuelle.

    Cyrillo va plus loin encore dans ce constat. Il cite certaines déclarations régulièrement faites par ces fondamentalistes, dont les propos n’ont pas réellement leur place :
    • « Le développement logiciel est une forme d’art qui ne peut être mesurée. » ;
    • « La mesure de la productivité relève du passé et de la production de masse. Les artefacts utilisés par les chefs de projets ne servent qu’à stresser les développeurs. » ;
    • « La mesure de la productivité est un risque parce que les équipes trouveront toujours des solutions pour prouver artificiellement qu’elles sont productives. ».


    A titre d’exemple, il explique ce qui suit : « Des métriques peuvent être utilisées pour mesurer les performances du processus utilisé, quant aux équipes de développement, elles doivent pouvoir calculer, mesurer et contrôler leur productivité. Une équipe qui n’en est pas capable ne peut pas comprendre ce qui l’affecte et par conséquent ne sera pas capable de s’améliorer en continue. »

    Enfin, le CEO livre quelques détails sur les clés du succès sous agile, tout en garantissant la croissance de l’entreprise comme le suivi des principes lean qui offrent, selon lui, la meilleure approche philosophique, combinée à n’importe quelles méthodes agiles telles que SCRUM, Kanban.

    Source : CI&T

    Et vous ?

    Qu’en pensez-vous ?
    Pensez-vous être un fondamentaliste ou plutôt un adepte qui se donne une certaine flexibilité ? Pourquoi ?

  2. #2
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Toute forme de fondamentalisme est a proscrire, bien evidemment.

    Maintenant que cette lapalissade est rappelee, je trouve interessant de voir qu'on commence a trouver de plus en plus de "critiques" d'Agile, constructives ou non, en meme temps. Je pense que ca montre surtout qu'on est en train de passer de la phase "on est cool on fait de l'Agile/Scrum" a une phase de prise de recul, d'analyse, au cours de laquelle on se rend compte que oui, il y a des bonnes choses dedans, mais que non, tout n'est pas merveilleux, et il ne faut pas l'appliquer aveuglement.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    C'est quand même paradoxal, cette mise en Abyme : le principe de base de l'agile, c'est de ne pas trop s'attacher aux principes, et on s'aperçoit que s'attacher trop à ce principe est nuisible.....
    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.

  4. #4
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    Pour ma part, je serais intéressé qu'il nous explique comment évaluer une équipe de dev.
    Après plusieurs mois a réfléchir a la question, j'en suis arrivé a la conclusion que ce n'était pas faisable sur des critères mesurable et qu'il fallait faire confiance a l'humain, quitte a multiplier les évaluation pour limiter les effets de copinage.

  5. #5
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par pmithrandir Voir le message
    Pour ma part, je serais intéressé qu'il nous explique comment évaluer une équipe de dev.
    Après plusieurs mois a réfléchir a la question, j'en suis arrivé a la conclusion que ce n'était pas faisable sur des critères mesurable et qu'il fallait faire confiance a l'humain, quitte a multiplier les évaluation pour limiter les effets de copinage.
    L'evaluation des developpeurs est effectivement quelque chose de complexe, mais je ne vois pas bien le rapport avec le fait que l'application a outrance d'une methode, quelle qu'elle soit, n'est pas benefique au developpement logiciel, et donc a la sante globale de l'entreprise -- ou tout du moins a sa profitabilité.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  6. #6
    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 917
    Points
    2 917
    Par défaut
    L'article repose sur le procédé assez connu de l'homme de paille : on établit une caricature d'agiliste "fondamentaliste" qu'on affuble de tous les maux, pour ne pas avoir à débattre de manière pragmatique sur une approche raisonnée. Les critiques restent assez vagues pour paraitre pleines de bon sens. Certaines seraient intéressantes si elles étaient argumentées, d'autres sont juste des vérités toutes faites. Ex : "Those are all myths that can be proven wrong." => OK, la démonstration SVP ?

    La référence à l'article de Dave Thomas, un des signataires du manifeste agile, est utilisée à total contresens : D. Thomas ne critique pas les gens qui prennent trop le manifeste au pied de la lettre, mais ceux qui ne le prennent pas assez. Ceux qui ont marketé l'agilité au point de la vider de tout son sens.

    En face de cela, l'auteur ne détaille aucune solution concrète, juste un mot : Lean, qui serait selon lui "la meilleure façon d'implémenter agile" et générateur "d'une qualité et d'une performance de rendement jamais vues avant".

    On parie que dans 5 ans il nous ressort le même article sur Lean ?

  7. #7
    Expert éminent Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    Mars 2014
    Messages
    1 760
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Mars 2014
    Messages : 1 760
    Points : 7 185
    Points
    7 185
    Par défaut
    L'origine de la méthode Agile provient d'une double nécessité : produire mieux en évitant de mettre trop de pression aux développeurs dans le rythme infernal mis par l'obsolescence programmée. Obsolescence causée par la pression mise par le monde de la finance et du ROI suite à la "bulle internet".
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  8. #8
    Expert éminent sénior
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2012
    Messages
    3 020
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2012
    Messages : 3 020
    Points : 16 093
    Points
    16 093
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    On parie que dans 5 ans il nous ressort le même article sur Lean ?
    Probablement.

    D'autant que pour avoir vu des collègues "subir" le lean, je peux vous dire que des fondamentalistes, il y en a de ce coté là aussi...

    Bilan, six mois après 4 mois de lean (donc avec des demies journées entières avec un gugusse qui ne connait rien à votre taf au dessus de votre épaule qui note le moindre de vos fait et geste, super agréable...), je crois que quasi aucune "bonne pratique" du lean n'a été conservé. Et à chaque fois que le mot "lean" est prononcé dans ce service, l'ambiance se tend instantanément.

    Bref, les méthodologies toutes faites, c'est de la poudre aux yeux. Chaque societé, chaque service, chaque client à ses spécificités. On ne peut pas appliquer une recette toute faite. Si c'était le cas, ça se saurait.

  9. #9
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Citation Envoyé par Carhiboux Voir le message
    Probablement.

    D'autant que pour avoir vu des collègues "subir" le lean, je peux vous dire que des fondamentalistes, il y en a de ce coté là aussi...

    Bilan, six mois après 4 mois de lean (donc avec des demies journées entières avec un gugusse qui ne connait rien à votre taf au dessus de votre épaule qui note le moindre de vos fait et geste, super agréable...), je crois que quasi aucune "bonne pratique" du lean n'a été conservé. Et à chaque fois que le mot "lean" est prononcé dans ce service, l'ambiance se tend instantanément.

    Bref, les méthodologies toutes faites, c'est de la poudre aux yeux. Chaque societé, chaque service, chaque client à ses spécificités. On ne peut pas appliquer une recette toute faite. Si c'était le cas, ça se saurait.

    Il faut aussi prendre en compte la façon dont a été appliqué le Lean.

    Nous avons fait cette démarche dans notre société (mais je ne suis pas dans une SSII qui fournit du service), et nous avons augmenté notre productivité, amélioré un certain nombre de nos processus, etc etc

    Mais pour cela, nous avons été somme encore suivi par une société spécialisé dans le domaine depuis plus d'un an, qui a étudié avec nous nos besoins, nos contraintes, et qui a pris le temps de comprendre nos processus dans les grandes lignes afin de pouvoir y appliquer les principes du Lean de la façon la plus adéquate, car comme tu le dis, chaque société à ses spécificités, peut-être n'êtes vous pas tombez sur les bons intervenants.


    Et puis comme dans tous changements dans les habitudes, il y a aussi une bonne partie de réfractaires, qui peuvent aussi, freiner voir fausser la mise en application du principe du Lean, car cela demande une certaine remise en cause de soit-même et de notre façon de travailler.

  10. #10
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Arsene Newman Voir le message
    L’un des premiers constats que fait Cyrillo est : « Nous admettons qu’au début, nous avons pris trop à la lettre le manifeste agile. Nous sommes alors devenus une sorte de fondamentaliste qui veut suivre et implémenter d’une manière stricte la philosophie en l’imposant à ses clients ».

    « Nous avons réalisé que nous nous dupions en pensant que nous pouvions suivre à la lettre le manifeste. Nous étions plus fragiles qu’agiles. » et « le défi était de savoir comment rendre l'information et les processus de décision effectifs dans un environnement où il est tout simplement impossible d'avoir toutes les parties prenantes dans des réunions quotidiennes. »
    Croire au Père Noël et se rendre compte qu'il faut se retrousser les manches n'a pas grand chose à voir avec une méthode agile ( ou une autre méthode ).

    Citation Envoyé par Arsene Newman
    Ainsi, pour le CEO de CI&T et sur la base des valeurs agiles qui mettent en avant chacun deux points de vue opposés l’un à l’autre (un point de vu à gauche et un second à droite), un suivi à la lettre de ces valeurs conduites à une sorte de fondamentalisme où les équipes de développement se concentrent uniquement sur le premier point de vue, délaissant le second. Or, les signataires du manifeste mettent l’accent sur le premier sans oublier l’importance du second.
    Pas compris .

    Citation Envoyé par Arsene Newman
    Cette situation mène par exemple certains fondamentalistes à ne pas documenter leur programme, même si cela est nécessaire dans certaines situations (valeur n°2) ou encore à ne pas fixer clairement de deadlines évoquant pour cela la valeur n°3 où il est question de collaboration avec le client, plus que la négociation contractuelle.

    • « Le développement logiciel est une forme d’art qui ne peut être mesurée. »
    • « La mesure de la productivité relève du passé et de la production de masse. Les artefacts utilisés par les chefs de projets ne servent qu’à stresser les développeurs. »
    • « La mesure de la productivité est un risque parce que les équipes trouveront toujours des solutions pour prouver artificiellement qu’elles sont productives. »


    « Des métriques peuvent être utilisées pour mesurer les performances du processus utilisé, quant aux équipes de développement, elles doivent pouvoir calculer, mesurer et contrôler leur productivité. Une équipe qui n’en est pas capable ne peut pas comprendre ce qui l’affecte et par conséquent ne sera pas capable de s’améliorer en continue. »
    c'est sérieux ? Pas de documentation du code, pas de limites de temps ( = incapacité à découper le travail donc ils n'ont pas compris les besoins... ), quand à l'incapacité à "calculer" son efficacité celle là est la meilleur !!!
    Visiblement cette personne emploi le mot équipe sur un groupe qui n'en est pas une, qui ne connait pas les besoins du client et est incapable de faire du bon boulot ( ils n'ont font pas à mon avis ) et de s'en rendre compte
    De plus à part le passé je ne vois pas trop quoi mesurer pour estimer l'avenir .
    Bon on a compris ils ne font pas de l'agile.

    Citation Envoyé par Arsene Newman
    Enfin, le CEO livre quelques détails sur les clés du succès sous agile, tout en garantissant la croissance de l’entreprise comme le suivi des principes lean qui offrent, selon lui, la meilleure approche philosophique, combinée à n’importe quelles méthodes agiles telles que SCRUM, Kanban.
    je serais moins idiot ce soir.

  11. #11
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Je suis d'accord pour dire que le dogmatisme vis à vis d'une méthodologie est néfaste, surtout qu'autour d'agile il y a aussi un petit versant commercial bien rôdé. Si vous me croyez pas, constatez par vous mêmes que presque tous les sites qui parlent d'agile proposent des services de consulting ou de coaching d'équipe.
    Bref dans cet article, ça manque vraiment d'exemples concrets, on y apprend que ce qui marche pour les start-ups de 5 personnes marche pas forcément pour les équipes de 500, merci c'est vrai qu'on s'en douterait pas .

    Le seul point où on a droit à un peu plus de précision c'est sur l'implication de l'utilisateur dans le processus. Là il nous dit que ce n'est pas évident d'avoir quelqu'un à disposition en permanence et qu'il y avait souvent des complications à cause du manque d'alignement des différents interlocuteurs (enfin comme je le comprends même si c'est pas dit aussi clairement). C'est aussi un problème connu, qui n'a jamais rencontré plusieurs personnes lors d'une séance, et vu à quel point ça se met à partir live lorsque chacun jette sur la table sa propre idée de ce que le produit devrait être? C'est même pas imputable à une méthodologie, c'est plutôt je sais pas moi... un fait anthropologique?

  12. #12
    Expert éminent sénior
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2012
    Messages
    3 020
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2012
    Messages : 3 020
    Points : 16 093
    Points
    16 093
    Par défaut
    Citation Envoyé par Zirak Voir le message
    Il faut aussi prendre en compte la façon dont a été appliqué le Lean.

    Nous avons fait cette démarche dans notre société (mais je ne suis pas dans une SSII qui fournit du service), et nous avons augmenté notre productivité, amélioré un certain nombre de nos processus, etc etc
    Peut être que vous aviez plus de "marge de progression" que le service donc je parle alors. C'est possible. Ou alors comme tu le dis, ils sont tombés sur des mauvais accompagnants. Très possible aussi.

    Citation Envoyé par Zirak Voir le message
    Mais pour cela, nous avons été somme encore suivi [...] Et puis comme dans tous changements dans les habitudes, il y a aussi une bonne partie de réfractaires, qui peuvent aussi, freiner voir fausser la mise en application du principe du Lean, car cela demande une certaine remise en cause de soit-même et de notre façon de travailler.
    Oui, il y a clairement cela aussi.

    Quand le lean vient "d'en haut" et que cela n'a comme objectif que d'augmenter les marges de la SS2I, c'est vrai que c'est pas trop fédérateur comme projet!

  13. #13
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Oui, après comme je le dis, ne faisant pas parti d'une SSII, la démarche n'était pas forcement la même également, mais le côté réfractaire car cela vient d'en-haut, c'est un des premiers trucs dont nous ont parlé les consultants qui nous suivaient, que le changement, cela faisait peur.


    Je travaille dans une société qui fabrique quelque chose de concret, avec une chaine de montage plus ou moins automatisée, ce n'est pas que du "service", il y avait donc aussi plus de possibilité de voir réellement le gain.

    Mais dans le principe du Lean, de développer son environement de travail de façon à tout avoir à portée de main sans bouger, de chercher les "gâchis" afin d'améliorer les processus, etc etc, Au final, ce n'est pas évident à faire car comme je le disais, chacun a ses petites habitudes, et n'a pas forcement envie de changer son train-train (ni se faire remarqué que c'est à son poste que le processus perds le plus de "gain" car pas optimisé etc etc...).

    Sauf que, que cela soit pendant le processus (réflechir sur son poste, ses améliorations possibles, etc etc) ou après (travailler avec des processus plus optimisés, avoir de meilleurs communications au sein des différents services, etc etc), cela rend le travail plus agréable, surtout lors de ce moment où l'on se rend compte que : "tiens je viens de faire ça en 15mn, avant cela me prennait 1h30", on a moins l'impression de travailler dans le vide


    Après d'un point de vue SSII, c'est vrai que le principe doit être un peu différent, nous le plus gros du changement s'étant plus déroulé au niveau production que bureaux, je ne vois pas trop comment cela s'adapte à une société de service.

  14. #14
    Membre actif
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    47
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 47
    Points : 211
    Points
    211
    Par défaut
    Agile? Le truc adapté pour du développement amateur entre potes, mais qui se casse la gueule face à la nature productiviste de l'entreprise? A force de sprinter sous le chrono attentif du chef de la galère, on perd en endurance Ca me rappelle le cas de l'ouvrier qui suggère tellement d'optimisation de son processus de travail, qu'il ne ménage plus de temps de pause, et forcément La cadence de travail à court terme sabote celle à moyen et long terme. Pointeuse, ouvrier, développeur, promotion, rivalité pour le poste de grand chef...

  15. #15
    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 917
    Points
    2 917
    Par défaut
    @herdans : c'était ironique ?

    Les méthodes agiles ont été conçues précisément pour l'entreprise, pas pour du dev entre potes, et préconisent au contraire d'autres approches plus "tayloristes" un rythme durable :

    Business people and developers must work
    together daily throughout the project.
    Agile processes promote sustainable development.
    The sponsors, developers, and users should be able
    to maintain a constant pace indefinitely.
    http://agilemanifesto.org/principles.html

    Maintenant, comme toute autre méthodo, elles peuvent être mal utilisées et totalement détournées de leur esprit initial...

  16. #16
    Membre actif
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    47
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 47
    Points : 211
    Points
    211
    Par défaut
    Ironique? Non, réaliste.

    Le but de la plupart des entreprises est de produire à moindre coût. Pas forcément de le faire bien. Les informaticiens ont pour vocation à produire du code correct, les autres parties impliquées veulent un résultat rapide, sinon la facture grimpe en raison du temps supplémentaire générateur de coût. Les clients vont pressurer les chefs de projet, qui vont eux même cravacher les informaticiens pour éviter les surcoûts (get shit done) inhérents à un travail plus long. Forcément en rabotant, la qualité en pâtit. Les informaticiens vont bâcler le truc pour respecter les ordres du très haut.

    Agile requiert un niveau de confiance, et d'équilibre entre les différentes parties, qu'il est impossible à mon avis d'atteindre dans le privé. Le chef va faire l'interface entre le dév, et le client, avec en ligne de mire une date de livraison irréaliste . Mais les client/chef n'ont pas le temps de vérifier faute de disponibilité, donc bonjour les dégats, on arrive à l'éternel effet tunnel, avec détection du problème en bout de chaine, proche de la deadline ultime

  17. #17
    Membre confirmé
    Inscrit en
    Juin 2009
    Messages
    219
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 219
    Points : 473
    Points
    473
    Par défaut
    Citation Envoyé par marsupial Voir le message
    L'origine de la méthode Agile provient d'une double nécessité : produire mieux en évitant de mettre trop de pression aux développeurs
    C'est faux. Ceci n'est qu'une conséquence de l'application de la méthode.

    L'origine vient de 2 constats simples, constats que tu observeras dans la nature:
    1) On résout plus facilement un problème en le découpant
    2) On résout plus rapidement un problème en faisant appel à l'intelligence collective

    Le fondamentalisme ne nait que lorsqu'on oublie ce pourquoi on fait une chose.

    Pour revenir à la problématique de métrique/benchmark d'une équipe, à ma connaissance, impossible de faire de l'agile sans utiliser la métrique de base, la vélocité. Et c'est un très bon indicateur pour mesurer l'évolution de la performance d'une équipe agile. Par contre, c'est une métrique qui ne peut en aucun cas être utilisé pour comparer les performances de 2 équipes différentes tant elle est subjective.
    Et c'est de là que vient la frustration des manager. Comment s'assurer que j'ai payer le bon prix pour le service reçu??? Et donc des fortunes sont dépensées pour métriques que l'on peut aisément contourner. Par chez moi ce sont les points de fonctions qu'on utilise

    Pour ma part, j'estime qu'être heureux cela n'a pas de prix. Et si je ne suis pas content, je vais voir ailleurs. Mon niveau de stress est proche du 0.

  18. #18
    Membre émérite

    Homme Profil pro
    Ingénieur Réseaux
    Inscrit en
    Juin 2012
    Messages
    877
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur Réseaux
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2012
    Messages : 877
    Points : 2 427
    Points
    2 427
    Par défaut
    Loin d'être expert, je me pose une question.

    Est-ce qu'on ne nuit pas à l'efficience collective en s'enfermant dans quelque chose d'imperméable, d'impénétrable ?

    La méthode Agile n'est pas en cause, c'est plutôt l'utilisation et l'interprétation qu'ils en ont eu qui nuit le plus.

    La méthode Agile et autres méthodes de management, gestion de projet sont des outils, des pistes de reflexion.
    Certaines ne matchent pas avec certaines secteurs d'activités, certaines équipes ou certains managers.

    Je pense que le principal dans tout cela est d'avoir la connaissance des méthodes de management et que suivant le projet, l'équipe, les individualités en place, le manager doit choisir certains points d'une méthode ou de plusieurs pour tirer le meilleur de son équipe.
    Si la réponse vous a été donnée, pensez au Tag .
    Un petit aide à se sentir utile. Merci.

    "La folie. C'est de faire et refaire la même chose en espérant que le résultat sera différent."
    Albert Einstein

  19. #19
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par marsupial Voir le message
    L'origine de la méthode Agile provient d'une double nécessité : produire mieux en évitant de mettre trop de pression aux développeurs dans le rythme infernal mis par l'obsolescence programmée. Obsolescence causée par la pression mise par le monde de la finance et du ROI suite à la "bulle internet".
    Citation Envoyé par notia Voir le message
    C'est faux. Ceci n'est qu'une conséquence de l'application de la méthode.

    L'origine vient de 2 constats simples, constats que tu observeras dans la nature:
    1) On résout plus facilement un problème en le découpant
    2) On résout plus rapidement un problème en faisant appel à l'intelligence collective
    Vous avez tous les 2 faux

    L'origine vient tout simplement d'une longue et extensive pratique du cycle en V... sur de gros projets dans de grosses équipes.. ou à avoir eu à développer en parallèle à de grosses équipes en cycle en V.

    J'ai déjà mis quelque part - mais je peux le remettre - des stats du milieu des années 90 où 91% des projets échouent, et sur les 9% qui marchent, ils n'ont que 47% des fonctionnalités demandées.. (voir ces stats ici)

    C'est partant de ce constat, et en ayant l'habitude d'équipes où la production de documents internes, d'erreurs de traductions, et de réunions à plusieurs niveaux parce que le découpage était taylorien, entraînant des prises de décisions sur plusieurs mois, voire années, que les auteurs ont créé le Manifeste..

    Et à peu près n’importe quelle personne sensée ayant travaillé sur ce genre de projet vous le dira..


    Quant à l'article, son fond était prévisible dès le départ : je l'ai déjà dit X fois, l'agilité est un état d'esprit, et avec des bons, voire excellents, c'est encore mieux.. voire indispensable..

    Donc, ce que je me suis tué à dire sur ces forums depuis maintenant 7 ans, c'est que les méthodologies agiles sont aussi nocives que n'importe quoi d'autre, si on en fait une religion.. Ce qu'on en a fait, par un élan marketing comparable à la mode du tout OO, du C++, ou du Cloud, ou n'importe quel buzz-word..

    Mais bon, l'info aime le buzz, et les manuels pour savoir comment faire.....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

Discussions similaires

  1. Réponses: 8
    Dernier message: 16/07/2008, 10h08
  2. Réponses: 9
    Dernier message: 15/07/2008, 10h09
  3. Réponses: 2
    Dernier message: 30/10/2007, 11h27
  4. Réponses: 6
    Dernier message: 26/07/2006, 17h36
  5. Deux sous formulaires dans Formulaire: Maj des données
    Par capitaine dans le forum Access
    Réponses: 4
    Dernier message: 24/05/2006, 13h09

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