Fleche retour aux articles de blogIntroduction à l’expérience développeur

Dans cet article de blog, nous allons nous concentrer sur différentes façons d’améliorer l’expérience développeur dans une entreprise. Le but de cet article est d’aider les personnes en charge d’équipes techniques à mieux comprendre les problèmes de leurs développeurs afin de pouvoir les aider à les résoudre.

Mots clés :

développement

DX

La Developer Experience (DX)

Recruter un développeur c’est aujourd’hui plutôt compliqué, c’est un processus long, coûteux et le profil qui correspond au poste est souvent difficile à trouver. Mais il est encore plus difficile de fidéliser et de conserver les développeurs une fois qu’ils ont rejoints vos équipes ! Les entreprises concentrent souvent leurs efforts sur des avantages liés au contrat de travail : rémunération, horaires, primes, etc. Ces aspects sont évidemment importants, mais ils ne doivent pas faire disparaître de vue un autre pan tout aussi important de la vie du développeur : peuvent-il travailler de manière efficace et apprécient-ils leur travail ?

L’expérience développeur (DX) n’est pas aussi clairement définie que ce qu’on appelle l’expérience utilisateur (UX). Certains considèrent qu’elle concerne l’expérience que les développeurs ont ou créent lorsqu’ils utilisent un outil, d’autres parlent plus largement de l’expérience des développeurs au sein de leurs entreprises. Ces deux opinions sont évidemment liées, et s’influencent l’une et l’autre. Les équipes internes qui apprécient l’utilisation d’outils bien conçus sont bien plus à même d’apprécier et de créer elles-même des outils bien conçus.

Dans cet article, nous allons nous concentrer sur différentes façons d’améliorer l’expérience développeur dans une entreprise. Le but de cet article est d’aider les personnes en charge d’équipes techniques à mieux comprendre les problèmes de leurs développeurs afin de pouvoir les aider à les résoudre.

L’équilibre entre expérimentation et productivité

La ligne de conduite à avoir pour obtenir une bonne expérience développeur en interne n’est pas si évidente à suivre. Les développeurs tendent généralement à aimer expérimenter avec de nouveaux outils, langages et pratiques. Faire travailler vos développeurs sur des tâches répétitives, ou avec le même langage et les même technologies peut rapidement entrainer un ennui et une démotivation ce qui peut les pousser à aller voir si l’herbe est plus verte ailleurs.

Leur donner l’opportunité d’expérimenter peut aussi vous être bénéfique, résultant en l’amélioration de votre produit ou en l’apparition de nouvelles fonctionnalités. Cependant, l’effet inverse peut apparaître sous la forme de temps gâché ou de complexité inutile.

Certains outils techniques sont réputés pour être parfois source de complexité dans un environnement qui ne le nécessitait peut-être pas. Mettre en place un cluster Kubernetes étalé sur plusieurs zones géographiques avec un load balancer pour servir un site vitrine est probablement superflu : un simple serveur web suffirait largement.

Pour encadrer ces sessions d’expérimentation, plusieurs entreprises ont mit en place un temps dédié intégré au temps de travail global. Ce fonctionnement donne aux développeurs un cadre temporel pour expérimenter de nouvelles idées sans ajouter une pression supplémentaire via une attente de résultat. Cependant les entreprises qui ont implémenté ces programmes (dont Google, Yahoo et Atlassian pour ne citer qu’elles) ont relevé qu’un temps dédié sans encadrement précis ne fonctionnait pas forcément : la peur de paraître moins efficace au niveau du travail “productif”, ou le manque de suivi et de valorisation diminuent grandement l’effet positif de ces mesures.

Faire des choix pour améliorer la DX

Choisissez des outils qui réduisent la charge mentale

Le développement est une activité qui est principalement cognitive, au niveau des outils il ne faut pas s’orienter vers des choix qui pourraient ajouter de la charge de réflexion supplémentaire.

Quand vous choisissez des outils pour votre équipe, ne vous basez pas uniquement sur les outils en vogue ou sur les louanges chantées par leur commerciaux respectifs, mais portez plutôt attention à ceux qui proposeront la meilleur DX à vos développeurs.

Certains éléments peuvent vous assister lors de vos choix :

  • Si c’est un outil payant, vos développeurs peuvent-ils profiter d’une période d’essai avant votre engagement ?
  • Si c’est un outil open-source, quelle est la base d’utilisateurs et s’intègre-t’il bien au sein de votre écosystème ?
  • L’open-source est souvent plus flexible, mais demande plus de travail et de la maintenance, qui va avoir la charge de s’en occuper ?
  • Comment se déroule la prise en main de l’outil et combien de temps faut-il pour mettre en place un prototype fonctionnel ?
  • Si un outil semble complexe dès les premières étapes, il est probable que cela ne s’arrange pas par la suite.
  • Est-ce que quelqu’un dans l’équipe a une expérience passée avec cet outil ou un outil similaire ?
  • Avez vous simplement accès à une documentation publique ? Une mauvaise grammaire, de nombreuses fautes ou plus simplement une lecture laborieuse peuvent indiquer un manque de qualité ou d’attention sous-jacent.

Choisissez des outils qui sont maintenu au sein d’une communauté ou d’un écosystème

