Il s'agit d'une journée pleine, proposée par l'Institut Agile, le Chapitre France-Atlantic du PMI et l'Université de Caen, qui se tiendra le 22 mars 2012 à Caen. Vous pouvez télécharger la plaquette ou vous inscrire sur le site du Chapitre.
Affichage des articles dont le libellé est institut. Afficher tous les articles
Affichage des articles dont le libellé est institut. Afficher tous les articles
Prochain Rendez-Vous de l'Institut: le 22 mars à Caen
L'Institut sort de Paris pour son prochain Rendez-Vous:"Vous avez dit Management Agile ?"
Naissance d'une communauté: Enseigner Agile
Le 9 novembre s'est réuni une nouvelle communauté thématique à l'initiative de l'Institut Agile: elle se composait d'enseignants en activité et d'intervenants issus de l'industrie. (Plusieurs d'entre nous ont d'ailleurs eu des parcours mixtes: ex-enseignants devenus ingénieurs ou chefs de projet, ex-ingénieurs devenus enseignants, par exemple.) Une dizaine de personnes étaient présentes.
Les Rendez-Vous de l'Institut: Enseignement Agile
Parmi les sujets que l'Institut Agile entend traiter en priorité, on trouve en bonne place la recherche et l'enseignement.
Que pouvons-nous apprendre, par la méthode expériementale notamment, sur les pratiques Agiles et leur relation à d'autres "bonnes pratiques"dans le domaine du logiciel? Mais également, et les deux sujets sont indissociables, comment favoriser l'acquisition de ces connaissances (et d'autres) par les élèves, les étudiants et les jeunes diplômés d'aujourdhui qui vont (rapidement) devenir les professionnels du logiciel de demain? C'est un enjeu d'avenir mais encore peu abordé par la communauté Agile.
Que pouvons-nous apprendre, par la méthode expériementale notamment, sur les pratiques Agiles et leur relation à d'autres "bonnes pratiques"dans le domaine du logiciel? Mais également, et les deux sujets sont indissociables, comment favoriser l'acquisition de ces connaissances (et d'autres) par les élèves, les étudiants et les jeunes diplômés d'aujourdhui qui vont (rapidement) devenir les professionnels du logiciel de demain? C'est un enjeu d'avenir mais encore peu abordé par la communauté Agile.
Premier Rendez-vous de l'Institut Agile: 04/05
Le 4 mai, l'Institut Agile vous invite au premier de ses Rendez-Vous. (Attention: changement de date par rapport à la première annonce!)
Petit à petit le projet de l'Institut Agile se construit, grâce au soutien de ses partenaires. Comme annoncé au fil de ce blog divers livrables importants ont vu le jour: le référentiel des pratiques agiles, les premières sessions "Master Class", les premières communautés thématiques. D'autres projets encore en couveuse produiront prochainement leurs résultats.
Première communauté thématique de l'Institut Agile: Contrats Agiles
La première réunion de groupe de travail "Contrats Agiles" de l'Institut s'est tenue le 17 janvier dernier; ce billet en donne un compte-rendu. (Pour en savoir plus, vous pouvez également participer à la liste de diffusion "Institut Agile - Contrats")
Session "Innovation Games" les 29 et 30 mars 2011, première Master Class
Ouverture des inscriptions
Les inscriptions sont ouvertes dès aujourd'hui pour la première Master Class de l'Institut Agile.
Celle-ci a pour thème les Innovation Games popularisés par Luke Hohmann. Elle se déroulera les 29 et 30 mars à Paris et sera animée en anglais par Maarten Volders, instructeur accrédité par Innovation Games Inc.
Les inscriptions sont ouvertes dès aujourd'hui pour la première Master Class de l'Institut Agile.
Celle-ci a pour thème les Innovation Games popularisés par Luke Hohmann. Elle se déroulera les 29 et 30 mars à Paris et sera animée en anglais par Maarten Volders, instructeur accrédité par Innovation Games Inc.
Un petit jeu de "Cinq Pourquoi"
Hier matin j'ai eu le plaisir d'une discussion autour d'un café avec Hugo Heitz, responsable du déploiement Lean dans le département Exploitation d'une grande banque, dont j'avais bien apprécié l'intervention lors d'un précédent séminaire consacré à l'approche Lean, et avec qui je suis resté en contact depuis.
A un moment la conversation a abordé les difficultés liées à la "dette technique", l'entropie qui semble frapper inexorablement tous les projets informatiques avec pour conséquences qu'après un temps plus ou moins long (trop souvent assez court), des évolutions qui auraient été considérées comme mineures en début de parcours deviennent de plus en plus coûteuses, laborieuses, pénibles à réaliser comme à négocier.
Nous avons des constats très similaires malgré nos perspectives différentes, Hugo oeuvrant dans le domaine de l'exploitation, alors que je m'intéresse au développement; les deux mondes sont inexorablement liés mais semblent ne pas vouloir reconnaître leur existence mutuelle. (En plaisantant j'ai fait allusion à H.G. Wells pour décrire ce qui semble se passer entre ces deux populations: les "Morlocks de l'informatique" faisant un travail souterrain et ignoré tandis que les "Eloi du logiciel" mènent une vie insouciante. Evidemment ça nous a amenés à nous demander si de temps en temps un Eloi se faisait manger...)
Nous nous sommes alors lancés, presque sans le remarquer, dans un petit jeu des "cinq pourquoi", un des outils Lean qui a été assez joyeusement repris par les équipes Agiles. Pourquoi les projets finissent-ils par s'engluer, que ce soit du côté développement ou du côté exploitation? Parce que cette "dette technique" est composée de logiciel, et que le logiciel est par nature invisible, contrairement au hardware. On peut plus facilement mesurer l'âge moyen d'un parc matériel vieillissant et convaincre par des chiffres qu'il est temps d'investir, mais comment mesurer la "dette technique" logicielle?
Alors pourquoi cette "dette technique" est-elle si difficile à mesurer? Parce que les programmeurs (je parlais alors pour ma partie) investissent leurs efforts sur les mauvaises priorités. "Pas le temps de mettre ce code au propre, il faut qu'on livre de nouvelles fonctionnalités." Et pourquoi les programmeurs ne se rendent-ils pas compte que ces choix sont contre-productifs? Parce que bien souvent il leur manque certains savoirs et savoirs-faire qui leur permettraient d'objectiver et d'argumenter en faveur de décisions plus appropriées. Pourquoi leur manque-t-il ces connaissances?
A ce moment nous n'avions posé que quatre "pourquoi" (et il faudra sans doute un jour creuser plus loin) mais nous sommes tombés d'accord sur un constat: tant que la formation des personnes entrant dans les métiers de l'informatique ne les prépare pas à imposer dans leurs entreprises des pratiques plus efficaces, il sera difficile d'espérer des améliorations.
En France les cursus de formations supérieures sont indissociablement liés aux organismes publics de recherche, la recherche en entreprise étant moins développée dans l'informatique que dans d'autres secteurs économiques; c'est donc à mon avis vers les enseignants-chercheurs qu'il est important de se tourner pour trouver des réponses.
Or la collaboration entre les professionnels en entreprise et ce monde de la recherche et de l'enseignement publics me semble extrêmement marginale, presque inexistante. C'est vrai de manière générale pour ce qui concerne le génie logiciel: combien de développeurs ou de chefs de projet travaillant en entreprise s'intéressent au travail des chercheurs dans ce domaine et les trouvent pertinents et concrètement utiles? Le seul domaine que je connaisse où il semble qu'une collaboration fructueuse se soit établie est celui de la "programmation par les modèles" ou "model driven".
Concernant les approches Agiles, c'est carrément le désert. Un exemple: il existe des projets de recherche à l'échelle européenne, par exemple le programme ITEA2. Ces projets mutualisent des investissements publics et privés en R&D et visent à rendre l'Europe plus compétitive dans ce domaine. Au sein d'ITEA2, il existe un sous-projet FLEXI réunissant des chercheurs en un réseau qui cible spécifiquement des pratiques Agiles. On n'y trouve... aucun partenaire industriel français, et apparemment aucun chercheur français.
Le projet de l'Institut Agile prend très au sérieux ce rapprochement nécessaire entre le milieu de la recherche et de l'enseignement d'une part, et la communauté Agile et ses professionnels d'autre part. Rendre compte de la recherche sur les différentes pratiques est par exemple un des objectifs du référentiel.
Il faut aller plus loin. J'ai publié aujourd'hui un premier appel en vue du recensement des chercheurs en France (ou dans la sphère francophone plus largement) qui s'intéressent à ce sujet. Si vous exercez vous-même des activités d'enseignement et de recherche, je vous encourage vivement à vous inscrire; si ce n'est pas le cas, à diffuser autour de vous l'adresse de cette page.
L'objectif dans un premier temps est de mieux connaître et mieux faire connaître cette partie de la communauté Agile. Travailler ensemble, c'est pouvoir mieux faire valoir l'intérêt de ces recherches, à la fois envers les organismes habilités à financer et favoriser des projets de recherche, mais aussi et surtout en direction des développeurs, chefs de projets et autres intervenants sur les projets Agiles.
A un moment la conversation a abordé les difficultés liées à la "dette technique", l'entropie qui semble frapper inexorablement tous les projets informatiques avec pour conséquences qu'après un temps plus ou moins long (trop souvent assez court), des évolutions qui auraient été considérées comme mineures en début de parcours deviennent de plus en plus coûteuses, laborieuses, pénibles à réaliser comme à négocier.
Nous avons des constats très similaires malgré nos perspectives différentes, Hugo oeuvrant dans le domaine de l'exploitation, alors que je m'intéresse au développement; les deux mondes sont inexorablement liés mais semblent ne pas vouloir reconnaître leur existence mutuelle. (En plaisantant j'ai fait allusion à H.G. Wells pour décrire ce qui semble se passer entre ces deux populations: les "Morlocks de l'informatique" faisant un travail souterrain et ignoré tandis que les "Eloi du logiciel" mènent une vie insouciante. Evidemment ça nous a amenés à nous demander si de temps en temps un Eloi se faisait manger...)
Nous nous sommes alors lancés, presque sans le remarquer, dans un petit jeu des "cinq pourquoi", un des outils Lean qui a été assez joyeusement repris par les équipes Agiles. Pourquoi les projets finissent-ils par s'engluer, que ce soit du côté développement ou du côté exploitation? Parce que cette "dette technique" est composée de logiciel, et que le logiciel est par nature invisible, contrairement au hardware. On peut plus facilement mesurer l'âge moyen d'un parc matériel vieillissant et convaincre par des chiffres qu'il est temps d'investir, mais comment mesurer la "dette technique" logicielle?
Alors pourquoi cette "dette technique" est-elle si difficile à mesurer? Parce que les programmeurs (je parlais alors pour ma partie) investissent leurs efforts sur les mauvaises priorités. "Pas le temps de mettre ce code au propre, il faut qu'on livre de nouvelles fonctionnalités." Et pourquoi les programmeurs ne se rendent-ils pas compte que ces choix sont contre-productifs? Parce que bien souvent il leur manque certains savoirs et savoirs-faire qui leur permettraient d'objectiver et d'argumenter en faveur de décisions plus appropriées. Pourquoi leur manque-t-il ces connaissances?
A ce moment nous n'avions posé que quatre "pourquoi" (et il faudra sans doute un jour creuser plus loin) mais nous sommes tombés d'accord sur un constat: tant que la formation des personnes entrant dans les métiers de l'informatique ne les prépare pas à imposer dans leurs entreprises des pratiques plus efficaces, il sera difficile d'espérer des améliorations.
En France les cursus de formations supérieures sont indissociablement liés aux organismes publics de recherche, la recherche en entreprise étant moins développée dans l'informatique que dans d'autres secteurs économiques; c'est donc à mon avis vers les enseignants-chercheurs qu'il est important de se tourner pour trouver des réponses.
Or la collaboration entre les professionnels en entreprise et ce monde de la recherche et de l'enseignement publics me semble extrêmement marginale, presque inexistante. C'est vrai de manière générale pour ce qui concerne le génie logiciel: combien de développeurs ou de chefs de projet travaillant en entreprise s'intéressent au travail des chercheurs dans ce domaine et les trouvent pertinents et concrètement utiles? Le seul domaine que je connaisse où il semble qu'une collaboration fructueuse se soit établie est celui de la "programmation par les modèles" ou "model driven".
Concernant les approches Agiles, c'est carrément le désert. Un exemple: il existe des projets de recherche à l'échelle européenne, par exemple le programme ITEA2. Ces projets mutualisent des investissements publics et privés en R&D et visent à rendre l'Europe plus compétitive dans ce domaine. Au sein d'ITEA2, il existe un sous-projet FLEXI réunissant des chercheurs en un réseau qui cible spécifiquement des pratiques Agiles. On n'y trouve... aucun partenaire industriel français, et apparemment aucun chercheur français.
Le projet de l'Institut Agile prend très au sérieux ce rapprochement nécessaire entre le milieu de la recherche et de l'enseignement d'une part, et la communauté Agile et ses professionnels d'autre part. Rendre compte de la recherche sur les différentes pratiques est par exemple un des objectifs du référentiel.
Il faut aller plus loin. J'ai publié aujourd'hui un premier appel en vue du recensement des chercheurs en France (ou dans la sphère francophone plus largement) qui s'intéressent à ce sujet. Si vous exercez vous-même des activités d'enseignement et de recherche, je vous encourage vivement à vous inscrire; si ce n'est pas le cas, à diffuser autour de vous l'adresse de cette page.
L'objectif dans un premier temps est de mieux connaître et mieux faire connaître cette partie de la communauté Agile. Travailler ensemble, c'est pouvoir mieux faire valoir l'intérêt de ces recherches, à la fois envers les organismes habilités à financer et favoriser des projets de recherche, mais aussi et surtout en direction des développeurs, chefs de projets et autres intervenants sur les projets Agiles.
Dix ans d'agilité, et après?
Un billet rapide pour vous signaler mon entretien d'une heure et quelques avec Mario Cardinal pour le Visual Studio Talk Show, disponible en podcast (ou ballado-diffusion pour les puristes).
Nous avons parlé des dix ans du Manifeste Agile, de ce qui se passe en ce moment et de ce qui se trame à l'avenir, et donc notamment des projets de l'Institut.
Nous avons parlé des dix ans du Manifeste Agile, de ce qui se passe en ce moment et de ce qui se trame à l'avenir, et donc notamment des projets de l'Institut.
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
