Publié par
Il y a 10 années · 5 minutes · Agile, Mot du président

Agilité : Petites vérités entre amis

Vous trouverez ci dessous, un petit recueil de pensées, métaphores, vrais chiffres et idées reçues à destination de ceux, qui en les lisant (ou les relisant), percevrons, peut être, la philosophie des méthodes agiles.

Je ne revendique qu’une partie de la paternité de ce billet et remercie pour le reste, l’ensemble des auteurs dont j’ai utilisé les citations.


Commençons par un peu d’humour

  • Dans l’économie actuelle, vouloir élaborer des spécifications détaillées exhaustives dans le cadre d’un projet classique revient à utiliser un canon de la guerre de 1870, charger un obus, ajuster le tir le plus précisément possible et faire feu ! Mais malheureusement … sur une cible mouvante qui changera d’endroit alors que le tir lui ne peut plus être corrigé. Mener un projet agile, c’est tirer d’abord (privilégier l’action), mais avec un missile à tête chercheuse qui changera de direction (se configurer en mode adaptatif) car tout le monde est conscient que la cible va bouger (intégrer le changement).
  • Au même titre que le boursicoteur malheureux rachètera des titres d’une société qu’il a déjà en portefeuille après une baisse brutale, pour réduire son prix moyen d’achat, une entreprise menant un projet au forfait en difficulté devra souvent continuer à injecter de l’argent pour sauver l’investissement initial pour finalement ne pas gagner grand-chose (voire tout perdre c’est-à-dire arrêter le projet).
  • Le concept de « Two Pizzas » team est la seule manière de déterminer la taille maximale d’une équipe Agile : si pour la nourrir, il faut plus de 2 pizzas, c’est qu’elle doit être divisée en plusieurs équipes.
  • Charles Darwin disait « Ce ne sont pas les espèces les plus fortes qui survivent, ni les plus intelligentes mais celles qui s’adaptent au changement« .

Soyons plus sérieux

  • Classique vs Agile = Suivre un plan vs Répondre au changement.
  • Classique vs Agile = Prédictif vs Adaptatif.
  • Classique vs Agile = Négociations contractuelles vs Collaboration client/fournisseur.
  • Classique vs Agile = Rédaction d’une documentation exhaustive souvent inutile vs Communication privilégiée.

Quelques idées reçues

RAD veut dire Agile

Faux !
L’Agilité inclue, entre autres mais pas uniquement, la notion d’excellence technique, la priorité donnée aux fonctionnalités porteuses de la plus grande valeur ajoutée métier, la simplicité dans les choix techniques, la motivation des équipes …

Un projet agile ne peut pas être mené au forfait

Faux !
La notion de forfait n’est pas antinomique du concept de projet Agile puisque les itérations sont de longueur déterminée. C’est l’arbitrage des fonctionnalités à inclure dans une itération donnée qui est l’instrument de la négociation et non pas l’enveloppe budgétaire.

Le paradigme des projets au forfait repose sur le besoin de réduire les risques ce qui semble impossible dans le cadre de projets Agiles

Faux !
Les méthodes Agiles reposent sur le principe du feedback utilisateur permanent et donc de la suppression de l’effet tunnel, générateur des plus grands risques pour les projets informatique.

Devriez vous être Agile ?

Si vous répondez non à l’une des trois questions suivantes, vous devriez vous intéresser aux méthodes agiles.
Dans le cadre du dernier projet informatique que vous avez commandé et qui vous a été livré,

  • Avez-vous eu ce dont vous aviez besoin ?
  • L’avez-vous eu dans les délais prévus ?
  • Le coût total est-il raisonnable et conforme à vos attentes ?

Ils sont Agiles

L’une de ces sociétés est elle un symbole de réussite pour vous ? Microsoft, Oracle, Siemens, IBM, Philips, Yahoo, Xerox, Nokia, SAP, Google ?

Sachez que toutes utilisent des méthodes agiles pour mener leurs projets informatiques.

Le meilleur exemple d’entreprise agile est Toyota. Elle applique le principe du Lean Manufacturing (action, contrôle et adaptation, suppression des gaspillages) depuis les années 50 avec succès et est devenue en 2007 le premier constructeur mondial en CA. C’est aussi le constructeur automobile le plus rentable au monde.

Les faits

Dans un projet informatique mené de manière traditionnel, 45% des fonctionnalités du logiciel développé ne sont jamais utilisées, 19% ne le se sont que très rarement.

Dans le cadre d’une enquête menée par le Standish Group, il s’avère que 53% des projets menés de manière classique sont en difficulté, et 18% sont en échec.