Observez la communication de la communauté ou de l’entreprise qui produit et maintient l’outil. Sont ils ouverts et honnêtes lors de l’explication de problèmes comme des coupures ou des bugs bloquants ? Répondent-ils de manière constructives aux questions et aux retours des utilisateurs ? Un bon point de départ, en particulier pour l’open source, est le dépôt de code publique : les issues écrites par les utilisateurs sont-elles prises en comptent ou sont elles à l’abandon ? Les réponses à ces questions peuvent indiquer l’implication réelle des personnes derrière l’outil.

Cette phase de recherche est importante, que l’outil soit open-source ou propriétaire. Quelque chose de maintenu par une seule personne, ou par une petite équipe sans structure, est sujet à des vulnérabilités. Une bonne communication technique autour d’un projet commercial, soutenu par une entreprise, est un signe d’ouverture et d’écoute de leurs utilisateurs.

Le choix des outils, des langages et des frameworks doit avoir pour but d’augmenter la productivité de vos équipes tout en facilitant leur quotidien. Il ne faut pas se précipiter et changer son mode de travail et ses outils juste pour le plaisir de varier.

Choisissez des outils flexibles

Rechercher des outils qui laisse les développeurs (et potentiellement aux autres membres de l’équipe) les utiliser de la manière la plus confortable pour eux. Par exemple, un outil de développement qui laisse la possibilité d’y accéder à la fois via une interface graphique (GUI) mais aussi d’utiliser la ligne de commande ou même une API va permettre aux développeurs de choisir la façon de travailler qui leur corresponds le mieux.

Les meilleurs outils facilitent cette flexibilité en proposant des résultats et des fonctionnalités cohérentes quelle que soit la façon dont on y accède. Ils permettent à un même utilisateur de transitionner de façon transparente d’un mode d’interaction à un autre.

L’adaptabilité est aussi un facteur de choix au niveau des intégrations dans le code : existe-t’il des plugins officiels, des SDK ou des toolkits pour les langages de programmation principaux ou est-il uniquement exploitable via une API SOAP vieillissante ?

Évitez les outils fragmentés qui ne suivent pas un standard établi

Les équipes de développement n’utilisent pas ces outils et frameworks de manière isolées : ils les intègrent dans un système comprenant de nombreux outils. Si il y a quoi qu’il arrive des challenges lors de l’intégration d’un nouvel outil, ceux qui sont construit en suivant des standards et des schéma connus limitent cette complexité.

Heureusement, la plupart des outils qui cochent les cases précédemment définies dans cette article sont développés par des équipes au courant de ces problématiques, mais méfiez-vous des outils internes ou vieillissants.

De plus, suivre un standard ne signifie pas forcément le suivre bien. Une bonne pratique est d’intégrer les développeurs a ce choix en leur demandant d’évaluer le produit, soit directement s’il est open-source, soit via des tests d’intégration sur les points les plus critiques de votre système. Pensez aussi à vous renseigner sur les feuilles de routes des différents outils : un outil auquel il manquerait quelques briques à l’instant T pourrait être exactement ce qu’il vous faut 3 mois plus tard.

Organisez les règles et les processus internes

Choisir de bons outils n’est qu’un côté de la pièce : ça ne vous mènera pas loin si les fonctionnements internes de l’équipe, et de la société en général, sont eux-même sources de blocages limitant la productivité.

Une entreprise ne peut se targuer de promouvoir une bonne expérience développeur interne (ni des pratiques Agiles étendues) si de trop nombreuses tâches exécutées par les développeurs nécessitent un processus de validation long ou complexe. Par exemple, un développeur doit-il créer un ticket, et attendre l’autorisation d’une ou plusieurs personnes avant de créer un nouveau repository ou un nouvel environnement de développement ? Si c’est le cas, combien de temps doit-il attendre en moyenne ? Ce délais est-il raisonnable ou le développeurs doit-il prendre le temps de se replonger dans sa demande une fois validée ?

Il est compréhensible que des entreprises, surtout à partir d’une certaine taille, souhaite garder un œil sur les coûts liés à l’utilisation de leur ressources, mais de nombreuses plateformes et outils permettent d’automatiser cette surveillance ou de fixer des limites au niveau des ressources et des budgets. Une approche de plus en plus adoptée par les entreprises est celle de “psychological safety”. En bon français, l’objectif pourrais se traduire en “permettre à tout le monde de dormir sur ses deux oreilles”.

Cette approche est principalement basée sur la confiance de l’organisation envers son équipe de développement pour prendre les bonnes décisions, tout en mettant en place un suivi des métriques en particulier sur l’efficacité de ces décisions, afin de justifier leur utilisation, ou au contraire éliminer le superflu. De cette façon, les développeurs sont libres d’expérimenter de manière autonome, mais un manager d’équipe ou un un responsable technique peut aussi évaluer la bonne utilisation des ressources, et les contrôles automatiques assurent à tous que si gâchis il y a, il est limité.

Un fort sentiment de confiance entre les membres de l’équipe est un levier puissant d’engagement des salariés, d’amélioration de la DX et de diminution du turn-over.

Maintenez une documentation interne

Plus tôt dans cet article j’ai parlé de l’importance de la documentation des outils que vous choisissez, mais la documentation interne des processus, des fonctionnement et des systèmes en place dans votre entreprise est tout aussi importante. La documentation interne n’aide pas seulement les membres actuels des équipes à mieux comprendre comment fonctionnent et interagissent les outils (ce qui est utile pour des tâches peu courantes), mais elle est aussi un élément important lors de l’accueil de nouvelles recrues ! Une bonne documentation interne devrait réduire les questions et les errances des développeurs et donc augmenter et améliorer leur temps de développement productif !