[SCRUM WEEK] Dans la peau d'un Développeur Scrum

[SCRUM WEEK] Dans la peau d'un Développeur Scrum

Publié le : 24/08/2017 24 août Août 2017
RG System lance sa Scrum Week et met à l'honneur notre Team Scrum pendant 1 semaine ! Nous vous proposons de découvrir chaque jour un de nos acteurs Scrum au sein de RG System, et on poursuit ce jeudi avec Rémi, membre de l'équipe de développement RG System !
 

Bonjour Rémi ! Qui es-tu ?

Je suis Rémi PASCAUD, je suis développeur chez RG System depuis un peu plus d’un an. J’ai travaillé dans 3 entreprises auparavant où j’ai toujours fait du Scrum Agile, mais chaque entreprise adoptait la méthode selon son mode de fonctionnement.
 

Au regard de ton expérience passée, comment qualifies-tu l'Agilité Scrum chez RG System ?

L’Agilité c’est le fait pour moi de savoir répondre rapidement aux demandes, de savoir délivrer très régulièrement des nouvelles versions, d’être en lien direct avec ce que veulent les utilisateurs. Scrum, c’est plus un ensemble de pratiques, une méthode un peu toute faite avec des outils spécifiques. Chez RG System on suit bien la méthode Scrum classique, et on est très agile : on revoit les plans de développement tous les mois et on fait peu de développement long-terme. Ça a été facile de m’intégrer à l’équipe parce qu’on participe tous à la partie conception, et ça permet de s’impliquer davantage, de voir toutes les stories disponibles et de pouvoir se répartir les tâches de manière collective. Ainsi on a tous une vision d’ensemble précise.
 

Peux-tu présenter le processus Scrum global chez RG System ?

Au tout début, il y a une étape de préconception pendant laquelle le Product Owner regarde les stories de manière globale, essaie d’avoir une idée de leur coût (en termes de temps et de ressources humaines) et d’identifier le découpage fonctionnel.
Puis il nous présente en conception les stories qu’il a présélectionnées pour qu’on les regarde plus en détails et qu’on ait une idée précise de comment on va les aborder, comment on les découpe techniquement. L’important est de définir le cap à prendre pour que chacun travaille ses tâches correctement et qu’on ne parte pas dans tous les sens. À la fin de la conception on s’engage, on décide pour chaque développeur quelles stories il va prendre sur ce sprint, et à ce moment-là on va démarrer la phase de réalisation. Chacun commence à travailler sur ses stories, le but étant qu’à la fin du sprint de deux semaines toutes les stories soient validées. On va alors entamer la phase de code, puis de tests et une fois qu’on considère qu’elle est suffisamment mature, on prévient l’équipe que la story est terminée et qu’elle doit être revue. C’est là qu’on entame une phase qui n’est pas forcément très rapide parce qu’on va recevoir des commentaires techniques sur des détails du code réalisé et il va falloir revoir ces commentaires pour remettre à jour le code et reprendre le cycle de réalisation/validation. Actuellement ce sont notre Directeur Technique et le Scrum Master qui s’occupent de valider la partie technique du code. Pour qu’une story soit validée elle doit être revue. Si elle est revue trop tard, elle ne sera pas validée. Une fois que le code est revu, c’est le Product Owner qui valide la partie fonctionnelle, c’est-à-dire le rendu sur le Dashboard RG, et il vérifie également que tout est en accord avec la spécification initiale. Entre le moment où on a fini la première version du développement et la validation d’une story, il peut se passer un peu de temps. Finalement au niveau du développement chez RG System, la première semaine du sprint est dédiée au code et la seconde à la validation. Il arrive que des stories meurent en cours de route, soit parce qu’on s’est rendu compte que le coût estimé est bien plus important, soit parce que la priorité a changé. On assume les stories non validées si on n’a pas terminé les tests complets et on préfère les reporter au sprint prochain. Que ça prenne 3 heures ou 3 jours, on préfère passer une story en rouge plutôt que de forcer sa validation, tout simplement parce que nous souhaitons privilégier la qualité à la quantité.
 

Quels sont les outils que tu utilises en Agilité Scrum au sein de RG System ?

