Ce qui devait être un blogmark devient un article, vu que le commentaire est un poil trop long. Ceci est donc un commentaire à propos de
L'Agile est mort de Sébastien Douche.
Si je diffuse un logiciel avec une licence Libre, par exemple BSD, mais que je ne propose pas de bugtracker, de liste de diffusion, ou que je refuse toute contribution extérieure, ou que j'obfusque mon code, ou que j'envoie sur les roses les demandes d'utilisateurs, je fais du Logiciel Libre (ma licence le prouve) sur papier. Dans les faits, ce n'est qu'un erstatz, je ne respecte pas la philosophie du Logiciel Libre.
Si si, c'est du logiciel libre sur le papier et dans la philosophie. Le logiciel libre ça n'est pas ouvrir son processus de développement, ça n'est pas répondre inlassablement aux questions stupides des n00bz : ça c'est du logiciel bazaaresque (au sens ESRien du terme), et ça n'a rien à voir avec le free software.
Le développement est une histoire de développeurs avant tout. Vous devez faire confiance aux gens, les respectez dans leur capacité à produire, dans leur jugement. Cet accent me semble t'il est absent des approches précédentes comme la cascade ou RUP. Ces dernières sont plutôt accés processus, avec des dizaines de procédures et de la documentation à profusion, le développeur n'étant qu'un rouage du système. CMMi est un bon exemple de cette vision : la documentation officielle parle sempiternellement d'organisation et de processus. Et pire, il faut être certifié CMMi pour savoir lire une doc CMMi (cherchez l'erreur) tellement elle est inbitable et truffée d'une terminologie incompréhensible.
On doit faire confiance au développeur, dans sa capacité à produire, à juger, tout ça tout ça, mais on le préjuge incapable d'acquérir le vocabulaire de base et le formalisme de CMMi ? Parce que le métier du client que l'agiliste devra maîtriser sera forcément moins "truffée de terminologie" que CMMi ?
L'agilité apporte beaucoup de solutions intéressantes : le TDD, les tests, la revue par les pairs, l'intégration continue ou le refactoring par exemple.
Les tests : euh... le contrôle qualité est la pierre angulaire de toute discipline qui vise à produire. TDD : on parle de "redécouverte" du TDD par Beck, c'est parce qu'on est poli. Revue par pair : de Dijkstra 1961 à Constantine 1995, nnss. Refactoring : popularisé par Fowler avant que l'agile n'ait son heure de gloire. Intégration continue : Booch 1993 (ou avant ?). Enfin bref, tout ça a été remis dans la lumière par les agilistes, mais en aucun cas ce ne sont des pratiques apportées par l'Agile. D'ailleurs le pair programming est encore plus populaire dans le monde de la Rache que dans le monde de l'Agile.
Je suis malgré tout un vieux Geek, j'achetais pas mal de livres sur la programmation voici 20 ans et je n'ai aucun souvenir des livres (en France en tout cas !) qui ressemblait peu ou prou à l'agilité, on apprenait plutôt en copiant le code des maitres (en crackant des logiciels, en écoutant les démo-makers ou en bavardant sur les BBS).
Effectivement, clash de culture, on est très loin des K&R, TAOCP, Wizard Book, Dragon Book et MMM.
Des pratiques quasi inconnues voici 10 ans sont maintenant considérées comme des pratiques indispensables (vous faisiez beaucoup de tests unitaires en 2000 ?). L'agilité a apporté la lumière à des milliers de développeurs, dont moi, et à fait progresser notre connaissance de notre métier, en construisant pour la première fois un socle stable. Nous en sommes encore au début mais nous tentons chaque jour de mieux comprendre ce métier Ô combien difficile.
Il faut toujours se méfier quand on écrit "pour la première fois", à part si on vit dans un monde binaire évidemment. Et il faut toujours se méfier quand on parle d'"apporter la lumière", car la question sous-jacente est toujours "mais qui donc les maintenait dans l'ombre ?" (et la réponse étant normalement "ben personne, il suffisait d'ouvrir les yeux, pas besoin d'attendre un messie").
Dites moi si ces quelques exemples vous dit quelques choses : Le Chef de projet est appellé ScrumMaster, parce qu'il a fait 2 jours de formation.
C'était le processus standard de la Scrum Alliance jusqu'à peu, sanctionné par Jeff Sutherland en personne. Et d'ailleurs, pourquoi est-ce que ça devrait être problématique ? Ne devrait-on pas avoir confiance en ses capacités d'être Scrum Master après une formation initiale ? Ou alors il ne devrait recevoir le titre de Scrum Master qu'à la suite d'un compagnonnage, cette pratique moyenâgeuse ?
L'Agile est mort en 2001. Plus précisément en février 2001, à Snowbird Utah USA. C'est la création du Manifeste Agile et de l'emploi du terme Agile. Plus généralement, c'est une volonté de mettre en place un modèle, un cadre. C'est à partir de 2002 que l'on voit fleurir les livres avec le terme agile dans le titre.
Cela peut paraitre surprenant de dire cela, puisque c'est aussi le début du mouvement Agile. L'objectif de normaliser termes et principes, de les figer, est avant tout pour mieux le vendre.
C'est bien connu, la transmission du savoir est infiniment plus facile quand tout le monde parle en termes différents, et avec des références (principes) différents. L'Agile est donc mort à partir du moment où on s'est donné les moyens de le transmettre en masse, l'Agile est donc réservé à une élite, donc l'Agile n'est pas Agile vu qu'il ne respecte pas le premier principe figé de l'Agile qui est de faire confiance et respecter les gens.
Ne voulant pas remettre en cause ces deux postulats, il ne peut en résulter qu'un dévoiement du mouvement Agile. Et c'est ce qui se passe. L'Agile est donc une mode, qui passe après le développement objet, les Design Patterns, le C++, Java, les frameworks, RUP et quelques autres. On verra dans quelques années fleurir de nouvelles modes quand les promesses des vendeurs Agiles se seront écrasées sur le mur de la réalité des entreprises.
L'Agile est devenue une mode comme un produit Apple, avec les mêmes problèmes de fanboyisme qui fait que pour n'importe quel produit ou pratique ou service labellisé, on érige un nouveau totem aux noms de l'innovation et de la nouveauté apocryphes.
Pourquoi ? Parce qu'on est plus intéressé à vendre qu'a réfléchir, car pour réfléchir il faut avant tout faire ! Ce n'est pas en écrivant des livres et en faisant du consulting qu'on peut produire. XP est le résultat de très nombreuses années de pratique de développement logiciel. Taiichi Ono (fondateur du Toyota Production System) à passé plusieurs décénnies pour perfectioner son organisation. Il ne faisait surement pas passer des certifications TPS 5 ans après avoir débuté sa nouvelle organisation !
Et un jour peut-être, une certaine classe d'agilistes arrivera à ne pas ressortir à tout bout champ des références au toyotisme, qui est une solution pour produire de manière performante (qualité, coût, délai) et en masse des produits manufacturés à options sur base commune sans faire exploser les stocks (en particulier BDL). Si certaines des pratiques embarquées dans le toyotisme sont d'application générale dans l'organisation du travail (et on serait tenté de dire dans l'organisation "scientifique" du travail), la transposition directe "assembler un véhicule" / "analyser un processus métier pour concevoir et implémenter un logiciel" est d'une honnêteté intellectuelle à peu près aussi convaincante que de dire "Struts c'est du MVC (Reenskaug 1979)". Ceci était juste un aparté.
Il faut seulement avoir une vision systémique du mouvement, comprendre d'où il vient, pourquoi il a été créé et pourquoi certaines personnes vendent le modèle Agile. Cela permet par exemple de comprendre le Manifeste Agile au lieu de répéter bêtement son contenu qui est loin d'être optimal en 2011. Cela permet aussi de comprendre que ce modèle créé en 2001 (Scrum en 96, XP en 99) et qui a mis du temps à se propager n'apporte plus rien de neuf depuis de nombreuses années. Si l'argent fut toujours le moteur, le modèle est maintenant dévoyé pour rentrer dans la matrice consulting, loin des objectifs initiaux. Et ni les voix officielles (Agile Alliance, Scrum Alliance), ni ses têtes pensantes se sont élevés contre cela. Pire, elles ont participé activement à ce dévoiement (qui a dit certification ?).
Là on rentre dans une problématique extrêmement vaste, qui est celle de la formation, sujet proche de la diffusion de la connaissance mais avec ses spécificités propres. Le monde des rebelles aux SSII (pour caricaturer) est entré dans un cercle vicieux de dévalorisation des formations en général ("les diplômes c'est bidon, seule l'expérience compte", "les certifications c'est bidon, c'est uniquement sur des modèles dépassés", "les formations c'est bidon, les formateurs ne sont que des perroquets", "à quoi ça sert une formation ? J'aurais toujours la réponse sur internet"), et en arrive à s'imaginer vivre dans le monde de "La citadelle du vertige" d'Alain Grousset, dans un progressisme perpétuel et s'appuyant sur des fondations fantasmées. Et ceci nous amène à une contradiction de ces rebelles, ces champions du logiciel, c'est-à-dire de la mise en place des procédés et règles de traitement de l'information sous la forme de programmes, sont incapables de données du crédit au moindre processus de transmission et de validation de la connaissance qui sorte du sillon de l'apprentissage ou du compagnonnage, dans un médiévisme de bon aloi qui nous ramène à "La citadelle du vertige". Pour la faction agiliste qui met la primauté dans la confiance en l'homme (par défiance envers "le processus"), cela relève d'un cynisme assez redoutable.
Je pourrais résumer ma pensée ainsi : L'agilité est une avancée importante, mais le modèle Agile est inutile. C'est peut être le destin de tout modèle. En tout cas il est temps que chaque organisation invente, à l'instar de Toyota, son propre modèle de production. Un modèle adapté à son business, ses clients, ses collaborateurs. Un modèle qui prend en compte toutes les nouvelles avancées que l'on peut trouver dans les mouvements tels que Devops, Lean, Lean startup ou Kanban. Un modèle qui évolue sans cesse avec la maturité et la capacité de l'organisation à produire.
Le modèle évolue sans cesse, mais le business change aussi, on change de clients, les collaborateurs changent (ils arrivent, partent, sont déprimés). Donc tout change ; et s'il n'y a pas de référentiel, alors tout le discours autour d'une évolution est par nature paralogique.
Pour conclure, comme la naissance de l'Agile est concomitante avec sa mort (comme le Big-Bang), alors les agilistes sont des étoiles (filantes ?).
