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.
Affichage des articles dont le libellé est competences. Afficher tous les articles
Affichage des articles dont le libellé est competences. Afficher tous les articles
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.
Dans une bonne bouteille, vous buvez l'étiquette?
Une question malicieuse pour un sujet très sérieux, puisque l'une de mes plus grandes inquiétudes est de voir notre profession se détourner d'idées qu'elles vient pourtant à peine de découvrir et qui, bien maîtrisées, lui font le plus grand bien.
Ce qui est important dans l'ensemble certes un peu hétéroclite de notions associées au terme "Agile", ce n'est évidemment pas le mot "Agile", de la même façon que ce qui nous procure du plaisir dans une bonne bouteille de vin, c'est (en principe) son contenu.
En principe? Oui, une des vertus de cette analogie, c'est de nous rappeler que trop souvent on se délecte de l'étiquette. On appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors même que si nous faisions l'essai à l'aveugle nous ne saurions pas distinguer une piquette d'un cru à la mode.
Je ne jetterai donc la pierre à personne, mais le fait est que nous courons un risque à trop parler des étiquettes: Agile, Lean, Scrum, XP... J'entends des choses parfaitement absurdes, par exemple "Lean est le successeur d'Agile".
C'est un contre-sens pour qui connaît le contenu qu'on désigne par le terme Agile: un ensemble de pratiques, certes pas toutes de la même origine, certes pas toutes aussi largement connues et pratiquées, mais dont statistiquement, en interrogeant un assez grand nombre de personnes faisant partie de la communauté depuis longtemps (cette appartenance pourrait se déterminer par un critère concret tel que la participation à des conférences), le recouvrement nous donnerait une idée assez précise.
Citons en vrac, et pour l'exercice: le développement par les tests (TDD), le refactoring, l'automatisation du build, l'intégration continue, la conception incrémentale, les User Stories, les tests de recette, les critères "Done", les Personas, le Story Mapping, le Planning Poker, les itérations timeboxées, les rétrospectives, le tableau des tâches, le libre choix des tâches, la réunion quotidienne ou "mélée", la programmation en binômes, les demandes d'aide explicites...
Parmi les "méthodes Agiles" (le mot méthode est mal choisi, mais ce sera le sujet d'un prochain billet) on peut effectivement recenser certaines dont les préconisations sont des sous-ensembles de cette longue liste: Scrum et XP notamment.
Si on se pose la question de savoir de quel mode de pensée sont issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a de nombreuses affinités avec le discours Lean. Pour autant, le recouvrement en termes de pratiques est relativement faible.
Or, soyons clair là-dessus, ce qui fait le succès ou non d'un projet, ce n'est pas le nom du discours dont on se revendique, l'attachement identitaire des membres de l'équipe: "nous sommes Agiles" ou "nous sommes Lean". Ce qui fait le succès d'un projet c'est ce que font les gens!
De ce point de vue, force est de constater que beaucoup d'équipes se proclament "Agiles" alors même qu'elles peinent à appliquer de façon compétente des pratiques aussi élémentaires que le refactoring, ou qu'elles révèlent lorsqu'on interroge les ingénieurs des contresens sur des notions de base comme la vélocité.
Une partie de ce déficit est à mettre sur le compte de la communauté Agile elle-même: il n'existe nulle part sur le Web un "Wikipedia de l'Agilité", une description systématique, détaillée, cohérente et mise à jour des pratiques désignées par le terme "Agile".
D'où le projet actuellement prioritaire de l'Institut Agile: mettre à la disposition des personnes intéressées par le sujet un "référentiel des compétences, pratiques, notions et principes" des approches Agiles. Qu'est-ce qui différentie une compétence d'une pratique, d'un principe, etc? C'est ce que j'aborderai dans le prochain billet...
Ce qui est important dans l'ensemble certes un peu hétéroclite de notions associées au terme "Agile", ce n'est évidemment pas le mot "Agile", de la même façon que ce qui nous procure du plaisir dans une bonne bouteille de vin, c'est (en principe) son contenu.
En principe? Oui, une des vertus de cette analogie, c'est de nous rappeler que trop souvent on se délecte de l'étiquette. On appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors même que si nous faisions l'essai à l'aveugle nous ne saurions pas distinguer une piquette d'un cru à la mode.
Je ne jetterai donc la pierre à personne, mais le fait est que nous courons un risque à trop parler des étiquettes: Agile, Lean, Scrum, XP... J'entends des choses parfaitement absurdes, par exemple "Lean est le successeur d'Agile".
C'est un contre-sens pour qui connaît le contenu qu'on désigne par le terme Agile: un ensemble de pratiques, certes pas toutes de la même origine, certes pas toutes aussi largement connues et pratiquées, mais dont statistiquement, en interrogeant un assez grand nombre de personnes faisant partie de la communauté depuis longtemps (cette appartenance pourrait se déterminer par un critère concret tel que la participation à des conférences), le recouvrement nous donnerait une idée assez précise.
Citons en vrac, et pour l'exercice: le développement par les tests (TDD), le refactoring, l'automatisation du build, l'intégration continue, la conception incrémentale, les User Stories, les tests de recette, les critères "Done", les Personas, le Story Mapping, le Planning Poker, les itérations timeboxées, les rétrospectives, le tableau des tâches, le libre choix des tâches, la réunion quotidienne ou "mélée", la programmation en binômes, les demandes d'aide explicites...
Parmi les "méthodes Agiles" (le mot méthode est mal choisi, mais ce sera le sujet d'un prochain billet) on peut effectivement recenser certaines dont les préconisations sont des sous-ensembles de cette longue liste: Scrum et XP notamment.
Si on se pose la question de savoir de quel mode de pensée sont issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a de nombreuses affinités avec le discours Lean. Pour autant, le recouvrement en termes de pratiques est relativement faible.
Or, soyons clair là-dessus, ce qui fait le succès ou non d'un projet, ce n'est pas le nom du discours dont on se revendique, l'attachement identitaire des membres de l'équipe: "nous sommes Agiles" ou "nous sommes Lean". Ce qui fait le succès d'un projet c'est ce que font les gens!
De ce point de vue, force est de constater que beaucoup d'équipes se proclament "Agiles" alors même qu'elles peinent à appliquer de façon compétente des pratiques aussi élémentaires que le refactoring, ou qu'elles révèlent lorsqu'on interroge les ingénieurs des contresens sur des notions de base comme la vélocité.
Une partie de ce déficit est à mettre sur le compte de la communauté Agile elle-même: il n'existe nulle part sur le Web un "Wikipedia de l'Agilité", une description systématique, détaillée, cohérente et mise à jour des pratiques désignées par le terme "Agile".
D'où le projet actuellement prioritaire de l'Institut Agile: mettre à la disposition des personnes intéressées par le sujet un "référentiel des compétences, pratiques, notions et principes" des approches Agiles. Qu'est-ce qui différentie une compétence d'une pratique, d'un principe, etc? C'est ce que j'aborderai dans le prochain billet...
Inscription à :
Articles (Atom)
Articles
