Si vous avez déjà essayé ou appris un peu la méthodologie agile scrum, vous devriez avoir sans aucun doute entendu parler des équipes pluridisciplinaires. Il s’agit d’équipes dont les membres ont différentes spécialisations avec une connaissance générale des spécialisations des autres membres. Une équipe pluridisciplinaire est bien sûr quelque chose qu’une organisation ne bâtit pas en une nuit. La réussite de la formation d’équipes pluridisciplinaires demande une grande maturité agile, suffisamment de ressources (en argent et en compétences) et le plus important, un super travail d’équipe.

Pour rendre cela plus facile à comprendre de ce qu’est supposé être une équipe pluridisciplinaire, je vais faire l’analogie entre une équipe pluridisciplinaire et un groupe de JdR¹. Je prends cette analogie car je jouais autrefois au JdR, et il existe heureusement d’autres analogies qui peuvent fonctionner tout aussi bien.

De la présence de plusieurs experts

Quand vous jouez au JdR, que ce soit à d’anciens jeux comme Lunar Silver Star Story ou à des jeux récents comme Wasteland 2², vous vous apercevrez que votre personnage sera le résultat de différentes classes de personnages. Il n’est jamais avisé d’avancer avec une équipe composée uniquement de guerriers ou de magiciens, dans la plupart des cas, votre équipe serait écrasée immédiatement. Par exemple, si tous vos personnages sont des guerriers, dès que vos ennemis seront des magiciens, votre équipe sera dans la panade.

De manière générale, les classes de personnages de l’équipe avec lesquelles je joue sont :

1. Des guerriers légers (ceux qui font rapidement des dégâts modérés)
2. Des guerriers lourds (ceux qui font des gros dégâts physiques mais qui sont plus lents)
3. De la magie offensive (des magiciens avec une spécialisation offensive)
4. De la magie guérisseuse (des magiciens avec une spécialisation dans la guérison de l’équipe)
5. Un marchand (pour obtenir de meilleurs prix sur les objets)

Maintenant, même si j’ai la totalité ce que je viens de citer précédemment, un groupe puissant ne se fait pas en une nuit. Au fur et à mesure que le groupe avance, l’expérience de chaque membre de l’équipe augmentera. La chose importante est d’être certain que nous utilisons les points d’expérience pour apprendre la spécialisation spécifique de chacun des membres du groupe.

Je vais utiliser l’exemple du magicien. Il peut soit apprendre la magie offensive soit la magie guérisseuse, la meilleure chose à faire est d’avoir chacun des magiciens spécialisés dans chacune d’elles. Un magicien avec un niveau élevé en magie guérisseuse sera capable de faire récupérer beaucoup plus de points de vie. Je pense que la pire chose à faire est d’essayer de faire monter de niveaux les magiciens à la fois en magie offensive et en magie guérisseuse, ils finiront avec un niveau médiocre dans chacune d’elles, ce qui aura comme résultat des affrontements très difficiles.

Lorsque votre groupe de JdR est d’un niveau élevé et qu’ils sont tous spécialisés, il est plus que probable que l’équipe sera capable d’affronter différents types de quêtes et d’ennemis. Si un groupe d’ennemis puissants apparaît, les guerriers légers feront des attaques ciblées, les guerriers lourds feront des dégâts de masse, les magiciens offensifs renforceront l’équipe ou feront des attaques de magie élémentaire. N’oublions pas également le magicien guérisseur, il guérira le groupe à chaque tour, permettant aux autres membres de l’équipe de récupérer des points de vie.

Alors vous pourriez dire … euh, et le marchand alors ? Il peut marchander mais il est faible en attaque et il ne connaît pas la magie. Eh bien, vous serez surpris de l’utilité de ce membre supplémentaire qui peut apporter des potions de récupération de mana pendant la bataille ou apporter un appui tactique. Il peut aussi accomplir des choses utiles comme appliquer des potions de récupération à un membre devenu inconscient (0 point de vie) pendant la bataille, afin qu’il/elle puisse continuer la bataille. Nous parlerons du marchand un peu plus tard.

La réalité

Revenons à la réalité et réfléchissons à notre équipe scrum pluridisciplinaire. Je vais utiliser le terme équipe de développement tout au long de cet article pour évoquer l’équipe scrum. La meilleure composition d’une équipe mature de développement web pourrait correspondre à quelque chose qui ressemblerait à ceci :

1. Développeur frontend
2. Développeur backend
3. Concepteur graphique et expérience utilisateur
4. Testeur
5. Analyste métier / product owner
6. Scrum Master

