#2 Journal d’un développeur chez Esker : Stand-up et développement
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.
Ce matin, nous avons comme tous les jours commencé la journée par un stand-up. Je t’explique : pendant quinze minutes, l’équipe se réunit pour parler des avancées de la veille, organiser la journée à venir et lever les blocages potentiels que certains rencontrent. Justement, un de mes collègues a rencontré un problème lorsqu’il a commencé à développer une des stories que nous avions planifiées il y a quelques jours. Nous avons donc essayé de trouver ensemble des pistes pour le débloquer. Ce rendez-vous journalier est indispensable : il me permet non seulement de connaître les avancées et les problèmes des autres membres de mon équipe, mais aussi d’organiser ma journée selon mes priorités et celles de l’équipe. Un stand-up et un café, c’est tout ce qu’il me faut pour commencer ma journée !
Il arrive parfois que les stand-up durent plus longtemps que prévu : les discussions s’écartent des sujets véritablement intéressants et perdent leur intérêt, certains esprits s’égarent… Dans ces cas-là, le Scrum Master recadre la discussion et remobilise l’équipe. Son rôle est important car il nous permet de préserver l’efficacité de la réunion. Grâce à lui, elle ne dure pas plus de quinze minutes et reste utile à tous les membres de l’équipe !
Après ce meeting, je peux commencer à développer. De manière générale, dans notre équipe, nous codons en Javascript/Typescript car je fais partie d’une équipe dite « fonctionnelle », mais il nous arrive souvent de toucher aux couches plus basses de notre produit, qui sont écrites en C# et en C++. Nous sommes aussi amenés à utiliser d’autres langages et d’autres outils de manière plus ponctuelle pour des projets associés à notre produit principal : Ionic/Angular pour notre application mobile, Python, PL/SQL pour notre intégration avec certains ERP… Ne pas connaître ces langages à la base n’est pas un problème en soi, car il y a énormément de connaissances réparties entre les différentes équipes de la R&D, et il est facile de trouver un autre développeur expert disponible pour aider.
J’ai dû dans la journée faire appel à un de mes collègues pour avancer sur une tâche que je n’arrivais pas à terminer. Nous avons donc travaillé comme souvent en pairing afin de résoudre le problème. Cette méthode de travail est très utilisée dans notre équipe, et toujours utile puisqu’elle permet de partager ses connaissances et de débloquer des situations sur lesquelles une personne seule pourrait parfois rester bloquée plus longtemps. En ce qui me concerne, j’aime beaucoup le côté collaboratif du pairing : 1+1 est souvent égal à 3 ! Nous avons bien avancé, et je suis sûr que je pourrai lever les quelques blocages restants en en parlant demain au stand-up.
Finalement, l’équipe est libre de s’organiser comme elle le souhaite : son mode de fonctionnement se définit souvent de lui même, de manière logique, au fil du temps passé à travailler ensemble. Certaines équipes vont mieux fonctionner en travaillant à plusieurs, quand d’autres préféreront fonctionner autrement, par exemple en se répartissant d’abord les tâches et en mettant en commun leur travail plus tard. Pour moi, c’est à ça que se résume l’agilité : travailler tous ensemble, s’organiser et s’améliorer au fur et à mesure pour finalement arriver à un but commun. Ce n’est pas plus compliqué que ça !
Tu as hâte de savoir la suite ? C’est par ici :
Retrouve les autres parties du journal d’un développeur chez Esker :
