#6 Journal d’un développeur chez Esker : Review et Rétrospective
Cher journal,
Cela fait plus de deux ans que j’ai décroché mon premier emploi chez Esker. Je suis développeur dans une des dix équipes de la R&D en charge du développement des solutions à destination de nos clients. Nous sommes entre quatre et six développeuses/développeurs par équipe, et travaillons tous en méthode Agile sur une base de code commune afin de développer de nouvelles fonctionnalités pour nos produits. Mais notre travail ne se limite pas qu’à ça ! Je tenterai donc de t’en présenter toutes les facettes en plusieurs articles. Tu peux retrouver les sujets précédents sur la page d’Esker Labs.
REVIEW
Chez Esker, lorsqu’un sprint se termine, un nouveau commence dans la foulée. Avant cela, il est tout de même important de communiquer au reste de l’entreprise les nouvelles fonctionnalités que nous avons développées lors de ces deux semaines, de l’ajout d’un champ d’un formulaire à l’intégration d’un nouveau module au sein de notre éventail de solutions. C’est ce que nous avons fait aujourd’hui lors de la review.
La review est donc une réunion organisée par chaque équipe dont le but est de présenter les développements réalisés aux différentes parties prenantes du produit, ainsi que la meilleure manière de tirer parti de ces nouvelles fonctionnalités. Chez Esker, les participants à cette review restent internes à l’entreprise. Y assistent notamment des Consultantes/Consultants (ou PS pour Professional Services), des membres des équipes Support et de l’équipe Documentation, l’ensemble de l’équipe de Développement… et toute autre personne de l’entreprise qui le souhaite. Les reviews se déroulent en présentiel, mais sont aussi accessibles à distance à tout employé de l’entreprise.
Chaque membre de l’équipe a son rôle à jouer lors de la réunion. Celui-ci peut varier selon les équipes :
- Le Product Owner peut être chargé de présenter succinctement les stories qui ont été réalisées pendant le sprint avant de laisser la parole aux développeuses/développeurs qui rentreront plus dans le détail. Il présente aussi les stories qui seront développées par l’équipe lors du prochain sprint.
- Les Développeuses/Développeurs présentent les fonctionnalités mises en place lors de ce sprint, en utilisant le support qu’ils souhaitent : démonstration directe sur une version de test du produit, Powerpoint… Cette review est aussi l’occasion pour eux de recueillir du feedback sur ce qu’ils viennent de développer, et potentiellement de prévoir des corrections ou améliorations dans les prochains sprints.
- Le Scrum Master facilite la mise en place des différents outils permettant le bon déroulement de la réunion : ordinateur utilisé pour faire la présentation en présentiel, caméras retransmettant la salle pour les personnes à distance, logiciel d’enregistrement permettant de mettre la vidéo de la review en ligne pour qu’elle soit accessible par les collaborateurs n’étant pas disponibles au moment de la réunion…
RETROSPECTIVE
Après avoir communiqué à l’extérieur de l’équipe, il est aussi nécessaire de communiquer à l’intérieur sur les événements et blocages qui ont eu lieu pendant le sprint. C’est ce qui est fait pendant la rétrospective. Animée en général par le Scrum Master, ce rendez-vous est l’occasion pour chaque membre de l’équipe d’aborder les points positifs qu’il a relevés, les problèmes qu’il a rencontrés durant ces deux semaines… et tout ça dans un cadre bienveillant. L’objectif final ? S’améliorer à chaque sprint et atteindre une performance optimale de l’équipe dans tous les domaines : développement de nouvelles fonctionnalités, innovation, amélioration des outils existants ou création de nouveaux outils, meilleures conditions de travail… Par exemple, nous avons pu y aborder notamment les difficultés rencontrées lors du développement d’un nouveau module, mais aussi l’horaire des stand-ups de notre équipe, la mise en place de code reviews pour chacun de nos développements… Dernièrement, elle nous a permis de réfléchir aux besoins que nous avions et aux différents outils que nous souhaitions mettre en place afin de pouvoir télétravailler un ou plusieurs jours par semaine de la meilleure façon possible. La rétrospective donne lieu en général à un certain nombre d’expérimentations, sur lesquelles nous revenons lors des rétrospectives suivantes afin de déterminer si celles-ci ont fonctionné ou pas. L’ idée est qu’à terme, l’équipe soit suffisamment indépendante vis à vis du Scrum Master, qui pourra alors changer de posture et adopter un point de vue plus global à l’entreprise.
Chez Esker, en plus de la rétrospective de chaque équipe, nous avons ajouté une rétrospective inter-équipes de la R&D. Chaque équipe y est représentée par au moins une personne. De la même façon qu’une rétrospective d’équipe, on y aborde les problèmes inter-équipes qui ont eu lieu lors du sprint, et on essaye de trouver des axes d’amélioration pour les prochains sprints.
ET ENSUITE ?
La story a finalement été développée et présentée au reste de l’entreprise. Mais comment la fonctionnalité arrive t-elle jusqu’à l’écran de l’utilisateur ?
Généralement, notre équipe d’installeurs déploie toutes les nouveautés d’un sprint dans les deux semaines qui suivent sa validation. Dans ce même temps, l’équipe de documentation ajoute ou modifie les spécifications de notre produit de façon à ce qu’elles soient prêtes au moment du déploiement des nouvelles fonctionnalités. Certaines d’entre elles sont accessibles dès le déploiement pour les utilisateurs, d’autres nécessitent une action de la part d’un consultant sur le compte des clients intéressés.
Les nouveaux développements sont en général assez nombreux; il peut être difficile pour les commerciaux présentant nos solutions de s’y retrouver. C’est pour cela que deux fois par an, des sessions appelées releases sont organisées pour présenter dans les grandes lignes les nouveautés mises en place ces derniers mois. De cette façon, les salariés en contact avec les clients sont mis au courant des avancées de la R&D et peuvent les informer au besoin.
Voilà, tu sais maintenant de quoi est fait mon quotidien en tant que développeur R&D chez Esker. Comme tu as pu le voir, nous sommes organisés sur des cycles de deux semaines, et chaque étape que je t’ai décrite se répète au sprint suivant. Cela étant, chaque sprint comporte son lot de nouveautés, d’améliorations, de problématiques, de changements, de sorte que l’on ne s’ennuie jamais !
Retrouve les autres parties du journal d’un développeur chez Esker :
