Un avis ? Un commentaire ?
Cet espace est pour vous.
Pour ce deuxième article sur les métaphores au service du test, nous allons nous concentrer sur un aspect crucial de tout projet informatique : la gestion des connaissances. Comment faire pour partager les bonnes infos aux bons endroits, de manière à ce que les bonnes personnes puissent les trouver au bon moment ? Et pour commencer, comment donner aux collaborateurs l’envie de transmettre leur savoir d’une part, d’augmenter leurs compétences d’autre part ? Lorsque vous étudiez ces questions avec votre équipe, nous vous proposons de garder à l’esprit une métaphore, qui nous vient des confins du Pacifique Sud. Au passage, merci au Guichet du Savoir pour les recherches bibliographiques sur ce sujet !
Vous en êtes certain, il y a des trous dans la raquette. Les membres de votre équipe sont excellents dans leur spécialité, mais ne connaissent pas suffisamment le travail les uns des autres et sont incapables de se relayer. Cela peut être un handicap à plusieurs niveaux :
Mike Talks est testeur en Nouvelle-Zélande. Cité dans More Agile Testing de Janet Gregory et Lisa Crispin (2014), il s’inspire au travail de l’histoire de son pays.
Dans la lignée des idéaux historiques néo-zélandais, j’encourage tout un chacun à sortir de sa zone de confort au sein de son équipe et s’essayer à de nouvelles choses. Dans un contexte de rareté des ressources et des compétences, ces modes de fonctionnements se sont révélées cruciaux pour les premiers pionniers de Nouvelle-Zélande. De manière générale, les spécialistes étaient amenés à diversifier leurs connaissances pour devenir des « spécialistes généralisants« . [Traduction Hightest]
A propos des pionniers de Nouvelle Zélande, Francine Tolron (source) rapporte effectivement les détails d’une vie quotidienne débrouillarde, émaillée de multiples activités :
Le pionnier […] dut trouver en lui-même ses ressources : construire […] un abri, une baraque de ponga, à partir des stipes de fougères, un toit en feuille de lin ; il lui fallut ramasser la nourriture de la forêt […], brûler les troncs pour fertiliser la terre entre les souches afin de planter du blé qu’il devait moudre sur place. Il fabriquait tout ce dont il avait besoin, depuis le beurre jusqu’aux chandelles et aux briques.
Visualisez-vous en train de fabriquer vos propres chandelles pendant que les briques que vous avez vous-mêmes façonnées sont en train de cuire dans votre four ; il n’y a rien que vous ne puissiez pas apprendre, ni vos collègues. Cela dit, on peut être aussi débrouillard que l’on veut, certains savoir-faire ne s’inventent pas, et les cycles projet ne permettent pas forcément de s’accorder de longues journées d’apprentissage autodidacte. La métaphore de Mike Talks permet donc de mettre l’accent sur les liens indispensable entre les membres de l’équipe. De même que les pionniers de Nouvelle-Zélande, il est nécessaire de développer des compétences secondaires, en s’appuyant sur les compétences les uns des autres. L’équipe projet est comme une île où il est nécessaire de valoriser au maximum chacune des ressources, car les risques de perdre une expertise sont décuplés.
Pour la petite histoire, Mike Talks a mis en action cette idée en travaillant de concert avec un business analyst. D’abord convaincu qu’il lui serait simple de rédiger des expressions de besoins, il s’est finalement rendu compte qu’il s’y prenait mal. D’une part, il n’expliquait pas suffisamment le cœur du problème, d’autre part il partait trop loin dans les détails, empiétant sur la marge de manœuvre des développeurs. Progressivement, monter en compétences dans ce domaine a enrichi ses propres pratiques et a par la suite amélioré la performance de ses échanges avec d’autres business analysts.
Mike Talks a également pu approfondir sa connaissance du métier en allant proactivement à la rencontre des utilisateurs du produit testé. Bâtir une relation de confiance, là où il aurait pu ne rien y avoir, lui a encore permis de gagner en pertinence lors de ses tests.
Cette démarche d’apprentissage a pour conséquence de modeler une expertise en forme de T, de nous transformer en « versatilistes » ou « T-shaped testers » (et non, on ne parle pas d’haltérophilie). Cette image a été développée en 1991 par David Guest dans l’ouvrage The Hunt Is On for the Renaissance Man of Computing, où est évoquée l’image de l’homme de Vitruve dessiné par Léonard de Vinci.
Ici, la barre verticale du T représente les connaissances en test, approfondies par l’expérience, et qui permet au testeur d’exercer au mieux son coeur de métier. C’est la taille du testeur ; plus il est grand, plus il voit loin ; il a en tête de nombreux paysages logiciels, il voit venir les problèmes à l’horizon et a le temps de s’y préparer.
La barre horizontale est quant à elle le symbole des domaines connexes maîtrisés en second plan. C’est l’envergure du testeur, ce qui lui permet de tendre la main et d’attraper, d’assimiler et de valoriser des informations issues d’autres domaines. Ce sont les connaissances métier engrangées au contact des clients, la culture technique acquise au contact des développeurs, les compétences managériales développées au fil des projets.
Et vous, quelle est votre T ? Quel est celui de vos collègues ? Que pouvez-vous vous apporter les uns les autres, de manière à ce que votre île soit la plus vivable possible ?
La métaphore de l’île nous amène à capitaliser les connaissances qui existent au sein d’une équipe, afin d’élargir le champ de compétences de chaque individu. De la même manière qu’une fonctionnalité peut être partiellement couverte par des tests portant sur une autre fonctionnalité, des activités peuvent être sommairement assurées par des personnes dont ce n’est pas le coeur de métier.
La démarche d’apprentissage peut s’accompagner d’une réflexion sur le « nous » de l’équipe. Pour cela, nous vous conseillons d’explorer les ateliers et supports développés par l’UdN (Université du Nous).
Nous vous proposerons prochainement une nouvelle métaphore issue de More Agile Testing, qui nous reliera cette fois au monde agricole… d’ici-là, n’hésitez pas à poster en commentaire les métaphores qui vous semblent précieuses pour illustrer la gestion des connaissances.
Cet espace est pour vous.