Quentin nous parle de son quotidien d’analyste-programmeur avant que tout monde n’arrive …

Article publié le 17 octobre 2015

Aujourd’hui,  j’ai rendez-vous avec Quentin, analyste-programmeur de notre équipe SCRUM.

Sa mission d’aujourd’hui : convaincre des étudiants en informatique de rejoindre l’équipe pour un stage ! Nos développeurs aiment ce qu’ils font, ce sont tous des passionnés. L’envie de partager et de transmettre leurs compétences fait aussi partie de leur quotidien. Cette fois donc, c’est Quentin qui s’y colle… pour mon plus grand plaisir !

Et même si leurs activités ont une fâcheuse tendance à me donner quelques maux de tête, c’est toujours avec beaucoup d’intérêt que je les écoute s’étendre sur leur méthode de travail : SCRUM !

Quentin m’offre un café (que les stagiaires en prennent de la graine) et c’est parti pour 20 minutes chrono…

Quel est ton poste et ta mission au sein de QualNet ?

Je suis concepteur-développeur ou  analyste-programmeur si tu préfères, c’est au choix. J’analyse et je développe les fonctionnalités à implémenter dans les solutions Intraqual DOC et Intraqual DYNAMIC. Je corrige également les anomalies, participe aux tests et nous avons tous une mission bien particulière en R&D.

Aujourd’hui, nos missions ne se limitent pas uniquement au développement et pour ma part, mon projet R&D consiste à étudier la mise en place d’une technologie de communication en temps réel des objets de l’application. Pour faire plus simple, cela fonctionne comme un tchat, sauf qu’ici, ce sont les objets de l’application qui échangent.

Quelle est ta journée type ?

Tout est très influencé par la méthodologie SCRUM. Dès notre arrivée le matin, toute l’équipe fait très rapidement un point que nous appelons le SUM (stand up meeting). Il s’articule autour de trois points : ce que nous avons fait hier, les problèmes que nous avons rencontrés et ce que nous allons faire aujourd’hui. L’objectif n’est absolument pas de nous « fliquer » mais d’entrer dans une démarche d’amélioration continue exigée par SCRUM.

Au cours de la journée et en fonction du rôle qui m’est attribué par le sprint (test, dysfonctionnements,…), je travaille soit sur l’implémentation de nouvelles fonctionnalités, soit je corrige des anomalies, soit je participe aux tests et au contrôle de la qualité du code.

Le dernier point dans une journée type consiste à estimer des points de backlogs* (ça y est, ça commence, ndlr). Le but est d’évaluer grâce à une « user story** » (ah… ça continue…NDLR ) une fonctionnalité à développer. Cela peut nous prendre jusqu’à ½ heure par jour. C’est un moment qui génère beaucoup d’échanges dans l’équipe, notamment autour de points techniques ou fonctionnels qui peuvent s’avérer bloquants et avoir un réel impact sur l’application. Pour faire simple : on prend un Rubik’s Cube, on le retourne dans tous les sens et on s’aperçoit que chaque mouvement impacte un côté…  le fait d’échanger au sein du groupe entraîne beaucoup d’idées et de points de vue. C’est précisément cela qui améliore considérablement l’approche et l’analyse technique. A partir de tous ces éléments, il nous est possible d’estimer un point.

Un sprint égal 15 jours. Comment vis-tu ces 15 jours ?

Comme une histoire… On nous donne une situation de départ où nous avons tous un rôle bien défini et une charge de travail. Et comme dans un roman, nous allons devoir faire face à des incidents, des péripéties qui alimentent cette histoire. Pendant ces 15 jours, nous sommes amenés à solliciter des personnes différentes ! Parfois nous sommes d’accord et parfois non… D’un sprint à l’autre c’est très différent !

C’est légitime d’appréhender au début… mais finalement c’est très excitant et loin d’être monotone !

Selon toi, la méthode SCRUM a-t-elle une réelle influence sur ton métier ?

La méthode SCRUM vient en opposition directe avec les méthodes traditionnelles ! Mon mémoire de fin d’étude portait sur les méthodes agiles. Aujourd’hui j’ai la chance de pouvoir les mettre en pratique au quotidien et voir comment ça se passe dans la vraie vie !

SCRUM permet d’être beaucoup plus réactif. L’approche technique reste la même. Le découpage de ma charge de travail est cependant bien différent… elle me permet surtout d’en voir le bout ! Et c’est très plaisant !

Si je construis une pyramide, je pose une brique, puis une autre, puis une autre … plutôt que de me dire j’ai 100 briques à poser (c’est beaucoup plus rassurant), j’aurai à la fin une belle pyramide mais j’avance petit à petit… cela nous permet au fur et à mesure, d’ajouter des idées.

D’un point de vue humain, c’est également très enrichissant ! Il ne faut pas être rancunier et savoir écouter la critique, c’est une évidence… mais chez QualNet, ça fonctionne vraiment très bien !

Quels sont selon toi les avantages ?

La remise en question permanente est pour moi une notion qui permet de monter en compétences ! Si ce n’est pas le cas, ça devient compliqué… on apprend à faire des erreurs… Personnellement c’est très enrichissant.

Et les inconvénients ?

Tu commences quelque chose qui a été découpé sur plusieurs sprints et que tu ne vas pas forcément continuer… soit un autre développeur prend le relais, soit une autre fonctionnalité devient prioritaire… Il faut apprendre à se détacher de ce que l’on produit … ce n’est pas toujours évident…

Envisages-tu de revenir à une méthode de travail plus traditionnelle ?

Non … et inutile d’argumenter !

3 mots pour décrire ton quotidien chez QualNet ?

Relations humaines | amélioration | convivialité

Question bonus … Travailler en pleine forêt pour toi, c’est un problème ?

Ah Non pas du tout !!!! Bien au contraire !!!! Ce cadre est génial …

 

Octobre 2015