Le billet précédent positionnait Agile comme le concurrent, initialement peu crédible, du "produit dominant" qu'est le Génie Logiciel. Mais nous l'avons vu, le challenger augmente progressivement ses parts de marché en diversifiant sa cible, et ce faisant il rattrape peu à peu son retard y compris sur les critères qui assurent au produit dominant sa position de force.
Pour autant, en matière d'innovation la victoire n'est jamais acquise d'avance. Bien des avancées prometteuses ont échoué, pour des raisons qui n'ont pas forcément à voir avec la qualité des technologies sous-jacentes, mais faute d'avoir habilement négocié cette montée en puissance.
Premier défi: enterrer la certification
Ainsi l'obession persistante de la communauté pour le sujet de la certification continue-t-elle de mener bataille sur un terrain, le contrôle des qualifications, où elle représente précisément ce qu'il ne faut pas faire, une concurrence frontale au modèle dominant. Le mouvement Agile doit trouver des solutions à cette question lancinante, mais des solutions qui soient compatibles avec sa propre philosophie.
Deuxième défi: proposer un modèle contractuel propre
De même, il faut répondre enfin à une autre question lancinante, celle du modèle contractuel. Nous continuons à dire que le contrat forfaitaire est un frein à l'adoption des pratiques Agiles en France, mais quelle solution proposons-nous?
Troisième défi: le choc des photos plutôt que le poids des mots
La prolifération de jargon rend difficile la conversation au-delà du cercle des initiés; la communication sur les pratiques Agile est brouillonne et trop centrée sur les étiquettes: Scrum vs Kanban vs Lean vs XP. J'applaudis ceux qui présentent la réalité du terrain, les éléments concrets et visibles qui au sein d'une équipe permettent d'identifier les pratiques Agiles et les bénéfices qu'elles apportent.
Quatrième défi: des chiffres!
A ce sujet, il est regrettable que l'une des critiques les plus courantes du mouvement Agile soit désormais la suivante: "Depuis 10 ans, il n'y a toujours pas de chiffres probants". La communauté Agile a désormais suffisamment d'ampleur pour être en principe capable de fournir ces chiffres.
Certes, il y a dix ans, la demande "montrez-nous vos statistiques" pouvait à raison être rejetée comme un discours de délégitimation, une façon de remettre à leur place ces "hippies du logiciel". Mais nous ne sommes plus en 2001, nous sommes en 2010; les éléments empiriques sont nécessaires, non seulement pour étayer ce que nous avançons, mais aussi pour faire le tri entre celles des pratiques qu'il faut conserver et celles qu'il faut modifier ou éliminer de notre discours. Non seulement nécessaires, mais disponibles, pour peu que nous nous donnions la peine d'aller les chercher.
Cinquième défi: le gouffre recherche-industrie
Dans cette logique, il est critique que la communauté Agile se rapproche de la communauté de la recherche et de l'enseignement. Pour l'instant, rares sont les chercheurs qui s'intéressent à l'Agilité, tout simplement parce que les travaux dans ce domaine ne trouveraient pas à être publiés. Ceci pourrait être réparé en entamant une démarche explicite pour faire de ce sujet une discipline soeur, voire concurrente, du Génie Logiciel. Après tout, cette dernière a pu persister pendant 40 ans sans solutionner les difficultés qui ont motivé sa création... il est temps qu'elle subisse la concurrence.
Cette liste n'est sans doute pas exhaustive mais suffirait probablement à tracer une feuille de route pour les approches Agiles au cours des 10 ans à venir.
Affichage des articles dont le libellé est certification. Afficher tous les articles
Affichage des articles dont le libellé est certification. Afficher tous les articles
Alternatives à la certification
Sur le sujet de la certification, l'Institut annonce clairement la couleur: cet organisme n'aura, en son nom, aucune activité de certification ou même de labelisation.
(Notamment, la qualité de Partenaire de l'Institut ne vaut pas, de la part de l'Institut, quelque reconnaissance que ce soit du caractère "agile" ou des compétences d'une entreprise. Les Partenaires de l'Institut sont des entreprises qui choisissent, pour des raisons économiques, de contribuer aux missions de l'Institut.)
Qu'est-ce qu'une certification? Voici ce qu'en dit la Commission Nationale de la Certification Professionnelle:
Ce que l'Institut se refuse, c'est la démarche qui consiste à s'auto-proclamer organisme de certification, sans dialogue préalable avec qui que ce soit, dans le but de rendre plus attractive une offre commerciale de formation. Hélas, force est de constater que généralement dans notre domaine, cette démarche est le fait d'entreprises qui, par ailleurs, vendent de la formation.
Ces entreprises se trouvent donc juge et partie dans une situation qui peut être sensible. D'une part, si je suis déjà pourvoyeur d'une formation, il est évident que ma définition du référentiel pédagogique collera (on est tenté de dire "comme par hasard") au contenu de mes propres formations. D'où un avantage indéniable à être le premier à dégainer en proposant une certification: je n'ai rien à faire pour adapter ma propre formation aux objectifs de conformité au référentiel, par contre mes concurrents vont devoir s'aligner sur ce que moi j'enseigne.
Or ce référentiel des pratiques et compétences agiles, j'en reparlerai, est un "work in progress". La communauté Agile travaille en permanence à le faire évoluer, à y ajouter des volets entiers, à le simplifier parfois, à le reformuler pour être plus percutant et plus efficace. Dès lors, créer un système qui agit de façon à standardiser les enseignements n'a pas de sens.
De plus, ce référentiel n'existe pas encore, du moins pas encore de façon systématique et détaillée. Nous n'avons pas encore su donner dans un seul endroit une définition canonique, claire et commentée de termes comme Vélocité, Refactoring, Test-Driven, etc.
Pour finir, la plupart des formations actuellement vendues à l'aide du mot magique "certification" sont des formations courtes, qui ne peuvent en aucun cas prétendre à construire des "capacités à réaliser des activités professionnelles dans le cadre de plusieurs situations de travail". Deux jours ne suffisent pas à former un ingénieur ou un leader de projet Agile. (Ni même cinq.)
Entretenir la confusion entre formation et certification participe d'ailleurs du même principe malhonnête qui consiste à faire prendre des vessies pour des lanternes. Une certification est censée attester, notez le mot, qui est fort, d'une qualification. Elle n'est pas censée la construire: c'est justement le rôle de la formation. On peut très bien dissocier la formation, qui consiste à travailler avec des gens pour leur enseigner quelque chose, de la certification, qui consiste en fait à mettre en jeu sa réputation sur une déclaration solennelle que telle personne est qualifée pour un travail.
Si vous examinez ce qui est actuellement proposé par diverses entreprises sous la rubrique "certification Agile", vous entendrez le discours opposé: "Ah, mais attention, nous ne nous engageons absolument pas sur le fait que la personne qui a suivi nos cours est qualifiée, uniquement sur le fait qu'elle a enregistré ce qu'on lui a dit".
Vous l'avez compris, parler de certification aujourdh'ui, c'est dans le meilleur des cas mettre la charrue avant les boeufs.
Dans ces conditions, la démarche alternative me semble claire: commencer d'abord par mettre au point ce référentiel pédagogique, en invitant largement la communauté à y participer. En soi, cette démarche a de l'intérêt, parce qu'elle permettra aux personnes visées par les offres de "certification" de trouver tous les bénéfices prétendument apportés par ces offres: aux employeurs de savoir quelles questions poser aux recrues potentielles; aux ingénieurs qui souhaitent se former de savoir ce que doivent couvrir les formations qu'ils envisagent; aux formateurs de composer des parcours utiles, sans avoir à suivre un cursus imposé, mais en se sentant responsables de leur contenu.
C'est une partie du projet de l'Institut.
(Notamment, la qualité de Partenaire de l'Institut ne vaut pas, de la part de l'Institut, quelque reconnaissance que ce soit du caractère "agile" ou des compétences d'une entreprise. Les Partenaires de l'Institut sont des entreprises qui choisissent, pour des raisons économiques, de contribuer aux missions de l'Institut.)
Qu'est-ce qu'une certification? Voici ce qu'en dit la Commission Nationale de la Certification Professionnelle:
Une certification professionnelle atteste d'une "qualification" c'est-à-dire de capacités à réaliser des activités professionnelles dans le cadre de plusieurs situations de travail et à des degrés de responsabilités définis dans un "référentiel".Pourquoi "en son nom"? Parce qu'il existe en France des organismes qui certifient, c'est-à-dire qui délivrent des diplômes professionnels, et qu'il est non seulement légitime mais bel et bien prévu que l'Institut contribue à définir un "référentiel" des capacités et des responsabilités que désigne le terme "développement de logiciels Agile".
Ce que l'Institut se refuse, c'est la démarche qui consiste à s'auto-proclamer organisme de certification, sans dialogue préalable avec qui que ce soit, dans le but de rendre plus attractive une offre commerciale de formation. Hélas, force est de constater que généralement dans notre domaine, cette démarche est le fait d'entreprises qui, par ailleurs, vendent de la formation.
Ces entreprises se trouvent donc juge et partie dans une situation qui peut être sensible. D'une part, si je suis déjà pourvoyeur d'une formation, il est évident que ma définition du référentiel pédagogique collera (on est tenté de dire "comme par hasard") au contenu de mes propres formations. D'où un avantage indéniable à être le premier à dégainer en proposant une certification: je n'ai rien à faire pour adapter ma propre formation aux objectifs de conformité au référentiel, par contre mes concurrents vont devoir s'aligner sur ce que moi j'enseigne.
Or ce référentiel des pratiques et compétences agiles, j'en reparlerai, est un "work in progress". La communauté Agile travaille en permanence à le faire évoluer, à y ajouter des volets entiers, à le simplifier parfois, à le reformuler pour être plus percutant et plus efficace. Dès lors, créer un système qui agit de façon à standardiser les enseignements n'a pas de sens.
De plus, ce référentiel n'existe pas encore, du moins pas encore de façon systématique et détaillée. Nous n'avons pas encore su donner dans un seul endroit une définition canonique, claire et commentée de termes comme Vélocité, Refactoring, Test-Driven, etc.
Pour finir, la plupart des formations actuellement vendues à l'aide du mot magique "certification" sont des formations courtes, qui ne peuvent en aucun cas prétendre à construire des "capacités à réaliser des activités professionnelles dans le cadre de plusieurs situations de travail". Deux jours ne suffisent pas à former un ingénieur ou un leader de projet Agile. (Ni même cinq.)
Entretenir la confusion entre formation et certification participe d'ailleurs du même principe malhonnête qui consiste à faire prendre des vessies pour des lanternes. Une certification est censée attester, notez le mot, qui est fort, d'une qualification. Elle n'est pas censée la construire: c'est justement le rôle de la formation. On peut très bien dissocier la formation, qui consiste à travailler avec des gens pour leur enseigner quelque chose, de la certification, qui consiste en fait à mettre en jeu sa réputation sur une déclaration solennelle que telle personne est qualifée pour un travail.
Si vous examinez ce qui est actuellement proposé par diverses entreprises sous la rubrique "certification Agile", vous entendrez le discours opposé: "Ah, mais attention, nous ne nous engageons absolument pas sur le fait que la personne qui a suivi nos cours est qualifiée, uniquement sur le fait qu'elle a enregistré ce qu'on lui a dit".
Vous l'avez compris, parler de certification aujourdh'ui, c'est dans le meilleur des cas mettre la charrue avant les boeufs.
Dans ces conditions, la démarche alternative me semble claire: commencer d'abord par mettre au point ce référentiel pédagogique, en invitant largement la communauté à y participer. En soi, cette démarche a de l'intérêt, parce qu'elle permettra aux personnes visées par les offres de "certification" de trouver tous les bénéfices prétendument apportés par ces offres: aux employeurs de savoir quelles questions poser aux recrues potentielles; aux ingénieurs qui souhaitent se former de savoir ce que doivent couvrir les formations qu'ils envisagent; aux formateurs de composer des parcours utiles, sans avoir à suivre un cursus imposé, mais en se sentant responsables de leur contenu.
C'est une partie du projet de l'Institut.
Inscription à :
Articles (Atom)
Articles