Comme nos magiciens dans notre groupe de JdR, les développeurs se concentrent tous sur leurs propres spécialisations. Par conséquent, quelque soit les projets donnés à l’équipe, ils seront capables de les prendre en charge. De plus, lorsque le besoin se fait sentir, ils auront le concepteur graphique et expérience utilisateur pour les aider sur les interactions utilisateurs. Le testeur aidera alors l’équipe en s’assurant que tous les produits seront de qualité supérieure pendant la durée de développement. La chose importante est que le testeur doit travailler avec toute l’équipe pendant la totalité du processus, tout comme le guérisseur doit travailler pendant toute la durée de la bataille. S’ils travaillent juste à la fin du cycle, alors des problèmes de qualité pourraient survenir, tout comme si le groupe de JdR attendait que l’ensemble de l’équipe ait atteint les 10% de points de vie restants avant de se soigner.

Afin de terminer le parallèle, j’aimerai mentionner l’analyste métier, qui est un peu comme le marchand dans notre groupe de JdR. Il ne met pas forcément les mains dans le cambouis du développement en tant que tel, mais il doit travailler continuellement avec le reste de l’équipe comme la personne qui est la plus même de dire que le produit va dans le bon sens. Une autre chose qui n’existait pas dans le groupe de JdR précédemment évoqué est le scrum master. Il/Elle est la personne qui, en un sens, protège et guide l’équipe scrum toute entière, un peu comme Nall (le chat compagnon) dans Lunar. Il ne prend pas forcément part à la bataille, mais il prend note de ce qu’il se passe et guide l’équipe. Si la situation est désespérée, il soigne aussi si possible toute l’équipe. Par conséquent, le scrum master n’est pas le héros, il est plus le protecteur et le guide de l’équipe.

Pluridisciplinaires en cas de besoin

Nous avons beaucoup parlé des spécialisations dans la section précédente. Alors que nous avons parlé clairement en faveur de la spécialisation, eh bien devinez quoi, quelques fois la situation exige de la pluridisciplinarité, tout spécialement lorsque la quête est d’un niveau de difficulté supérieur à la zone de confort de l’équipe. Si pour quelle que raison que ce soit tous les guerriers du groupe sont hors de combat, nous nous attendons à ce qu’un ou plusieurs membres du groupe prennent le rôle des guerriers pendant que les guerriers originaux de l’équipe soient en train d’être remis d’aplomb.

Ce n’est pas parce qu’un personnage est spécialisé en marchandage ou en magie, qu’il/elle ne peut pas faire d’attaque au corps à corps. Bien que le marchand n’ait pas beaucoup de capacité de combat à cause sa classe, il est possible de l’équiper avec de bonnes épées et une bonne armure, et il devrait donc être capable d’infliger quelques dégâts aux ennemis. Cela doit être la même chose pour les autres membres du groupe, le magicien peut utiliser son bâton magique pour attaquer un ogre. Bien sûr, il faut se rappeler de remettre en état les membres de l’équipe qui vont habituellement à l’attaque. C’est pourquoi le guérisseur ne doit pas aussi attaquer, à la place lui/elle doit se focaliser sur la tâche la plus importante du moment : remettre d’aplomb les deux guerriers.

Réalité

Retournons de nouveau de notre monde de JdR à la réalité. J’espère que le parallèle avec la réalité est assez clair, dans le sens où les membres de l’équipe scrum devraient avoir la capacité d’assumer le rôle des autres si nécessaire. Pour vous donner un exemple : si l’application web que vous êtes en train de réaliser a, d’une quelconque manière, des problèmes d’interface utilisateur en raison de difficultés techniques et de complexités inattendues, il est possible pour le développeur backend de donner un coup de main au développeur frontend. Même si le développeur backend n’est pas très entraîné dans le développement d’interface utilisateur, il/elle devrait avoir quelque connaissance en développement afin qu’il puisse contribuer dans la correction des anomalies les plus faciles. C’est la même chose avec le concepteur d’interface utilisateur et l’analyste métier, il peut soit aider dans le développement d’interfaces utilisateur soit aider le testeur.

Tout comme notre magicien dans l’exemple précédent, le développeur frontend ne doit pas être distrait de sa tâche sur l’item le plus prioritaire du moment, c’est-à-dire de continuer le développement de l’interface utilisateur et de corriger les anomalies. Bien que la même chose s’applique avec le testeur, il/elle doit continuer avec le test continu car il est important pour l’avancée du développement de l’interface utilisateur, il ne serait pas conseiller pour lui/elle d’abandonner le rôle du test et de commencer à aider sur le développement.

Ainsi, n’oublions pas que bien que les membres de l’équipe devraient être avoir une connaissance approfondie de leur domaine, ils devraient avoir une connaissance superficielle des différents domaines de l’équipe. Bien sûr, il n’est pas possible de faire cela à 100% mais au moins nous devrions nous acharner à le faire. Par exemple, un développeur frontend peut jeter un coup d’oeil de temps à autre au code backend et avoir l’autorisation de le modifier ou de travailler sur des tâches de moindre priorité.

