C’est ainsi que nous accueillons, Lana Lesik, ancienne psychologue sociale et clinique, spécialisée dans l’addictologie et les troubles du comportement. Après un revirement à 180°, elle est désormais développeuse mobile et fullstack au sein d’Octo Technology.
C’est cette expérience singulière qu’elle nous a partagée lors de sa présentation, et sa promesse: s’éclater au travail tous les jours tout en développant un produit de qualité.
Tout d’abord, pour répondre à cette question, il est important de bien comprendre comment se déroule une journée de travail pour un développeur.
Today was a Good Day: The Daily Life of Software Developers
Comme vous pouvez le voir et l’imaginer, la production du code d'un développeur se limite en moyenne à 84 minutes par jour. Aussi choquant que cela puisse paraître, on remarque aussi que la communication (36 %) et la gestion de la dette (14 %) représentent à eux seuls la moitié du temps de travail. Au vu de ces chiffres, il devient d’autant plus important de maximiser le temps de production de valeur des développeurs, et ceci est aussi la promesse du DevEX.
Mais comment a-t-on pu en arriver à cela ? Quelles sont les voies d’amélioration ? Pour cela, intéressons-nous d'abord aux causes.
Aujourd’hui, le développeur moderne doit :
1 - Savoir maîtriser plusieurs langages et frameworks, connaître les bonnes pratiques de développement et de sécurité, savoir faire du TDD.
2 - Connaître des notions de Cloud et de CI/CD.
3 - Pouvoir concevoir des architectures adaptées aux besoins.
4 - Savoir travailler en équipe, maîtriser les principes de communication non-violente
5 - Connaître la méthodologie mise en place.
6 - Ne pas oublier la documentation technique, savoir utiliser le design system, savoir intégrer de nouveaux développeurs.
Et tout cela est demandé de manière “naturelle” et évidente. Sans système et organisation, ces tâches peuvent accabler et créer un chaos dans le quotidien des développeurs! Cela peut d’autant plus être vrai, lorsque l’on a le sentiment que les tâches n’avancent pas.
Pour introduire ce paragraphe, la citation de Jonathan Carter, conseiller technique du PDG de GitHub, semble tout à fait appropriée.
> “Le but est de rendre les développeurs heureux. Personne dans le monde ne se sent bien en ouvrant un pull request qui reste en attente de validation pendant deux jours.”
C’est un peu le postulat de base du DevEx, un développeur épanoui, sera plus volontaire et plus productif, il deviendra un formidable moteur auprès de ses collègues.
Et comment rendre des développeurs épanouis et productifs, demanderiez-vous ? En améliorant l’expérience des développeurs bien sûr ! Mais qu’est-ce que c’est réellement ?
La DevEx, ou encore DX, est une approche explorant l’expérience “d’utilisateur” où l'utilisateur est un développeur. De la même manière, quand on parle de l’approche UX pour un produit, on essaie d’améliorer le parcours d’utilisation, dans le cas du DevEx on parle de l’amélioration du quotidien des devs : les outils, l’organisation, les pratiques de travail.
Comme la DevEx se trouve à mi-chemin entre la technique et l’humain, c’est très compliqué de la définir. Des géants tech et des entreprises centrant leur produit sur la DevEx ont des définitions hétérogènes de ce concept, en mettant l’accent sur différentes parties de l'écosystème de développement.
Pour GitHub la DevEx est l'ensemble des processus socio-techniques conçus pour améliorer la performance des équipes en les alignant avec les missions et la culture de l’organisation
Tandis que pour Microsoft c’est tout simplement la facilité d'effectuer les tâches demandées.
Ou encore pour DX (entreprise spécialisée dans le domaine) c'est l'ensemble des rôles, de l’expérience et de la satisfaction dans le cycle de vie du développement logiciel
Vous l’aurez compris la définition de la DevEx est unique à chaque entité et reflète bien souvent le but que l’on cherche à atteindre. C’est pour cela que nous vous laissons le choix de celle-ci en fonction de vos ambitions et du contexte dans lequel vous vous trouvez. Nous allons, en revanche, nous intéresser davantage aux dimensions qui peuvent impacter l'expérience des développeurs.
Si on essaie de regrouper et d'organiser différentes facettes de la DevEx, on pourrait retrouver les couches suivantes :
Dans la couche la plus basse, on retrouve ce qui est directement de la responsabilité des développeurs, ce qui impacte directement leur quotidien.
Ensuite, on va avoir l’ensemble de l’écosystème dans lequel les développeurs gravitent, on va y trouver les outils fournis par d’autres équipes, l’architecture du projet. Cette couche a surtout un impact sur le processus de développement jusqu’en production.
Qui dit d’autres équipes dit organisation, la question ici va être de savoir si l’organisation est un frein ou un irritant pour les développeurs, ou si au contraire c’est un levier.
Et ensuite viennent les couches plus haut niveau de la direction et de la culture qui jouent principalement sur le sentiment d’appartenance et la raison d’être du développeur. Ceci peut avoir un impact sur la motivation, l'engagement, l'alignement des valeurs et la proactivité des développeurs.
Maintenant que la DevEx n’est plus un mystère et que les différentes couches d’action ont été identifiées, il est le temps de découvrir différentes méthodes d’amélioration sur son projet en quelques mois.
L’expérience aura pour cible l’évolution de la productivité et de la satisfaction du développeur, ce sont des metrics tout à fait personnelle et subjective. Cependant, cela pourra vous donner des clés de lecture sur le résultat probable de certaines initiatives.
L’aventure commence par la couche la plus basse, le quotidien du développeur. Améliorer l’expérience et la productivité, c’est aussi la promesse des assistants de code tels que Copilot, c’est donc la solution qui a été choisie pour le test.
Après plus d’un mois d’utilisation, les bénéfices ont commencé à se manifester surtout dans les tâches assez répétitives comme la génération de documentation et les boilerplates. Le bilan de ce test se solde par une légère augmentation de la productivité en effaçant une partie de la redondance des tâches, cependant, au niveau de l’expérience aucun gain notable de ce côté.
En résumé, les assistants de code peuvent booster la DevEx en nous soulageant des tâches redondantes, ce qui permet de se concentrer sur des activités plus complexes et intéressantes.
Après avoir essayé l’assistant de code, on avance vers la couche d’écosystème et on découvre l’Internal Developer Portal (aussi connu sous l’acronyme, IDP). Son but est d'agréger des applications et des données sur le projet, ce qui permet de centraliser et de répertorier les différentes ressources. Cela facilite la recherche d’information au quotidien et aussi à l’onboarding d’un nouveau membre dans l’équipe.
Pour aller plus loin dans ce domaine, un talk de Adrien Saunier et Romain Taillade sur l’implémentation d’IDP.
Pour mieux comprendre comment la centralisation peut améliorer l’expérience du développeur, on va notamment se pencher sur la charge cognitive.
La charge cognitive est les efforts ou de ressources mentales nécessaires pour effectuer une tâche. En moyenne, notre cerveau arrive à gérer entre 5 et 9 informations efficacement. Avec un nombre de sources d’information en hausse, il est difficile de faire abstraction de tout cela pour se concentrer uniquement sur la tâche à effectuer en tant que développeur.
C’est ainsi qu’en centralisant une partie des sources d’information il est plus facile d’être efficace dans sa recherche et de ne pas avoir l’impression d’être submergé.
Par contre, l’IDP est un produit en lui-même, afin de le développer et maintenir il faut prévoir une équipe afin d’éviter les dettes et l’obsolescence d’IDP. Cela demande des coûts non négligeables et devient un frein à l'implémentation de cette solution.
Une autre solution en vogue en ce moment qui peut impacter la DevEx. Cette solution concerne les patterns d’architecture à l'échelle et impacte les couches d'écosystème et d’organisation simultanément.
Si on prend pour exemple un projet qui gère une vingtaine d’applications relativement similaires, au lieu que chaque application soit indépendante et que bon nombre des composants soient identiques. Le système de plateformisation nous permet de baser chaque application sur une base d’abstraction commune.
Cela a de nombreux bénéfices tels que standardiser les pratiques à l'échelle d’un projet ce qui favorise la montée en compétence des nouveaux arrivants. Ceci permet aussi de rendre ces applications modulaires. Cependant toute cette approche n'est pas gratuite et nécessite qu'une équipe s'occupe de ce socle commun et cela nécessite aussi une refonte de l’organisation interne du projet. Cette approche peut être très coûteuse au début d’un projet lorsque l’on gère 2-3 applications, mais au long terme si le périmètre est voué à s'agrandir c’est un investissement rentable.
Pour aller plus loin dans ce domaine, [un talk de Hana Amiri ](https://www.youtube.com/watch?v=0B8-NSmk3a4)[sur l’approche plateforme ](https://www.youtube.com/watch?v=0B8-NSmk3a4)\.
Le bilan de la mise en place de cette architecture a permis d'augmenter encore la productivité De plus, cette fois-ci, la satisfaction s'est aussi améliorée due à la communication, qu’a engendrée cette architecture, entre les différentes équipes.
Bien que ces différentes expériences nous aient montré qu’elles pouvaient être un plus pour l’expérience développeur. Il est difficile d’améliorer le ressenti d’une personne, ici les développeurs, purement en se basant sur des solutions techniques.
C’est donc pour cela que pour définir la DevEx on aime parler de 3 axes majeurs qui sont les suivants: Feedback loops, Flow State et Cognitive load. Qui sont tous les trois aussi bien impactés par l’environnement technique que par les interactions humaines.
Le cognitive load a déjà été mentionné à travers la charge cognitive précédemment.
Le flow state représente un niveau de concentration absolue dans lequel toutes les distractions superflues sont mises sur le côté pour ne garder que ce qui est nécessaire à la réalisation d’une tâche. Cet état peut être atteint grâce à 3 axes majeurs: la motivation, l’immersion et la concentration.
Pour atteindre et maintenir ce niveau de concentration, il est important d’avoir des sessions ininterrompues de travail, car une fois ce niveau de concentration interrompu il faut en moyenne 23 minutes pour le retrouver
Il est bon de noter que cet état de concentration est facilement rompu par des interruptions extérieures, même brèves, telles que des notifications, des réunions ou une discussion.
La feedback loop est une attention toute particulière de la méthodologie agile et le framework Accelerate, qui cherche constamment à donner des retours aussi bien techniques qu’humains.
La DevEx n’apporte que la notion de ressenti utilisateur à cette méthodologie.
Le dernier sujet abordé est l’importance d’avoir une politique à l’échelle d’entreprise qui favorise la DevEx. En effet les actions mineures telles que la mise en place de technologies, ne peuvent pas être comparées, au niveau de l’impact sur les employés, à des transformations en profondeur.
En effet le sentiment de but collectif et de valeurs partagées est un prérequis à une stratégie de DevEx commune à un périmètre élargi.
Le fait d’avoir une stratégie globale permet d'influencer l’ensemble des couches ci-dessous et donc d’en maximiser les gains. Si l’initiative est localisée sur un petit périmètre, il sera difficile d’établir une causalité directe entre les gains et l'initiative DevEx.
Le quotidien d’un développeur est bien plus complexe et ne se réduit pas à une production de code. Les journées des développeurs des développeurs sont chaotiques et épuisantes
Developpeur Expérience (DevEx) est une approche visant à optimiser l'environnement du travail en diminuant le chaos et en favorisant l’état de flow. C’est un activateur de la productivité et du bien-être des développeurs.
L’amélioration de la DevEx doit faire partie de l’engagement d’entreprise : c’est un deal gagnant-gagnant, qui ne peut pas dépendre seulement de l'équipe des développeurs
Lectures recommandées:
1. An Actionable Framework for Understanding and Improving Developer Experience, https://www.michaelagreiler.com/wp-content/uploads/2021/12/Framework-for-Understanding-and-Improving.pdf
2. Recovering from an interruption: Investigating speed−accuracy trade-offs in task resumption behavior, https://psycnet.apa.org/record/2013-21648-001
https://dl.acm.org/doi/pdf/10.1145/3595878
3. Today was a Good Day: The Daily Life of Software Developers, https://www.microsoft.com/en-us/research/uploads/prod/2019/04/devtime-preprint-TSE19.pdf
4. Octoverse Spotlight 2021: The Good Day Project—Personal analytics to make your work days better,
https://github.blog/news-insights/research/octoverse-spotlight-good-day-project/
5. Qu'est-ce que la DX (Developer eXperience) et pourquoi vous devriez vous y intéresser ?, https://niji.tech/dx-developer-experience-enjeux
6. Cutting Through the Noise: Three Things We've Learned About Generative AI and Developer Productivity, https://innovation.ebayinc.com/tech/features/cutting-through-the-noise-three-things-weve-learned-about-generative-ai-and-developer-productivity/?_bhlid=2b04117fca86995bec0f1d40c843bb6a223947e9&utm_source=leadershipintech&utm_medium=newsletter&utm_campaign=steve-ballmer-was-an-underrated-ceo
7. Harmonizing Complexity - Hana Amiri - DDD Europe, https://www.youtube.com/watch?v=0B8-NSmk3a4
8. Construire la carte d'un SI en mouvement pour visualiser l'efficience - La Duck Conf 2024, https://www.youtube.com/watch?v=aMu4gOZnTEc
Ou sinon, directement en vidéo sur YouTube