Publié le
par
Dans cet article je vais vous parler de l’équipe développement : comment elle s’est formée, les rôles de chacun, notre organisation.
Ensuite, je vous parlerai du cadre Scrum que nous utilisons dans notre quotidien et je vous expliquerai les réunions qui y sont liées. J’emploierai des termes techniques dans cette partie, mais pas d’inquiétude ! Tous seront expliqués, de façon à ce que, développeur.euse ou non, vous vous en sentiez comme un.e à la fin !
Pour terminer cet article je mentionnerai les petits processus du quotidien que nous avons mis en place pour améliorer notre travail et ce qui fait qu’aujourd’hui nous sommes plus efficaces encore. (Même si ça ne permet pas d’être 100% parfaits tout le temps 😉)
Prêts ? C’est parti ! 👇
Une présentation de qui je suis avant de débuter cet article ? Je m’appelle Alicia et je suis actuellement en M2 ICE-LD (Ingénierie Continue pour les Écosystèmes Logiciels et Données). J’ai intégré l’équipe de développement moins de 4 mois après la création de MerciYanis, soit il y a plus de 2 ans. Notre travail, c’est de créer la plateforme MerciYanis, et de coder toutes les fonctionnalités que vous retrouvez dessus. Au départ, seule Élise, co-fondatrice de MerciYanis, s’occupait du “dev”. Je l’ai rejointe lors d’un stage de 2 mois durant ma seconde année de licence MIASHS (Mathématiques et Informatiques appliquées aux Sciences Humaines et Sociales) et ce stage s’est par la suite transformé en alternance que je continue actuellement. D’ailleurs, si vous souhaitez en savoir plus sur le déroulement de l’alternance, vous pouvez retrouver un petit article sur notre blog.
Lors de mon stage avec Élise, nous n’avions pas d'organisation très définie, nous ne suivions pas de méthode particulière pour travailler. Notre fonctionnement était généralement le suivant : Élise me donnait une liste de tâches à faire et je piochais dedans pour les développer. Étant encore nouvelle, je n’avais donc pas de vision claire sur notre Roadmap (feuille de route, vision des prochains développements de l’entreprise).
👉 De même, sur Git, le logiciel qui nous permet de garder chaque version de notre code, nous n’avions pas de règles particulières. La visibilité de l’avancement de notre projet s’en retrouvait donc impacté.
Cette façon de travailler était suffisante puisque nous n'étions que 2, mais n’était pas la meilleure.
C’est il y a un peu plus d’un an de cela, grâce à l’arrivée de Florian au sein de l’équipe, que nous avons mis en place Scrum, un cadre (ou framework) agile. Ayant lui-même été ”Scrum Master” (le garant de la bonne application de Scrum) dans sa précédente équipe, il nous a formées afin de nous l’expliquer et de l’intégrer par la suite dans notre quotidien. Le but étant d’améliorer notre manière de travailler, de nous organiser, de livrer plus fréquemment, etc.
Pour cela, première étape après la formation, définir les rôles Scrum. Au sein de notre équipe, nous allions intégrer plusieurs rôles :
Une fois les rôles attribués, avant de commencer à pouvoir réellement devenir une équipe Scrum, il nous a fallu trouver un nom.
Pour cela, il y a eu de nombreuses propositions : les licornes 🦄, les Lannister 🦁, les Chouffes 🍺, ... (oui, oui, plein d’idées en tout genre). Et finalement, après plusieurs échanges, nous nous sommes décidés pour les Quokkas !
Pourquoi ? Parce que c’est mignon et que ça garde toujours le sourire 😊
Pour ceux qui ne savent pas à quoi ça ressemble, voici une petite photo :
À ce jour chez les Quokkas, nous sommes actuellement 4,5 personnes. Le 4,5 c’est parce que Thilor fait surtout partie de l'équipe opérationnelle tout en étant dev.
Jusqu’à présent j’ai plusieurs fois mentionné le cadre Scrum, mais comment l’avons-nous appliqué ?
Afin d’appliquer correctement Scrum, plusieurs cérémonies (réunions) sont nécessaires. Ces cérémonies vont être réalisées lors de sprints.
Un sprint, c’est un cycle de développement durant lequel vont s’effectuer plusieurs cérémonies ainsi qu’une phase d’implémentation, le tout dans le but de se concentrer sur des fonctionnalités précises. Par exemple, un sprint peut être axé autour d’une fonctionnalité, comme la sortie d’une vue calendrier sur la plateforme MerciYanis par exemple.
Mais autour de quelles fonctionnalités axer le sprint ?
J’ai mentionné plus haut le fait que la PO découpait les projets en US. Plus exactement ce qu’il se passe, c’est que nous allons avoir un projet qui correspond à ce que l’on appelle une epic, c’est à dire une très grosse fonctionnalité à développer. Par exemple, si je reprends la fonctionnalité énoncée plus haut, mon epic pourrait être “Vue calendrier”.
C’est une fois l’epic créé que vont intervenir les User Stories, une granularité plus fine de ces epics.
Élise va décomposer l’epic en plusieurs User Stories. Il s’agit de fonctionnalités qui partent de l’expérience utilisateur (d’où leur nom).
Pour utiliser notre exemple, ça donne : “En tant qu’utilisateur, j’aimerais pouvoir créer une ronde depuis la vue calendrier”.
Les US sont donc rédigées sous forme d’exigence et permettent de voir la fonctionnalité en se mettant dans le rôle d’un utilisateur.
Ces mêmes US seront enfin découpées en tâches. Celles-ci, plus techniques, seront créées non plus par la PO seulement, mais par les développeurs. Cela nous permet de savoir ce qui est nécessaire pour développer.
Par exemple, une tâche pourrait être : “faire la maquette du pop-up de création de ronde”.
Afin de garder une vision sur tout ce qui nous reste à faire et dans quel ordre, nous avons également notre Roadmap qui va correspondre à l’organisation / priorisation des epics dans le temps ainsi qu’à leurs US et leurs tâches.
Chez nous, les sprints durent 2 semaines, parce que c’est une durée d’itération qui nous permet de tenir l’équipe au courant de notre avancée en ayant suffisamment de contenu à leur montrer. Ainsi, si jamais des modifications imprévues sont à faire, l’équipe est très réactive pour les mettre en place sur l’itération suivante.
Tout au long de ces deux semaines, nous allons donc réaliser des cérémonies Scrum. La première : le Sprint Planning.
C’est la réunion indispensable au bon commencement du sprint, c’est également elle qui sonne le début.
Au début du sprint planning, nous avons des US qui ont déjà été rédigées dans le détail par la PO. Le but va être de réfléchir au maximum à tous les problèmes qu’on pourrait avoir lors du développement de cette US, de chercher à toujours la remettre en question (pour être sûr que tout soit bien spécifié dessus) et de répondre à toutes les questions qui y sont liées.
Voici un exemple d’une de nos US qui concerne l’ajout d’un filtre sur la barre de recherche de la vue ronde sur la plateforme MerciYanis.
C’est également au cours de cette réunion que l’US sera découpée en tâches techniques par l’équipe de développement.
Chaque matin nous faisons ce que nous appelons un Daily Scrum. Il s’agit d’une réunion quotidienne qui ne dure pas plus de 15 minutes durant laquelle à tour de rôle chaque membre de l’équipe va énoncer le travail qu’il a fait la veille, ce qu’il va faire le jour même et éventuellement dire s’il nécessite de l’aide dans ses tâches.
Cette réunion nous permet de nous tenir au courant les uns les autres de l’avancement de chacun et donc plus globalement de l’avancement des fonctionnalités sur le sprint.
Comment savons-nous combien d’US choisir pour le sprint ?
Chaque US va avoir un nombre de points, appelé complexité, qui va lui être associé. Il s’agit d'un mix entre la difficulté qu’une story représente et le temps nécessaire à son développement.
Afin de décider de cette complexité, nous utilisons le planning poker.
Le but, c’est que chaque membre de l’équipe estime la complexité de la story face cachée grâce à des cartes avec des valeurs (pour nous, il s'agit de valeur de la suite de Fibonnacci). Ensuite, nous retournons les cartes en même temps, et, à moins que tout le monde n’ait mis la même valeur, nous allons demander à la personne ayant mis la plus haute valeur d’expliquer son choix, et de même pour celle qui a mis la plus petite. Cela permet d’éclaircir des zones d’ombre de l’US qui n’avait pas été détectées. Suite à cette discussion, une seconde estimation est faite où généralement tout le monde et d’accord, sinon on continue !
Ce planning poker est fait durant les cérémonies appelées Backlog Refinement, que nous avons au moins une fois par sprint. Le but, c’est que le backlog contiennent suffisamment d’US afin d’effectuer le sprint courant et les 2 prochains.
Habituellement, comme nous prenons environ 15 points par sprint (il s’agit de notre vélocité) lorsque nous sommes 3 (Stéphanie et moi sommes en alternance). Nous savons qu’à chaque sprint, il faut prendre suffisamment d’US pour atteindre les 15 points.
Cela permet également d’avoir une vision long terme de la capacité d’exécution de l’équipe Scrum et ainsi mieux planifier les deadlines de nos projets !
La sprint review, c’est là où on va montrer notre travail au reste de l’équipe. C’est la réunion où on va échanger avec eux, récolter leurs retours à chaud, et éventuellement modifier ce qu’on a fait en fonction de ce qui a été dit.
Le petit plus de cette réunion ? C’est qu’aujourd’hui, on fait les sprints review en anglais.
Cela permet 2 choses :
La rétrospective, c’est le symbole de la fin de notre sprint. C’est l’occasion pour l’équipe Scrum de faire un bilan dessus et dire ce qui allait, n’allait pas, ... Le but ce n’est pas d’accuser quelqu’un, mais de dire ce qu’ON doit améliorer. Cela nous permet par la suite d’être encore plus efficaces ! C’est également bien d’arriver à la rétro avec déjà des idées en tête qu’il nous semble important de discuter. Personnellement, j’ai toujours mon petit doc brouillon qui me permet d’écrire tout au long du sprint les trucs positifs et négatifs que je pourrais faire remonter 🤓
Bon, ça fait beaucoup d’informations et de vocabulaire ! Voici un petit schéma pour vous résumer tout ce que je viens de vous dire depuis le début et l’ordre de chaque cérémonie :
C’est très important pour nous d’avoir une équipe solide et qui monte en compétences. Et pour cela, on a instauré plusieurs points plus ou moins récurrents dans notre quotidien.
Dans le but de s’améliorer, on organise parfois des points formations. Le déroulement va être le suivant : une personne se renseigne sur un sujet, prépare une présentation et va venir former l’équipe sur ce sujet. Le but, c’est que tout le monde ressorte avec une plus grande connaissance sur le sujet qui a été abordé.
Comme dernièrement de nouveaux Quokkas nous ont rejoints, il peut être difficile pour eux de savoir dès le début comment développer certaines fonctionnalités (comment fonctionne le code, où chercher, que faut-il faire ?...). C’est une des raisons pour lesquelles il est important pour nous que les US soient explicites et les tâches complètes. Malgré cela, il peut rester des zones d’ombre.
Sur demande, Thilor et Stéphanie peuvent donc bénéficier d’un point de maximum 30 minutes avec le membre de l’équipe le plus compétent dans le sujet. Généralement, ces points servent à les débloquer dans leurs tâches ou à leur apporter des précisions sur le code.
Pour cela, on a chaque jour un rappel Slack afin qu’ils puissent demander de l’aide. Procéder ainsi (via le rappel de Slack) permet de les pousser à demander de l’aide, ce qu’ils ne feraient pas forcément de peur de nous déranger dans nos tâches.
Personnellement lorsque j’étais moi-même en stage chez MerciYanis (à mes tous débuts), j’avais souvent beaucoup de questions à poser à Elise. À cette époque, elle avait déjà commencé à mettre en place ces points, qui me permettaient ainsi de lui demander tout ce que je ne comprenais pas. Le fait de faire ça sous forme de point permet à la fois pour la personne en difficulté de savoir rester autonome, et pour les 2 personnes d’optimiser leur temps.
Ayant gagné en expérience, là où j’avais moi-même tendance à être auparavant la personne qui demandait de l’aide lors de ces points, je suis devenue aujourd’hui celle qui peut l’apporter ! 😁
Je vous ai expliqué mon quotidien de manière générale ; et si je vous emmenais dans les coulisses ? 📽
Premièrement, je relis mes notes sur Slack. Slack, c’est un petit peu mon fourre-tout, chaque jour, j’écris mes notes dessus, ce que je dois faire, que je ne dois pas oublier, ... Et comme j’ai beaucoup de notes, je dois être devenue la personne qui me parle le plus de l’équipe 😂
Deuxièmement, je vérifie tout le temps mon agenda pour m’organiser du mieux possible et voir s'il est nécessaire de préparer un point, réfléchir à un sujet en amont, ...
Ensuite, je vais sur Jira. C'est l’outil qu’on utilise et sur lequel se trouvent toutes les epics, US, tâches, ... que nous allons devoir implémenter. Étant toutes priorisées, nous prenons généralement les premières du sprint courant, cependant comme nous ne sommes pas tous full-stack (très compétent à la fois sur la partie front-end et back-end), mais plutôt complémentaires, nous allons avoir tendance à prendre les US sur lesquels nous avons le plus de compétences (personnellement, il s’agit du front).
Vient ensuite le développement.
Parmi les développements que nous faisons, tous ne sont pas prévus. Depuis le début, je vous ai parlé d’épics et de leurs US. Cependant, à ce jour les US ne sont pas les seuls types de tâches que nous devons développer et elles ne proviennent pas forcément de demandes de clients.
En effet, il y a aussi les bugs, et il arrive parfois que nous ayons des demandes venant du reste de l’équipe. Il s’agit majoritairement de demande d’ajout de capteurs sur la plateforme, de suppression de données d’un espace de travail, ... N'importe quel type de tâche qui ne leur est pas possible d’effectuer.
Pour cela nous avons donc aujourd’hui une chaîne sur Slack qui permet à l’équipe de faire directement leur demande en indiquant le sujet, l’importance et éventuellement la date de résolution attendue. Suite à une demande par exemple, j’ai décidé de rédiger 2 documentations pour des demandes semblables dans le futur :
Avoir ce genre de documentation permet à l’équipe à la fois de s’entraider sur certaines tâches et à la fois de rendre les membres autonomes durant leur résolution. Même si parfois rédiger les documentations peut prendre du temps, à la fin, procéder ainsi nous permet de gagner du temps sur de nombreuses demandes qui ont été automatisées/qui possèdent une documentation. Et c’est grâce à ce genre de “petites” améliorations dans notre quotidien qu’on devient encore plus efficace et qu’on arrive à délivrer à nos clients au mieux par la suite ! 🚀
Auparavant, lorsque nous n’étions pas encore les Quokkas, nous ne connaissions que de nom le cadre Scrum et ne le pratiquions pas. Aujourd’hui il nous serait difficile d’imaginer notre quotidien sans !
Utiliser Scrum est réellement bénéfique dans notre quotidien, car il nous permet :
Certes, lors de certains sprints, il est parfois difficile pour nous de réussir à réaliser toutes les US, mais même lorsque cela arrive, nous mettons tout en œuvre pour développer le maximum d’US et fournir les fonctionnalités dans les temps.
C’est ça la team Quokkas, s’entraider et se motiver pour réussir à donner le meilleur de nous-mêmes. Et avec le sourire ! 😉
Merci d’avoir lu cet article jusqu’au bout ! 💙
Alicia, de la team Quokkas
Ce qu'il faut retenir :
✅ MerciYanis suit un cadre Scrum sous 2 semaines
✅ Ça a permis à l'équipe dev de se structurer, d'avancer plus vite et de délivrer plus de fonctionnalités
✅ Toutes les petites idées pour se débarrasser ou régler les soucis du quotidiens le plus vite possible sont bienvenues !
par
Découvrez les changements induits par la génération Z et la manière dont l’intelligence artificielle peut répondre à ces nouvelles attentes, tout en mettant en avant des aménagements inspirants.
Découvrir
par
Apprenez à intégrer la RSE dans le secteur de la propreté en couvrant les 4 piliers essentiels : qualité de vie, management responsable, performance économique, et respect de l'environnement, grâce à des solutions comme MerciYanis.
Découvrir
par
Découvrez comment Thilor a fait de sa passion pour l’IoT et la data une mission chez MerciYanis. Il partage son quotidien, entre technologie et valeurs humaines au service du collectif.
Découvrir