La formation de l’équipe elle-même est une quête

Rappelez-vous lorsque vous commencez à jouer à un JdR, commencez-vous à jouer uniquement avec votre héros ? Dans Lunar Silver Star Story, vous commencerez juste avec votre héros accompagné de Nall. Un groupe en parfaite harmonie n’existe pas en un jour. Un par un, les membres de l’équipe seront trouvés et se joindront éventuellement à l’équipe, en commençant par Luna, le marchand et le reste des personnages tout au long du jeu. Quelques-uns des personnages ne seront pas trouvés avant même le milieu du jeu, beaucoup de quêtes devront être accomplies avant de recruter des membres importants du groupe. Certains ne resteront même pas avec votre groupe de manière permanente, ils viendront se joindre et aider l’équipe seulement pour certaines quêtes.

Cela demande aussi beaucoup d’efforts de montées de niveaux pour avoir un niveau de compétences suffisant afin que chacun des personnages puissent aider l’équipe.

Réalité

Je suis certain désormais que vous saisissez le parallèle entre votre équipe scrum et le groupe de JdR. Quand vous montez une équipe scrum pluridisciplinaire, vous en tant qu’avocat et débutant commencerez certainement en solitaire tout comme le héros dans un JdR. L’équipe ne se formera pas tout de suite, quelque fois vous commencerez avec des membres d’équipes différentes partageant leurs responsabilités entre différentes équipes.

D’autres fois, vous aurez quelques membres permanents et le reste viendra se joindre à l’équipe si nécessaire. Si je dois donner un exemple, ce serait celui des administrateurs de bases de données. Dans la plupart des organisations, il n’y a pas abondance de ce type de ressources et tous les projets n’ont pas besoin d’administrateurs de bases de données. Par conséquent, il n’y a pas de sens à avoir des administrateurs de bases de données de manière permanente dans une équipe scrum, donc normalement, ils se joignent à l’équipe lorsque cela est nécessaire et la quittent lorsque leur devoir est accompli.

Comme je l’ai dit sur la montée de niveau dans les JdRs, une équipe pluridisciplinaire doit toujours s’acharner à s’améliorer. Cela peut être à travers des recherches, du développement en binôme, des présentations, des rétrospectives et plein d’autres choses encore. Nous devons toujours garder à l’esprit que le partage de connaissance est un élément vital à se rappeler et que chaque membre de l’équipe doit toujours penser positivement en termes d’entraide des uns envers les autres. Cela prend du temps de connaître chacun des membres de l’équipe et cela prend du temps aussi de trouver la bonne personne pour se joindre à l’équipe.

En conclusion

Je voudrais réitérer mon affirmation qu’une équipe pluridisciplinaire scrum est comme un groupe de JdR. Cela ne se fait pas en une nuit, cela peut prendre un peu de temps pour le faire, les membres doivent avoir une connaissance approfondie de leur spécialisation tout en ayant une connaissance superficielle des autres domaines de compétences dans lesquels les autres membres sont spécialisés afin que, si le besoin survient, l’équipe soit capable de continuer d’avancer.

Le plus important est de toujours garder des attitudes positives au sein de l’équipe. Si vous jouez à des JdRs comme Lunar Silver Star, je ne pense pas que vous trouverez des personnages de votre groupe grogner ou blâmer les uns sur les autres tout le temps (d’accord, peut être que cela arrive dans d’autres jeux que je ne connais pas, mais pas dans Lunar !), à la place les membres sont toujours prêts à avancer vers la prochaine quête quoi qu’il se passe. Dans certains cas, le personnage ennemi peut même devenir un des membres du groupe. Pourquoi est-ce que les histoires sont écrites dans ce sens ? Parce que c’est toujours plus amusant lorsque tout le monde a une attitude positive même lorsqu’ils font face aux défis les plus difficiles.

Je comprends que cet article est plutôt pour des initiés (du JdR - NdT) ou plutôt inhabituel pour un sujet professionnel, mais j’espère qu’il a du sens et qu’il peut résonner pour toutes les personnes pour lesquelles les JdRs sont des jeux plutôt répandus de nos jours.

Si vous voulez ajouter quelque chose, n’hésitez pas à laisser quelques commentaires dans la zone commentaire. Rappelez-vous, une attitude positive et le partage de connaissances est la clé vers la réussite d’une équipe !

Auteur : Arvy Budiarto
Source : Scrum Agile Cross Functional Team is an RPG Party
Date de parution originale : 08 Juin 2015

Traducteur : Nicolas Mereaux
Date de traduction : 10/08/2015

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.