Notre parcours avec Scrum
Alors que nous approchons de nos premiers dix-huit mots d’utilisation de la méthodologie Agile Scrum chez Ennov PV, il m’a semblé approprié de revenir sur ce parcours.
C’est une évidence qu’implémenter n’importe quel nouveau procédé est une tâche difficile mais la beauté de Scrum est qu’il s’agit d’une méthodologie très simple. Il y a peu de règles et conventions à suivre (voir http://www.scrumguides.org/scrum-guide.html) et son exécution a été conçue pour être flexible et adaptative. Par définition, en tant qu’approche ‘agile’, il est possible d’anticiper comment votre implémentation va évoluer et l’améliorer de manière dynamique au fur et à mesure.
Le but ultime de Scrum est de permettre l’exécution d’une itération de logiciel testée (et potentiellement séparable) à la fin d’une période répétée et définie appelée Sprint. Je ne vais pas vous fournir de description détaillée de la théorie Scrum mais je vais me concentrer sur les rôles essentiels, les artefacts et les événements que nous utilisons aujourd’hui dans notre configuration chez Ennov PV.
Nous avons actuellement deux équipes Scrum puisque que nous venons de diviser notre groupe en pleine expansion. Au sein de chaque équipe des personnes sont en charge du développement de base (respectivement 5 et trois personnes dans chaque équipe), pendant que les ressources servant aux tests (cinq) sont partagées. Strictement parlant, Scrum ne supporte pas cette distinction entre développeur et testeur, il attend que les équipes soient polyvalentes et largement autonomes avec ses membres tous appelés développeurs Scrum (même s’ils sont spécialisés en test ou codage). Nous avons un Chargé de Produit précis, il s’agit en l’occurrence de moi-même. Je reçois de l’aide des autres Chargés de Produit concernant d’autres produits de la gamme. Nous possédons un Spécialiste Scrum par équipe, il est chargé d’endosser le rôle d’un mentor ou tuteur tout au long du processus, de divulguer des conseils et aussi d’aider à éliminer les obstacles extérieurs à l’équipe.
Scrum utilise un artefact primaire : le Carnet du Produit (ou Backlog Produit). Il sert de liste de référence à toutes les choses que l’on souhaite entreprendre pour un produit fixé. Chaque produit possède un Carnet différent. Il est principalement constitué des activités de développement (les bugs et les nouvelles fonctionnalités demandées) mais peut aussi inclure de la documentation ou d’autres tâches auxiliaires. Le Carnet a quelques particularités qui méritent d’être étudiées plus en détail :
- Les éléments sont classés par valeur décroissante – bien entendu, la ‘valeur’ est déterminée par différents facteurs. Dans notre domaine, il pourrait s’agir d’un impact règlementaire, de l’étendue ou l’importance d’un bug ou du nombre d’utilisateurs à être impactés par une nouvelle fonctionnalité.
- Il appartient au Chargé de Produit – je suis seul responsable pour accepter les items dans le Carnet du Produit et pour définir leur ordre d’importance. Naturellement, il m’appartient d’essayer d’obtenir les contributions d’autant d’acteurs que possible, de manière à refléter une large variété d’exigences internes et externes (provenant de clients).
- Le Carnet du produit est dit transparent – c’est-à-dire que tous les membres de l’équipe, et même de l’entreprise, peuvent y avoir accès. Cela facilite l’entrée de données pour ma part mais permet aussi que l’équipe Scrum aie une vision claire de chaque produit.
- Les items sont représentés comme des « stories » – chaque story détaille les changements envisagés, les personnes qui vont être affectées par ces changements et les avantages perçus. Chaque story est donc caractérisée par un certain nombre de critères d’acceptation qui ont besoin d’être remplis pour que la tâche soit accomplie.
Un deuxième artefact est le Carnet du Sprint (ou Backlog du Sprint). Celui-ci définit les stories qui doivent avoir été terminées dans chaque Sprint. Les items sont sélectionnés dans le Carnet du produit pour le Carnet du Sprint et sont ensuite développés dans une courte période de temps. C’est ce qui fait de Scrum un mécanisme efficace.
Un cycle de Sprint dure deux semaines et est fait d’un nombre fixe de « cérémonies » ou événements :
- Rétrospective – elle se passe au début du Sprint, et comme son nom l’indique, elle consiste à s’intéresser au Sprint précédent. Son objectif est de déterminer les améliorations qui peuvent être faites à l’avenir.
- Réunion de présélection (ou Grooming) – elle a aussi lieu pendant la première semaine du Sprint et a pour but de commencer à prévoir les choses qui seront vues dans le Sprint suivant. En prenant ainsi de l’avance tout en travaillant sur le Sprint en cours, l’équipe pourra commencer à prévoir le travail du prochain Sprint et à redéfinir les stories. Cet événement a notamment aidé à améliorer la justesse de nos estimations mais aussi à apporter plus de transparence pour toute l’équipe.
- Réunion de sélection (ou Sprint planning) – elle a lieu à la fin du cycle du sprint et nous donne l’opportunité d’évaluer toutes les stories qui n’ont pas pu être achevées (pour qu’elle puisse l’être dans le Sprint suivant ou qu’elles soient retournées dans le Carnet du produit). Cette cérémonie permet aussi à notre équipe de se tenir aux objectifs du prochain Sprint et faire en sorte que nous soyons ambitieux sans être irréalistes.
- Réunion quotidienne (ou Standup meeting) – il s’agit sûrement de l’activité la plus importante. Elle a lieu chaque jour et donne à l’équipe la possibilité de discuter de la situation actuelle et d’identifier les obstacles qui pourraient potentiellement venir entraver la bonne exécution des objectifs du Sprint.
En plus de ces événements, nous organisons également des démonstrations du produit (Sprint demo) pour présenter le développement au reste de l’entreprise afin d’obtenir des idées ou des retours. J’aimerais que ces présentations aient lieu plus souvent, comme elles sont importantes pour partager les connaissances de chacun et définir une stratégie de développement. Il n’y a pas de doute qu’inclure des réunions de routine similaires pour les clients serait également bénéfique.
De mon point de vue de Chargé de Produit, qu’avons-nous gagné en adoptant Scrum ?
Pour mieux répondre à cette question, il est important de comprendre à quel point Scrum diffère de notre ancienne approche de développement. Il y a, selon moi, trois distinctions principales :
- 1. Priorisation du développement – bien que nous ayons travaillé avec un Carnet de Produit précédemment, également priorisé pour refléter les besoins de la réglementation et des clients, la répartition des tâches au sein des équipes de développement était fondamentalement descendante. Comme le nouveau Carnet de Produit est transparent, chaque employé de l’entreprise pouvant y accéder, il est à présent beaucoup plus simple d’avoir un aperçu de la direction du produit. Ainsi, n’importe qui peut apporter sa contribution à la conception de nouvelles fonctionnalités et aider à repérer les dépendances potentielles dans le développement. Les personnes extérieures à l’équipe de développement peuvent ajouter leur expérience client spécifique pour aider à identifier des conflits entre la conception et l’utilisation actuelle des fonctionnalités existantes.
- 2. Intégration développeur/testeur – auparavant, un développeur livrait en fonction d’une spécification, avant de la remettre à l’équipe d’essai. En travaillant ensemble tout au long du Sprint, les testeurs peuvent maintenant fournir un feedback beaucoup plus tôt au fur et à mesure que la story est préparée. Les critères d’acceptation évoluent en collaboration et, par conséquent, favorisent une plus grande réflexion de l’ensemble de l’équipe sur les impacts potentiels en dehors de l’axe principal de développement. Les stories sur Carnet du Sprint ne sont considérées comme ayant été faites que lorsqu’elles ont été testées de façon satisfaisante par rapport aux critères d’acceptation globale. Je suis convaincu que l’utilisation de ces critères d’acceptation s’avère déjà très influente dans l’amélioration de l’efficacité et de la précision de notre développement.
- 3. Souplesse de développement – dans le cadre de nos pratiques antérieures, nous avions tendance à nous diriger vers des sorties plus importantes avec une vaste ampleur de changements. L’expérience nous a appris que de nombreux clients sont réticents à déployer ces versions plus importantes en raison de la charge de validation. Malheureusement, l’intérêt limité d’appliquer les mises à jour a eu un effet auto-réalisateur sur la taille des versions ultérieures, à mesure que les carnets grossissent. Avec la nouvelle approche, nous pouvons être plus dynamiques dans notre préparation de nouvelles versions – un seul Sprint, par définition, peut générer une version du logiciel qui peut potentiellement sortir. Par conséquent, nous pouvons plus facilement nous assurer que des versions logicielles plus petites et plus régulières peuvent être mises à disposition. Nos clients peuvent déployer ces mises à jour plus rapidement, ou au moins en assembler un certain nombre et ensuite les déployer avec des stratégies de validation contrôlées et allégées.
Afin de renforcer cette approche, nous travaillons d’arrache-pied sur de nouvelles mesures pour éliminer la régression d’une mise à jour à l’autre. Nous construisons rapidement une bibliothèque de scripts de test automatisés qui peuvent être exécutés pour chaque build afin de confirmer le comportement attendu des fonctionnalités existantes. L’autotest, ainsi que des tests manuels rigoureux tout au long du Sprint, nous aideront à atteindre un objectif combiné d’amélioration de la qualité et de l’efficacité.
J’ai dit au début de ce post que n’importe quel changement de méthodologie risque de s’avérer difficile. Quels ont été les principales difficultés que nous avons rencontrées ?
Grâce à notre équipe réceptive et volontaire, l’adoption de Scrum en elle-même a été relativement indolore. Nos principales difficultés ont été rencontrées dans les mécanismes détaillés du processus :
- 1. Estimation – afin de programmer les progrès dans un Sprint de développement de deux semaines, il est nécessaire d’estimer avec précision le temps qu’il faudra pour développer, réviser et tester chaque story. C’est notoirement difficile à faire, et cela ne devient vraiment plus facile qu’avec l’expérience. Cela ne veut pas dire que nous ne nous trompons pas occasionnellement – quand une seule story prend beaucoup plus de temps que prévu ! Nous travaillons sur des stratégies pour éviter cela, ou du moins pour en atténuer l’impact, par exemple en divisant des tâches plus importantes en stories séparées ou en ayant des stories de recherche dédiées (appelées pics ou « spike ») pour évaluer plus rigoureusement les exigences avant l’estimation.
- 2. De la livraison au test – pour chaque Sprint, il y a nécessairement un délai avant que les stories puissent être transmises d’un développeur à un testeur. C’est un défi permanent de s’assurer que nous avons une quantité constante d’articles à tester pendant le Sprint, et que nous ne reportons pas tous les tests sur les derniers jours. Pour y remédier, chaque jour, nous essayons d’identifier ce qui peut être testé (et nous essayons aussi de nous assurer que des tâches de développement plus courtes sont abordées au début de la semaine).
- 3. Objectifs d’équipe – Scrum est une pratique d’équipe et il faut certainement du temps pour s’assurer que le Carnet du Sprint est considéré comme un objectif d’équipe. Dans la plupart des circonstances, une story donnée ne nécessitera que l’action d’un développeur, d’un relecteur de code et d’un testeur pour être terminée. Évaluer l’objectif global poursuivi par l’équipe chaque jour et planifier la meilleure approche à l’échelle de l’équipe pour atteindre l’objectif du sprint est essentiel pour pouvoir faire changer cet état d’esprit.
Alors, où en arrivons-nous ?
Avec l’intégration de nouvelles personnes dans nos équipes (nous avons recruté trois développeurs supplémentaires et un spécialiste des tests automatisés au cours des quatre derniers mois) et la récente scission en deux équipes, nous devons maintenant nous assurer que nous pouvons adopter une approche cohérente et continuer à gérer le processus efficacement.
Nous sommes en train de mettre en place un nouvel outil, appelé Redmine, pour gérer nos Carnets de Produit et aider à la gestion du Sprint. Le nouvel outil est moins lourd que notre solution existante, mais nous offre toujours une traçabilité complète sur le cycle de vie du développement, comme l’exigent notre système de gestion de la qualité (SMQ) et nos procédures de développement. Nous espérons faire évoluer l’utilisation de Redmine et de notre processus Scrum vers encore plus d’efficacité.
Scrum est sans aucun doute polyvalent et, par conséquent, je pense qu’il s’agit d’une approche que nous pouvons envisager pour d’autres secteurs de notre entreprise. Je peux anticiper l’exécution de certains projets clients sous Scrum, et même l’utilisation du framework pour gérer une plus grande partie de notre charge de travail interne.
J’espère que la lecture de nos expériences avec Scrum vous a donné un bon aperçu de l’évolution de nos processus de développement au cours des dix-huit derniers mois. Peut-être même que vous souhaiterez en apprendre davantage et d’intégrer certains aspects de Scrum dans vos processus de gestion de projet ?
Merci de votre intérêt !
Nic
