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

ALM Discussion :

Comment l’Agile s’est détourné de son chemin et comment corriger cela


Sujet :

ALM

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    juillet 2013
    Messages
    2 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 473
    Points : 78 485
    Points
    78 485
    Billets dans le blog
    2
    Par défaut Comment l’Agile s’est détourné de son chemin et comment corriger cela
    Comment l’Agile s’est détourné de son chemin et comment corriger cela
    Explique l’un des auteurs du Manifeste Agile

    Andy Hunt, l’un des 17 co-auteurs du Manifeste Agile en 2001 s’est indigné de la manière dont le concept Agile s’est détourné du droit chemin et compte corriger cela par une nouvelle méthode. Sa nouvelle méthode résume un ensemble de concepts qui pourraient permettre de « régler les problèmes inhérents à l'adoption et l'évolution de l'Agile et aider à faire avancer l'industrie », a-t-il dit.

    Comment l’Agile s’est-il écarté de la vision initiale ? C’est ce qu’Andy explique dans un premier temps. Au début, l’Agile « a fourni un sursaut d'énergie, espoir d'une meilleure façon de faire les choses, de créer des logiciels et de faire mieux travailler le monde. Ce fut un tournant décisif », explique-t-il pour commencer. Mais près de 15 ans plus tard, il est devenu plus un slogan qu’une méthode et a été dépourvu de tout son sens. « Et le pire de tout, les méthodes agiles elles-mêmes ne sont pas agiles », a-t-il écrit dans un billet de blog.

    Il a décrié le fait que les gens appliquent les pratiques agiles en demi-teinte en étant figé à des règles rigides plutôt que de garder à l’esprit l’idée maitresse de l’Agile qui est d’ « examiner et s’adapter », pour pouvoir suivre le changement.

    « La base d'une approche agile est d'embrasser le changement ; d'être au courant des changements apportés au produit en cours de développement, des besoins et des souhaits des utilisateurs, de l'environnement, la concurrence, le marché, la technologie ; tous ces éléments peuvent être des fontaines volatiles de changement », a-t-il rappelé. « Pour embrasser le flot de changements, les méthodes agiles nous conseillent d'examiner et s’adapter. Autrement dit, comprendre ce qui a changé et s'y adapter en changeant nos méthodes, le refactoring de notre code, en collaboration avec nos clients, et ainsi de suite », ajoute Andy Hunt.

    Le cofondateur du Manifeste Agile estime que suivre des règles rigides limite la performance des équipes à celle de novices. Et c’est dans cette situation que les équipes se sont retrouvées, une situation qu’il qualifie d’ « ornière de béton ». Pour Andy, l’Agile c’est aussi la possibilité d’introduire de nouvelles pratiques, de faire évoluer les pratiques actuelles pour mieux répondre aux défis à relever. Et malheureusement, les méthodes agiles qui permettent de faire face au changement sont elles-mêmes restées inchangées depuis plus d’une décennie. Autrement dit, elles ne sont pas elles-mêmes agiles.

    Il reconnaît que les plaintes de plus d’une personne contre le mouvement agile ne sont pas tout à fait non fondées, mais promet que les choses vont changer. Pour cela, il propose une nouvelle méthode, une collection d’idées résumées sous un nom, une marque qui pourra accrocher les gens. Il l’appelle la méthode GROWS.

    « GROWS est un acronyme, pour Growing Real-World Oriented Working Systems. C'est une idée sur laquelle Jared Richardson et moi (Andy Hunt) avons travaillé », explique Andy.

    Par « Growing », il explique que la croissance vient avec le changement. Alors les équipes agiles devraient être en mesure d’examiner et s’adapter à ce changement. Mais l’adaptation au changement doit être « Real-World Oriented », c’est-à-dire basée sur les faits du monde réel. Il estime que « nous devons fonder nos décisions sur des preuves et la direction réelle: la rétroaction du monde réel, dans des conditions réelles ». Selon lui, « tout le reste est juste une combinaison malheureuse d'un fantasme et d'un vœu pieux ».

    Cela devrait enfin conduire à des « Working Systems », ou encore des systèmes qui fonctionnent. Andy explique que le livrable ultime de la démarche agile – le logiciel – doit bien fonctionner, mais pas au détriment des autres composantes du système. Il fait valoir que « tout ce que nous tentons ici doit marcher pour l'ensemble du système, et pas seulement pour les développeurs, et pas seulement pour les gestionnaires, pas seulement pour les testeurs, et pas seulement pour les utilisateurs, et pas seulement pour les sponsors ». Il clarifie encore qu’il n'y a pas de « nous » contre « eux » dans la méthode GROWS, mais seulement une équipe unie, seulement « nous ».

    Andy Hunt a promis de développer dans les jours à venir encore plus les idées maitresses de la nouvelle méthode, et encourage tous ceux qui trouvent que c’est quelque chose d’intéressant, à les rejoindre sur growsmethod.com et s’inscrire à leur liste de diffusion.

    S’inscrire sur growsmethod.com

    Source : Billet de blog d’Andy Hunt

    Et vous ?

    Que pensez-vous de son opinion sur les déviations du concept Agile ?

    Quel est votre avis sur la méthode GROWS ? La trouvez-vous intéressante ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    520
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 520
    Points : 1 644
    Points
    1 644
    Par défaut
    Personnellement,
    j'ai toujours pensé que pour bien travailler en agile, le développeur doit connaitre le métier et développer un logiciel comme si c'était le sien.
    Je n'ai pour l'instant jamais connus d'échec avec cette méthode.
    Le développement en binôme m'a beaucoup apporté lorsque j'ai débuté. Je n'étais pas mauvais, mais j'aime apprendre des autres ou transmettre mes connaissances, dans notre métier on ne peut pas tout savoir sur tout.

    Cela dit on se heurte à plusieurs soucis :
    - Certaines entreprises veulent cacher le métier au DEV pour qu'il ne parte pas voir la concurrence
    - Dans une équipe certains n'aiment pas l'agile ( souvent des gens qui fonctionnent à la tache , une Jira --> un dev) Et ils ne sont pas incompétent pour autant.
    - Je documente mes codes en C#/C++ , mais le métier et le service technique ne suivent pas pour faire les docs utilisateurs ( il y a un service dédié)
    - Certains services vitaux ne sont pas adaptés à l'agile ( décision)
    - Le salaire doit suivre car on peut faire beaucoup d'heures supp
    - y'a aussi le soucis du faux agile avec 35 intermédiaires


    J'aime l'agile car ça me rends heureux de proposer des solutions et d'avoir les commentaires du métier, cette méthode tire ma qualité de développement vers le haut et me procure une connaissance de mon métier qui me permet de mieux anticiper les évolutions futures.

  3. #3
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 476
    Points : 4 728
    Points
    4 728
    Billets dans le blog
    6
    Par défaut
    @dfiad77pro il est clair que si chez ton client c'est un stagiaire qui te transmet les specs qui est lui en dessous d'un chef de projet lui même en dessous d'un chef de secteur lui même sous la direction ....
    de temps à autre j'ai ce genre de merde et on est obligé de remonter leur hiérarchie et discuter avec la direction pour avoir enfin des specs qui ne change pas en permanence(même si on y passe du temps)
    Rien, je n'ai plus rien de pertinent à ajouter

  4. #4
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    520
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 520
    Points : 1 644
    Points
    1 644
    Par défaut
    Citation Envoyé par TiranusKBX Voir le message
    @dfiad77pro il est clair que si chez ton client c'est un stagiaire qui te transmet les specs qui est lui en dessous d'un chef de projet lui même en dessous d'un chef de secteur lui même sous la direction ....
    de temps à autre j'ai ce genre de merde et on est obligé de remonter leur hiérarchie et discuter avec la direction pour avoir enfin des specs qui ne change pas en permanence(même si on y passe du temps)
    J'ai la chance d'être en interne .

    j'ai connu ce genre de situations , qui est très courante...
    Je peut le comprendre sur des modules critiques.
    Ce qui me gène c'est que ce genre de process est souvent mis en place aussi pour des nouveaux logiciels et cela freine l’innovation( surtout que le dev est souvent seul et il n'y a même pas d'architecte).


    Après le facteur humain fait que la remonté en hiérarchie crée des tensions...

    Ps j'ai mis un +1 pour la signature

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 614
    Points : 31 089
    Points
    31 089
    Par défaut
    Le truc, c'est qu'agile, ce n'est pas une méthode, c'est un état d'esprit. C'est être capable de se dire "j'ai fait fausse route, je corrige le tir". Peu importe que la fausse route vienne d'une erreur de spec, de méthode, de codage, ou d'un changement d'environnement, technique ou fonctionnel. J'ai fait fausse route, c'est pas grave, je m'adapte. J'ai fait réussir 2 projets importants en disant "oups, ce que j'ai fait n'est pas optimal, il faut que je reprenne autrement".

    A partir du moment ou celui qui reconnait qu'il a fait fausse route se fait flinguer, aucun agile n'est possible. Même en scrum. Agile, c’est quasiment une question de politique.
    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.

  6. #6
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    520
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 520
    Points : 1 644
    Points
    1 644
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Le truc, c'est qu'agile, ce n'est pas une méthode, c'est un état d'esprit. C'est être capable de se dire "j'ai fait fausse route, je corrige le tir". Peu importe que la fausse route vienne d'une erreur de spec, de méthode, de codage, ou d'un changement d'environnement, technique ou fonctionnel. J'ai fait fausse route, c'est pas grave, je m'adapte. J'ai fait réussir 2 projets importants en disant "oups, ce que j'ai fait n'est pas optimal, il faut que je reprenne autrement".

    A partir du moment ou celui qui reconnait qu'il a fait fausse route se fait flinguer, aucun agile n'est possible. Même en scrum. Agile, c’est quasiment une question de politique.
    Oui sans cet État d'esprit c'est pratiquement impossible d'être agile. Cela dit ça amène un petit stress quand le métier change souvent d'avis surtout sur des choses dont on avait dit qu'elle étaient mal spécifiées.

    De plus on code souvent vite et on est amené à revoir son code, même hors périmètre.

    Moi j'aime bien, je m’ennuie pas avec cette méthode.

  7. #7
    Membre extrêmement actif
    Avatar de Aurelien Plazzotta
    Homme Profil pro
    .
    Inscrit en
    juillet 2006
    Messages
    312
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : juillet 2006
    Messages : 312
    Points : 920
    Points
    920
    Par défaut
    De mon point de vue, ce n'est pas la rédaction ni le contenu du manifeste Agile qui pose des problèmes mais la manière de l'aborder, ou de ne pas l'aborder dans une organisation. L'adoption des pratiques Agile exigent l'implication de la direction technique voire plus, et c'est ça qui coince. Tant que l'industrie du génie logiciel restera perçue comme un centre de coûts et non un centre de profit, les budgets seront toujours serrés et la reconnaissance technique et salariale au rabais.

    C'est selon moi le facteur humain et l'aspect financier et notamment commercial qui a nettement discréditer le concept Agile en entreprise en France. Il a été survendu par les vendeurs (ingénieurs commerciaux comme on dit ^^) en SSII qui a permis de gonfler les factures en délégation de main d'oeuvre aux clients finaux.
    Et après on dit : "L'Agilité ça marche pas faut le remplacer."

    Je suis personnellement contre l'abandon du manifeste Agile. La méthode GROW va surfer sur la vague et se vendre comme du petit pain durant un temps. Cela me rappelle le Craftmanship pour remplacer l'Agilité il y a 2 ans.
    Je porte l'épée brisée, et sépare les vrais rois des tyrans. Qui suis-je ?

  8. #8
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 248
    Points
    2 248
    Par défaut
    On peut tourner longtemps autour du pot, mais les principes agiles font que ça ne peut pas fonctionner sans l'implication de gens qui ne sont pas des informaticiens et ne comprennent pas forcément les enjeux d'n telle méthode. Il faut que la maitrise d'ouvrage s'implique (le service auquel se destine l'application ou la partie commerciale/marketing), il faut que la direction générale soit prête à y mettre les moyens, etc. Les situations où on n'a pas de retour de la maitrise d'ouvrage, ou s'il y a des changements mais que les délais et le budget restent les mêmes, et les méthodes agiles virent au cauchemar.

    En d'autres termes : l'essentiel de ce qui permet la réussite d'un process agile est hors des mains des informaticiens.

  9. #9
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 145
    Points
    2 145
    Par défaut
    Citation Envoyé par dfiad77pro Voir le message
    - Le salaire doit suivre car on peut faire beaucoup d'heures supp
    Je dirais même qu'en mode agile, on ne devrait pas en faire du tout.
    Citation Envoyé par 8ème principe de l'Agile Manifesto
    Les processus Agiles encouragent un rythme de développement
    soutenable. Ensemble, les commanditaires, les développeurs
    et les utilisateurs devraient être capables de maintenir
    indéfiniment un rythme constant.
    Citation Envoyé par 5ème pratique de l'XP
    Rythme soutenable
    L'équipe ne fait pas d'heures supplémentaires. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.

  10. #10
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    520
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 520
    Points : 1 644
    Points
    1 644
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Je dirais même qu'en mode agile, on ne devrait pas en faire du tout.

    Pour moi les heures supp ne se manifestent pas souvent en temps de DEV,
    mais en temps de réunion avec le métier ( qui bosse en horaires décalés) et en voyage ( Paris, Espagne , Italie...)

    je ne me plains pas car les entreprises qui font voyager les devs sont rares et le salaire est tient en compte cela

Discussions similaires

  1. Réponses: 15
    Dernier message: 24/12/2012, 15h49
  2. [Reflexion] Comment récupérer une class via son chemin python
    Par anthyme dans le forum Général Python
    Réponses: 2
    Dernier message: 27/12/2007, 13h16
  3. Réponses: 3
    Dernier message: 27/11/2007, 07h40
  4. Réponses: 11
    Dernier message: 23/08/2007, 18h07
  5. Réponses: 19
    Dernier message: 02/10/2006, 17h19

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