Méthodes AGILES: une belle définition

Le coaching agile est une activité qui a le vent en poupe, mais quand on parle d’agilité, de quoi parle-t-on exactement?

Méthodes Agiles: une belle définition

Celle de Veronique Messager Rota, dans Gestion de projet : Vers les méthodes agiles :

« Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients »

Voilà qui est clair, précis et tout à fait fidèle aux 4 valeurs et 12 principes de l’Agile Manifesto, ce signal fort lancé en 2001 par 17 personnalités de l’industrie logicielle (Beck, Cockburn, Fowler, Jeffries, Marick, Schwaber, Sutherland …) en réponse à un malaise et aux insuffisances et difficultés liées aux méthodes de développement traditionnelles :

Agilité: une définition

Aujourd’hui le développement Agile transforme le business ; la France semble enfin s’en apercevoir, et l‘agilité :

L’agilité est la capacité d’une organisation à ravir ses Clients et ses Employés, tout en s’adaptant -à temps- aux changements de son environnement

(Grosjean, 2016)

pénètre toutes les couches de l’Entreprise:

Scrum est devenu incontestablement la méthode la plus populaire. Les rôles de Scrum Master et de Product Owner montent en puissance. C’est aussi la méthode Agile que je porte dans mes missions de Coaching Agile tant ce framework est pertinent pour initier le process agile de l’organisation, symbole d’une agilité qui ne peut fonctionner qu’en contexte. L’agilité modifie donc notre façon de concevoir des produits, et d’envisager un Projet Informatique (notamment en termes d’estimation, de planification et de suivi)… un choc culturel pour beaucoup de personnes, d’équipes ou d’organisations. Mais les Méthodes Agiles vont impacter également la notion de contrat et bouleversent surtout la façon d’exercer nos propres métiers…

Le jeu en vaut-il la chandelle ? Devenir une entreprise agile est-il une stratégie gagnante? Je réponds OUI, sans hésitation; les bénéfices sont en effet bien réels (comme le montre cette dernière étude ou ma propre capitalisation):

  • Visibilité
  • Vélocité
  • Adaptabilité et réactivité (dimensions clés du Time to market)
  • Réduction des risques
  • Qualité
  • Efficacité

Beaucoup chercheront à comparer les différentes méthodes Agiles (XP, SCRUM, DSDM, ASD, AUP …), c’est intéressant, certes… Mais, plus que de méthodes, je parlerais davantage de techniques, de pratiques à piocher ici ou là, dans XP, dans SCRUM, dans Lean, à essayer, à adapter, à intégrer sur un socle stabilisé mais souple propre à chaque organisation, en respectant quelques principes fondamentaux (discipline nécessaire):

  • Itératif (courtes)
  • Incrémental (avec en plus des livraisons de fonctionnalités opértationnelles à chaque itération)
  • Collaboratif
  • Timeboxing
  • Focus sur les Tests, à chaque itération
  • Feedback Client et Utilisateurs

Toutes ces pratiques intégrables et ajustables ainsi que la remise au premier plan du FACTEUR HUMAIN sont la vraie RICHESSE des Méthodes Agiles.

Des Méthodes qui véhiculent malheureusement encore pas mal d’idées reçues : du point de vue de la documentation, de la planification, de l’offshore, du CMMI ou même de l’Ergonomie et de l’Expérience Utilisateur

Coach agile reconnu, impliqué depuis environ 10 ans dans des transformations agile de grande envergure, je peux vous accompagner dans la mise en place de d’une agilité adaptée à votre organisation. N’hésitez pas à me contacter par mail à l’adresse suivante : jcgrosjean@gmail.com ou par téléphone au 06 20 98 58 40.

2 126 views