Le Scrum Board bien sûr, très utile pour assurer le suivi et ne pas oublier de story. Chacun a sa to do list personnelle mais il permet à tous, y compris à toute l’entreprise, d’avoir une vision globale de ce qui est fait et de ce qu’il reste à faire. Le principe c’est d’avoir une vue synthétique et que tout le monde la comprenne. Ensuite il y a les Daily Scrum, le point que nous faisons tous les matins devant le Scrum Board pour aborder ce qui a été fait la veille et ce que l’on s’apprête à faire. Ça peut prendre du temps à cause des bavards, mais au moins ça permet d’avoir une vue globale de l’avancement du sprint. Il y a ensuite la revue de sprint. C’est particulier chez RG System car toute la société y est conviée. Du coup on a essayé de la rendre le plus appréciable pour tous en démocratisant les fonctionnalités qui peuvent l’être. De cette manière, toute la société est au courant de ce qui a été développé, du commerce au marketing en passant par le support, chacun est concerné par les évolutions du produit. Et enfin, le sprint s’achève sur la rétrospective. Chez RG System c’est vraiment utile car structuré par rapport à mes expériences passées. On passe le temps qu’il faut à faire le point sur ce qui a fonctionné et ce qui n’a pas marché, et occasionnellement, on prend la décision de mettre en place sur le prochain sprint une action d’amélioration pour faire évoluer le process. Des fois cela aide et fonctionne, d’autres fois ce n’est pas le cas, mais cela a au moins le mérite de remettre en cause régulièrement la méthode et de nous aider à progresser.
 

Est-ce important qu’un collaborateur développeur porte également la casquette Scrum Master ?

Ce n’est pas du tout gênant, je pense juste qu’il développe peut-être moins puisqu’il doit partager son temps. Ce qui lui prend du temps je pense, c’est la préparation de la revue. Il doit maîtriser tout ce qui se passe sur toutes les stories, et du coup il produit peut-être un peu moins de code que s’il se concentrait seulement sur ses stories. C’est bien de répartir les responsabilités sur ce poste, et que le Product Owner ne soit pas Scrum Master. Le rôle du Scrum Master n’est pas de contrôler notre travail mais de s’assurer qu’on va atteindre la fin du sprint. Nos interactions avec lui sont très informelles et il est toujours là pour nous aider. C’est lui par exemple qui s’assure que les Daily Scrum ne soient pas trop longs, il sait faire ce qu’il faut pour que l’équipe tourne. Finalement je pense que le rôle du Scrum Master permet essentiellement de veiller à ce que le sprint se passe bien ; qu’on ne s’engage pas trop, qu’on suive bien les tâches et qu’on ne perde pas trop de temps sur le Daily Scrum.
 

Comment vois-tu ton rôle de développeur au sein de RG System ?

J’aime surtout l’idée d’être en lien avec le support technique qui a régulièrement des besoins de développement afin d’apporter des réponses aux utilisateurs. Au support il y a deux types de questions entrantes : soit il s’agit d’une question sur le fonctionnement de l’outil, soit il s’agit d’un problème. Dans le second cas, s’il s’agit d’une nouvelle fonctionnalité, c’est Arnaud qui prend la main, mais s’il s’agit d’un bug à fixer, c’est moi qui vais m’en charger. J’aime bien être proche du terrain et de ce que les gens pensent du produit. Du coup je suis le lien identifié du support au développement pour la correction des bugs rencontrés.


Cet article vous a plu ? Découvrez les autres posts dédiés aux autres rôles Scrum au sein de RG System !

Historique

<< < 1 2 3 4 5 6 7 ... > >>
Information sur les cookies
Ce site utilise des "cookies" pour effectuer de la mesure d’audience, ne nécessitant pas de consentement préalable, en application des textes régissant la protection des données personnelles.
Vos données personnelles ne sont pas collectées et ces cookies ne représentent aucun danger pour votre équipement.
En poursuivant votre navigation sur ce site, vous acceptez l'utilisation des cookies. Plus d'informations Moins d'informations
Les cookies sont des fichiers textes utilisés à des fins statistiques ou pour le fonctionnement de certains modules d'identification par exemple.
Ces fichiers ne sont pas dangereux pour votre périphérique et ne sont pas utilisés pour collecter des données personnelles.
Le présent site n’utilise que des cookies d'identification, d'authentification, d’analyse de mesure d'audience ou de load-balancing ne nécessitant pas de consentement préalable, en application des textes régissant la protection des données personnelles.
Vous pouvez cependant vous opposer à la mise en place de ces cookies en désactivant cette option dans les paramètres de votre navigateur.
Nous vous invitons à consulter les instructions de votre navigateur à cet effet et vous informons qu'en cas de blocage de ces cookies certaines fonctionnalités du site peuvent devenir indisponibles.
J'ai compris