Jérôme Guyot (directeur Produits Articque) : « La méthode agile Scrum bonifie le développement de nos solutions »

1.  Pourquoi avoir choisi la méthode agile Scrum chez Articque ?

Jérôme Guyot : « Pendant très longtemps, chez Articque, nous avons travaillé de manière linéaire avec une méthodologie de type Waterfall, qui repose sur des cycles d’environ 4 mois : 1 mois pour le design et les spécifications techniques, 2 mois pour le développement et 1 mois pour réaliser les tests et l’implémentation du logiciel. Cette méthode présente notamment l’avantage de décrire précisément ce que l’on obtiendra au final ou de fixer une date de sortie plusieurs mois à l’avance. Mais, dans notre cas, elle avait des conséquences néfastes au niveau :

– du facteur temps : le délai minimum de 4 mois entre 2 versions du logiciel engendre de l’impatience chez les clients qui attendent un correctif ou un développement.

– de l’organisation du travail : un problème exceptionnel ou une urgence (maladie, bug bloquant…) pouvait gripper la machine et bouleverser le planning de développement, voire l’allonger. Ce qui est très problématique lorsqu’on a de gros blocs de développement à réaliser. Certains bugs remettant en cause la structure même du logiciel n’étaient détectés qu’à la fin du développement (ce qui pouvait entraîner des soucis de performance ou de volumétrie).

– du tunnel de développement : parfois, au bout de plusieurs semaines, la demande initiale du client était moins pressante ou alors il avait une demande plus urgente. Nous nous apercevions tardivement que le développement pensé à l’origine n’était plus adapté à la demande ou aux avancées technologiques (comme l’évolution des algorithmes par exemple).  »

3. Quels sont les principes fondamentaux de la méthode agile Scrum ?

Jérôme Guyot : « Scrum est une méthode agile qui propose de progresser par itération et qui donne surtout un cadre de travail. Elle repose sur des cycles de développement courts de 2 semaines qui sont appelés sprints. Pendant ces 2 semaines, les différentes phases de développement (recueil de besoins, design, développement et tests) sont intégrées, de manière à détecter plus tôt les problèmes.

Durant un sprint, l’échange avec le client se fait en continu : il est favorisé par la présence d’un Scrum Master dans l’équipe (qui est le garant du bon déroulement et de l’atteinte des objectifs d’un cycle de développement) et d’un Product Owner (qui est le représentant des utilisateurs). Nous proposons une solution au client qui soit la plus intelligente, la plus ergonomique et la plus rapide possible. Nous tenons compte de l’objectif que ce client veut atteindre. Cet objectif est décliné sous forme de User Stories : chaque besoin est découpé en petits récits utilisateurs (en fonction du rôle, du besoin et de l’objectif). Pour chaque Story, un chiffrage du développement est réalisé par l’équipe, qui prend en considération les conditions d’acceptation et la faisabilité technique.

Le Product Owner est plus spécialement chargé de récupérer l’expression des besoins des utilisateurs (en interne ou en externe). Il décrypte ensuite les demandes d’évolution pour les transformer en expression de besoins. Nos clients ont la possibilité de nous transmettre leurs retours d’expérience via :

– un formulaire, présent dans le logiciel Cartes & Données, qui nous confère un score NPS. Grâce aux commentaires laissés par les utilisateurs, nous identifions facilement ce qui plaît ou non.

– un formulaire de suggestions pour les utilisateurs de Cartes & Données Online. »

4. Quelles sont les apports décisifs de la méthode Scrum appliquée à Articque ?

Jérôme Guyot : « Tout d’abord, l’estimation et le découpage des tâches revêtent une grande importance. L’équipe discute de chaque User Story afin de l’estimer de manière consensuelle. Une bonne story est INVEST : Indépendante, Négociable, Valuable (qui produit de la valeur), Estimable (en termes de temps et de difficultés) et Testable. Cette Story est retranscrite sous forme d’épopée au sein de notre logiciel de gestion de projets Jira. Elle est découpée en petits blocs fonctionnels d’une durée maximale de 2 jours : nous avons ainsi une idée précise du déroulement du développement à très court terme.

Autre point important qui occupe une place déterminante : la phase de test. Avec la méthode Waterfall, les développeurs testaient leur travail à la fin du processus. Maintenant, conformément à nos objectifs et à la méthode agile Scrum, nous testons rapidement et de manière continue. Nous avons mis en place des tests automatisés (développés par Kévin Marie) : à chaque fois que les développeurs ont codé une nouvelle partie fonctionnelle, celle-ci est testée immédiatement sur un serveur où s’exécutent automatiquement des centaines de scripts. Il s’agit de garantir la compatibilité de ces nouveaux développements avec le logiciel.

De plus, à chaque sprint et à tour de rôle, l’un des développeurs devient testeur. Il met entre parenthèses sa fonction de développeur pour ne se consacrer qu’aux tests durant 2 semaines. Grâce à la présence de ce testeur tournant, les développeurs codent mieux et plus clairement. Cela contribue à réduire considérablement la dette technique et à améliorer la qualité du code source rédigé.

Enfin, des tests de qualité sont réalisés par les formateurs, les consultants et le support technique : ces derniers sont prévenus dès qu’une fonctionnalité est mise en place en cours de sprint. Ils la testent et font un retour (correctifs, améliorations, suggestions…) au Product Owner avant même la fin du sprint. Cela constitue un énorme gain de réactivité. La méthode agile Scrum bonifie le développement de nos solutions. »

5. Quels sont les rituels agiles chez Articque ?

Jérôme Guyot : « La méthode Scrum chez Articque repose sur 4 rituels principaux, qui favorisent le bon déroulement d’un cycle de développement :

– le daily scrum : c’est la réunion du quotidienne, qui dure entre 5 et 10 minutes. Chaque développeur fait un point sur l’avancement de ses tâches, sur son programme du jour et sur les éventuels problèmes qu’il rencontre pour tenir ses délais et son objectif.

– le sprint planning : il se déroule soit le vendredi à la fin d’un sprint, soit le lundi au début d’un nouveau sprint. Le Product Owner présélectionne le contenu du futur sprint en fonction des priorités. Il en discute avec l’ensemble de l’équipe pour être sûr que l’objectif est compris de tous les développeurs. L’équipe s’engage alors à remplir cet objectif au regard des tâches définies.

– le sprint démo : à l’issue d’un sprint, l’équipe de développeurs présente aux autres services le résultat de son travail sous forme de démo. Elle est confrontée aux retours des salariés qui sont en rapport direct avec les utilisateurs. Les développeurs sont plutôt fiers de présenter le fruit de leur travail. Ils recueillent les félicitations, les encouragements mais aussi parfois les critiques. Le sprint démo est important pour consolider la relation entre les développeurs et les utilisateurs.

– le sprint retrospective. C’est un rituel capital qui suit le sprint démo. Il permet de poser un regard plus critique sur la façon de travailler et de communiquer du Product Owner. À cette occasion, nous débriefons également sur le déroulement du dernier sprint : nous identifions les points positifs et négatifs, ainsi que les erreurs à éviter dans le futur. Des actions correctives sont alors apportées pour améliorer notre process de travail. »