22 thoughts on “Méthodes AGILES: une belle définition

  1. Bob Sponge says:

    "Des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive"
    "Collaboration avec le client plutôt que la contractualisation des relations"

    J’aime beaucoup… c’est typiquement les bobards de commercial de SS2i!

    J’ai fait de l’extrême programming en 2002 dans mon ex SS2i, sur un projet interne.
    Le produit est devenu obsolète, et l’idée d’une évolution fut très vite rangée au placard compte tenu du coût initial, de l’investissement fourni par le client et surtout du manque de documentation.

    Aujourd’hui, Chef de projet MOA je rencontre toujours quelques charlots vantant les mérites des "méthodes modernes"… mon calcul est simple : sur du long terme on multiplie par 2,5 les coûts par rapport à une méthode classique, car en fait il faut repartir de zéro presque systématiquement (le turn-over est tel dans les SS2i que maintenir une équipe projet pendant 1 ans tient du miracle!).

    D’autre part, beaucoup de SS2i s’enorgueillissent de proposer du forfait Offshore, mais derrière il ne s’agit que d’applications type portail de service "génériques", en "prêt à porter".

    Le métier n’est connu que par le client et de lui seul, c’est une illusion de croire qu’un développeur indien ou roumain va comprendre la subtilité de ce dernier!!
    Surtout sans une expression de besoin ou un cahier des charges (complète et claire fournie par le client), et même là il faut compter avec le niveau de rédaction et de compréhension de l’anglais de chacun…

    Par expérience, j’ai pu tester les solutions Offshore… Le bilan sur des applications métiers, ça fait froid dans le dos!

    Bref, je le dis et réaffirme: la méthode Agile est une approche "pause café" et "au doigt mouillé" qui à part pour les start-up, sur le dépôt de bilan, n’a pas sa place dans le monde industriel.

  2. Une position quelque peu radicale mais des questions soulevées qui se révèlent tout à fait intéressantes.

    Preuve que certaines idées reçues ont la vie dure … c’est le cas pour la documentation. Agilité ne signifie pas absence de documentation mais une documentation au plus juste, appropriée par rapport au contexte et toujours synonyme de valeur.
    Un peu plus dans ce billet:
    http://www.qualitystreet.fr/?200...

    Le contexte offshore est un contexte particulier, qui nécessite une approche approfondie et une adaptation des pratiques Agiles.
    De récentes études tendent à montrer que les deux approches font plutôt bon ménage même si leur cumul nécessite encore plus de rigueur et de discipline…
    Un peu plus dans ce billet:
    http://www.qualitystreet.fr/?200...

    Pour le reste il serait intéressant de nous faire profiter d’une courte rétrospective de votre projet XP de 2002, quelles pratiques XP vous avez mis en oeuvre, dans quel contexte, qu’est ce qui n’a pas marché précisément, pourquoi avoir basculé sur ce mode, quel était le point de vue de l’équipe …la façon de communiquer ce projet, y a t- il accompagnement, étiez-vous dans une démarche de conception centrée utilisateur, avez-vous fait appel à un ergonome ? et j’ose à peine poser la question, y a t-il eu dans tout cela quelques éléments positifs ?
    D’autres projets alimentent-ils vos stats ?
    L’agilité a gagné en maturité depuis 2002 mais vous pourriez permettre à certains de ne pas tomber dans les mêmes travers.

    Visibilité, vélocité, réduction des risques, qualité sont des bénéfices bel et bien réels, dont chaque acteur peut observer les bienfaits qu’il soit chef de projet, analyste, développeur, ergonome, client ou utilisateur …
    Je n’ose imaginer que le développement itératif, un focus sur les pratiques de test et de qualité, un pilotage par les risques ne puissent vous être profitables au quotidien, en SSII ou ailleurs; ce sont des aspects à creuser !!
    J’irais même plus loin, dans une approche Kaizen (amélioration continue) voyons en quoi vos process actuels qui semblent être déjà satisfaisants peuvent s’améliorer ? Identifions les leviers sur lesquels s’appuyer, travaillons sur les points faibles en y testant, en glissant ici ou là, pourquoi pas, quelques pratiques agiles …

    Bref, gardons le meilleur, multiplions les pratiques Agiles, les sources d’inspiration (Scrum, XP, UP, Lean) et gardons l’Esprit Agile !

  3. Nous subissons en ce moment une méthode Agile de la part de notre prestataire. Sous prétexte de vouloir éviter "l’effet tunnel", on se spécifie rien. Résultat : on a recommencé 4 fois le boulot. Là, je suis fatigué de perdre mon temps à recetter des trucs pas finis : pour la prochaine itération, j’ai fait moi-même des spécifications ergos que j’ai envoyé au prestataire !
    A mon avis : avec ce type de méthode, on préfère employer une armée de développeurs débutants qui feront des trucs vites faits/mal faits, plutôt que d’engager un bon ergonome. C’est la vision "informaticienne" par excellence.

  4. Etre Agile ne signifie pas "ne pas spécifier" mais "specifier autrement" tout en privilègiant un produit qui marche (c’est à dire testé !) pour mesurer l’avancement du projet.

    Il serait là aussi interessant d’analyser en profondeur les causes de ces dysfonctionnements …dans un objectif d’amélioration continue. D’ailleurs, vous même avez déjà trouvé quelques remèdes.

    La collaboration efficace Client – Développement, le travail d’équipe, le feedback permanent et pas seulement en fin d’itération sont les vraies clés de la réussite. En lisant entre les lignes, ces éléments semblent faire défaut sur votre projet. Etes vous situés au même endroit ? Discutez-vous les user stories et des élements du backlog ? Faites-vous des scrums quotidiens ? Echangez vous régulièrement sur ce qui est produit ? Jouez-vous la "Transparence" ?…

    L’agilité vous aura permis de vous apercevoir rapidement (c’est le cas semble-t-il , c’est déjà ça) de ces problèmes et de les corriger au plus tôt !

    Je suis d’accord avec vous sur le fait que les besoins d’ergonomie et de prise en compte de l’experience Utilisateur sont aujourd’hui trés fort sur les projets Agiles. L’agilité offre un contexte favorable : encore faut-il l’exploiter !

    L’emploi d’une armée de développeurs débutants n’est quant à lui pas lié à des contextes Agiles / Non Agiles.
    L’agilité nécessite maîtrise et discipline… et je me contenterai de signaler que si des débutants arrivent sur le projet (ce qui est évidemment envisageable), ils monteront naturellement en compétences …

    Si vous souhaitez que nous en discutions davantage et que nous envisagions des solutions pour que vous ne "subissiez" plus ces méthodes Agiles, n’hésitez pas à me contacter.

  5. J’entends parlé de CMMI, de méthode Agile, de cycle de développement en V, inctémental, evolutionnaire… que de confusions !

    La définition de Veronique Messager Rota est débile et montre l’incompétence flagrante de nombreux managers en France.

    La méthode Agile ne s’adresse pas à tout type de projet. A l’embarqué certainement pas. A la TMA, certainement pas. Au développement web, oui mais sous certaines conditions.

    L’agilité nécessite une TRES GRANDE compétence dans l’identification et l’analyse des risques: Le point faible des chefs de projets en France. La gestion des risques est l’activité la plus difficile dans la gestion de projet.

    Vous ne comprennez pas ce que je vous dis? Alors n’utiliser la méthode Agile, vous allez planter votre projet et votre carriere. Faites appel à votre BON SENS !!!!

    Je ne suis pas contre la méthode Agile. Je suis même pour, je l’ai même pratiqué, mais sur le projet qui le permettais (1/100).

    Pour info: En soft embarqué(mobile platform): 5ppm sans agilité, 1 450 ppm avec agilité.
    En dev web (ajax, php5, flex,..): 1 ppm avec agilité

    Vous ne comprenez toujours pas? Ne faites plus de conseil en qualité.

  6. De très bons constats qui mériterait des exemples concrets. En tant que développeur ingénieur et bien que connaissant assez bien le domaine et les termes, il n’est pas toujours facile d’entrevoir la réalité dans les arguments avancés.

    PS: Sth je n’ai rien compris. Il n’y a peut être rien a comprendre aussi.

  7. Ne comprenant pas ce que signifiait "5ppm sans agilité, 1 450 ppm avec agilité" j’ai parcouru le WEB pour comprendre.

    Je n’ai trouvé que cela :
    (1) When uppercase, PPM refers to project portfolio management.
    (2) When lowercase, ppm refers to page per minute.

    Par ailleurs pour moi ppm signifie "partie par million". Bref comme je ne voudrai pas mourir ignorant, pourriez-vous me donner l’information. Merci d’avance.

    Enfin un commentaire : "Vous ne comprenez toujours pas? Ne faites plus de conseil en qualité." pourtant il me semblait que la bonne compréhension d’un discours par l’auditoire était un critère important de qualité… Dans ces conditions que vaut l’affirmation ci-dessus. Merci de m’éclairer aussi sur ce point.

  8. Le prosélytisme autour des méthodes agiles, tel que vous le pratiquez, représente une véritable régression dans le monde de l’informatique. Quoiqu’on en dise, c’est le retour à "j’analyse au fur et à mesure et j’avise" de grand papa.
    Vous perdez de vue que toute analyse n’est pas intégralement décomposable. Vous tirez des conclusions à partir de succès sur des cibles dont on ne peut juger de la teneur, ni de la pérennité…ni de la justesse du coût.
    Si les grattes-ciels étaient conçus avec ce genre de méthode, ils coûteraient très cher…et se casseraient tous la figure au premier coup de vent. Vous, vous parlez de maisons individuelles. Mais vous ne semblez pas en avoir conscience.
    Le méthodes agiles, c’est "l’analyse pour les nuls". Ca permet a une équipe faible d’obtenir un résultat empirique (et cher), ce qui est mieux que pas de résultat du tout. Mais ce n’est certainement pas un processus industriel permettant de bâtir des systèmes complexes.
    Et ça nous amène à leur principal paradoxe : elles attirent des compétences faibles, alors qu’il faut des compétences fortes pour en éviter les pièges.

  9. Les méthodes AGILE n’ont rien de magique… et c’est certainement une partie du problème. Mais les échecs avec les méthodes conventionnel sont aussi courante. Alors… comme certain le dise déjà.. le problème est peut-être pas la méthode.

    Ca me fait penser à cathédrale vs bazar et au modèle Open Source
    fr.wikipedia.org/wiki/La_…

    Ca me rappel aussi la théorie des constructals, qui est en train de rejoindre l’ingégnerie industrielle justement…
    fr.wikipedia.org/wiki/Th%…

    À vous de juger

  10. Llib Etag says:

    Quand quelqu’un s’énerve c’est qu’il a des doutes.

    Si Jason, sth et les autres ont des ‘arguments’ contre la mise en place de méthodes agiles, qu’ils les expliquent car dire c’est nul n’a aucune porté sur l’auditoire et ne fait en rien avancer le débat ou la discussion.

    Les méthodes agiles ne sont pas une fin en soi, mais si l’on considère les ressources humaines comme l’une des composantes primordiale pour la réalisation d’un projet, je dirais que les méthodes agiles mettent en valeurs les hommes plus que d’autres.

    Malheureusement pour Jason, les méthodes agiles sont étudiées pour être mise en place dans le secteur du batiment.
    Pas de chance, Harvard publie de temps à autre quelques rapports sur ce sujet, allé cherche bien et tu trouveras.

    D’autre part, il est important de rappeler que certaines SSII se disent agile alors qu’elle n’utilise pas réellement ces méthodes.
    Ceci créé une confusion et un profond désarroi quant aux clients ayant décider de faire confiance à ces entreprises.
    La conclusion a de tels pratiques est une baisse de confiance dans ces méthodes ainsi que l’émergence d’une horde de mauvaises langues pensant avoir travaillé de manière agile alors qu’il n’en est rien.

  11. Pingback: Les moms » Blog Archive » Come back !

  12. Pingback: Richard Coffre

  13. J’ai trouvé l’article assez intéressé mais les commentaires encore plus.

    Personnellement, je suis chef de projet en informatique depuis plus de 10.
    J’ai commencé, comme à peu prés tous les CP je pense, sans aucune méthologie de pilotage. Durant ces années je me suis donc contenté de « suivre » mes projets.
    Un jour, ma société m’a fait suivre une formation PMI (Project Management Institute) puis quelque mois plus tard j’ai eu l’occasion de découvrir sur le terrain CMMI.
    Depuis maintenant 4 ans, je pratique CMMI sur la plupart de mes projets.
    Je pense pouvoir dire aujourd’hui que je « pilote » mes projets, et non plus que je les « suis » comme auparavant.

    Je n’ai pas réellement d’expérience des méthodes Agile mais cela m’intéresse beaucoup de part mon expérience de CMMI et de part le fait que ces méthodes sont souvent opposées.

    Personnellement, je pense que toutes ces méthodes (CMMI, Agile, ITIL, etc.) sont très utiles mais que le plus important est de rester très pragmatique.
    Pourquoi vouloir les opposer ?
    Pourquoi vouloir prétendre telle ou telle méthode universelle ?

    Il me semblerait plus intéressant d’identifier des typologies de projet et de proposer une méthode applicable pour chaque typologie plutôt que de vouloir définir des méthodes universelles.
    Bref, se concentrer sur le projet (qui reste le but ultime) plus que sur la méthode (ce qui correspond assez bien au 1er précepte du manifeste Agile il me semble)

    Comme il a été dit précédemment, je ne vois comment on peut prétendre qu’une méthode peut fonctionner à la fois pour des projets de développement de 100 jours, de 1000 jours, de 10000 jours, des projets de TMA, des projets d’informatique embarquée, de développement web, etc.

    Bref, aujourd’hui, je suis plus à la recherche du retour sur expérience de chefs de projet ayant pu appliquer (concrètement et réellement) l’une ou l’autre de ces méthodes afin d’en faire une synthèse plus que d’une méthode miracle.

  14. Pingback: Philippe MARTY

  15. Je me permet de rappeler que tout développement doit tenir compte de l’architecture d’entreprise existante, une étude de faisabilité, une étude de marché, des évaluations et preuve de concept de progiciel (ou composantes) à intégrer et d’une architecture d’information solide.

    C’est souvent ce qui manque au départ d’un projet de développement ! d’où les conséquences que l’on connait.

  16. @sylvain, hélas il arrive souvent que l’architecture d’entreprise puisse être vieillissante, et donc plus du tout adaptée ni aux réalités du marché, ni aux besoins d’évolutions soutenues, imposés par Internet par exemple.

    Là où « Agile » est intéressant, c’est de pouvoir repartir sur des bases complètement nouvelles « assez facilement » comparé à des méthodes classiques.

    il faut tout de même noter, que seule une direction d’entreprise est en mesure de soutenir et de rendre viable de telles approches. Les charges finales restent importantes. Observations : gros gros bénéfices pour les utilisateurs (clients), l’innovation, et les phases de recette ;-)

    Ces méthodes ont la particularité de favoriser le travaille en équipe pluridisciplinaire, ce qui manque cruellement dans beaucoup d’entreprise, encore organisées en silot. C’est un vrai vecteur pour la conduite du changement en organisation.

    Jerome.

  17. Bonjour à tous,

    J’ai lu avec attention les posts précédents, et j’avoue que j’ai l’impression de vivre le grand débat JAVA contre .NET, microsoft contre LINUX.
    Je pense qu’il faut faire preuve de bonne intelligence dans l’utilisation de méthode, je suis Directeur de projet dans un grand groupe, et par expérience sur des gros projets, la méthode agile ne permet pas une maîtrise des coûts, clairement.
    En revanche, il existe depuis la nuit des temps plusieurs méthodes pour des projets, le cycle en V, le Cycle itératif (qui ressemble étrangement à la méthode Agile), et quelque soit la méthode, les documentations sont les mêmes, alors maintenant à chacun d’être intelligent pour adapter les volumes de documentation ou rythme du projet et à sa complexité.
    Je pense surtout qu’on essaie de trouver des méthodes pour des non informaticien, je m’explique depuis 15 ans maintenant, je me rend compte que les profils en informatique sont de moins en moins pointus, on assiste plus a du bricolage qu’a de la vraie programmtion rigoureuse, l’époque ou on programmait en pur C, il fallait être de très bon niveau et extrêmement rigoureux. Aujourd’hui on assiste à une mutation des développeurs qui n’ont plus qu’à faire du drag and drop pour développer alors là oui ça peut-être agile, mais j’aimerais qu’on s’arrête sur les performances de ces applications, zéro …

    Cdt

  18. Pingback: Gildas NOEL

  19. Pingback: yann

  20. Pingback: La vie des intégrateurs, chapitre IV : Les specs ? Quels specs ? | Les intégristes

Comments are closed.