Petit à petit le projet de l'Institut Agile se construit, grâce au soutien de ses partenaires. Comme annoncé au fil de ce blog divers livrables importants ont vu le jour: le référentiel des pratiques agiles, les premières sessions "Master Class", les premières communautés thématiques. D'autres projets encore en couveuse produiront prochainement leurs résultats.
Affichage des articles dont le libellé est référentiel. Afficher tous les articles
Affichage des articles dont le libellé est référentiel. Afficher tous les articles
Premier Rendez-vous de l'Institut Agile: 04/05
Le 4 mai, l'Institut Agile vous invite au premier de ses Rendez-Vous. (Attention: changement de date par rapport à la première annonce!)
Synthèse: référentiel des pratiques
Voici, pour ceux qui le découvriraient tardivement et souhaitent le lire dans l'ordre, un récapitulatif du chapitre "référentiel" tel que je l'ai abordé au fil des billets précédents. (L'inconvénient majeur d'un blog, c'est que quand on arrive après le début du film, les épisodes précédents sont présentés à l'envers: ça marche bien pour Memento mais moins bien pour un sujet plus technique.) Je profiterai également de ce billet pour dire un mot sur un sujet connexe: à qui appartient ce référentiel et comment il va évoluer.
Voici l'adresse de publication du Référentiel, et en voici les motivations:
Les billets futurs vont se concentrer sur d'autres chapitres de l'action de l'Institut.
A qui appartiennent les pratiques Agiles?
Une des raisons qui me font me méfier des initiatives de certification: je me préoccupe des mécanismes par lesquels, si je juge incorrecte la conception que se font les certifieurs de l'Agilité, je pourrai leur soumettre une demande de correction. C'est un point important: si j'enseigne quelque chose en rapport avec l'agilité, mais que mon contenu est incompatible avec ce que disent les certifieurs, j'aurai le choix cornélien entre enseigner quelque chose auquel je ne crois pas ou renoncer à l'atout que peut représenter la certification.
Pour l'Institut, la question ne se pose pas, puisqu'il y a un parti pris contre toute initiative de ce type. Mais le Référentiel tel qu'il se présente a, sans détour, une intention normative. Il prétend rendre compte de la pratique la plus courante, même si cela admet des exceptions.
A mon sens, les pratiques Agiles appartiennent à la communauté Agile dans son entier, et je pose cette interprétation comme un principe qui fait partie de la définition même de l'Agilité. C'est un mouvement qui a ceci de particulier qu'il est "bottom up", par construction et par philosophie.
Le Référentiel lui-même est une "oeuvre de l'esprit", protégé par le droit d'auteur. Je souhaite, pour des raisons éditoriales, contrôler un tant soit peu sa diffusion et sa modification pendant la période de rédaction, avant d'en faire un contenu "open source" une fois qu'il sera complet. Par conséquent, le Référentiel sera:
L'évolution future du Référentiel
La version actuelle du Référentiel est techniquement minimaliste, mais je compte dans l'immédiat me concentrer sur son contenu (tout en alimentant ce blog en parallèle...). Je publierai simultanément sur Github et sur le site les nouvelles pratiques au fur et à mesure de leur rédaction.
Tout au long de cette phase de rédaction j'acueillerai avec plaisir les suggestions d'amélioration, y compris sous la forme de "patchs" proposés via Github. L'objectif est d'être en mesure d'accueillir le plus largement possible les connaissances pertinentes sur les pratiques Agiles: liens vers des articles de référence, vers des travaux de recherche, vers des descriptifs de formations universitaires.
(Je suis dés à présent ouvert à l'inclusion de liens vers des formations commerciales, sous réserve que cela puisse se faire sans entrer en conflit avec la politique de l'Institut vis-à-vis de ses partenaires et vis-à-vis du marché: une neutralité bienveillante.)
Voici l'adresse de publication du Référentiel, et en voici les motivations:
- Pourquoi il est préférable de se focaliser sur les pratiques agiles et non sur l'étiquette "Agile"
- Principes, concepts, pratiques et compétences: les composants du corpus Agile
- Précautions d'utilisation d'un référentiel des pratiques Agiles: attention au Culte du Cargo
- Comment adapter les pratiques Agiles à son propre contexte: une activité efficace
- Les "rôles" Agiles et pourquoi s'en méfier
- Les canevas pour décrire une pratique et une compétence
Les billets futurs vont se concentrer sur d'autres chapitres de l'action de l'Institut.
A qui appartiennent les pratiques Agiles?
Une des raisons qui me font me méfier des initiatives de certification: je me préoccupe des mécanismes par lesquels, si je juge incorrecte la conception que se font les certifieurs de l'Agilité, je pourrai leur soumettre une demande de correction. C'est un point important: si j'enseigne quelque chose en rapport avec l'agilité, mais que mon contenu est incompatible avec ce que disent les certifieurs, j'aurai le choix cornélien entre enseigner quelque chose auquel je ne crois pas ou renoncer à l'atout que peut représenter la certification.
Pour l'Institut, la question ne se pose pas, puisqu'il y a un parti pris contre toute initiative de ce type. Mais le Référentiel tel qu'il se présente a, sans détour, une intention normative. Il prétend rendre compte de la pratique la plus courante, même si cela admet des exceptions.
A mon sens, les pratiques Agiles appartiennent à la communauté Agile dans son entier, et je pose cette interprétation comme un principe qui fait partie de la définition même de l'Agilité. C'est un mouvement qui a ceci de particulier qu'il est "bottom up", par construction et par philosophie.
Le Référentiel lui-même est une "oeuvre de l'esprit", protégé par le droit d'auteur. Je souhaite, pour des raisons éditoriales, contrôler un tant soit peu sa diffusion et sa modification pendant la période de rédaction, avant d'en faire un contenu "open source" une fois qu'il sera complet. Par conséquent, le Référentiel sera:
- dans un premier temps, diffusé sous une licence Creative Commons "by-nc-nd", avec l'exception suivante: toute personne qui le souhaite est autorisée à "forker" le Référentiel et à le modifier, sous réserve que ce soit dans la seule intention de soumettre ces modifications à l'auteur
- dans un second temps, et pas plus tard que le 31 décembre 2012, le Référentiel sera utilisable sous la licence "by-nc-sa", toute personne souhaitant alors y apporter ses modifications pourra le faire sans restriction
L'évolution future du Référentiel
La version actuelle du Référentiel est techniquement minimaliste, mais je compte dans l'immédiat me concentrer sur son contenu (tout en alimentant ce blog en parallèle...). Je publierai simultanément sur Github et sur le site les nouvelles pratiques au fur et à mesure de leur rédaction.
Tout au long de cette phase de rédaction j'acueillerai avec plaisir les suggestions d'amélioration, y compris sous la forme de "patchs" proposés via Github. L'objectif est d'être en mesure d'accueillir le plus largement possible les connaissances pertinentes sur les pratiques Agiles: liens vers des articles de référence, vers des travaux de recherche, vers des descriptifs de formations universitaires.
(Je suis dés à présent ouvert à l'inclusion de liens vers des formations commerciales, sous réserve que cela puisse se faire sans entrer en conflit avec la politique de l'Institut vis-à-vis de ses partenaires et vis-à-vis du marché: une neutralité bienveillante.)
Canevas de description d'une compétence
Que dire de plus pour éclairer précisément une compétence, par rapport à ce qu'on peut dire concernant une pratique? Notre exemple sera le Refactoring, compétence centrale dans Extreme Programming.
Tout d'abord, une compétence est aussi une pratique: elle se constate à certains signes visibles, elle apporte un bénéfice présumé, qui peut être démontré par des études empiriques. Le canevas de description d'une compétence est donc en règle générale un sur-ensemble de celui qui vaut pour les pratiques.
La principale différence est qu'une compétence nous amènes à distinguer des niveaux de performance. Cela n'a pas tellement de sens de dire qu'une personne ou même une équipe est "douée" pour établir sa "definition of Done". Soit elle a une définition, et la trouve satisfaisante; soit elle n'en a pas. Il n'y a pas grand chose à dire à une équipe qui lui permettra d'améliorer sa pratique de la définition. (Certes, une équipe peut avoir une mauvaise définition de "fini", si elle est incomplète ou au contraire trop rigoureuse. Pour autant on ne parlera pas d'améliorer une compétence, mais simplement d'améliorer... le document!)
Au contraire, une personne peut maîtriser plus ou moins bien les différentes techniques du refactoring, et s'améliorer dans ce domaine, soit par la recherche et la pratique personnelle, soit par des mécanismes d'apprentissage en travaillant auprès d'un mentor qui lui enseignera des éléments plus avancés que ceux déjà connus, soit en suivant une formation qui fixera des objectifs pédagogiques adaptés. Recenser ces formations est, en matière de compétences, l'un des objectifs importants du référentiel.
N'étant pas lui-même un support pédagogique, le référentiel n'a pas vocation à recenser l'intégralité des savoirs-faires qui composent une compétence donnée, mais simplement de fournir des pointeurs vers les ressources documentaires, lorsqu'elles existent, qui font autorité. Par exemple, le livre de Martin Fowler qui définit plusieurs dizaines de refactorings élémentaires. La connaissance encyclopédique de tous ces refactorings n'est certes pas une exigence pour pouvoir prétendre maîtriser le sujet, mais d'évidence l'une des choses qui distinguera un expert d'un débutant sera le nombre de ces refactorings qu'il est capable d'utiliser à bon escient.
Tout d'abord, une compétence est aussi une pratique: elle se constate à certains signes visibles, elle apporte un bénéfice présumé, qui peut être démontré par des études empiriques. Le canevas de description d'une compétence est donc en règle générale un sur-ensemble de celui qui vaut pour les pratiques.
La principale différence est qu'une compétence nous amènes à distinguer des niveaux de performance. Cela n'a pas tellement de sens de dire qu'une personne ou même une équipe est "douée" pour établir sa "definition of Done". Soit elle a une définition, et la trouve satisfaisante; soit elle n'en a pas. Il n'y a pas grand chose à dire à une équipe qui lui permettra d'améliorer sa pratique de la définition. (Certes, une équipe peut avoir une mauvaise définition de "fini", si elle est incomplète ou au contraire trop rigoureuse. Pour autant on ne parlera pas d'améliorer une compétence, mais simplement d'améliorer... le document!)
Au contraire, une personne peut maîtriser plus ou moins bien les différentes techniques du refactoring, et s'améliorer dans ce domaine, soit par la recherche et la pratique personnelle, soit par des mécanismes d'apprentissage en travaillant auprès d'un mentor qui lui enseignera des éléments plus avancés que ceux déjà connus, soit en suivant une formation qui fixera des objectifs pédagogiques adaptés. Recenser ces formations est, en matière de compétences, l'un des objectifs importants du référentiel.
N'étant pas lui-même un support pédagogique, le référentiel n'a pas vocation à recenser l'intégralité des savoirs-faires qui composent une compétence donnée, mais simplement de fournir des pointeurs vers les ressources documentaires, lorsqu'elles existent, qui font autorité. Par exemple, le livre de Martin Fowler qui définit plusieurs dizaines de refactorings élémentaires. La connaissance encyclopédique de tous ces refactorings n'est certes pas une exigence pour pouvoir prétendre maîtriser le sujet, mais d'évidence l'une des choses qui distinguera un expert d'un débutant sera le nombre de ces refactorings qu'il est capable d'utiliser à bon escient.
Canevas de description d'une pratique
Voici les éléments qui me semblent pertinent pour décrire une pratique agile. Nous allons prendre pour exemple une pratique Scrum relativement récente, la Définition de 'fini'.
Parlons d'abord, même si ce n'est pas la première chose qu'on lira, du descriptif succint d'une pratique. (La première chose qu'on lira, c'est le nom, j'y reviens plus bas.) Le référentiel n'a pas vocation à se substituer aux livres, articles et contenus de formation qui donne une définition plus précise et plus détaillée de chaque pratique, compétence et outil abordés. Il s'agit donc ici de se borner à un paragraphe court qui reprend l'essentiel.
Un autre exercice délicat consiste à choisir un nom canonique pour cette pratique. La plupart de mes collègues francophones utilisent un demi-anglicisme, et parlent de "Definition du Done", quand ce n'est pas le terme anglais qu'ils utilisent directement. Quand c'est possible, il me semble souhaitable de vraiment traduire, c'est pourquoi j'ai préféré "fini" à "done".
Le but n'est pas de faire évoluer le lexique, même s'il est tentant de chercher jouer de son influence... Ma préférence irait au terme "Liste Sashimi", le terme "sashimi" bénéficie actuellement d'un petit effet de mode, et comme l'illustre le site Web de cette formation de mon ami et collègue J.B. Rainsberger il est parlant et plaisant. Mais cette appellation pour désigner une pratique spécifique reste tout à fait marginale.
En tout cas, pour toutes ces raisons, il me semble important de recenser les synonymes connus qui désignent la même pratique ou des pratiques tellement voisines que nous les considérerons comme une seule (par exemple le Sprint de Scrum ne diffère pas assez de l'Itération d'XP pour y voir deux pratiques distinctes).
Une pratique s'accompagne généralement d'un certain nombre d'erreurs classiques, de contre-sens et d'abus. En rencensant les plus courantes, on donne de la profondeur à la description brève (mais toujours sans chercher à se substituer à un contenu plus pédagogique), et on encourage à se méfier des imitations et contrefaçons.
Conformément à la division "principes, concepts, pratiques, compétences" j'ai choisi de faire ressortir de cette pratique le côté visible: je sais qu'une équipe utilise une pratique quand je peux le constater par des signes observables dans l'espace de travail, par exemple une feuille de paperboard sur laquelle on peut lire la (ou les) définition(s) de "fini".
(C'est un arbitrage de ma part, certaines personnes diront qu'il suffit qu'une équipe connaisse sa définition de "fini" et que tout le monde soit d'accord. Pourquoi pas: dans ce cas, le signe observable consiste à s'asseoir avec plusieurs personnes dans l'équipe et leur demander de réciter cette définition. Je suis presque certain que dans ces conditions chacun donnera une définition de "fini" légérement différente; je vous renvoie donc à la rubrique "erreurs classiques".)
Comme indiqué précédemment, une pratique ne vaut que par les bénéfices qu'elle confère au projet. Décider, en conscience, d'adopter une pratique, c'est s'engager à vérifier quelques temps après si ces bénéfices ont bien été obtenus, et remettre en question sa vision du fonctionnement du projet si ce n'est pas le cas. L'objectif n'est pas d'utiliser telle et telle pratique pour le plaisir de s'identifier comme "Agile" mais bel et bien d'obtenir ces bénéfices. Notamment, chaque pratique se caractérisera aussi par un coût d'utilisation plus ou moins grand et une efficacité plus ou moins nette: notre objectif, idéalement, est d'obtenir avec le minimum de pratiques, exigeant le minimum d'effort pour les adopter, le plus grand nombre de bénéfices possibles sur les aspects du projet qui nous intéressent. Peu importe d'où viennent ces pratiques - de Scrum, d'XP, de Lean...
Il est cependant important, pour plusieurs raisons que j'approfondira dans des billets à venir, de positionner les pratiques dans un contexte historique, de retracer leurs origines et leur évolution. La "définition de 'fini'" ne fait partie de Scrum que depuis quelques années, et son intégration définitive dans les pratiques considérées comme indispensables ne remonte qu'à 2006-2007 environ d'après mes recherches. (Perfectibles, sans doute: c'est pourquoi je citerai mes sources.) Ou bien il est possible de pratiquer Scrum sans utiliser une définition explicite de "fini" - auquel cas on doit se demander s'il est nécessaire dans un contexte particulier d'utiliser cette pratique - ou bien cet évolution s'explique par le fait que seules les équipes qui l'utilisaient réussissaient dans leur application de Scrum, et qu'on a finalement mis le discours en conformité avec la pratique. La différence entre ces deux scénarios n'est pas anodine.
Un dernier élément, mais qui a son importance, consiste à relever les travaux scientifiques pertinents. Ceux-ci sont de deux types: théoriques ou conceptuels, qui vont donner un éclairage plus précis et plus rigoureux sur les mécanismes par lesquels une pratique produit ses effets; et, les plus importants, empiriques, qui vont constater dans des conditions contrôlées la réalité et l'importance quantitative de ces prétendus effets.
Cette validation scientifique n'est pas un prérequis à l'utilisation de pratiques qui ont montré leur efficacité. J'aurai l'occasion de revenir sur ce sujet, mais il faut bien constater que le dialogue entre les chercheurs qui s'intéressent à la dynamique des projets agiles d'une part, et les praticiens d'autre part, n'est pas encore d'une grande qualité. On ne s'étonnera pas, par conséquent, que la recherche tarde à s'intéresser à ce que les praticiens trouvent évident depuis longtemps, ou que ces derniers ignorent des résultats que les chercheurs considèrent comme acquis. Mais la convergence au fil du temps entre
ces deux communautés me semble indispensable.
Si les pratiques sont réellement utiles et produisent leurs effets de façon fiable, alors on doit être en mesure de le prouver; sinon c'est qu'elles ne sont qu'un placebo, et leur utilisation est nuisible puisqu'elles mobilisent une partie de l'énergie des intervenants d'un projet, qu'ils pourraient consacrer à d'autres pratiques qui elles sont réellement utiles.
Parlons d'abord, même si ce n'est pas la première chose qu'on lira, du descriptif succint d'une pratique. (La première chose qu'on lira, c'est le nom, j'y reviens plus bas.) Le référentiel n'a pas vocation à se substituer aux livres, articles et contenus de formation qui donne une définition plus précise et plus détaillée de chaque pratique, compétence et outil abordés. Il s'agit donc ici de se borner à un paragraphe court qui reprend l'essentiel.
Un autre exercice délicat consiste à choisir un nom canonique pour cette pratique. La plupart de mes collègues francophones utilisent un demi-anglicisme, et parlent de "Definition du Done", quand ce n'est pas le terme anglais qu'ils utilisent directement. Quand c'est possible, il me semble souhaitable de vraiment traduire, c'est pourquoi j'ai préféré "fini" à "done".
Le but n'est pas de faire évoluer le lexique, même s'il est tentant de chercher jouer de son influence... Ma préférence irait au terme "Liste Sashimi", le terme "sashimi" bénéficie actuellement d'un petit effet de mode, et comme l'illustre le site Web de cette formation de mon ami et collègue J.B. Rainsberger il est parlant et plaisant. Mais cette appellation pour désigner une pratique spécifique reste tout à fait marginale.
En tout cas, pour toutes ces raisons, il me semble important de recenser les synonymes connus qui désignent la même pratique ou des pratiques tellement voisines que nous les considérerons comme une seule (par exemple le Sprint de Scrum ne diffère pas assez de l'Itération d'XP pour y voir deux pratiques distinctes).
Une pratique s'accompagne généralement d'un certain nombre d'erreurs classiques, de contre-sens et d'abus. En rencensant les plus courantes, on donne de la profondeur à la description brève (mais toujours sans chercher à se substituer à un contenu plus pédagogique), et on encourage à se méfier des imitations et contrefaçons.
Conformément à la division "principes, concepts, pratiques, compétences" j'ai choisi de faire ressortir de cette pratique le côté visible: je sais qu'une équipe utilise une pratique quand je peux le constater par des signes observables dans l'espace de travail, par exemple une feuille de paperboard sur laquelle on peut lire la (ou les) définition(s) de "fini".
(C'est un arbitrage de ma part, certaines personnes diront qu'il suffit qu'une équipe connaisse sa définition de "fini" et que tout le monde soit d'accord. Pourquoi pas: dans ce cas, le signe observable consiste à s'asseoir avec plusieurs personnes dans l'équipe et leur demander de réciter cette définition. Je suis presque certain que dans ces conditions chacun donnera une définition de "fini" légérement différente; je vous renvoie donc à la rubrique "erreurs classiques".)
Comme indiqué précédemment, une pratique ne vaut que par les bénéfices qu'elle confère au projet. Décider, en conscience, d'adopter une pratique, c'est s'engager à vérifier quelques temps après si ces bénéfices ont bien été obtenus, et remettre en question sa vision du fonctionnement du projet si ce n'est pas le cas. L'objectif n'est pas d'utiliser telle et telle pratique pour le plaisir de s'identifier comme "Agile" mais bel et bien d'obtenir ces bénéfices. Notamment, chaque pratique se caractérisera aussi par un coût d'utilisation plus ou moins grand et une efficacité plus ou moins nette: notre objectif, idéalement, est d'obtenir avec le minimum de pratiques, exigeant le minimum d'effort pour les adopter, le plus grand nombre de bénéfices possibles sur les aspects du projet qui nous intéressent. Peu importe d'où viennent ces pratiques - de Scrum, d'XP, de Lean...
Il est cependant important, pour plusieurs raisons que j'approfondira dans des billets à venir, de positionner les pratiques dans un contexte historique, de retracer leurs origines et leur évolution. La "définition de 'fini'" ne fait partie de Scrum que depuis quelques années, et son intégration définitive dans les pratiques considérées comme indispensables ne remonte qu'à 2006-2007 environ d'après mes recherches. (Perfectibles, sans doute: c'est pourquoi je citerai mes sources.) Ou bien il est possible de pratiquer Scrum sans utiliser une définition explicite de "fini" - auquel cas on doit se demander s'il est nécessaire dans un contexte particulier d'utiliser cette pratique - ou bien cet évolution s'explique par le fait que seules les équipes qui l'utilisaient réussissaient dans leur application de Scrum, et qu'on a finalement mis le discours en conformité avec la pratique. La différence entre ces deux scénarios n'est pas anodine.
Un dernier élément, mais qui a son importance, consiste à relever les travaux scientifiques pertinents. Ceux-ci sont de deux types: théoriques ou conceptuels, qui vont donner un éclairage plus précis et plus rigoureux sur les mécanismes par lesquels une pratique produit ses effets; et, les plus importants, empiriques, qui vont constater dans des conditions contrôlées la réalité et l'importance quantitative de ces prétendus effets.
Cette validation scientifique n'est pas un prérequis à l'utilisation de pratiques qui ont montré leur efficacité. J'aurai l'occasion de revenir sur ce sujet, mais il faut bien constater que le dialogue entre les chercheurs qui s'intéressent à la dynamique des projets agiles d'une part, et les praticiens d'autre part, n'est pas encore d'une grande qualité. On ne s'étonnera pas, par conséquent, que la recherche tarde à s'intéresser à ce que les praticiens trouvent évident depuis longtemps, ou que ces derniers ignorent des résultats que les chercheurs considèrent comme acquis. Mais la convergence au fil du temps entre
ces deux communautés me semble indispensable.
Si les pratiques sont réellement utiles et produisent leurs effets de façon fiable, alors on doit être en mesure de le prouver; sinon c'est qu'elles ne sont qu'un placebo, et leur utilisation est nuisible puisqu'elles mobilisent une partie de l'énergie des intervenants d'un projet, qu'ils pourraient consacrer à d'autres pratiques qui elles sont réellement utiles.
Le monde est une scène
Quand je parle autour de moi du projet du référentiel des pratiques Agiles, une question revient à l'occasion: "Est-ce que tu vas parler des rôles du Scrum Master, du Product Owner?.."
Je ne suis pas tout à fait à l'aise avec ces notions de "rôles", en tout cas avec l'importance qu'on leur donne. En y réfléchissant bien, mon raisonnement repose sur un principe simple; je l'ai déjà énoncé en passant mais il mérite que j'insiste:
Le principe de Ricardo ou principe de l'avantage comparatif me pousse à m'associer à une personne compétente dans le domaine graphique, et montre que je peux y trouver un avantage même dans le cas où je suis un peu doué en graphisme. (Ce qui est contre-intuitif dans le principe de Ricardo, c'est l'idée que même si je suis strictement meilleur en développement ET en graphisme qu'une autre personne, m'associer avec elle en nous spécialisant chacun dans un domaine peut quand même être intéressant pour chacun des deux.)
Mais ce qui vaut en analyse économique ne vaut pas nécessairement dans un projet. Par exemple les acteurs d'un projet ne travaillent pas chacun dans leur coin: ils ont besoin, chacun, de comprendre ce que font les autres acteurs. Trop de spécialisation peut engendrer ce que j'appelle le "syndrôme du bébé", d'après une conversation entre parents, par exemple au supermarché: "Dis donc, le bébé n'est pas avec toi?" - "Ah non, je croyais qu'il était avec toi..." - "Alors où est-il?" Transposé au monde du projet, cela donne des tâches importantes qui ne sont pas réalisées parce que chacun pense qu'elles relèvent de la responsabilité de quelqu'un d'autre.
Prenons donc l'exemple d'un des nouveaux "rôles" Agiles les plus emblématiques, celui du Scrum Master. Le Scrum Master est chargé:
A mon sens un rôle formellement défini n'est qu'une "checklist", un rappel utile d'un certain "lot" d'activités ou responsabilités dont il est important de garantir que chacune est assurée par au moins un membre de l'équipe, afin d'éviter le "syndrôme du bébé". La spécialisation a du sens au niveau des responsabilités isolées, pas au niveau de rôles agrégeant plusieurs responsabilités.
Il existe, bien sûr, des corrélations. Un développeur compétent est probablement une personne plus apte à se charger d'un travail de rédaction technique qu'un graphiste compétent. Mais c'est seulement une tendance (peut-être même pas une tendance très marquée). Lorsqu'il s'agit de se répartir des tâches précises, identifiées, au sein d'un projet particulier, entre des personnes réelles, dans toute leur singularité, la notion de rôles doit passer au second plan. C'est la place que je compte leur accorder dans le référentiel, sauf à entendre des arguments convaincants bien entendu!
Je ne suis pas tout à fait à l'aise avec ces notions de "rôles", en tout cas avec l'importance qu'on leur donne. En y réfléchissant bien, mon raisonnement repose sur un principe simple; je l'ai déjà énoncé en passant mais il mérite que j'insiste:
Ce qui compte surtout pour le succès d'un projet, c'est ce que les gens font.Il existe bien sûr des contraintes: les journées de travail ne faisant (en principe) que 8 heures, une même personne ne peut pas tout faire. On doit bien se spécialiser afin de mener certaines activités de façon compétente; le temps que j'investis à devenir un meilleur développeur est autant de temps que je ne passerai pas à acquérir des rudiments de graphisme.
Le principe de Ricardo ou principe de l'avantage comparatif me pousse à m'associer à une personne compétente dans le domaine graphique, et montre que je peux y trouver un avantage même dans le cas où je suis un peu doué en graphisme. (Ce qui est contre-intuitif dans le principe de Ricardo, c'est l'idée que même si je suis strictement meilleur en développement ET en graphisme qu'une autre personne, m'associer avec elle en nous spécialisant chacun dans un domaine peut quand même être intéressant pour chacun des deux.)
Mais ce qui vaut en analyse économique ne vaut pas nécessairement dans un projet. Par exemple les acteurs d'un projet ne travaillent pas chacun dans leur coin: ils ont besoin, chacun, de comprendre ce que font les autres acteurs. Trop de spécialisation peut engendrer ce que j'appelle le "syndrôme du bébé", d'après une conversation entre parents, par exemple au supermarché: "Dis donc, le bébé n'est pas avec toi?" - "Ah non, je croyais qu'il était avec toi..." - "Alors où est-il?" Transposé au monde du projet, cela donne des tâches importantes qui ne sont pas réalisées parce que chacun pense qu'elles relèvent de la responsabilité de quelqu'un d'autre.
Prenons donc l'exemple d'un des nouveaux "rôles" Agiles les plus emblématiques, celui du Scrum Master. Le Scrum Master est chargé:
- de lever les obstacles signalés par l'équipe lors des réunions quotidiennes ("mélées")
- d'être un facilitateur lors de ces réunions
- de rappeler à l'équipe les fondamentaux théoriques de Scrum
- de protéger l'équipe des interruptions
- donner à l'une de ces personnes les quatre responsabilités ci-dessus, au risque que deux d'entre elles soient moins bien assurées, ou
- jeter aux orties la définition stricte du rôle du Scrum Master, et répartir ces quatre responsabilités entre les deux équipiers en fonction de leurs talents?
A mon sens un rôle formellement défini n'est qu'une "checklist", un rappel utile d'un certain "lot" d'activités ou responsabilités dont il est important de garantir que chacune est assurée par au moins un membre de l'équipe, afin d'éviter le "syndrôme du bébé". La spécialisation a du sens au niveau des responsabilités isolées, pas au niveau de rôles agrégeant plusieurs responsabilités.
Il existe, bien sûr, des corrélations. Un développeur compétent est probablement une personne plus apte à se charger d'un travail de rédaction technique qu'un graphiste compétent. Mais c'est seulement une tendance (peut-être même pas une tendance très marquée). Lorsqu'il s'agit de se répartir des tâches précises, identifiées, au sein d'un projet particulier, entre des personnes réelles, dans toute leur singularité, la notion de rôles doit passer au second plan. C'est la place que je compte leur accorder dans le référentiel, sauf à entendre des arguments convaincants bien entendu!
Principes, concepts, pratiques et compétences
Voici résumés dans le titre, et par ordre croissant d'importance, les éléments qui font le contenu de l'approche Agile. Pour résumer le contenu de ce billet: les principes, c'est ce qui nous préoccupe quand on s'arrête pour réfléchir; les concepts, ce sont les définitions auxquelles on revient pour éviter de se tromper; les pratiques, c'est ce qui nous distingue visiblement d'autres équipes; mais le plus important reste les compétences, c'est-à-dire que nous nous attachons à améliorer.
La question "sommes-nous Agiles" n'a que peu d'intérêt. Bien plus importante est la question "qu'avons-nous appris, qui nous permet dans la pratique de mieux réussir nos projets?"
Lors de la réunion où fut écrit le fameux Manifeste, c'est cette question qui animait les participants. Leur objectif était de décrire leurs points de convergence les plus forts possibles: c'est une démarche qui les conduisait nécessairement à une formulation un peu abstraite, un peu éloignée de la réalité quotidienne des projets qu'ils vivaient alors. Ce sont donc les "douze principes" réputés sous-tendre la pratique Agile.
Les principes fournissent un garde-fou utile. Si je m'aperçois que la mise en place de pratiques censément Agiles a eu pour résultat de démoraliser toute l'équipe, le cinquième principe, "bâtissez le projet autour de personnes motivées", m'avertit qu'il y a peut-être une contradiction quelque part. A tout le moins, je dois le prendre comme un sérieux avertissement, envisager que j'ai pu faire fausse route.
Mais on ne peut pas construire un projet sur la seule base de quelques principes. Admettons, nous somme tous d'accord pour "satisfaire le client en livrant tôt et régulièrement des logiciels utiles". Cela ne constitue pas un conseil opérant, ou comme on le dit en anglais avec beaucoup de pertinence, "actionable". C'est comme si on vous conseillait, pour gagner en bourse: "achetez des actions lorsque les prix sont bas et revendez-les lorsque les prix sont hauts". Parfaitement juste et sensé, mais aussi parfaitement inutile: on demande immédiatement comment?
Les concepts doivent être maîtrisés sous peine de contresens fatals. Scène vécue: un "Scrum Master" nouvellement certifié débarque sur une liste de diffusion et demande, "est-il raisonnable de fixer pour le prochain Sprint une vélocité de 80% parce qu'un membre de l'équipe est absent?". Des questions de ce type me mettent mal à l'aise quant à l'efficacité et à la qualité des formations! (C'est un de ces incidents qui m'a amené à la conclusion qu'un référentiel plus clair était nécessaire.)
La mise en place d'une approche Agile exige de connaitre un peu de théorie. Pour acquérir un concept théorique il suffit le plus souvent d'en recevoir la définition, par exemple "la vélocité est obtenue en faisant le total des points (estimations) associés aux User Stories qui ont été terminées dans l'itération qui vient de s'achever". Cette définition suffit à identifier les erreurs de notre jeune Scrum Master; la vélocité est quelque chose qui se mesure, non quelque chose qui se décrete à l'avance; c'est une mesure qui s'exprime dans la même unité que les estimations, donc des points ou des hommes-jours mais en aucun cas un pourcentage. Le réflexe qui joue est le même que celui du physicien à qui on annoncerait une vitesse exprimée en mètres carrés: ce n'est pas la peine de vérifier le calcul, il faut d'abord rectifier une incompréhension théorique.
Nuançons quand même le propos: certains des termes utilisés pour décrire Scrum ou XP exigent plus qu'une définition brute, il faut comprendre comment les mettre en relation. J'affectione les simulations de projet comme outil pédagogique pour garantir que des termes comme vélocité ou itération sont bien compris.
Les pratiques, c'est ce dont on peut constater la mise en place sur le terrain, de façon visible. Par exemple, une heuristique que j'emploie fréquemment pour juger qu'équipe prend au sérieux l'approche Agile: les murs de la salle de travail sont-ils recouverts de tableaux blancs remplis, de grandes feuilles de papier chargés de Post-It, de documents divers relatifs au projet et mis à jours récemment? La présence de ces indices n'est évidemment pas une garantie de succès, mais elle met en évidence certaines pratiques communes parmi les équipes Agiles: utilisation d'un tableau de tâches par exemple.
Ou bien encore, je pourrais passer un peu de temps avec un développeur, et constater quelques différences visibles entre son travail et ce que j'ai vu faire ailleurs. Lorsqu'il programme, je le vois systématiquement se préoccuper de tests unitaires automatisés, qui se matérialisent par une "barre verte" ou "barre rouge" dans l'outil qui gère ces tests. Ou bien, je remarque qu'il ne travaille que rarement seul, mais le plus souvent avec un autre développeur assis au même bureau; il ne travaille pas en silence mais explique (sans trop lever la voix pour ne pas perturber d'autres binômes) le raisonnement derrière le code qu'il propose à son collègue.
Les compétences, c'est ce qu'on peut voir quand on examine de plus près certaines pratiques (mais pas toutes), ce sont celles parmi les pratiques qui amènent à distinguer des niveaux de performance. Telle équipe est meilleure que l'équipe voisine dans le domaine de la conception évolutive. Tel développeur est plus doué qu'un autre pour le refactoring, il l'applique de façon plus fluide, à une plus grande échelle, avec plus de rapidité.
Certaines pratiques ne sont pas nécessairement des compétences: d'un certain point de vue une réunion de type "stand-up" ou "daily Scrum", c'est simplement une réunion. On constate, ou non, que l'équipe se réunit une fois par jour à heure fixe pour échanger sur les progrès accomplis. Par contre on peut considérer que l'animation de cette réunion est une compétence. Si cette compétence est présente cela se traduit par une réunion courte et le sentiment (subjectif, certes) qu'elle a été utile. Si cette compétence fait défaut, la réunion peut s'éterniser et sembler contre-productive.
Attention, "animer un stand-up court" ne décrit pas une compétence! On préfèrera quelque chose comme: "telle personne est capable d'équilibrer les temps de parole lors d'une réunion, en encourageant les plus timides à contribuer et les plus extravertis à se limiter". Cette compétence s'appuie sur de l'observation (il faut avoir noté qui a parlé ou pas parlé) et sur de l'autorité (adopter le ton juste lorsqu'on demande à quelqu'un de rendre la parole: ni minauderie ni éclat de voix).
Conclusion: pour pouvoir obtenir les bénéfices d'une approche Agile, il me semble important d'avoir accès à une description approfondie et détaillée du contenu de cette approche, avec une attention particulière aux pratiques et aux compétences qui, sans doute parce qu'elles sont plus difficile à décrire finement, ont jusqu'à présent surtout fait l'objet d'une "tradition orale", d'un apprentissage par la transmission individuelle. Même si cette dernière garde son importance dans la culture Agile, elle ne peut que bénéficier d'un corpus écrit, si celui-ci est soigneusement réalisé et entretenu.
La question "sommes-nous Agiles" n'a que peu d'intérêt. Bien plus importante est la question "qu'avons-nous appris, qui nous permet dans la pratique de mieux réussir nos projets?"
Lors de la réunion où fut écrit le fameux Manifeste, c'est cette question qui animait les participants. Leur objectif était de décrire leurs points de convergence les plus forts possibles: c'est une démarche qui les conduisait nécessairement à une formulation un peu abstraite, un peu éloignée de la réalité quotidienne des projets qu'ils vivaient alors. Ce sont donc les "douze principes" réputés sous-tendre la pratique Agile.
Les principes fournissent un garde-fou utile. Si je m'aperçois que la mise en place de pratiques censément Agiles a eu pour résultat de démoraliser toute l'équipe, le cinquième principe, "bâtissez le projet autour de personnes motivées", m'avertit qu'il y a peut-être une contradiction quelque part. A tout le moins, je dois le prendre comme un sérieux avertissement, envisager que j'ai pu faire fausse route.
Mais on ne peut pas construire un projet sur la seule base de quelques principes. Admettons, nous somme tous d'accord pour "satisfaire le client en livrant tôt et régulièrement des logiciels utiles". Cela ne constitue pas un conseil opérant, ou comme on le dit en anglais avec beaucoup de pertinence, "actionable". C'est comme si on vous conseillait, pour gagner en bourse: "achetez des actions lorsque les prix sont bas et revendez-les lorsque les prix sont hauts". Parfaitement juste et sensé, mais aussi parfaitement inutile: on demande immédiatement comment?
Les concepts doivent être maîtrisés sous peine de contresens fatals. Scène vécue: un "Scrum Master" nouvellement certifié débarque sur une liste de diffusion et demande, "est-il raisonnable de fixer pour le prochain Sprint une vélocité de 80% parce qu'un membre de l'équipe est absent?". Des questions de ce type me mettent mal à l'aise quant à l'efficacité et à la qualité des formations! (C'est un de ces incidents qui m'a amené à la conclusion qu'un référentiel plus clair était nécessaire.)
La mise en place d'une approche Agile exige de connaitre un peu de théorie. Pour acquérir un concept théorique il suffit le plus souvent d'en recevoir la définition, par exemple "la vélocité est obtenue en faisant le total des points (estimations) associés aux User Stories qui ont été terminées dans l'itération qui vient de s'achever". Cette définition suffit à identifier les erreurs de notre jeune Scrum Master; la vélocité est quelque chose qui se mesure, non quelque chose qui se décrete à l'avance; c'est une mesure qui s'exprime dans la même unité que les estimations, donc des points ou des hommes-jours mais en aucun cas un pourcentage. Le réflexe qui joue est le même que celui du physicien à qui on annoncerait une vitesse exprimée en mètres carrés: ce n'est pas la peine de vérifier le calcul, il faut d'abord rectifier une incompréhension théorique.
Nuançons quand même le propos: certains des termes utilisés pour décrire Scrum ou XP exigent plus qu'une définition brute, il faut comprendre comment les mettre en relation. J'affectione les simulations de projet comme outil pédagogique pour garantir que des termes comme vélocité ou itération sont bien compris.
Les pratiques, c'est ce dont on peut constater la mise en place sur le terrain, de façon visible. Par exemple, une heuristique que j'emploie fréquemment pour juger qu'équipe prend au sérieux l'approche Agile: les murs de la salle de travail sont-ils recouverts de tableaux blancs remplis, de grandes feuilles de papier chargés de Post-It, de documents divers relatifs au projet et mis à jours récemment? La présence de ces indices n'est évidemment pas une garantie de succès, mais elle met en évidence certaines pratiques communes parmi les équipes Agiles: utilisation d'un tableau de tâches par exemple.
Ou bien encore, je pourrais passer un peu de temps avec un développeur, et constater quelques différences visibles entre son travail et ce que j'ai vu faire ailleurs. Lorsqu'il programme, je le vois systématiquement se préoccuper de tests unitaires automatisés, qui se matérialisent par une "barre verte" ou "barre rouge" dans l'outil qui gère ces tests. Ou bien, je remarque qu'il ne travaille que rarement seul, mais le plus souvent avec un autre développeur assis au même bureau; il ne travaille pas en silence mais explique (sans trop lever la voix pour ne pas perturber d'autres binômes) le raisonnement derrière le code qu'il propose à son collègue.
Les compétences, c'est ce qu'on peut voir quand on examine de plus près certaines pratiques (mais pas toutes), ce sont celles parmi les pratiques qui amènent à distinguer des niveaux de performance. Telle équipe est meilleure que l'équipe voisine dans le domaine de la conception évolutive. Tel développeur est plus doué qu'un autre pour le refactoring, il l'applique de façon plus fluide, à une plus grande échelle, avec plus de rapidité.
Certaines pratiques ne sont pas nécessairement des compétences: d'un certain point de vue une réunion de type "stand-up" ou "daily Scrum", c'est simplement une réunion. On constate, ou non, que l'équipe se réunit une fois par jour à heure fixe pour échanger sur les progrès accomplis. Par contre on peut considérer que l'animation de cette réunion est une compétence. Si cette compétence est présente cela se traduit par une réunion courte et le sentiment (subjectif, certes) qu'elle a été utile. Si cette compétence fait défaut, la réunion peut s'éterniser et sembler contre-productive.
Attention, "animer un stand-up court" ne décrit pas une compétence! On préfèrera quelque chose comme: "telle personne est capable d'équilibrer les temps de parole lors d'une réunion, en encourageant les plus timides à contribuer et les plus extravertis à se limiter". Cette compétence s'appuie sur de l'observation (il faut avoir noté qui a parlé ou pas parlé) et sur de l'autorité (adopter le ton juste lorsqu'on demande à quelqu'un de rendre la parole: ni minauderie ni éclat de voix).
Conclusion: pour pouvoir obtenir les bénéfices d'une approche Agile, il me semble important d'avoir accès à une description approfondie et détaillée du contenu de cette approche, avec une attention particulière aux pratiques et aux compétences qui, sans doute parce qu'elles sont plus difficile à décrire finement, ont jusqu'à présent surtout fait l'objet d'une "tradition orale", d'un apprentissage par la transmission individuelle. Même si cette dernière garde son importance dans la culture Agile, elle ne peut que bénéficier d'un corpus écrit, si celui-ci est soigneusement réalisé et entretenu.
Inscription à :
Articles (Atom)
Articles
