Points Clés
- Comprendre ce qu'est un radar technologique
- Assurer une forte cohésion technologique dans votre équipe
- Empêcher les technologies au sein de l'entreprise de devenir incontrôlables
Maintenir la compétitivité d'un projet sur le marché de la technologie est sans aucun doute l'un des plus grands défis pour les équipes d'ingénierie. En effet, il est nécessaire de toujours mettre à jour et réviser les solutions : car, de la même manière qu'il est mauvais d'utiliser des technologies héritées, il est également déconseillé d'utiliser des technologies simplement parce qu'elles sont des mots à la mode.
Mais comment suivre et visualiser toutes ces solutions ? Une façon de garder une trace de ces piles, qui sont cruciales pour l'organisation, est de doter votre entreprise ou vos équipes d'un Tech Radar.
Dans cet article, nous parlerons de ce que c'est, comment nous l'utilisons au sein de notre équipe Open Source et pourquoi votre entreprise devrait en avoir un.
Apprendre à connaître Tech Radar
En général, Tech Radar est une documentation d'ingénierie technique qui fonctionne comme un portefeuille pour vous permettre de visualiser les technologies et les méthodologies d'une organisation, de surveiller les nouvelles tendances et d'identifier les outils qui doivent être supprimés, soit parce que la technologie est héritée, soit parce qu'elle n'est plus stratégique pour l'entreprise.
Le Tech Radar le plus célèbre et le pionnier du marché appartient à Thoughtworks et il est très courant que cet outil soit adapté et mis à jour en fonction des besoins de chaque organisation. Le plus grand différenciateur de cette solution est qu'elle est construite à travers un processus de contribution au sein de l'équipe d'ingénierie elle-même.
Le radar en pratique
Les radars, par défaut, ont quatre quadrants avec leurs catégories respectives :
- langages et frameworks
- plates-formes
- techniques
- prestations de service
Dans chacun des quadrants, il y a quatre cercles dans lesquels vous identifiez le niveau d'importance et de pertinence de la technologie et/ou de la méthodologie pour l'établissement : Hold, Assess, Trial et Adopt. Plus on est proche du centre, plus cet outil est important.
En pratique, cela signifie que lors du choix d'un outil, d'un langage et/ou d'une méthodologie, par exemple, la priorité sera toujours donnée à ce que l'équipe sait déjà et/ou maîtrise.
Dans certains cas, il est important de vérifier s'il existe une étude concernant cette nouvelle demande. Si deux équipes ont besoin de connaître un outil, toute l'ingénierie saura qu'il existe un nouvelle vue avec cet objectif. Après tout, tout sera enregistré sur Tech Radar.
Actuellement, il existe plusieurs modèles qui peuvent être utilisés pour créer un Tech Radar :
Pourquoi construire un Tech Radar pour une équipe d'ingénieurs ?
Au sein de l'équipe Open Source de Zup, nous utilisons Tech Radar principalement pour la gestion des connaissances et aussi pour nous aider à construire des solutions de meilleure qualité.
La gestion des connaissances via un Tech Radar a plusieurs objectifs :
- Gérer les informations qui circulent entre les différentes équipes : connaissant les outils que chaque équipe utilise ou souhaite utiliser, il est plus facile d'établir une communication efficace entre les projets et aussi d'éviter les silos de connaissances.
- Motivation et formation : une fois cartographiées les technologies que les équipes ont besoin d'apprendre et/ou d'améliorer, il est possible d'organiser des groupes d'étude, des conférences, des ateliers et des recherches, y compris en équipes croisées.
- Empêcher l'équipe de perdre le focus et de suivre "l'effet de troupeau" : même s'il y a beaucoup d'opportunités de découvrir de nouveaux outils lors d'événements externes, il est important de prêter attention aux véritables motivations derrière la pile utilisée, car elles seront certainement avoir des outils qui « s'adaptent », « réussissent», etc. Il faut veiller à ne pas transformer les projets en "laboratoire en production".
- Éviter que la pile technologique ne devienne une "salade de fruits" : très similaire au cas précédent et, parfois, venant de celui-ci, l'essentiel est d'éviter d'avoir plusieurs outils qui font la même chose. Après tout, si au sein du groupe il existe déjà une solution qui résout un problème, quelle est la motivation pour en utiliser une nouvelle dans le même but ?
- Qualité du code : une équipe concentrée avec une forte cohésion dans la pile technologique facilite la gestion des connaissances, ce qui se traduit par de bonnes pratiques et une fluidité entre les équipes, en plus d'un code mieux écrit et opérationnel.
- Open Source : l'un des points critiques des projets Open Source est qu'ils doivent vraiment être Open Source, c'est-à-dire que leurs dépendances disposent de licences compatibles avec nos projets.
Au sein des options Tech Radar, nous avons opté pour la solution Agile Patner et son adaptation à Hugo, réalisée par Yoan Thirion. Nous nous basons sur 2 raisons : l'équipe connaît et maîtrise déjà Markdown et Hugo, en plus de la licence étant du MIT.
Sur cette base, nous avons créé les nomenclatures au plus près de notre quotidien :
Les cercles
- Stratégique (Strategic) : tout ce qui est considéré comme fondamental pour les projets. Les équipes ont la connaissance, la sécurité et la fluidité.
- Essentiel (Essential) : tout ce qui est déjà en cours d'adoption et de connaissance est vital pour le succès de l'équipe. Par conséquent, les équipes ont besoin de formation et/ou d'expérience.
- Potentiel (Potential) : tout ce qui adhère à la culture, aux licences appropriées et a le potentiel d'être adopté dans les projets en cours ou dans les engagements futurs. Pour cela, il est intéressant de réaliser des études et des tests pour valider l'efficacité dans le scénario d'application respectif.
- Abandonné (Discontinued) : tout ce qui est actuellement utilisé mais doit être supprimé. Les raisons de cette mesure tiennent à la cohésion de la pile technologique ou à la rupture avec la culture et/ou les licences Open Source adoptées.
Les quadrants ou catégories
- Langages et frameworks : ce sont les outils que nous utilisons directement dans le développement de projets.
- Outils : sont des logiciels que nous utilisons directement pour le développement, nécessitant une maintenance directe. Par exemple, une base de données, un orchestrateur de conteneurs, etc.
- Services : similaires au précédent, ce sont des logiciels qui aident au développement, cependant ils sont mis à disposition sans nécessité de maintenance directe de l'équipe. Dans l'ensemble, ils s'intègrent comme un PaaS et/ou un SaaS.
- Techniques : éléments d'un processus logiciel, tels que la conception et/ou le code, les méthodologies, ainsi que les moyens de structurer le logiciel en tant que microservices.
Découvrez notre radar technologique
C'est parti, vous pouvez jeter un œil au radar Zup Tech : https://opensource.zup.com.br/radar
Le point le plus important est que c'est open source, vous pouvez donc forker et créer votre propre radar technologique:
https://github.com/ZupIT/opensource-tech-radar
Tech-radar en tant que portefeuille de technologies utilisées par notre équipe. Pour l'équipe Open Source de Zup, en plus d'être organisée en tenant compte des solutions Open Source, c'est aussi un processus transparent pour les choix de stack qui seront utilisés dans les solutions.