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.
Affichage des articles dont le libellé est communaute. Afficher tous les articles
Affichage des articles dont le libellé est communaute. Afficher tous les articles
Synthèse: référentiel des pratiques
Voici, pour ceux qui le découvriraient tardivement et souhaitent le lire dans l'ordre, un récapitulatif du chapitre "référentiel" tel que je l'ai abordé au fil des billets précédents. (L'inconvénient majeur d'un blog, c'est que quand on arrive après le début du film, les épisodes précédents sont présentés à l'envers: ça marche bien pour Memento mais moins bien pour un sujet plus technique.) Je profiterai également de ce billet pour dire un mot sur un sujet connexe: à qui appartient ce référentiel et comment il va évoluer.
Voici l'adresse de publication du Référentiel, et en voici les motivations:
Les billets futurs vont se concentrer sur d'autres chapitres de l'action de l'Institut.
A qui appartiennent les pratiques Agiles?
Une des raisons qui me font me méfier des initiatives de certification: je me préoccupe des mécanismes par lesquels, si je juge incorrecte la conception que se font les certifieurs de l'Agilité, je pourrai leur soumettre une demande de correction. C'est un point important: si j'enseigne quelque chose en rapport avec l'agilité, mais que mon contenu est incompatible avec ce que disent les certifieurs, j'aurai le choix cornélien entre enseigner quelque chose auquel je ne crois pas ou renoncer à l'atout que peut représenter la certification.
Pour l'Institut, la question ne se pose pas, puisqu'il y a un parti pris contre toute initiative de ce type. Mais le Référentiel tel qu'il se présente a, sans détour, une intention normative. Il prétend rendre compte de la pratique la plus courante, même si cela admet des exceptions.
A mon sens, les pratiques Agiles appartiennent à la communauté Agile dans son entier, et je pose cette interprétation comme un principe qui fait partie de la définition même de l'Agilité. C'est un mouvement qui a ceci de particulier qu'il est "bottom up", par construction et par philosophie.
Le Référentiel lui-même est une "oeuvre de l'esprit", protégé par le droit d'auteur. Je souhaite, pour des raisons éditoriales, contrôler un tant soit peu sa diffusion et sa modification pendant la période de rédaction, avant d'en faire un contenu "open source" une fois qu'il sera complet. Par conséquent, le Référentiel sera:
L'évolution future du Référentiel
La version actuelle du Référentiel est techniquement minimaliste, mais je compte dans l'immédiat me concentrer sur son contenu (tout en alimentant ce blog en parallèle...). Je publierai simultanément sur Github et sur le site les nouvelles pratiques au fur et à mesure de leur rédaction.
Tout au long de cette phase de rédaction j'acueillerai avec plaisir les suggestions d'amélioration, y compris sous la forme de "patchs" proposés via Github. L'objectif est d'être en mesure d'accueillir le plus largement possible les connaissances pertinentes sur les pratiques Agiles: liens vers des articles de référence, vers des travaux de recherche, vers des descriptifs de formations universitaires.
(Je suis dés à présent ouvert à l'inclusion de liens vers des formations commerciales, sous réserve que cela puisse se faire sans entrer en conflit avec la politique de l'Institut vis-à-vis de ses partenaires et vis-à-vis du marché: une neutralité bienveillante.)
Voici l'adresse de publication du Référentiel, et en voici les motivations:
- Pourquoi il est préférable de se focaliser sur les pratiques agiles et non sur l'étiquette "Agile"
- Principes, concepts, pratiques et compétences: les composants du corpus Agile
- Précautions d'utilisation d'un référentiel des pratiques Agiles: attention au Culte du Cargo
- Comment adapter les pratiques Agiles à son propre contexte: une activité efficace
- Les "rôles" Agiles et pourquoi s'en méfier
- Les canevas pour décrire une pratique et une compétence
Les billets futurs vont se concentrer sur d'autres chapitres de l'action de l'Institut.
A qui appartiennent les pratiques Agiles?
Une des raisons qui me font me méfier des initiatives de certification: je me préoccupe des mécanismes par lesquels, si je juge incorrecte la conception que se font les certifieurs de l'Agilité, je pourrai leur soumettre une demande de correction. C'est un point important: si j'enseigne quelque chose en rapport avec l'agilité, mais que mon contenu est incompatible avec ce que disent les certifieurs, j'aurai le choix cornélien entre enseigner quelque chose auquel je ne crois pas ou renoncer à l'atout que peut représenter la certification.
Pour l'Institut, la question ne se pose pas, puisqu'il y a un parti pris contre toute initiative de ce type. Mais le Référentiel tel qu'il se présente a, sans détour, une intention normative. Il prétend rendre compte de la pratique la plus courante, même si cela admet des exceptions.
A mon sens, les pratiques Agiles appartiennent à la communauté Agile dans son entier, et je pose cette interprétation comme un principe qui fait partie de la définition même de l'Agilité. C'est un mouvement qui a ceci de particulier qu'il est "bottom up", par construction et par philosophie.
Le Référentiel lui-même est une "oeuvre de l'esprit", protégé par le droit d'auteur. Je souhaite, pour des raisons éditoriales, contrôler un tant soit peu sa diffusion et sa modification pendant la période de rédaction, avant d'en faire un contenu "open source" une fois qu'il sera complet. Par conséquent, le Référentiel sera:
- dans un premier temps, diffusé sous une licence Creative Commons "by-nc-nd", avec l'exception suivante: toute personne qui le souhaite est autorisée à "forker" le Référentiel et à le modifier, sous réserve que ce soit dans la seule intention de soumettre ces modifications à l'auteur
- dans un second temps, et pas plus tard que le 31 décembre 2012, le Référentiel sera utilisable sous la licence "by-nc-sa", toute personne souhaitant alors y apporter ses modifications pourra le faire sans restriction
L'évolution future du Référentiel
La version actuelle du Référentiel est techniquement minimaliste, mais je compte dans l'immédiat me concentrer sur son contenu (tout en alimentant ce blog en parallèle...). Je publierai simultanément sur Github et sur le site les nouvelles pratiques au fur et à mesure de leur rédaction.
Tout au long de cette phase de rédaction j'acueillerai avec plaisir les suggestions d'amélioration, y compris sous la forme de "patchs" proposés via Github. L'objectif est d'être en mesure d'accueillir le plus largement possible les connaissances pertinentes sur les pratiques Agiles: liens vers des articles de référence, vers des travaux de recherche, vers des descriptifs de formations universitaires.
(Je suis dés à présent ouvert à l'inclusion de liens vers des formations commerciales, sous réserve que cela puisse se faire sans entrer en conflit avec la politique de l'Institut vis-à-vis de ses partenaires et vis-à-vis du marché: une neutralité bienveillante.)
Dans une bonne bouteille, vous buvez l'étiquette?
Une question malicieuse pour un sujet très sérieux, puisque l'une de mes plus grandes inquiétudes est de voir notre profession se détourner d'idées qu'elles vient pourtant à peine de découvrir et qui, bien maîtrisées, lui font le plus grand bien.
Ce qui est important dans l'ensemble certes un peu hétéroclite de notions associées au terme "Agile", ce n'est évidemment pas le mot "Agile", de la même façon que ce qui nous procure du plaisir dans une bonne bouteille de vin, c'est (en principe) son contenu.
En principe? Oui, une des vertus de cette analogie, c'est de nous rappeler que trop souvent on se délecte de l'étiquette. On appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors même que si nous faisions l'essai à l'aveugle nous ne saurions pas distinguer une piquette d'un cru à la mode.
Je ne jetterai donc la pierre à personne, mais le fait est que nous courons un risque à trop parler des étiquettes: Agile, Lean, Scrum, XP... J'entends des choses parfaitement absurdes, par exemple "Lean est le successeur d'Agile".
C'est un contre-sens pour qui connaît le contenu qu'on désigne par le terme Agile: un ensemble de pratiques, certes pas toutes de la même origine, certes pas toutes aussi largement connues et pratiquées, mais dont statistiquement, en interrogeant un assez grand nombre de personnes faisant partie de la communauté depuis longtemps (cette appartenance pourrait se déterminer par un critère concret tel que la participation à des conférences), le recouvrement nous donnerait une idée assez précise.
Citons en vrac, et pour l'exercice: le développement par les tests (TDD), le refactoring, l'automatisation du build, l'intégration continue, la conception incrémentale, les User Stories, les tests de recette, les critères "Done", les Personas, le Story Mapping, le Planning Poker, les itérations timeboxées, les rétrospectives, le tableau des tâches, le libre choix des tâches, la réunion quotidienne ou "mélée", la programmation en binômes, les demandes d'aide explicites...
Parmi les "méthodes Agiles" (le mot méthode est mal choisi, mais ce sera le sujet d'un prochain billet) on peut effectivement recenser certaines dont les préconisations sont des sous-ensembles de cette longue liste: Scrum et XP notamment.
Si on se pose la question de savoir de quel mode de pensée sont issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a de nombreuses affinités avec le discours Lean. Pour autant, le recouvrement en termes de pratiques est relativement faible.
Or, soyons clair là-dessus, ce qui fait le succès ou non d'un projet, ce n'est pas le nom du discours dont on se revendique, l'attachement identitaire des membres de l'équipe: "nous sommes Agiles" ou "nous sommes Lean". Ce qui fait le succès d'un projet c'est ce que font les gens!
De ce point de vue, force est de constater que beaucoup d'équipes se proclament "Agiles" alors même qu'elles peinent à appliquer de façon compétente des pratiques aussi élémentaires que le refactoring, ou qu'elles révèlent lorsqu'on interroge les ingénieurs des contresens sur des notions de base comme la vélocité.
Une partie de ce déficit est à mettre sur le compte de la communauté Agile elle-même: il n'existe nulle part sur le Web un "Wikipedia de l'Agilité", une description systématique, détaillée, cohérente et mise à jour des pratiques désignées par le terme "Agile".
D'où le projet actuellement prioritaire de l'Institut Agile: mettre à la disposition des personnes intéressées par le sujet un "référentiel des compétences, pratiques, notions et principes" des approches Agiles. Qu'est-ce qui différentie une compétence d'une pratique, d'un principe, etc? C'est ce que j'aborderai dans le prochain billet...
Ce qui est important dans l'ensemble certes un peu hétéroclite de notions associées au terme "Agile", ce n'est évidemment pas le mot "Agile", de la même façon que ce qui nous procure du plaisir dans une bonne bouteille de vin, c'est (en principe) son contenu.
En principe? Oui, une des vertus de cette analogie, c'est de nous rappeler que trop souvent on se délecte de l'étiquette. On appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors même que si nous faisions l'essai à l'aveugle nous ne saurions pas distinguer une piquette d'un cru à la mode.
Je ne jetterai donc la pierre à personne, mais le fait est que nous courons un risque à trop parler des étiquettes: Agile, Lean, Scrum, XP... J'entends des choses parfaitement absurdes, par exemple "Lean est le successeur d'Agile".
C'est un contre-sens pour qui connaît le contenu qu'on désigne par le terme Agile: un ensemble de pratiques, certes pas toutes de la même origine, certes pas toutes aussi largement connues et pratiquées, mais dont statistiquement, en interrogeant un assez grand nombre de personnes faisant partie de la communauté depuis longtemps (cette appartenance pourrait se déterminer par un critère concret tel que la participation à des conférences), le recouvrement nous donnerait une idée assez précise.
Citons en vrac, et pour l'exercice: le développement par les tests (TDD), le refactoring, l'automatisation du build, l'intégration continue, la conception incrémentale, les User Stories, les tests de recette, les critères "Done", les Personas, le Story Mapping, le Planning Poker, les itérations timeboxées, les rétrospectives, le tableau des tâches, le libre choix des tâches, la réunion quotidienne ou "mélée", la programmation en binômes, les demandes d'aide explicites...
Parmi les "méthodes Agiles" (le mot méthode est mal choisi, mais ce sera le sujet d'un prochain billet) on peut effectivement recenser certaines dont les préconisations sont des sous-ensembles de cette longue liste: Scrum et XP notamment.
Si on se pose la question de savoir de quel mode de pensée sont issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a de nombreuses affinités avec le discours Lean. Pour autant, le recouvrement en termes de pratiques est relativement faible.
Or, soyons clair là-dessus, ce qui fait le succès ou non d'un projet, ce n'est pas le nom du discours dont on se revendique, l'attachement identitaire des membres de l'équipe: "nous sommes Agiles" ou "nous sommes Lean". Ce qui fait le succès d'un projet c'est ce que font les gens!
De ce point de vue, force est de constater que beaucoup d'équipes se proclament "Agiles" alors même qu'elles peinent à appliquer de façon compétente des pratiques aussi élémentaires que le refactoring, ou qu'elles révèlent lorsqu'on interroge les ingénieurs des contresens sur des notions de base comme la vélocité.
Une partie de ce déficit est à mettre sur le compte de la communauté Agile elle-même: il n'existe nulle part sur le Web un "Wikipedia de l'Agilité", une description systématique, détaillée, cohérente et mise à jour des pratiques désignées par le terme "Agile".
D'où le projet actuellement prioritaire de l'Institut Agile: mettre à la disposition des personnes intéressées par le sujet un "référentiel des compétences, pratiques, notions et principes" des approches Agiles. Qu'est-ce qui différentie une compétence d'une pratique, d'un principe, etc? C'est ce que j'aborderai dans le prochain billet...
Interventions programmées
Le périmètre d'intervention de l'Institut Agile couvre le territoire français.
C'est un choix délibéré: d'une part, il ne me semblait pas raisonnable d'annoncer des ambitions internationales, alors que pour l'instant l'Institut se compose d'une seule personne à temps plein. Par contre, il est désormais important de reconnaitre que la communauté Agile n'est plus un phénomène parisien; c'est à travers le pays qu'on s'y intéresse. (Au passage, il convient d'apprécier l'influence qu'a eu Agile Tour dans cette ouverture au-delà de la capitale.) L'Institut a donc des partenaires à Paris, mais aussi à Bordeaux, Marseille, Grenoble.
Jusqu'à présent, mes activités m'amenaient à voyager assez souvent à l'étranger, surtout pour des conférences; et beaucoup en France, le plus souvent pour rencontrer des clients. J'ai fait le choix de me consacrer à plein temps aux activités de l'Institut. Les conférences ainsi que ma participation à l'Alliance Agile font toujours partie de ces activités, au sens où l'Institut doit être un bon observateur de la communauté Agile.
Et, bien qu'ayant choisi de ne plus intervenir auprès d'aucun client, j'entends bien continuer à aller à la rencontre des projets Agiles partout en France. Habitué des conférences et séminaires, je suis aussi ravi de parler à des groupes d'utilisateurs ou associations. Ou même de discuter simplement en tête à tête autour d'un café avec un autre passionné.
Si vous souhaitez me rencontrer, soit à l'occasion d'un déplacement déjà programmé, soit à votre invitation, n'hésitez pas à me contacter. Je souhaite garder un calendrier de voyages relativement léger, et privilégier les déplacements que je pourrai faire dans la journée, mais tout peut s'envisager.
Je serai donc:
C'est un choix délibéré: d'une part, il ne me semblait pas raisonnable d'annoncer des ambitions internationales, alors que pour l'instant l'Institut se compose d'une seule personne à temps plein. Par contre, il est désormais important de reconnaitre que la communauté Agile n'est plus un phénomène parisien; c'est à travers le pays qu'on s'y intéresse. (Au passage, il convient d'apprécier l'influence qu'a eu Agile Tour dans cette ouverture au-delà de la capitale.) L'Institut a donc des partenaires à Paris, mais aussi à Bordeaux, Marseille, Grenoble.
Jusqu'à présent, mes activités m'amenaient à voyager assez souvent à l'étranger, surtout pour des conférences; et beaucoup en France, le plus souvent pour rencontrer des clients. J'ai fait le choix de me consacrer à plein temps aux activités de l'Institut. Les conférences ainsi que ma participation à l'Alliance Agile font toujours partie de ces activités, au sens où l'Institut doit être un bon observateur de la communauté Agile.
Et, bien qu'ayant choisi de ne plus intervenir auprès d'aucun client, j'entends bien continuer à aller à la rencontre des projets Agiles partout en France. Habitué des conférences et séminaires, je suis aussi ravi de parler à des groupes d'utilisateurs ou associations. Ou même de discuter simplement en tête à tête autour d'un café avec un autre passionné.
Si vous souhaitez me rencontrer, soit à l'occasion d'un déplacement déjà programmé, soit à votre invitation, n'hésitez pas à me contacter. Je souhaite garder un calendrier de voyages relativement léger, et privilégier les déplacements que je pourrai faire dans la journée, mais tout peut s'envisager.
Je serai donc:
- le 1er octobre à Londres pour le workshop sur les tests de recette AA-FTT
- les 6, 13 et 20 octobre à Douai, où je dispense une formation créée par mes collègues Christophe Thibaut et Bernard Notarianni pour l'école des Mines
- le 8 octobre à Nancy, pour commencer à évoquer les dix ans du Manifeste Agile
- le 17 novembre à Reykjavik en Islande, pour parler de pratiques de conception
- le 25 novembre... à Paris ;) où j'interviendrai lors du MDDay pour donner mon avis sur la modélisation
Agile 2010, compte-rendu partial
J'ai participé à la conférence Agile2010 mi-août et comme chaque année ce fut une semaine bien chargée.
Résurgence d'XP ou clivage?
L'un des faits marquants est l'initiative prise par certains de nos amis, associés notamment au mouvement "software craftsmanship", de redonner un coup de projecteur sur le volet technique des pratiques agiles. Cory Foy et Cory Haines ont ainsi annoncé, puis confirmé lors d'un événement "Code Retreat", en marge d'Agile2010, la tenue l'an prochain d'une conférence "XP Universe 2011".
L'annonce inquiète certains, qui y voient le signe d'une fragmentation de la communauté. Pour d'autres c'est une bonne nouvelle, car le contenu d'Agile2010 est très largement occupé par des sujets autres que le code: management, coaching, UX, DevOps, etc...
Pour d'autres encore c'est l'occasion de méditer sur le sens profond de cette conférence et de la marque Agile: j'ai ainsi entendu "Agile est le nom que l'on donne au courant qui s'intéresse à l'ensemble de la chaîne de valeur, et qui regroupe plusieurs disciplines qui s'intéressent chacune à un bout de la chaîne". Ca vous donne une idée des états d'âme du leadership de la communauté...
DevOps, un nouveau "courant" à surveiller
Le mot "nouveau" est tout relatif, cela fait au moins deux ans que des collègues comme Patrick Debois militent pour intégrer sous la bannière Agile des modes de collaboration plus efficaces entre développeurs et exploitants (Ops comme Opérations, d'où DevOps).
Cette année cependant ce groupe a fait parler de lui d'une part en apportant plusieurs sessions, d'autre part en mettant en scène un clone du personnage Borat ("de glorieuse nation Kazakhstan!") qui a sévi sur Twitter pendant toute la conférence. Blague à part, c'est une idée qui fait son chemin.
Lean Startup ou "Feedback Driven Development"
L'une des présentations les plus enrichissantes pour moi concernait les idées pour marier l'approche Lean Startup popularisée par Eric Ries avec les techniques de développement agile. J'ai particulièrement apprécier la présentation concrète - "voici des choses que vous pouvez faire en rentrant au boulot" - combinée avec une bonne maîtrise de la philosophie sous-jacente - "inclure vos clients finaux dans la boucle de développement de la façon la plus resserrée possible".
C'est ce mélange qui fait les meilleures sessions de nos conférences, je voudrais hélas qu'il soit plus systématique à Agile 2010 qui prend peut-être une teinte un peu spéculative, portée sur l'abstraction et l'auto-congratulation.
La certification toujours (hélas) d'actualité
J'ai eu une longue conversation avec Alistair Cockburn, une des stars de la communauté, j'avais été très déçu par son annonce pendant l'été d'un nouveau programme de certification appelé ICAgile.
Déçu parce qu'à mon sens la communauté n'a plus confiance dans les programmes de certification depuis les déboires qu'a connu la Scrum Alliance, et qu'il n'est plus temps de continuer à chercher à "refaire la même chose mais correctement". Il faut remettre les choses à plat et proposer au marché de plus en plus acheteur de compétences agiles une façon plus claire, plus crédible, d'identifier ces compétences. Le schéma de certification proposé par ICAgile me semble trop proche de ceux que nous avons déjà connus, trop flou sur les questions de gouvernance et d'éthique, trop vulnérable aux conflits d'intérêts.
Cela dit le travail d'Alistair rejoint celui de l'Institut sur au moins un point, la nécessité de formaliser un peu la cartographie de ces compétences. Au-delà, et malgré une évidente bonne volonté de sa part, nous ne sommes pas sur la même longueur d'onde.
Recherche: un fossé à combler
Une table ronde sur la recherche en matière de pratiques agiles m'a permis de faire le point avec des chercheurs et des praticiens. Participaient notamment Scott Ambler et Frank Maurer, avec deux points de vue très différents. Scott met l'accent sur le peu de données empiriques, Frank se montre pessimiste sur l'intérêt que portent les chercheurs en général aux pratiques agiles comme sujet de recherche.
Au cours de la semaine j'ai discuté avec plusieurs personnes à ce sujet et il m'est finalement venu une formule pour résumer l'ambition de l'Institut en ce qui concerne la recherche et l'enseignement: "le Génie Logiciel existe depuis 40 ans, et presque toutes les universités ont un département GL, alors que cette discipline semble n'avoir résolu aucune des difficultés qu'elle a été créée pour résoudre; l'objectif de l'Institut c'est créer des départements Agilité dans les universités, pour faire avancer l'état de l'art..."
Les prix Pask
Cette année les lauréats du prix Gordon Pask sont... des lauréates, ça nous change un peu. Le prix décerné annuellement depuis 2006 est destiné à mettre en avant deux personnes dont le comité estime que la communauté devrait les écouter, même si ce qu'elles ont à dire est un peu bizarre. Il a été attribué à Liz Keogh, infatigable pédagogue du BDD (Behaviour-Driven Development), ainsi qu'à Elizabeth Hendrickson, initiatrice d'un travail de réflexion et de synthèse sur les tests automatisés au delà du clivage test unitaire - test de recette. Le test à l'honneur, donc, et la technique, mais aussi la gent féminine.
Reprendre contact...
Comme tous les ans la conférence a été l'occasion de retrouver pas mal de collègues et amis, et de leur (re)parler du projet de l'Institut. Les retours sont unanimement positifs.
Résurgence d'XP ou clivage?
L'un des faits marquants est l'initiative prise par certains de nos amis, associés notamment au mouvement "software craftsmanship", de redonner un coup de projecteur sur le volet technique des pratiques agiles. Cory Foy et Cory Haines ont ainsi annoncé, puis confirmé lors d'un événement "Code Retreat", en marge d'Agile2010, la tenue l'an prochain d'une conférence "XP Universe 2011".
L'annonce inquiète certains, qui y voient le signe d'une fragmentation de la communauté. Pour d'autres c'est une bonne nouvelle, car le contenu d'Agile2010 est très largement occupé par des sujets autres que le code: management, coaching, UX, DevOps, etc...
Pour d'autres encore c'est l'occasion de méditer sur le sens profond de cette conférence et de la marque Agile: j'ai ainsi entendu "Agile est le nom que l'on donne au courant qui s'intéresse à l'ensemble de la chaîne de valeur, et qui regroupe plusieurs disciplines qui s'intéressent chacune à un bout de la chaîne". Ca vous donne une idée des états d'âme du leadership de la communauté...
DevOps, un nouveau "courant" à surveiller
Le mot "nouveau" est tout relatif, cela fait au moins deux ans que des collègues comme Patrick Debois militent pour intégrer sous la bannière Agile des modes de collaboration plus efficaces entre développeurs et exploitants (Ops comme Opérations, d'où DevOps).
Cette année cependant ce groupe a fait parler de lui d'une part en apportant plusieurs sessions, d'autre part en mettant en scène un clone du personnage Borat ("de glorieuse nation Kazakhstan!") qui a sévi sur Twitter pendant toute la conférence. Blague à part, c'est une idée qui fait son chemin.
Lean Startup ou "Feedback Driven Development"
L'une des présentations les plus enrichissantes pour moi concernait les idées pour marier l'approche Lean Startup popularisée par Eric Ries avec les techniques de développement agile. J'ai particulièrement apprécier la présentation concrète - "voici des choses que vous pouvez faire en rentrant au boulot" - combinée avec une bonne maîtrise de la philosophie sous-jacente - "inclure vos clients finaux dans la boucle de développement de la façon la plus resserrée possible".
C'est ce mélange qui fait les meilleures sessions de nos conférences, je voudrais hélas qu'il soit plus systématique à Agile 2010 qui prend peut-être une teinte un peu spéculative, portée sur l'abstraction et l'auto-congratulation.
La certification toujours (hélas) d'actualité
J'ai eu une longue conversation avec Alistair Cockburn, une des stars de la communauté, j'avais été très déçu par son annonce pendant l'été d'un nouveau programme de certification appelé ICAgile.
Déçu parce qu'à mon sens la communauté n'a plus confiance dans les programmes de certification depuis les déboires qu'a connu la Scrum Alliance, et qu'il n'est plus temps de continuer à chercher à "refaire la même chose mais correctement". Il faut remettre les choses à plat et proposer au marché de plus en plus acheteur de compétences agiles une façon plus claire, plus crédible, d'identifier ces compétences. Le schéma de certification proposé par ICAgile me semble trop proche de ceux que nous avons déjà connus, trop flou sur les questions de gouvernance et d'éthique, trop vulnérable aux conflits d'intérêts.
Cela dit le travail d'Alistair rejoint celui de l'Institut sur au moins un point, la nécessité de formaliser un peu la cartographie de ces compétences. Au-delà, et malgré une évidente bonne volonté de sa part, nous ne sommes pas sur la même longueur d'onde.
Recherche: un fossé à combler
Une table ronde sur la recherche en matière de pratiques agiles m'a permis de faire le point avec des chercheurs et des praticiens. Participaient notamment Scott Ambler et Frank Maurer, avec deux points de vue très différents. Scott met l'accent sur le peu de données empiriques, Frank se montre pessimiste sur l'intérêt que portent les chercheurs en général aux pratiques agiles comme sujet de recherche.
Au cours de la semaine j'ai discuté avec plusieurs personnes à ce sujet et il m'est finalement venu une formule pour résumer l'ambition de l'Institut en ce qui concerne la recherche et l'enseignement: "le Génie Logiciel existe depuis 40 ans, et presque toutes les universités ont un département GL, alors que cette discipline semble n'avoir résolu aucune des difficultés qu'elle a été créée pour résoudre; l'objectif de l'Institut c'est créer des départements Agilité dans les universités, pour faire avancer l'état de l'art..."
Les prix Pask
Cette année les lauréats du prix Gordon Pask sont... des lauréates, ça nous change un peu. Le prix décerné annuellement depuis 2006 est destiné à mettre en avant deux personnes dont le comité estime que la communauté devrait les écouter, même si ce qu'elles ont à dire est un peu bizarre. Il a été attribué à Liz Keogh, infatigable pédagogue du BDD (Behaviour-Driven Development), ainsi qu'à Elizabeth Hendrickson, initiatrice d'un travail de réflexion et de synthèse sur les tests automatisés au delà du clivage test unitaire - test de recette. Le test à l'honneur, donc, et la technique, mais aussi la gent féminine.
Reprendre contact...
Comme tous les ans la conférence a été l'occasion de retrouver pas mal de collègues et amis, et de leur (re)parler du projet de l'Institut. Les retours sont unanimement positifs.
Inscription à :
Articles (Atom)
Articles
