Comment l'Agile s'est détourné de son chemin et comment corriger cela
Explique l'un des auteurs du Manifeste Agile

Le , par Michael Guilloux, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de dfiad77pro dfiad77pro - Membre expérimenté https://www.developpez.com
le 08/05/2015 à 20:39
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.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 08/05/2015 à 22:39
@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)
Avatar de dfiad77pro dfiad77pro - Membre expérimenté https://www.developpez.com
le 08/05/2015 à 23:03
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
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 09/05/2015 à 9:10
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.
Avatar de dfiad77pro dfiad77pro - Membre expérimenté https://www.developpez.com
le 09/05/2015 à 11:28
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.
Avatar de Aurelien Plazzotta Aurelien Plazzotta - Membre éprouvé https://www.developpez.com
le 10/05/2015 à 12:27
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.
Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 11/05/2015 à 10:22
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.
Avatar de Laurent 1973 Laurent 1973 - Membre chevronné https://www.developpez.com
le 11/05/2015 à 14:41
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.
Avatar de dfiad77pro dfiad77pro - Membre expérimenté https://www.developpez.com
le 11/05/2015 à 15:20
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
Contacter le responsable de la rubrique Accueil