#1 Journal d’un développeur chez Esker : le planning
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 à ça ! Je tenterai donc de t’en présenter toutes les facettes en plusieurs articles.
Aujourd’hui, nous commençons un nouveau sprint. Et qui dit nouveau sprint, dit planning ! Tu ne sais peut-être pas de quoi je parle, mais ne t’inquiète pas, je vais t’expliquer.
Dans une équipe de R&D chez Esker, nos développements sont organisés sous forme de sprints de deux semaines pendant lesquels nous, développeuses et développeurs, pourrons programmer un certain nombre de fonctionnalités, appelées aussi stories. Un sprint commence toujours par un planning, durant lequel le Product Owner va nous présenter les stories à réaliser et nous expliquer leur contexte fonctionnel.
Ce matin, nous nous sommes donc réunis comme d’habitude devant les tableaux de notre bureau sur lesquels sont affichées les stories les plus prioritaires. Pour ce sprint, nous aurons des fonctionnalités à ajouter dans plusieurs domaines : Machine Learning, RPA (Robotic Process Automation), intégration avec des ERP, mais aussi maintenance et bug fix… Un vaste programme en perspective, qui varie beaucoup en fonction des sprints. Personnellement, je trouve très motivant de travailler sur des sujets différents et variés. Ca me permet d’apprendre énormément, ce qui pour moi est une des caractéristiques les plus importantes dans mon métier !
Suite à la présentation des stories, nous discutons au sein de l’équipe afin de déterminer les solutions pour les réaliser. C’est le moment pour chacun de nous d’exprimer ses doutes, de proposer ses idées et de poser des questions au Product Owner pour comprendre et clarifier les besoins fonctionnels. Les premières fois, j’hésitais toujours un peu avant de donner mon opinion et faire mes suggestions, mais je me suis vite rendu compte que je n’avais pas de soucis à me faire et que je serai écouté, quelle que soit mon expérience dans l’entreprise. C’est après tout un des objectifs du planning, n’est-ce pas ? Cette réunion nous est essentielle car elle nous permet de collaborer entre développeuses/développeurs pour trouver les solutions techniques qui répondront le mieux aux besoins fonctionnels du client.
Chaque équipe organise son planning comme elle l’entend, en fonction de ses besoins et dans un objectif d’amélioration continue. Dans mon équipe, nous ne faisons pas d’estimation du temps que va nous prendre une story, mais définissons en général un objectif de sprint qui sera peut-être amené à changer en fonction des problèmes rencontrés. C’est donc bien l’équipe de développement qui décide de ce qu’elle pourra et ne pourra pas faire lors du sprint. Elle est d’ailleurs aussi en charge d’y incorporer si nécessaire des actions d’amélioration continue : mise en place d’un nouvel outil, rédaction d’un tutoriel utile aux autres équipes, maintenance de machines virtuelles…
A la fin du planning, nous avons donc rempli notre dashboard de tâches à réaliser pour chacune des stories. Le sprint peut enfin commencer !
Tu as hâte de savoir la suite ? C’est par ici :