Selon cette même enquête,les principaux facteurs d’échec des projet informatiques sont, par ordre d’importance :

  1. Manque d’implication des utilisateurs finaux : 12,8 %
  2. Spécifications incomplètes : 12,3 %
  3. Changement de spécifications en cours de projet : 11,8 %
  4. Faible implication du Management : 7,5 %
  5. Manque de compétences des équipes : 7%
  6. Manque de ressources : 6,4 %
  7. Attentes irréalistes : 5,9 %
  8. Objectifs flous : 5.3 %
  9. Planning intenable : 4,3 %
  10. Introduction de nouvelles technologies : 3,7%
  11. Autres : 23 %

Les statistiques sur les chances de réussite des projets :

Taille du projet Equipe projet Durée du projet (mois) Pourcentage de réussite
Moins de $750 K 6 6 55%
De $750K à $1,5M 12 9 33%
De $1,5M à $3M 25 12 25%
De $3M à $6M 40 18 15%
De $6M à $10M Plus de 250 Plus de 24 mois 8%
Au dessus de $10M Plus de 500 Plus de 36 mois 0%

10 réflexions au sujet de « Agilité : Petites vérités entre amis »

  1. Publié par Olivier, Il y a 10 années

    Il va quand meme falloire que je me plonge plus profondement dans ce type de methodes dites « agiles » parce que à lire ce que j’ai lu d’un oeil distrait (et pas uniquement ce billet), j’ai l’impression que cette approche agile n’est ni plus ni moins que la celebre methode « A l’arrache » revetue du costard qui fait joli des societes prestataires de service !

    C’est sans doute un peu abrupte comme maniere de formuler mon idee, mais je ne pense pas qu’on soit si loin d’une tentative pour presenter de belle maniere les actions entreprises pour naviguer dans ce brouillard qui a toujours enrobé chaque projet informatique. Bref, ne serait-ce pas du marketing autour de la methode « A l’arrache » qui est, elle, employée sur 100% des projets informatiques, tabou de l’industrie des projet au forfait notamment ?

  2. Publié par arn, Il y a 10 années

    Merci de donner vos sources afin d’assoir votre crédibilité et de satisfaire notre curiosité. Quelle est cette étude du Standish Group ? Quelle année ? Donner un lien serait parfait, ouvert et parfaitement agile.
    D’où « sort » ces stats sur la réussite d’un projet ? Méthode de calcul ou lien ?

  3. Publié par Alain, Il y a 10 années

    Vous citez le standish group et Toyota. On pourrait utiliser rigoureusement les mêmes exemples en expliquant que le succès ou l’échec d’un projet proviennent non pas des méthodes agiles mais de l’adoption d’une démarche qualité basée sur l’amélioration des processus. Par exemple on justifie l’intéret d’adopter une démarche de type qualité/CMMI avec EXACTEMENT ces mêmes chiffres et exactement ce type d’exemple (Toyota et la qualité ça date de combien ?)!

    Attention, ce n’est pas parce qu’on juxtapose deux faits (méthode agile et succès d’un projet) que l’un est la cause du second !!!

    Pour ma part, je n’ai rien contre les méthodes agiles selon le contexte mais je pense qu’une approche par l’amélioration des processus est bcp plus *consistante* (pas contradictoire d’une démarche agile) et surtout bien plus porteuse de dynamique d’amélioration progressive et continue de la maturité informatique d’une entreprise.

  4. Publié par Luc Legardeur, Il y a 10 années

    Bonsoir,

    Ci dessous les réponses à vos commentaires (pour lesquels je tiens sincèrement à vous remercier)

    Olivier,

    Non ce n’est pas une méthode « A l’arrache » mais bien une approche ou pour être plus précis, un paradigme de conduite de projet basé sur le bon sens, le pragmatisme et la création de valeur. Si je peux me permettre une suggestion sincèrement amicale : écartez de votre cheminement intellectuel tout idée préconçue et tout jugement hâtif, soyez positif, naïf même peut être et accordez le bénéfice du doute à ceux qui s’attèlent à tenter de faire différemment pour faire mieux , ils ont au moins le mérite de tenter l’expérience.

    Arn,

    Je suis sûr que vous maîtrisez parfaitement un outil appelé « Google » . Il suffit de taper « Standish Group » et vous trouverez de vous même les informations que vous me demandez. Allez…, je vous aide, http://www.standishgroup.com/sample_research/chaos_1994_1.php. Les rapports plus récents mais qui, sur le fond, ne nous apprennent rien de nouveau, sont payants…

    Alain,

    Vous avez raison en partie. Ce n’est pas parce qu’on juxtapose deux faits que l’un est la cause du deuxième.
    Pour alimentet la réflexion, CMMI n’a pas le monopole de la qualité (comme le PS n’avait pas en 1986, le monopole du coeur – excusez moi, je ne pouvais m’en empêcher). D’ailleurs pour alimenter le débat, si cela vous intéresse, certains, et ils sont de plus en plus nombreux, pensent à tirer parti du meilleur des deux mondes ( http://www.agilecmmi.com ). Ces deux mondes sont complémentaires et non pas antinomiques comme vous semblez le penser.
    Quant à savoir laquelle des méthodes est la plus porteuse de consistence, je vous laisse l’entière paternité de votre jugement. Je ma garderai bien de commenter par manque de compétences sur…CMMI.

  5. Publié par Arn, Il y a 10 années

    C’est bien ce que je pensais, une étude de 1994, mais je voulais vous le voir ecrire. A réactualiser donc, car ces fameux rapport payant mais récent, il faudrait ne pas trop présuposer de leur contenu sans les lire.
    D’autre part, vous n’indiquez toujours pas votre méthode de calcul pour le tableau statistique.

    Enfin, aprés avoir pratiqué les méthodes dites « agiles » dans les pays anglo-saxon avec les societés de conseils compétente pour nous aider, j’en retire une profonde déception. Agile est un adjectif que les méthode agiles ne s’appliquent justement pas. J’ai trouvé ces méthodes beaucoup trop puristes et trés sur de leur propres fondements, sans cette remise en cause nécessaire à l’agilité justement.

    D’autre part, mais cela a été dit, agile est parfois-souvent synonyme de laisser faire. Aucun contrôle sur l’architecture logicielle qui emergerait des refactoring succssif, une sorte de Darwinisme du SI, sauf que nous n’avons pas des millions d’années hommes dans les entreprises.

    Enfin, je n’ai jamais pu comprendre ni en tant que developpeur, ni en tant que manager, l’absolue nécéssité de travailler tout le temps a deux sur un même poste. C’est une insulte au bon sens et un prodigieux gachi. Il faut bien noté que nos consultants et les developpeurs de l’équipe ont lourdement insisté pour que cette pratique soit systématique (Cf le point précédant sur le purisme). Il n’a pas été possible d’instaurer de « pair programming » de temps a autre seulement.

    Quant aux « retrospectives », réunion mensuelle obligatoire, c’est une vaste fumisterie, sorte de grand raout de l’équipe avec force manipulation phycologique et grosse pertes de temps.

    voila, désolé pour ce « feedback » plutot négatif.

  6. Publié par Arn, Il y a 10 années

    Remarque : ca ne remets pas en cause votre constat global que je partage.
    C’est juste que « agile », « extreme programming » et compagnie ne sont pas des solutions a ces problèmes constatés.

  7. Publié par Cecil, Il y a 10 années

    Bonjour,

    Pour ceux qui veulent s’interesser de plus près à des applications pratiques de méthodes agiles je vous conseille vivement « Scrum and XP from the trenches » de Henrik Kniberg.

    Il s’agit d’un e-book telechargeable gratuitement.

    J’en parle ici ( http://techiteasy.org/2007/08/26/scrum-and-xp-from-the-trenches/ ) et là ( http://ceciiil.wordpress.com/2007/08/28/scrum-agile-xp-and-the-real-life/ ).

    Et bien naturellement le manifeste Getting Real de 37Signals : http://gettingreal.37signals.com/

  8. Publié par Jean-Pierre Vickoff, Il y a 10 années

    — Evolution du courant de pensée Agile —
    En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif et incrémental.

    En 1991, James Martin (RAD), s’appuyant sur cette vision d’une évolution continue, proposa une méthode de développement rapide d’application. Sa structure, base des approches actuelles, déterminait le phasage essentiel et initiait un principe adaptatif fondé sur la validation permanente des utilisateurs.

    À partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD2 publié par le Gartner Group, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisirent des compléments tels que :

    – la spécialisation des rôles,
    – l’instrumentation des communications,
    – l’organisation des types de réunions,
    – le groupe de facilitation et de rapport,
    – les « raccourcis de modélisation,
    – l’architecture de réalisation
    – l’imbrication des itérations,
    – la formalisation de processus légers.

    Dans la seconde moitié des années quatre-vingt-dix, une vague d’une dizaine de méthodes (dont eXtrême Programming et Scrum sont les principales représentantes) poussa à l’extrême certaines pratiques de qualité de la construction applicative ainsi que les techniques adaptatives d’estimation, de planification et de pilotage de projet.

    Il aura fallu près de vingt ans au mouvement Agile, parallèlement à la pression de la mondialisation, pour bousculer vraiment la conduite de projet classique. Désormais, le futur de l’agilité méthodologique se trouve certainement, d’une part, dans l’instrumentation et la personnalisation « à la carte » des pratiques essentielles pour un contexte spécifique et, d’autre part, dans son élargissement à tous les aspects de l’Agilité organisationnelle.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *