Ma vie de développeuse, interview d'Elodie

Aujourd'hui, j'interviewe Élodie aka Élo, développeuse chez Anybox. Elle nous partage une journée en télétravail intégral ou Full remote.

Delphine: Bonjour Élo, que fais-tu au sein d'Anybox, quels sont tes rôles et missions?

Élodie: Bonjour Delphine, chez Anybox, je suis développeuse python. Je suis chargée de conseiller et de développer des projets web pour nos clients.

D: Qu’entends-tu par conseiller?

É: Trouver des solutions techniques pour résoudre les problématiques des clients; choisir les technos les plus adaptées.

D: En quoi consiste une journée type ?

É: Je me lève tous les matins à 7h15. Ma journée commence avec un petit-déjeuner. Après avoir déposé ma fille à l’école, à 8h20, je commence ma journée de travail.

Je reprends le travail en cours ou commence un nouveau ticket. Je termine généralement vers 18h30 / 19h.

Mes pauses aller-retours à l’école me permettent de prendre l’air et de souffler un peu.

D: Qu’est-ce qu’un ticket?

É: Chez Anybox, les clients nous transmettent leurs besoins sous forme de tickets gérés via un outil de ticketing. Cela permet au développeur d’avoir les informations et d’échanger avec le client sur la réalisation de la correction ou de l’évolution d’une fonctionnalité.

D: Rencontres-tu des problèmes? si oui, lesquels?

É: Des problèmes surviennent lorsque les tickets ne sont pas assez détaillés ou comportent des ambiguïtés.  Cela peut rendre le développement difficile.

D: Qu’entends-tu par difficile?

É: Lorsque la demande est sujette à interprétation, nous risquons de partir dans la mauvaise direction et développer des choses pour rien. Il arrive aussi que le manque d’information entraîne une impossibilité de répondre à la demande.

D: Lorsque cela arrive, comment fais-tu?

É: La seule solution est d’échanger avec le client. Je peux le faire par message via l’outil de ticketing, ou de vive voix, ce qui rend la compréhension du besoin plus efficace.

D: A quoi vois-tu qu’il y a besoin d’une clarification de vive voix?

É: Quand le risque d'interprétation est trop important et que cela peut entraîner des développements inappropriés assez conséquents.

D: Rencontres-tu d’autres difficultés?

É: Il arrive parfois que malgré un besoin clairement identifié, la façon d'y répondre ne le soit pas. Cela donne lieu à des brainstormings entre développeurs avec pour objectif d’en sortir la meilleure réalisation technique.

É: La reprise d'un développement existant peut aussi entraîner des  difficultés, car cela ajoute un temps de compréhension supplémentaire.

D: Selon toi qu’apportes-tu à tes clients?

É: D’une manière générale, les outils numériques créés sont là pour aider les utilisateurs dans leurs tâches quotidiennes ou le développement de leur activité. Je peux aussi les conseiller ou les rassurer.

D: Pourquoi penses-tu que les clients nous ont choisi?

É: Nous sommes une équipe avec différents profils, et, notre organisation en mode agile peut rassurer.

D: Ah oui? pourtant j’avais en tête que l’agilité pouvait faire peur, les clients ayant l’habitude de développement en mode projet avec date de fin identifiée ce qui les rassurent sur leur budget et la date de mise sur le marché de leurs propres services et/ou produits?

É: En théorie, le développement en mode projet semble rassurant. Mon expérience dans le développement m’a montré que la date de fin est rarement respectée et ajoute du stress pour tout le monde.

D: As-tu en tête la raison des retards?

É: Généralement, au démarrage du projet, le client n’a pas forcément en tête ce dont il a besoin et surtout comment le partager avec l’équipe de développement.

En parallèle, l’équipe de développement découvre un context client souvent différents, même s’il existe parfois des similitudes avec d’autres clients.

C’est d’autant plus vrai quand le client propose des produits et/ou services innovants. Il peut se passer beaucoup de temps avant que l’équipe et le client se rendent compte d’un éventuel désaccord.

D: Et tu penses que le mode agile est préférable et diminue le stress et favorise l’avancement des projets?

É: En mode agile, nous avons ce que nous appelons un Product Owner (PO) . Le PO connait le besoin des utilisateurs finaux et fait parti intégrante de l’équipe. Ce qui fait que tout ce qui est développé correspondra aux besoins. Les échanges et les démos sont plus fréquents et rythmés par des Sprints. Grâce à cette méthode, les besoins du client peuvent évoluer aux cours du projet sans trop d’impact.

D: En conclusion, pouvons nous dire que grâce à une méthode agile, le client apprend à identifier ses besoins au fil de l’eau ( exercice difficile en mode projet), cela permet à l’équipe technique de s’approprier plus finement le context client et, de fait, apporter une meilleure réponse. Le client constatant régulièrement le résultat peut réviser ses demandes. L’opportunité lui est donné de revisiter ses process d’une manière innovante.

E: Oui, c’est ce que je pense. Cela peut aussi laisser place à de nouvelle idée

D: Qui sont tes interlocuteurs chez nos clients ou autres?

É: À mon niveau, je communique essentiellement avec les Product Owner,  les développeurs, le service DSI chez le client et avec le Scrum Master.

D: Qu'aimes-tu faire le plus?

É: Apprendre de nouvelle chose des développeur(se) avec qui je travaille et m’améliorer. J’aime lorsqu’il y a beaucoup d’échange de connaissance sur un projet

D: Qu'aimes tu faire le moins?

É: Travailler seule ! :D

D: Quels sont tes outils ?

É: Je travaille toujours sous Linux avec l’éditeur de texte Sublime et la console toujours ouverte. J’utilise généralement PDB pour débugger lorsqu’il y a besoin. Nous utilisons également Git dans nos projets.

D: Cet interview se termine. En tant que Dev, quelle techno souhaites-tu mettre à l'honneur dans cet article?

É: J’ai découvert l'intégration continue que propose Gitlab lorsque je suis arrivée chez Anybox et je trouve celà puissant et super pratique ! J’ai également appris à développer en faisant beaucoup de tests unitaires. Incoutournable pour moi maintenant !

D: Qu’entends tu par super puissant et pratique; en quoi consiste l’intégration continue?

É: Celà permet d’avoir du code plus fiable et d’éviter les régressions car il est testé et déployé sur des environnements de tests automatiquement après les modifications.

D: Cela permet de mettre à disposition des utilisateurs de nouvelles fonctionnalités encore plus rapidement et surtout automatiquement une fois que le développeur les enregistre dans le répertoire du projet. ai-je bien compris ?

É: C’est ça, les déploiements sur différent environnement (Dév, tests, prod…) sont facilités

D: Pourquoi utiliser vous différents environnements?

É: Afin de pouvoir tester les modifications avant de les passer en production ( dans la vraie vie quoi) , et ainsi s’assurer du bon fonctionnement de celle-ci.

D: Cet interview est terminé, merci de t’être prêtée à l’exercice :-)

É: Merci à toi et à ceux qui liront jusqu’au bout !