Affichage des articles dont le libellé est recherche. Afficher tous les articles
Affichage des articles dont le libellé est recherche. Afficher tous les articles
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.
Rétrospectives et capitalisation
Lundi, en visite chez People In Action, un des partenaires de l'Institut, j'ai eu l'occasion d'une conversation très enrichissante avec Ludovic Perot sur les rétrospectives d'itération. Les équipes de PIA utilisent des pratiques Agiles en interne depuis plus de deux ans, et disposent par conséquent d'un stock important de notes prises à l'occasion de ces rétrospectives. Avec un tel stock il est naturel de finir par se poser la question: que peut-on en faire?
Les informations collectées pendant une rétrospective constituent des données de terrain, des données empiriques dont l'exploitation peut produire de la connaissance. Encore faut-il savoir comment... et pourquoi.
Quand on parle de "connaissance" dans ce domaine, l'une des questions importantes est de savoir quels enseignements généralisables on peut tirer de notre propre expérience.
Une ou plusieurs rétrospectives peuvent nous apprendre des choses comme: "quelle que soit l'heure que nous fixons pour la réunion quotidienne Bob a toujours 10 minutes de retard", ou bien "les repas de fin d'itération ne sont pas très motivants parce qu'on ne trouve pas de resto sympa dans le quartier". Ces informations peuvent être utiles localement - elles peuvent susciter des décisions appropriées - mais on aura du mal à les généraliser: à en tirer quelque chose d'utile pour d'autres projets ou pour d'autres entreprises.
Un enseignement qui se généralise bien pourra souvent s'exprimer sous la forme d'une règle, d'un mécanisme, ou d'un principe: "à chaque fois que A on observe B", ou "dans un contexte caractérisé par X, la pratique Y est plus bénéfique que la pratique Z".
On pourrait établir une hiérarchie des moyens utilisés pour traiter des données empiriques de terrain, selon l'opportunité qu'elles offrent d'en tirer des conclusions généralisables:
Pour l'instant il reste encore difficile de mener des études au-delà de l'échelle d'une seule entreprise (l'étude PPO de l'Institut étant une des rares initiatives dans ce domaine sur le sujet des pratiques Agiles), mais je trouve intéressante l'idée d'agréger les résultats de nombreuses rétrospectives.
D'une part le retour d'expérience est une forme très intéressante, et à juste titre mise en avant dans de nombreuses conférences: il permet à ceux qui y assistent de juger par eux-mêmes dans quelle mesure les résultats présentés peuvent être liés à des facteurs locaux ou sont potentiellement généralisables à leur propre contexte. De nombreuses pratiques Agiles se sont diffusées précisément de cette façon: parce que ceux qui les avaient expérimentées lors d'un ou plusieurs projets en on fait état lors d'une conférence, propageant l'idée à des personnes dans l'assistance qui, à leur tour, quelques mois ou années plus tard étaient venus présenter des résultats positifs à une prochaine édition.
Mais le retour d'expérience "véridique" est parfois difficile à distinguer d'un discours plus commercial. Sous couvert de dire "voici ce que nous avons fait et pourquoi, et comment ça s'est passé" j'ai trop souvent assisté à des sessions qui ressemblaient à une brochure publicitaire.
L'utilisation de rapports authentiques collectés lors des rétrospectives d'itération et de projet me semble être un très bon moyen de vérifier la sincérité d'un retour d'expérience.
En l'occurrence, chez PIA la démarche adoptée a été de comptabiliser les sujets qui revenaient le plus fréquemment lors des rétrospectives d'itération afin d'établir un "hit parade" des pratiques Agiles les plus discutées. Il en sortira au minimum un billet sur le blog de PIA, mais j'ai aussi insisté auprès de Ludovic pour qu'il envisage de proposer une session à une prochaine conférence.
Cette conversation m'a également donné une idée pour une exploitation un peu plus formelle des rétrospectives d'itération que je vous exposerai dans un prochain billet.
Les informations collectées pendant une rétrospective constituent des données de terrain, des données empiriques dont l'exploitation peut produire de la connaissance. Encore faut-il savoir comment... et pourquoi.
Quand on parle de "connaissance" dans ce domaine, l'une des questions importantes est de savoir quels enseignements généralisables on peut tirer de notre propre expérience.
Une ou plusieurs rétrospectives peuvent nous apprendre des choses comme: "quelle que soit l'heure que nous fixons pour la réunion quotidienne Bob a toujours 10 minutes de retard", ou bien "les repas de fin d'itération ne sont pas très motivants parce qu'on ne trouve pas de resto sympa dans le quartier". Ces informations peuvent être utiles localement - elles peuvent susciter des décisions appropriées - mais on aura du mal à les généraliser: à en tirer quelque chose d'utile pour d'autres projets ou pour d'autres entreprises.
Un enseignement qui se généralise bien pourra souvent s'exprimer sous la forme d'une règle, d'un mécanisme, ou d'un principe: "à chaque fois que A on observe B", ou "dans un contexte caractérisé par X, la pratique Y est plus bénéfique que la pratique Z".
On pourrait établir une hiérarchie des moyens utilisés pour traiter des données empiriques de terrain, selon l'opportunité qu'elles offrent d'en tirer des conclusions généralisables:
- une unique rétrospective d'itération ne permet que de formuler des hypothèses - elle concerne des éléments très ponctuels, qu'il est difficile de généraliser même s'ils sont localement utiles
- l'accumulation de plusieurs rétrospectives d'itération, voire une rétrospective de projet, permet de tirer des conclusions plus claires sur le fonctionnement d'une équipe en particulier: on peut espérer qu'elles se généralisent à de futurs projets confiés à cette même équipe
- la comparaison entre les expériences de plusieurs équipes au sein d'une même entreprise (souvent formalisée par un retour d'expérience) permet de dégager des conclusions plus robustes: si plusieurs équipes ont des expériences convergentes (par exemple "le binômage est une pratique efficace") on peut penser que ces observations s'expliquent par des raisons qui ne dépendent pas de l'équipe (mais peuvent dépendre de facteurs locaux, comme le management ou la culture de l'entreprise)
- la comparaison entre les expériences de nombreuses équipes dans des entreprises ou des contextes différents, par exemple dans le cadre d'une étude statistique, permet de tirer des conclusions plus générales encore.
Pour l'instant il reste encore difficile de mener des études au-delà de l'échelle d'une seule entreprise (l'étude PPO de l'Institut étant une des rares initiatives dans ce domaine sur le sujet des pratiques Agiles), mais je trouve intéressante l'idée d'agréger les résultats de nombreuses rétrospectives.
D'une part le retour d'expérience est une forme très intéressante, et à juste titre mise en avant dans de nombreuses conférences: il permet à ceux qui y assistent de juger par eux-mêmes dans quelle mesure les résultats présentés peuvent être liés à des facteurs locaux ou sont potentiellement généralisables à leur propre contexte. De nombreuses pratiques Agiles se sont diffusées précisément de cette façon: parce que ceux qui les avaient expérimentées lors d'un ou plusieurs projets en on fait état lors d'une conférence, propageant l'idée à des personnes dans l'assistance qui, à leur tour, quelques mois ou années plus tard étaient venus présenter des résultats positifs à une prochaine édition.
Mais le retour d'expérience "véridique" est parfois difficile à distinguer d'un discours plus commercial. Sous couvert de dire "voici ce que nous avons fait et pourquoi, et comment ça s'est passé" j'ai trop souvent assisté à des sessions qui ressemblaient à une brochure publicitaire.
L'utilisation de rapports authentiques collectés lors des rétrospectives d'itération et de projet me semble être un très bon moyen de vérifier la sincérité d'un retour d'expérience.
En l'occurrence, chez PIA la démarche adoptée a été de comptabiliser les sujets qui revenaient le plus fréquemment lors des rétrospectives d'itération afin d'établir un "hit parade" des pratiques Agiles les plus discutées. Il en sortira au minimum un billet sur le blog de PIA, mais j'ai aussi insisté auprès de Ludovic pour qu'il envisage de proposer une session à une prochaine conférence.
Cette conversation m'a également donné une idée pour une exploitation un peu plus formelle des rétrospectives d'itération que je vous exposerai dans un prochain billet.
Une Revue des Logiciels et Projets Agiles?
Il m'est arrivé de parler à des collègues chercheurs dans le milieu universitaire, aussi bien en France qu'à l'étranger, et de leur poser la question: "Comment se fait-il qu'on voit si peu de recherche spécifiquement sur les approches Agiles?" J'en connais plusieurs qui s'y intéressent et travaillent "officiellement" sur des sujets connexes, par exemple en génie logiciel. Mais ils ne publient pas ou peu d'études visant à analyser précisément telle ou telle pratique, tel ou tel discours porté par la communauté Agile.
Quand je m'en étonne, ils me font remarquer la chose suivante: pour un scientifique, un critère d'évaluation important de son travail est la production de publications acceptées par des revues réputées dans son domaine. Produire un "papier" qui ne trouverait pas un débouché dans une publication reconnue comme ayant un caractère scientifique constituerait un travail en pure perte. (Dans le secteur privé, un chercheur est un salarié, il ne rend finalement de comptes qu'à son employeur, et pour peu qu'il ait un manager éclairé il se verra imposer peu de contraintes. Il est possible que cette tyrannie des "bonnes" revues pour publier soit moins contraignante dans ce contexte.)
Il n'existe pas, à ma connaissance, de revues scientifiques spécifiquement consacrées à l'etude des pratiques Agiles. Par conséquent, on ne publie pas sur ce sujet. Mais, bien évidemment, l'absence de travaux dans ce domaine contribue à pérenniser la fracture entre recherche et industrie, ce qui fait que les intervenants des projets Agiles pensent que le travail des chercheurs ne les concerne pas. L'industrie n'en faisant pas la demande, la recherche de son côté continue à ne pas s'intéresser à ce sujet, et a peu de chance de vouloir reconnaître sa pertinence. Cela ressemble pas mal à un cercle vicieux!
Pourtant on peut facilement se convaincre qu'un canal de publication de ce type est nécessaire.
Le modèle consacré est celui de l'évaluation par les pairs ("peer review"), les publications se dotant d'un comité de lecture dont le rôle est de filtrer les travaux proposés pour veiller à ce que ce qui est publié répond à des critères de qualité spécifiques: il s'agit en fait d'assurer la bonne "circulation des références" comme l'a analysé Bruno Latour, vérifier par exemple que les chercheurs sont au courant des travaux précédemment effectués dans leur domaine, les référencent et les sites, que leurs études permettent de combler les lacunes de ces antécédents et ainsi consolider les connaissances.
Ainsi beaucoup de travaux portant sur des sujets tels que le développement par les tests ou la programmation en binômes souffrent d'un travers élémentaire: ils sont réalisés par des chercheurs qui utilisent leurs propres étudiants comme sujets d'étude. Mais, par définition, il s'agit d'une population non pas de programmeurs en exercice, mais de programmeurs en devenir! Pire encore, le protocole expérimental prévoit généralement un temps ridiculement court pour former ces sujets d'étude à la pratique dont on cherche à discerner les bénéfices.
On va donc passer une après-midi ou une journée à expliquer le développement par les tests (TDD) à des étudiants, puis comparer leur performance à celle d'autres étudiants, la condition expérimentale consistant pour l'essentiel à ce qu'un des deux groupes reçoit l'instruction "utilisez ce qu'on vous a appris". Quelle que soit la rigueur de l'analyse statistique qui vient ensuite, il est impensable de tirer de telles études la moindre conclusion définitive quant à l'intérêt que le TDD peut avoir en entreprise. Et ces études, même quand on les qualifie prudemment de "préliminaires", sont rarement suivies de nouvelles visant à corriger ces lacunes. Pour la simple et bonne raison qu'intervenir en entreprise coûte plus cher, et exige de surmonter la réticence, compréhensible mais pas nécessairement appropriée, de ces dernières à inviter des chercheurs dans leurs bureaux pour regarder de près ce qui s'y passe.
Fédérer en réseau les chercheurs qui oeuvrent dans ce domaine, et à terme contribuer à la création d'une telle revue, est une mission tout à fait naturelle pour l'Institut Agile. L'objectif est de produire des connaissances affranchies des opinions et idéologies qui soient utiles aux intervenants des projets Agiles.
Quand je m'en étonne, ils me font remarquer la chose suivante: pour un scientifique, un critère d'évaluation important de son travail est la production de publications acceptées par des revues réputées dans son domaine. Produire un "papier" qui ne trouverait pas un débouché dans une publication reconnue comme ayant un caractère scientifique constituerait un travail en pure perte. (Dans le secteur privé, un chercheur est un salarié, il ne rend finalement de comptes qu'à son employeur, et pour peu qu'il ait un manager éclairé il se verra imposer peu de contraintes. Il est possible que cette tyrannie des "bonnes" revues pour publier soit moins contraignante dans ce contexte.)
Il n'existe pas, à ma connaissance, de revues scientifiques spécifiquement consacrées à l'etude des pratiques Agiles. Par conséquent, on ne publie pas sur ce sujet. Mais, bien évidemment, l'absence de travaux dans ce domaine contribue à pérenniser la fracture entre recherche et industrie, ce qui fait que les intervenants des projets Agiles pensent que le travail des chercheurs ne les concerne pas. L'industrie n'en faisant pas la demande, la recherche de son côté continue à ne pas s'intéresser à ce sujet, et a peu de chance de vouloir reconnaître sa pertinence. Cela ressemble pas mal à un cercle vicieux!
Pourtant on peut facilement se convaincre qu'un canal de publication de ce type est nécessaire.
Le modèle consacré est celui de l'évaluation par les pairs ("peer review"), les publications se dotant d'un comité de lecture dont le rôle est de filtrer les travaux proposés pour veiller à ce que ce qui est publié répond à des critères de qualité spécifiques: il s'agit en fait d'assurer la bonne "circulation des références" comme l'a analysé Bruno Latour, vérifier par exemple que les chercheurs sont au courant des travaux précédemment effectués dans leur domaine, les référencent et les sites, que leurs études permettent de combler les lacunes de ces antécédents et ainsi consolider les connaissances.
Ainsi beaucoup de travaux portant sur des sujets tels que le développement par les tests ou la programmation en binômes souffrent d'un travers élémentaire: ils sont réalisés par des chercheurs qui utilisent leurs propres étudiants comme sujets d'étude. Mais, par définition, il s'agit d'une population non pas de programmeurs en exercice, mais de programmeurs en devenir! Pire encore, le protocole expérimental prévoit généralement un temps ridiculement court pour former ces sujets d'étude à la pratique dont on cherche à discerner les bénéfices.
On va donc passer une après-midi ou une journée à expliquer le développement par les tests (TDD) à des étudiants, puis comparer leur performance à celle d'autres étudiants, la condition expérimentale consistant pour l'essentiel à ce qu'un des deux groupes reçoit l'instruction "utilisez ce qu'on vous a appris". Quelle que soit la rigueur de l'analyse statistique qui vient ensuite, il est impensable de tirer de telles études la moindre conclusion définitive quant à l'intérêt que le TDD peut avoir en entreprise. Et ces études, même quand on les qualifie prudemment de "préliminaires", sont rarement suivies de nouvelles visant à corriger ces lacunes. Pour la simple et bonne raison qu'intervenir en entreprise coûte plus cher, et exige de surmonter la réticence, compréhensible mais pas nécessairement appropriée, de ces dernières à inviter des chercheurs dans leurs bureaux pour regarder de près ce qui s'y passe.
Fédérer en réseau les chercheurs qui oeuvrent dans ce domaine, et à terme contribuer à la création d'une telle revue, est une mission tout à fait naturelle pour l'Institut Agile. L'objectif est de produire des connaissances affranchies des opinions et idéologies qui soient utiles aux intervenants des projets Agiles.
Le social a plus d'influence sur les bugs que la technique
On peut penser ce qu'on veut de Microsoft en tant qu'entreprise, force est de constater que l'éditeur offre un terrain propice à l'étude à grande échelle des réalités du développement logiciel; et que les moyens financiers de Microsoft lui servent entre autres choses à financer une recherche privée d'un excellent niveau. L'exemple emblématique pour moi en est Nachi Nagappan, dont les travaux me fascinent.
Nagappan a repris un sujet d'étude assez ancient, la notion de susceptibilité aux bugs ("defect proneness"). Si vous découpez un logiciel en modules, et que vous comptez à l'issue d'une analyse raisonnablement rigoureuse quels modules font l'objet du plus grand nombre de corrections de défauts, vous vous rendrez compte que tous les modules ne se valent pas. Certains accumulent les casseroles, pour ainsi dire. On peut donc se demander s'il existe des régularités qui caractériseraient les modules les plus (ou les moins) susceptibles de contenir des défauts, de façon par exemple à guider le travail des testeurs.
On a beaucoup étudié les corrélations avec des mesures techniques, comme l'analyse des dépendances ou la complexité cyclomatique. Nagappan relève que c'est ignorer totalement l'aspect humain; on fait comme si le logiciel était en soi quelque chose d'objectif, une "chose" qu'on trouve telle quelle dans la nature et qu'on examine à la loupe comme un caillou ou une plante. Or ce qui est le plus important dans l'histoire c'est qu'un module ou un logiciel est produit par une organisation d'individus.
Nagappan et ses collaborateurs se sont donc penchés sur des "métriques" caractérisant l'organisation sociale des équipes responsables de divers modules dans le code, proprement garguantuesque, du système Windows 7. La culture d'entreprise de Microsoft offre un environnement relativement homogène, dans lequel des équipes bien identifiées s'occupent de modules bien identifiés, le terrain est donc favorable à une étude comparative qui analyse des caractéristiques relativement stables des équipes et des modules logiciels concernés.
Le résultat obtenu fait réfléchir (mais est-il vraiment surprenant): les paramètres "sociaux" sont plus pertinents que les paramètres "techniques" pour prédire quels modules sont les plus susceptibles de contenir des défauts.
Comme je l'ai dit précédemment il convient de rester critique, et le travail de Nagappan mobilise des outils statistiques et des critères d'évaluation ("précision" et "rappel") que je ne maîtrise pas, il me manque donc (pour l'instant) la culture nécessaire pour évaluer ces résultats.
Il me semble cependant qu'ils sont sur une bonne voie, qu'ils posent les bonnes questions.
Nagappan a repris un sujet d'étude assez ancient, la notion de susceptibilité aux bugs ("defect proneness"). Si vous découpez un logiciel en modules, et que vous comptez à l'issue d'une analyse raisonnablement rigoureuse quels modules font l'objet du plus grand nombre de corrections de défauts, vous vous rendrez compte que tous les modules ne se valent pas. Certains accumulent les casseroles, pour ainsi dire. On peut donc se demander s'il existe des régularités qui caractériseraient les modules les plus (ou les moins) susceptibles de contenir des défauts, de façon par exemple à guider le travail des testeurs.
On a beaucoup étudié les corrélations avec des mesures techniques, comme l'analyse des dépendances ou la complexité cyclomatique. Nagappan relève que c'est ignorer totalement l'aspect humain; on fait comme si le logiciel était en soi quelque chose d'objectif, une "chose" qu'on trouve telle quelle dans la nature et qu'on examine à la loupe comme un caillou ou une plante. Or ce qui est le plus important dans l'histoire c'est qu'un module ou un logiciel est produit par une organisation d'individus.
Nagappan et ses collaborateurs se sont donc penchés sur des "métriques" caractérisant l'organisation sociale des équipes responsables de divers modules dans le code, proprement garguantuesque, du système Windows 7. La culture d'entreprise de Microsoft offre un environnement relativement homogène, dans lequel des équipes bien identifiées s'occupent de modules bien identifiés, le terrain est donc favorable à une étude comparative qui analyse des caractéristiques relativement stables des équipes et des modules logiciels concernés.
Le résultat obtenu fait réfléchir (mais est-il vraiment surprenant): les paramètres "sociaux" sont plus pertinents que les paramètres "techniques" pour prédire quels modules sont les plus susceptibles de contenir des défauts.
Comme je l'ai dit précédemment il convient de rester critique, et le travail de Nagappan mobilise des outils statistiques et des critères d'évaluation ("précision" et "rappel") que je ne maîtrise pas, il me manque donc (pour l'instant) la culture nécessaire pour évaluer ces résultats.
Il me semble cependant qu'ils sont sur une bonne voie, qu'ils posent les bonnes questions.
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.
Folklore ou fait scientifique, comment les différencier
Ce qui est ennuyeux avec les opinions, c'est que chacun a la sienne. Et vous trouverez tout et son contraire. "Le développement par les tests élimine les bugs", affirme l'un. "Le développement par les tests fiche en l'air votre architecture", prétend l'autre. La connaissance ne peut pas se diffuser que par le biais des blogs, organes d'opinion s'il en est, faute de quoi tous les débats vont durer éternellement. L'intérêt du travail des scientifiques, c'est de trancher.
Comment fonctionne le discours scientifique
Bruno Latour, l'un des observateurs les plus passionnés du véritable travail que produit la science, et aussi l'un des plus attentifs à le débarrasser de ses mythes et images d'Epinal qui l'entourent, nous donne plusieurs pistes pour mieux évaluer le statut d'une recherche en cours, qui n'a pas encore abouti; ce qu'il nomme une controverse.
(J'ai découvert les écrits de Bruno Latour lorsqu'on m'a recommandé de lire Aramis ou l'Amour des Techniques. Ce livre a totalement changé ma façon de voir les projets informatiques, bien qu'il concerne un autre domaine technologique: les transports en commun. Depuis, je le recommande vivement à tous les chefs de projets, architectes, ingénieurs et managers de mon entourage; c'est un de mes livres indispensables. Il révèle Latour comme un observateur tenace et minutieux, avec une incroyable capacité à aller au fond des choses dans le domaine des sciences et techniques. Il se lit comme un roman, ce qui ne gâte rien.)
Latour attire notre attention en particulier sur la structure modale du discours scientifique. Cette expression barbarbe désigne quelque chose de tout simple. Vous partez d'un simple énoncé: "L'eau bout à 100 degrés." Une modalité est quelque chose qui vient, sans modifier cet énoncé mais en le complétant, lui donner un statut différent: "Si je me souviens bien, l'eau bout à 100 degrés" exprimerait de l'incertitude. "Tout le monde sait que l'eau bout à 100 degrés" au contraire renforce l'autorité du discours. "Les scientifiques savent que l'eau bout à 100 degrés" aurait une connotation légérement différente, celle d'un savoir pas nécessairement partagé par le commun des mortels.
Dans la pratique des sciences, une publication joue le rôle d'une (très longue) modalité. Un chercheur souhaite affirmer une conclusion: "l'eau bout à 100 degrés". Il doit dans un premier temps, c'est la convention de sa profession, la présenter avec des pincettes: "sous réserve des questions de validité soulevées ci-dessus, et au vu de nos mesures expérimentales il nous semble possible d'affirmer que l'intervalle de confiance à 95% situe le point d'ébullition d'H20 à 100 degrés plus ou moins 0,01 dans les conditions expérimentales". Le reste de la publication (du "papier") tient lieu d'autant de précautions qui visent à relativiser l'énoncé final.
Une expérience ou une étude n'étant jamais suffisante pour asseoir un fait scientifique, d'autres "papier" vont poursuivre ces travaux, qu'ils soient écrits par le même chercheur ou par ses confrères. Il faut pour cela que les travaux initiaux soient intéressants, ce qui est souvent un premier filtre; sans doute l'immense majorité des "papiers" publiés n'est jamais cité par d'autres scientifiques. La citation joue donc un rôle capital dans l'acquisition du statut de "fait scientifique".
La citation est elle-même une modalité, souvent complétée par un degré de confiance: "Un travail préliminaire de Dupont (2001) suggère que l'eau bout à 100 degrés. Nous présentons une réplication utilisant un équipement différent mais aboutissant à des conclusions qui semblent confirmer ce résultat, avec une légère variation." L'accumulation des citations d'un "papier" donné est souvent une mesure de son importance, et si l'énoncé fini par se confirmer il établira la paternité du fait en question.
Ce que Latour met en lumière c'est que l'établissement d'un fait scientifique s'accompagne de la disparition progressive des modalités. Ainsi l'étape suivante est-elle: "De nombreuses études ont mis en évidence que le point d'ébullition de l'eau se situe autour de 100 degrés (Dupont 2001, Durand 2002, Dupont 2003, Bogdanoff 2010), mais avec de légères variations; nous montrons que ce point d'ébullition dépend de la pression atmosphérique et selon quelle équation." Un peu plus loin encore, on commence à ne plus citer les auteurs: "Il est désormais établi que l'eau bout à 100 degrés à pression atmosphérique normale; nous étudions les effets de l'adjonction de sel dans l'eau."
Au stade ultime de l'acceptation d'un fait scientifique, celui-ci est d'une part débarrassé de toute modalité ("l'eau bout à 100 degrés") mais plus important encore devient opérationnel pour produire d'autres connaissances, ou des effets techniques utiles: "pour obtenir une température de 100 degrés nous portons de l'eau à ébullition". (Pour des exemples plus réalistes, lisez La vie de laboratoire de Latour et Woolgar.)
Evidemment, ce qui fait de ce jeu de citations une démarche proprement scientifique, c'est son caractère expérimental et contradictoire; cette réduction des modalités n'est pas inexorable, et une étude préliminaire largement citée peut se voir mise en défaut par des études postérieures.
L'autre cas de figure, c'est que le prétendu "fait" ne se débarrasse jamais tout à fait de ces modalités; il reste indéfiniment entâché de soupçon, et si personne ne s'y intéresse assez pour y donner suite dans de nouvelles publications, il tombe dans l'oubli, ou pire, s'incruste dans le discours collectif à l'état de folklore.
Que sait-on sur la productivité des programmeurs?
Prenons par exemple un "fait" largement cité dans le monde informatique, celui selon lequel "la productivité des programmeurs varie dans un rapport de 1 à 10 (ou 5, ou 20) entre les moins bons et les meilleurs". C'est un énoncé surprenant, ne serait-ce que pour ses implications en entreprise: les écarts de salaires entre programmeurs, par exemple, ne sont certainement pas de cet ordre.
A quand remonte cet énoncé? Coincidence amusante, la première étude à faire état de ces disparités remonte apparemment à 1968. C'est une "vraie" étude scientifique, qui au départ cherche à comparer, dans deux conditions expérimentales, la performance de programmeurs confrontés à une tâche de mise au point (debugging). Les temps de programmation sont collectés au cours de l'étude mais n'en sont pas le sujet principal. L'étude trouve de façon statistiquement significative que l'une des deux conditions de travail ("online" c'est à dire en mode interactif avec le compilateur) améliore légèrement la performance. Elle note par contre comme une observation surprenante la très grande magnitude des écarts entre les "scores" obtenus par les différents sujets de l'étude, sur diverses mesures de performance.
Cette étude fait rapidement l'objet de diverses critiques, à la suite desquelles on pourrait penser que d'autres recherches vont tenter de confirmer ou d'infirmer ces observations, activité dont on devrait retrouver, quarante ans plus tard, des traces conformes à ce qu'explique Latour: réduction des modalités et transformation en "fait scientifique".
En fait il n'en est rien. Aussi surprenant que cela puisse paraître, quarante ans après le résultat initial, l'énoncé reste aujourd'hui accompagné de ses modalités: chaque fois que j'ai l'occasion de lire ou d'entendre cette observation, c'est sous la forme "de nombreuses études montrent que la productivité varie dans un rapport de 1 à 10 (ou 5, ou 20)".
Non seulement il n'a pas perdu ses modalités, mais ce "fait" ne s'est toujours pas transformé en quelque chose d'opérationnellement utile. On ne sait pas aujourd'hui comment exploiter cette "trouvaille", par exemple en définissant des critères de recrutement qui nous permettraient d'écarter les programmeurs "fois 1" et garder préférentiellement les "fois 2 à 10". Par contre, personne ne se prive de citer cette "observation" pour étayer un discours essentiellement idéologique: "de nombreuses études montrent ceci, donc vous devriez suivre mes conseils".
Comment tricher avec les citations
L'un des essais les mieux renseignés sur le sujet est celui de Steve McConnell, "The Origin of 10x". Publié en 2008, ce billet publié sur son blog explique le titre de ce dernier, "10x programming". Il s'agit bien entendu d'une référence aux variations de productivité. McConnell reconnaît que l'étude de 1968 a été très critiquée, mais il affirme que ses résultats ont été confirmés:
Pourquoi reste-t-on dans le folklore?
Pour moi le verdict est clair, la prétendue observation "scientifique" sur l'ordre de grandeur des variations de productivité individuelle relève du folklore, des éléments d'opinion non confirmés qui se transmettent et se perpétuent pour des raisons plus culturelles que rationelles. (Je ne prétends pas qu'il n'y a pas de variations de productivité de cet ordre: je dis simplement que ce "fait" n'est pas démontré, et qu'on ne sait pas quoi en faire.)
L'une des raisons à cela est qu'on n'est pas en mesure de cerner avec assez de précision la notion de "productivité". A l'origine, on avait tendance à mesurer en lignes de code. Avec le développement de "langages de haut niveau" on a sévèrement remis en cause cette mesure de productivité, puisqu'ils permettaient précisément de faire la même chose en moins de lignes. On a tenté de leur substituer les points de fonction, qui s'avèrent compliqués et peu utilisés par la profession. Mais la vraie question à poser est celles des hypothèses qui sous-tendent la notion de "productivité".
Par exemple, considérons-nous qu'une productivité ne peut être que positive ou nulle? C'est une hypothèse battue en brèche par la notion de "net negative productivity programmers": des membres d'une équipe qui non seulement n'apportent pas une contribution à la productivité mais détruisent celle des autres intervenants.
Faisons-nous la différence entre les efforts et les résultats? Un programmeur peut très bien sembler improductif parce qu'il fournit peu de travail, mais s'il est à l'origine d'une idée innovante qui permet de ne pas coder plusieurs fonctionnalités complexes, sa contribution est d'une grande valeur.
Une notion importante dans les sciences sociales et cognitives est celle de "construct validity", c'est à dire de répondre à la question: ce que nous mesurons a-t-il une existence réelle, et est-il réellement reflété dans les mesures avec lesquelles nous avons choisi de l'opérationnaliser? (Consultez par exemple l'article sur la psychométrie de Wikipedia.) Ces questions semblent peu posées dans notre domaine; sans doute parce que nous ne nous inspirons pas des bonnes disciplines, et je reviendrai sur ce point prochainement.
Sortir du folklore
Au fil de la construction du référentiel des pratiques Agiles, le recensement des études empiriques pertinentes et, par le jeu des citations, les faits établis ou en construction dont elles dépendent permettra, c'est en tout cas mon intention, de définir les contours de ce que nous savons et de ce que nous ne savons pas encore sur le sujet.
Ce travail ne s'arrête pas au référentiel: il est important aussi de recenser qui travaille sur ces sujets, en France notamment mais ailleurs également, et mettre en lumière les collaborations (pour l'instant encore trop rares) visant à rapprocher la communauté Agile et le milieu de la recherche. A plus long terme, l'Institut Agile cherchera à initier, ou en tout cas à apporter une contribution, à un espace permettant aux chercheurs de publier plus efficacement.
Comment fonctionne le discours scientifique
Bruno Latour, l'un des observateurs les plus passionnés du véritable travail que produit la science, et aussi l'un des plus attentifs à le débarrasser de ses mythes et images d'Epinal qui l'entourent, nous donne plusieurs pistes pour mieux évaluer le statut d'une recherche en cours, qui n'a pas encore abouti; ce qu'il nomme une controverse.
(J'ai découvert les écrits de Bruno Latour lorsqu'on m'a recommandé de lire Aramis ou l'Amour des Techniques. Ce livre a totalement changé ma façon de voir les projets informatiques, bien qu'il concerne un autre domaine technologique: les transports en commun. Depuis, je le recommande vivement à tous les chefs de projets, architectes, ingénieurs et managers de mon entourage; c'est un de mes livres indispensables. Il révèle Latour comme un observateur tenace et minutieux, avec une incroyable capacité à aller au fond des choses dans le domaine des sciences et techniques. Il se lit comme un roman, ce qui ne gâte rien.)
Latour attire notre attention en particulier sur la structure modale du discours scientifique. Cette expression barbarbe désigne quelque chose de tout simple. Vous partez d'un simple énoncé: "L'eau bout à 100 degrés." Une modalité est quelque chose qui vient, sans modifier cet énoncé mais en le complétant, lui donner un statut différent: "Si je me souviens bien, l'eau bout à 100 degrés" exprimerait de l'incertitude. "Tout le monde sait que l'eau bout à 100 degrés" au contraire renforce l'autorité du discours. "Les scientifiques savent que l'eau bout à 100 degrés" aurait une connotation légérement différente, celle d'un savoir pas nécessairement partagé par le commun des mortels.
Dans la pratique des sciences, une publication joue le rôle d'une (très longue) modalité. Un chercheur souhaite affirmer une conclusion: "l'eau bout à 100 degrés". Il doit dans un premier temps, c'est la convention de sa profession, la présenter avec des pincettes: "sous réserve des questions de validité soulevées ci-dessus, et au vu de nos mesures expérimentales il nous semble possible d'affirmer que l'intervalle de confiance à 95% situe le point d'ébullition d'H20 à 100 degrés plus ou moins 0,01 dans les conditions expérimentales". Le reste de la publication (du "papier") tient lieu d'autant de précautions qui visent à relativiser l'énoncé final.
Une expérience ou une étude n'étant jamais suffisante pour asseoir un fait scientifique, d'autres "papier" vont poursuivre ces travaux, qu'ils soient écrits par le même chercheur ou par ses confrères. Il faut pour cela que les travaux initiaux soient intéressants, ce qui est souvent un premier filtre; sans doute l'immense majorité des "papiers" publiés n'est jamais cité par d'autres scientifiques. La citation joue donc un rôle capital dans l'acquisition du statut de "fait scientifique".
La citation est elle-même une modalité, souvent complétée par un degré de confiance: "Un travail préliminaire de Dupont (2001) suggère que l'eau bout à 100 degrés. Nous présentons une réplication utilisant un équipement différent mais aboutissant à des conclusions qui semblent confirmer ce résultat, avec une légère variation." L'accumulation des citations d'un "papier" donné est souvent une mesure de son importance, et si l'énoncé fini par se confirmer il établira la paternité du fait en question.
Ce que Latour met en lumière c'est que l'établissement d'un fait scientifique s'accompagne de la disparition progressive des modalités. Ainsi l'étape suivante est-elle: "De nombreuses études ont mis en évidence que le point d'ébullition de l'eau se situe autour de 100 degrés (Dupont 2001, Durand 2002, Dupont 2003, Bogdanoff 2010), mais avec de légères variations; nous montrons que ce point d'ébullition dépend de la pression atmosphérique et selon quelle équation." Un peu plus loin encore, on commence à ne plus citer les auteurs: "Il est désormais établi que l'eau bout à 100 degrés à pression atmosphérique normale; nous étudions les effets de l'adjonction de sel dans l'eau."
Au stade ultime de l'acceptation d'un fait scientifique, celui-ci est d'une part débarrassé de toute modalité ("l'eau bout à 100 degrés") mais plus important encore devient opérationnel pour produire d'autres connaissances, ou des effets techniques utiles: "pour obtenir une température de 100 degrés nous portons de l'eau à ébullition". (Pour des exemples plus réalistes, lisez La vie de laboratoire de Latour et Woolgar.)
Evidemment, ce qui fait de ce jeu de citations une démarche proprement scientifique, c'est son caractère expérimental et contradictoire; cette réduction des modalités n'est pas inexorable, et une étude préliminaire largement citée peut se voir mise en défaut par des études postérieures.
L'autre cas de figure, c'est que le prétendu "fait" ne se débarrasse jamais tout à fait de ces modalités; il reste indéfiniment entâché de soupçon, et si personne ne s'y intéresse assez pour y donner suite dans de nouvelles publications, il tombe dans l'oubli, ou pire, s'incruste dans le discours collectif à l'état de folklore.
Que sait-on sur la productivité des programmeurs?
Prenons par exemple un "fait" largement cité dans le monde informatique, celui selon lequel "la productivité des programmeurs varie dans un rapport de 1 à 10 (ou 5, ou 20) entre les moins bons et les meilleurs". C'est un énoncé surprenant, ne serait-ce que pour ses implications en entreprise: les écarts de salaires entre programmeurs, par exemple, ne sont certainement pas de cet ordre.
A quand remonte cet énoncé? Coincidence amusante, la première étude à faire état de ces disparités remonte apparemment à 1968. C'est une "vraie" étude scientifique, qui au départ cherche à comparer, dans deux conditions expérimentales, la performance de programmeurs confrontés à une tâche de mise au point (debugging). Les temps de programmation sont collectés au cours de l'étude mais n'en sont pas le sujet principal. L'étude trouve de façon statistiquement significative que l'une des deux conditions de travail ("online" c'est à dire en mode interactif avec le compilateur) améliore légèrement la performance. Elle note par contre comme une observation surprenante la très grande magnitude des écarts entre les "scores" obtenus par les différents sujets de l'étude, sur diverses mesures de performance.
Cette étude fait rapidement l'objet de diverses critiques, à la suite desquelles on pourrait penser que d'autres recherches vont tenter de confirmer ou d'infirmer ces observations, activité dont on devrait retrouver, quarante ans plus tard, des traces conformes à ce qu'explique Latour: réduction des modalités et transformation en "fait scientifique".
En fait il n'en est rien. Aussi surprenant que cela puisse paraître, quarante ans après le résultat initial, l'énoncé reste aujourd'hui accompagné de ses modalités: chaque fois que j'ai l'occasion de lire ou d'entendre cette observation, c'est sous la forme "de nombreuses études montrent que la productivité varie dans un rapport de 1 à 10 (ou 5, ou 20)".
Non seulement il n'a pas perdu ses modalités, mais ce "fait" ne s'est toujours pas transformé en quelque chose d'opérationnellement utile. On ne sait pas aujourd'hui comment exploiter cette "trouvaille", par exemple en définissant des critères de recrutement qui nous permettraient d'écarter les programmeurs "fois 1" et garder préférentiellement les "fois 2 à 10". Par contre, personne ne se prive de citer cette "observation" pour étayer un discours essentiellement idéologique: "de nombreuses études montrent ceci, donc vous devriez suivre mes conseils".
Comment tricher avec les citations
L'un des essais les mieux renseignés sur le sujet est celui de Steve McConnell, "The Origin of 10x". Publié en 2008, ce billet publié sur son blog explique le titre de ce dernier, "10x programming". Il s'agit bien entendu d'une référence aux variations de productivité. McConnell reconnaît que l'étude de 1968 a été très critiquée, mais il affirme que ses résultats ont été confirmés:
the general finding [...] has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).Rien ne fait plus "scientifique" que cette litanie de citations. Mais qu'en est-il en regardant de plus près?
- L'étude de Curtis de 1981 porte sur 60 programmeurs confrontés à nouveau à une tâche de mise au point et non de programmation.
- L'article de Curtis de 1984 n'est pas une étude, mais un appel à mieux intégrer les sciences cognitives dans le génie logiciel. (Au demeurant je rejoins Curtis à ce sujet, mais j'y reviendrai.)
- La citation de Mills 1983 se réfère à un livre regroupant divers essais sur la productivité, essentiellement des retours d'expérience et articles d'opinion, mais aucun qui porte sur une réplication de l'étude originelle.
- De même pour DeMarco et Lister 1985, il s'agit du célèbre "Peopleware", pavé jeté dans la mare d'une certaine forme de management par la presssion malheureusement toujours en vogue de nos jours; les seules "études" relatées portent sur des compétitions de programmation organisées par les auteurs, dans des conditions peu contrôlées (les participants devaient réaliser les exercises proposés sur leur lieu de travail et pendant les heures de bureau).
- La référence Card 1987 n'est pas une publication scientifique mais le rapport d'activité d'un laboratoire privé, où apparaissent quelques tableaux de synthèse dont aucun ne semble directement confirmer "des écarts de productivité de 1 à 10"
- La référence Boehm et Papaccio 1988 est un travail de synthèse qui cite plusieurs autres publications, la seule qui soit citée sur les variations de productivité étant... l'étude de 1968!
- Je n'ai pas pu vérifier la référence Boehm 2000 (de toutes façons, un livre sur COCOMO et non une publication scientifique)
- Une seule de ces références reproduit réellement le résultat d'origine mais indirectement, c'est Valett 1989, rapportant une étude de 1982 qui mesure la productivité en nombre de lignes de code (une approche fortement critiquée depuis) et fait apparaître des disparités dans un rapport de 1 à 8 sur de "petits" projets (moins de 20K lignes) et dans un rapport de 1 à 20 sur les gros projets. Comme il s'agit d'une citation d'une citation, presque aucun détail sur la méthode de collecte de données n'est disponible.
Pourquoi reste-t-on dans le folklore?
Pour moi le verdict est clair, la prétendue observation "scientifique" sur l'ordre de grandeur des variations de productivité individuelle relève du folklore, des éléments d'opinion non confirmés qui se transmettent et se perpétuent pour des raisons plus culturelles que rationelles. (Je ne prétends pas qu'il n'y a pas de variations de productivité de cet ordre: je dis simplement que ce "fait" n'est pas démontré, et qu'on ne sait pas quoi en faire.)
L'une des raisons à cela est qu'on n'est pas en mesure de cerner avec assez de précision la notion de "productivité". A l'origine, on avait tendance à mesurer en lignes de code. Avec le développement de "langages de haut niveau" on a sévèrement remis en cause cette mesure de productivité, puisqu'ils permettaient précisément de faire la même chose en moins de lignes. On a tenté de leur substituer les points de fonction, qui s'avèrent compliqués et peu utilisés par la profession. Mais la vraie question à poser est celles des hypothèses qui sous-tendent la notion de "productivité".
Par exemple, considérons-nous qu'une productivité ne peut être que positive ou nulle? C'est une hypothèse battue en brèche par la notion de "net negative productivity programmers": des membres d'une équipe qui non seulement n'apportent pas une contribution à la productivité mais détruisent celle des autres intervenants.
Faisons-nous la différence entre les efforts et les résultats? Un programmeur peut très bien sembler improductif parce qu'il fournit peu de travail, mais s'il est à l'origine d'une idée innovante qui permet de ne pas coder plusieurs fonctionnalités complexes, sa contribution est d'une grande valeur.
Une notion importante dans les sciences sociales et cognitives est celle de "construct validity", c'est à dire de répondre à la question: ce que nous mesurons a-t-il une existence réelle, et est-il réellement reflété dans les mesures avec lesquelles nous avons choisi de l'opérationnaliser? (Consultez par exemple l'article sur la psychométrie de Wikipedia.) Ces questions semblent peu posées dans notre domaine; sans doute parce que nous ne nous inspirons pas des bonnes disciplines, et je reviendrai sur ce point prochainement.
Sortir du folklore
Au fil de la construction du référentiel des pratiques Agiles, le recensement des études empiriques pertinentes et, par le jeu des citations, les faits établis ou en construction dont elles dépendent permettra, c'est en tout cas mon intention, de définir les contours de ce que nous savons et de ce que nous ne savons pas encore sur le sujet.
Ce travail ne s'arrête pas au référentiel: il est important aussi de recenser qui travaille sur ces sujets, en France notamment mais ailleurs également, et mettre en lumière les collaborations (pour l'instant encore trop rares) visant à rapprocher la communauté Agile et le milieu de la recherche. A plus long terme, l'Institut Agile cherchera à initier, ou en tout cas à apporter une contribution, à un espace permettant aux chercheurs de publier plus efficacement.
De l'opinion au savoir
Dans mon billet précédent je pointais ce qui me semble être des faiblesses des études actuellement les plus diffusées sur les "bénéfices de l'Agilité".
Pour ceux qui ont suivi les épisodes précédents, ce n'est pas difficile de comprendre d'où me vient cette attitude critique: d'une part parler "d'un projet Agile" en soi ne veut pas dire grand-chose, puisque ça ne nous dit rien sur ce que font les gens; d'autre part les apparences de la science ne suffisent pas à faire d'une étude quelque chose qui créée de la connaissance: le Culte du Cargo existe aussi dans le domaine scientifique.
J'ai entendu plus d'une fois l'argument suivant:
Qu'est-ce que c'est, sans vouloir chercher midi à quatorze heures, qu'un savoir scientifique? C'est un énoncé qui se vérifie de manière fiable dans toute une catégorie de situations, indépendamment des opinions de l'observateur. Par exemple "l'eau bout à 100 degrés" est une observation qui se vérifie avec beaucoup de régularité, et en particulier indépendamment de mes convictions sur ce que l'eau devrait faire à telle ou telle température, de mes décrets ou de mes incantations à ce sujet.
Certes il existe des exceptions: par exemple, si on veut faire du bon café au sommet de l'Himalaya, il vaut mieux savoir que la pression atmosphérique joue un rôle dans cette relation fiable entre l'état liquide ou gazeux de l'eau et sa température. Pour être vraiment précis, on pourra dire "l'eau bout à 100 degrés dans les conditions normales de pression et de température ambiante." Ces exceptions ne sont pas plus une affaire d'opinion que la règle à laquelle elles s'opposent. Le point d'ébullition de l'eau est un fait réel; pour reprendre une citation de Philip K. Dick: "la réalité, c'est ce qui continue d'exister même si vous cessez d'y croire".
A quelles réalités sommes-nous confrontés dans le domaine du logiciel? Elles sont de deux catégories, et malheureusement les recherches scientifiques à ce sujet ont tendance à faire, au mieux une impasse, au pire de graves contre-sens, vis-à-vis de l'une de ces catégories.
D'une part il existe la réalité de ce qu'un programme peut ou ne peut pas faire. Cette branche, c'est (dans les grandes lignes) l'algorithmique, la discipline appelée imprudemment "computer science", étrange étiquette puisqu'elle s'apparente plus aux mathématiques qu'aux sciences expérimentales et qu'elle n'étudie quasiment pas les ordinateurs. Les faits qu'on y découvre sont souvent très contre-intuitifs et leur applicabilité pratique rarement évidente. Par exemple la Thèse de Church-Turing qui permet notamment de démontrer que tous les langages de programmation et tous les ordinateurs se valent, du moins en termes de leur capacité à instantier n'importe quel processus qui peut s'exprimer sous la forme d'un programme: dans la pratique, les programmeurs professionnels sont précisément intéressés par l'inverse de cette conclusion, à savoir quel langage est le plus approprié.
La raison tient à l'autre catégorie de réalités pertinentes dans le domaine du logiciel: celles qui concernent le fonctionnement et les limitations de l'esprit humain. Nous ne nous intéressons que de loin en loin à ce qu'il est possible "en principe" à un ordinateur de faire; au quotidien, nous sommes plus concernés par leur application "en pratique", et notamment à savoir à quel coût et en combien de temps nous pouvons faire quelque chose, et quels sont les facteurs qui influent sur ces réponses.
Est-ce qu'il est impossible d'étudier le fonctionnement et les limitations de l'esprit humain? Pas du tout, la psychologie et les sciences cognitives le font depuis fort longtemps. Pour autant, il faut avancer avec prudence, parce que dès lors qu'on s'intéresse à l'humain, les opinions et croyances de l'observateur ou de l'observé ont une fâcheuse tendance à influer sur les résultats des expériences! On connait par exemple les distortions introduites par l'effet placebo, qu'on va chercher à éliminer par la mise en place de protocoles expérimentaux adaptés, tels que les protocoles en double aveugle.
L'équivalent dans notre domaine de l'effet placebo pourrait bien être l'effet Hawhthorne: lorsque des travailleurs savent qu'ils sont les sujets d'une expérience sur les conditions de travail, leur performance s'améliore, indépendamment des conditions expérimentales précises auxquelles ils sont soumis. Ce résultat souligne au passage que la motivation est un paramètre expérimental comme un autre, une observation qui a son importance. Elle peut facilement menacer la validité d'une étude scientifique sur la performance ou la productivité.
Contrairement à ce qu'on peut découvrir sur le point d'ébullition de l'eau, ces études ont aussi en commun avec, par exemple, la recherche médicale le fait de s'intéresser à des phénomènes qui sont rarement systématiques, mais au contraire présentent un aspect probabiliste. Cette difficulté vient de ce que l'esprit humain est complexe, il se compose d'un très grand nombre de processus qui contribuent de façon différente et parfois contradictoire aux résultats observés (et peuvent même interagir). Selon le processus qui l'emporte dans une situation donnée, le résultat peut être différent; il n'est généralement pas possible de reproduire la situation initiale avec assez de fidélité pour obtenir systématiquement le même résultat.
Est-il impossible d'étudier scientifiquement des phénomènes résultant, de façon probabiliste, de processus complexes? Evidemment pas; il faut par contre se doter des outils appropriés. La statistique permet de décrire les relations entre les paramètres qu'on arrive à tenir fixe d'une situation à une autre, et les résultats observés. Elle permet par exemple de mettre en évidence des corrélations, qui sont la matière première principale de très nombreuses études. Là aussi, il faut savoir rester prudent. Ce n'est pas l'outil statistique en soi qui rend scientifique une étude. Il faut savoir se méfier, par exemple, des conclusions hâtives à la lecture de simples corrélations.
Saviez-vous par exemple qu'une étude scientifique a constaté, sur un échantillon représentatif de plages touristiques, qu'il existait une nette corrélation entre le nombre de sorbets et crèmes glacées vendues par les buvettes chaque saison et le nombre de morts par noyade? On pourrait être tenté d'appeler au vote d'une loi interdisant la vente de glaces... Ce qui serait une idiotie: ce sont en fait deux paramètres corrélés à un troisième, la fréquentation des plages. S'il fait beau et chaud et qu'il vient beaucoup de monde sur la plage, on vendra plus de glaces ET il y aura (statistiquement, c'est hélas difficile à éviter) plus de noyades. Cette erreur est désignée de plusieurs façons: "cum hoc ergo propter hoc", "corrélation n'est pas causation", etc.
Raisonner de façon claire sur les phénomènes probabilistes n'est pas chose simple, parce que l'esprit humain est mal équipé pour traiter les probabilités. Je reviendrai là-dessus plus tard, lorsque j'aborderai un sujet presque totalement ignoré dans la recherche sur le génie logiciel, qui joue pourtant un rôle majeur pour expliquer la presque totalité des difficultés que nous rencontrons encore quarante ans après le "constat de crise" de notre profession: celui des biais cognitifs.
Il me semble parfaitement possible d'étudier de façon scientifique une question telle que "les approches Agiles ont-elles plus d'intérêt", mais il est clair que pour le faire il n'est pas possible de s'arrêter à une interprétation naïve de cette question. Il faut regarder de plus près, d'une part ce qu'on veut dire par une approche Agile, mais aussi ce qu'est le travail des scientifiques.
Dans le prochain billet, je reviendrai sur un exemple très concret pour illustrer un élément important de ce travail: le "fait scientifique" selon lequel la productivité des programmeurs varie dans un rapport de 1 à 20.
Pour ceux qui ont suivi les épisodes précédents, ce n'est pas difficile de comprendre d'où me vient cette attitude critique: d'une part parler "d'un projet Agile" en soi ne veut pas dire grand-chose, puisque ça ne nous dit rien sur ce que font les gens; d'autre part les apparences de la science ne suffisent pas à faire d'une étude quelque chose qui créée de la connaissance: le Culte du Cargo existe aussi dans le domaine scientifique.
J'ai entendu plus d'une fois l'argument suivant:
Ce n'est pas possible d'aborder de façon scientifique les projets logiciels, parce qu'ils sont le fait d'individus, humains et uniques, et que leurs projets sont eux-mêmes uniques.Je ne suis absolument pas d'accord.
Qu'est-ce que c'est, sans vouloir chercher midi à quatorze heures, qu'un savoir scientifique? C'est un énoncé qui se vérifie de manière fiable dans toute une catégorie de situations, indépendamment des opinions de l'observateur. Par exemple "l'eau bout à 100 degrés" est une observation qui se vérifie avec beaucoup de régularité, et en particulier indépendamment de mes convictions sur ce que l'eau devrait faire à telle ou telle température, de mes décrets ou de mes incantations à ce sujet.
Certes il existe des exceptions: par exemple, si on veut faire du bon café au sommet de l'Himalaya, il vaut mieux savoir que la pression atmosphérique joue un rôle dans cette relation fiable entre l'état liquide ou gazeux de l'eau et sa température. Pour être vraiment précis, on pourra dire "l'eau bout à 100 degrés dans les conditions normales de pression et de température ambiante." Ces exceptions ne sont pas plus une affaire d'opinion que la règle à laquelle elles s'opposent. Le point d'ébullition de l'eau est un fait réel; pour reprendre une citation de Philip K. Dick: "la réalité, c'est ce qui continue d'exister même si vous cessez d'y croire".
A quelles réalités sommes-nous confrontés dans le domaine du logiciel? Elles sont de deux catégories, et malheureusement les recherches scientifiques à ce sujet ont tendance à faire, au mieux une impasse, au pire de graves contre-sens, vis-à-vis de l'une de ces catégories.
D'une part il existe la réalité de ce qu'un programme peut ou ne peut pas faire. Cette branche, c'est (dans les grandes lignes) l'algorithmique, la discipline appelée imprudemment "computer science", étrange étiquette puisqu'elle s'apparente plus aux mathématiques qu'aux sciences expérimentales et qu'elle n'étudie quasiment pas les ordinateurs. Les faits qu'on y découvre sont souvent très contre-intuitifs et leur applicabilité pratique rarement évidente. Par exemple la Thèse de Church-Turing qui permet notamment de démontrer que tous les langages de programmation et tous les ordinateurs se valent, du moins en termes de leur capacité à instantier n'importe quel processus qui peut s'exprimer sous la forme d'un programme: dans la pratique, les programmeurs professionnels sont précisément intéressés par l'inverse de cette conclusion, à savoir quel langage est le plus approprié.
La raison tient à l'autre catégorie de réalités pertinentes dans le domaine du logiciel: celles qui concernent le fonctionnement et les limitations de l'esprit humain. Nous ne nous intéressons que de loin en loin à ce qu'il est possible "en principe" à un ordinateur de faire; au quotidien, nous sommes plus concernés par leur application "en pratique", et notamment à savoir à quel coût et en combien de temps nous pouvons faire quelque chose, et quels sont les facteurs qui influent sur ces réponses.
Est-ce qu'il est impossible d'étudier le fonctionnement et les limitations de l'esprit humain? Pas du tout, la psychologie et les sciences cognitives le font depuis fort longtemps. Pour autant, il faut avancer avec prudence, parce que dès lors qu'on s'intéresse à l'humain, les opinions et croyances de l'observateur ou de l'observé ont une fâcheuse tendance à influer sur les résultats des expériences! On connait par exemple les distortions introduites par l'effet placebo, qu'on va chercher à éliminer par la mise en place de protocoles expérimentaux adaptés, tels que les protocoles en double aveugle.
L'équivalent dans notre domaine de l'effet placebo pourrait bien être l'effet Hawhthorne: lorsque des travailleurs savent qu'ils sont les sujets d'une expérience sur les conditions de travail, leur performance s'améliore, indépendamment des conditions expérimentales précises auxquelles ils sont soumis. Ce résultat souligne au passage que la motivation est un paramètre expérimental comme un autre, une observation qui a son importance. Elle peut facilement menacer la validité d'une étude scientifique sur la performance ou la productivité.
Contrairement à ce qu'on peut découvrir sur le point d'ébullition de l'eau, ces études ont aussi en commun avec, par exemple, la recherche médicale le fait de s'intéresser à des phénomènes qui sont rarement systématiques, mais au contraire présentent un aspect probabiliste. Cette difficulté vient de ce que l'esprit humain est complexe, il se compose d'un très grand nombre de processus qui contribuent de façon différente et parfois contradictoire aux résultats observés (et peuvent même interagir). Selon le processus qui l'emporte dans une situation donnée, le résultat peut être différent; il n'est généralement pas possible de reproduire la situation initiale avec assez de fidélité pour obtenir systématiquement le même résultat.
Est-il impossible d'étudier scientifiquement des phénomènes résultant, de façon probabiliste, de processus complexes? Evidemment pas; il faut par contre se doter des outils appropriés. La statistique permet de décrire les relations entre les paramètres qu'on arrive à tenir fixe d'une situation à une autre, et les résultats observés. Elle permet par exemple de mettre en évidence des corrélations, qui sont la matière première principale de très nombreuses études. Là aussi, il faut savoir rester prudent. Ce n'est pas l'outil statistique en soi qui rend scientifique une étude. Il faut savoir se méfier, par exemple, des conclusions hâtives à la lecture de simples corrélations.
Saviez-vous par exemple qu'une étude scientifique a constaté, sur un échantillon représentatif de plages touristiques, qu'il existait une nette corrélation entre le nombre de sorbets et crèmes glacées vendues par les buvettes chaque saison et le nombre de morts par noyade? On pourrait être tenté d'appeler au vote d'une loi interdisant la vente de glaces... Ce qui serait une idiotie: ce sont en fait deux paramètres corrélés à un troisième, la fréquentation des plages. S'il fait beau et chaud et qu'il vient beaucoup de monde sur la plage, on vendra plus de glaces ET il y aura (statistiquement, c'est hélas difficile à éviter) plus de noyades. Cette erreur est désignée de plusieurs façons: "cum hoc ergo propter hoc", "corrélation n'est pas causation", etc.
Raisonner de façon claire sur les phénomènes probabilistes n'est pas chose simple, parce que l'esprit humain est mal équipé pour traiter les probabilités. Je reviendrai là-dessus plus tard, lorsque j'aborderai un sujet presque totalement ignoré dans la recherche sur le génie logiciel, qui joue pourtant un rôle majeur pour expliquer la presque totalité des difficultés que nous rencontrons encore quarante ans après le "constat de crise" de notre profession: celui des biais cognitifs.
Il me semble parfaitement possible d'étudier de façon scientifique une question telle que "les approches Agiles ont-elles plus d'intérêt", mais il est clair que pour le faire il n'est pas possible de s'arrêter à une interprétation naïve de cette question. Il faut regarder de plus près, d'une part ce qu'on veut dire par une approche Agile, mais aussi ce qu'est le travail des scientifiques.
Dans le prochain billet, je reviendrai sur un exemple très concret pour illustrer un élément important de ce travail: le "fait scientifique" selon lequel la productivité des programmeurs varie dans un rapport de 1 à 20.
Recherche: garder l'esprit critique
Merci à Claude d'avoir pris le temps d'une réponse point par point à mon billet précédent sur les "cinq défis". Le titre que j'avais initialement choisi était "Quelques lacunes persistantes", mais finalement il m'avait semblé plus constructif de le formuler comme une série d'objectifs à se donner.
Je trouve les réponses de Claude un peu optimistes. Certes, sur ces cinq points il existe des signes prometteurs. Mais ce qui m'intéresse c'est la "vélocité" observée dans la communauté pour y apporter des réponses complètes. Le boulet de la certification, voilà déjà plusieurs années que nous le traînons, et les choses n'évoluent pas dans un sens positif: nous avions jusqu'à présent une seule organisation proposant de la certification (la Scrum Alliance), il y en a maintenant deux depuis le départ de Ken Schwaber.
De même les progrès faits en matière de preuve empirique sont très, très insuffisants. Claude fournit un pointeur vers une présentation de Mike Cohn, sur les bénéfices mesurés des approches Agiles.
La première chose à observer c'est que s'intéresser uniquement aux bénéfices est en soi une approche biaisée! Faire de la recherche, c'est répondre à une question - "qu'est-ce qui change quand on introduit telle pratique, et pourquoi" - sans avoir écrit d'avance la réponse.
La présentation de Mike Cohn s'appuie sur plusieurs sources, dont plusieurs ont une validité d'emblée contestable: par exemple les questionnaires que fait circuler Scott Ambler, ou ceux de Version One (un éditeur d'outils de gestion de projet). J'ai eu l'occasion de discuter brièvement de ce sujet avec Scott à l'occasion d'Agile 2010, et il est le premier à le reconnaître: un questionnaire diffusé par Internet est totalement inadéquat pour mesurer l'effet réel des pratiques sur le terrain. Au mieux peut-on le considérer comme un sondage d'opinion, évaluant la popularité relative des pratiques Agiles parmi une population auto-sélectionnée de personnes s'intéressant déjà à ce sujet.
L'étude empirique la plus solide citée par Mike Cohn est celle de Michael Mah, "How Agile Projects Measure Up", basée sur une importante collecte de données terrain. La présentation de Mike Cohn reprend plusieurs graphes, apparemment issus de cette étude. Quand on y regarde de plus près, on s'aperçoit que la base de données évoquée par Michael Mah contient un total de 7500 projets. Impressionnant, certes... Mais sur ce nombre, seuls 23 sont des projets agiles! Et encore, on ne nous dit pas sur quels critères ces 23 ont été retenus parmi 7500 pour faire partie de ce lot, ni (ce qui est plus important) quel critère d'exclusion a permis d'écarter tous les autres. L'un de ces projets prétendument "Agile" mobilisait 1000 développeurs, ce qui laisse perplexe. Il me semble difficile de revendiquer une pertinence statistique pour un tel échantillon.
La présentation de Mike Cohn présente d'autres aspects troublants vis-à-vis de cette étude. Ainsi, page 5 apparaît un graphe opposant en abcisse la taille des projets, en ordonnée leur productivité. Ce graphe est tout simplement introuvable dans le rapport publié par Michael Mah: à tout le moins, le mécanisme de la citation, par lequel le discours scientifique permet de remonter aux sources et aux données originales, n'est pas utilisé correctement dans ce cas de figure.
Si nous citons des études scientifiques à l'appui de notre discours sur les méthodes agiles, il est important de ne pas nous laisser abuser par notre propre conviction. Nous devons être tout aussi critiques vis-à-vis des études qui font apparaître des résultats favorables que nous le sommes vis-à-vis de celles affichant des résultats négatifs, et nous devons nous intéresser également à chacune de ces deux catégories. Faute de quoi, nous ne sommes pas dans une approche empirique, mais tout simplement dans de la propagande.
Je trouve les réponses de Claude un peu optimistes. Certes, sur ces cinq points il existe des signes prometteurs. Mais ce qui m'intéresse c'est la "vélocité" observée dans la communauté pour y apporter des réponses complètes. Le boulet de la certification, voilà déjà plusieurs années que nous le traînons, et les choses n'évoluent pas dans un sens positif: nous avions jusqu'à présent une seule organisation proposant de la certification (la Scrum Alliance), il y en a maintenant deux depuis le départ de Ken Schwaber.
De même les progrès faits en matière de preuve empirique sont très, très insuffisants. Claude fournit un pointeur vers une présentation de Mike Cohn, sur les bénéfices mesurés des approches Agiles.
La première chose à observer c'est que s'intéresser uniquement aux bénéfices est en soi une approche biaisée! Faire de la recherche, c'est répondre à une question - "qu'est-ce qui change quand on introduit telle pratique, et pourquoi" - sans avoir écrit d'avance la réponse.
La présentation de Mike Cohn s'appuie sur plusieurs sources, dont plusieurs ont une validité d'emblée contestable: par exemple les questionnaires que fait circuler Scott Ambler, ou ceux de Version One (un éditeur d'outils de gestion de projet). J'ai eu l'occasion de discuter brièvement de ce sujet avec Scott à l'occasion d'Agile 2010, et il est le premier à le reconnaître: un questionnaire diffusé par Internet est totalement inadéquat pour mesurer l'effet réel des pratiques sur le terrain. Au mieux peut-on le considérer comme un sondage d'opinion, évaluant la popularité relative des pratiques Agiles parmi une population auto-sélectionnée de personnes s'intéressant déjà à ce sujet.
L'étude empirique la plus solide citée par Mike Cohn est celle de Michael Mah, "How Agile Projects Measure Up", basée sur une importante collecte de données terrain. La présentation de Mike Cohn reprend plusieurs graphes, apparemment issus de cette étude. Quand on y regarde de plus près, on s'aperçoit que la base de données évoquée par Michael Mah contient un total de 7500 projets. Impressionnant, certes... Mais sur ce nombre, seuls 23 sont des projets agiles! Et encore, on ne nous dit pas sur quels critères ces 23 ont été retenus parmi 7500 pour faire partie de ce lot, ni (ce qui est plus important) quel critère d'exclusion a permis d'écarter tous les autres. L'un de ces projets prétendument "Agile" mobilisait 1000 développeurs, ce qui laisse perplexe. Il me semble difficile de revendiquer une pertinence statistique pour un tel échantillon.
La présentation de Mike Cohn présente d'autres aspects troublants vis-à-vis de cette étude. Ainsi, page 5 apparaît un graphe opposant en abcisse la taille des projets, en ordonnée leur productivité. Ce graphe est tout simplement introuvable dans le rapport publié par Michael Mah: à tout le moins, le mécanisme de la citation, par lequel le discours scientifique permet de remonter aux sources et aux données originales, n'est pas utilisé correctement dans ce cas de figure.
Si nous citons des études scientifiques à l'appui de notre discours sur les méthodes agiles, il est important de ne pas nous laisser abuser par notre propre conviction. Nous devons être tout aussi critiques vis-à-vis des études qui font apparaître des résultats favorables que nous le sommes vis-à-vis de celles affichant des résultats négatifs, et nous devons nous intéresser également à chacune de ces deux catégories. Faute de quoi, nous ne sommes pas dans une approche empirique, mais tout simplement dans de la propagande.
Cinq défis pour la communauté Agile
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.
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.
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
