Artefacts Scrum dans Agile

Le terme d'artefact est souvent associé aux sites archéologiques et aux reliques. Pourtant, dans le domaine du développement logiciel, le terme artefact fait référence aux informations clés nécessaires durant le développement d'un produit.

Agile a ses propres sous-produits particuliers qui émergent de l'expérience de planification Scrum, du développement, du suivi et de l'itération des tâches pour concevoir des logiciels.

Les artefacts Scrum dans Agile sont des informations utilisées par les équipes Scrum et les parties prenantes pour détailler le produit en cours de développement, les actions à mettre en place pour y parvenir ainsi que les mesures prises durant le projet. Ces artefacts fournissent des points de métadonnées, sources d'informations sur les performances d'un sprint. Ce sont des outils essentiels à chaque équipe Scrum, car ils favorisent les attributs Scrum de base, à savoir la transparence, l'inspection et l'adaptation.

Les artefacts sont créés au cours des principales activités d'un sprint Scrum :

• Planifier le travail et les objectifs futurs
• Créer des tâches pour atteindre ces objectifs
• Organiser les tâches en sprints en fonction des dépendances et priorités
• Exécuter les tâches
• Examiner et analyser les résultats pour les comparer aux objectifs
• Répéter ces étapes

Les principaux artefacts Scrum dans Agile sont le backlog produit, le backlog de sprint et les incréments.

Le backlog produit est une liste de nouvelles fonctionnalités, améliorations, corrections de bugs, tâches ou exigences métier nécessaires à la conception d'un produit. Il regroupe différentes sources telles que le support client, l'analyse des concurrents, les demandes du marché et l'analyse commerciale générale.

Le backlog produit est un artefact « vivant », puisqu'il est mis à jour à la demande à mesure que de nouvelles informations sont disponibles. C'est un document transverse maintenu et organisé par le Product Owner entre les cycles de sprint ainsi qu'à l'émergence de nouvelles idées. Il contient des tâches qui ont fait partie d'un sprint actif, mais qui ne sont plus des priorités et ont été déplacées vers le backlog.

Le backlog de sprint est un ensemble de tâches du backlog produit qui ont été mises en avant pour être développées durant le prochain incrément de produit. Les backlogs de sprint sont créés par l'équipe de développement pour planifier des livrables pour de futurs incréments et préciser le travail nécessaire à la création de cet incrément.

Les backlogs de sprint sont créés en sélectionnant une tâche dans le backlog produit et en la décomposant en tâches de sprint plus petites et exploitables. Citons comme exemple de tâche « concevoir une page de panier », ce qui nécessite de nombreuses sous-tâches de design et de développement. La tâche principale est indiquée dans le backlog produit, tandis que les tâches annexes telles que « créer une maquette de design visuel du panier » ou « programmer les sessions du panier » sont stockées dans le backlog de sprint.

Le backlog de sprint est mis à jour durant la phase de planification du sprint de Scrum. Les tâches de sprint les plus petites sont assignées aux équipes concernées, les équipes de design et de développement, par exemple. Si une équipe n'est pas en mesure de livrer toutes les tâches du sprint, les tâches restantes seront mises en attente dans le backlog de sprint pour un sprint à venir.

Un incrément de produit correspond aux livrables client créés en exécutant les tâches du backlog produit durant un sprint. Les incréments des sprints précédents sont également inclus. Un incrément est toujours compris dans chaque sprint et est décidé durant la phase de planification de Scrum. Un incrément se produit si l'équipe décide de livrer au client. Les incréments de produit sont très utiles et complètent la CI/CD par un suivi de version et, si nécessaire, une restauration de version.

Les équipes tirent parti de tout leur travail aligné sur les tâches du backlog. Par exemple, créer une branche et un build chaque tâche du backlog. Les équipes qui intègrent leurs outils de contrôle de version et de CI/CD à leur logiciel de suivi Scrum peuvent utiliser les informations de ces outils pour mieux comprendre l'avancement du travail. Elles peuvent également savoir quelles tâches du backlog sont déployées et livrées aux clients. Enfin, à l'inverse, cela permet également à l'équipe d'examiner les commits et de les associer à nouveau à un incrément Scrum pour voir l'historique et la planification de ce code.

Outre les artefacts Scrum officiels précédemment présentés, il existe des artefacts étendus ou méta-artefacts. Bien qu'ils ne soient pas reconnus comme officiels par les recommandations Scrum, ces artefacts étendus ajoutent de la valeur et des informations supplémentaires à un cycle Scrum.

Un graphique Burndown (ou Burnup) de sprint n'est pas un artefact Scrum officiel, mais de nombreuses équipes l'utilisent durant le sprint pour communiquer et suivre l'avancement vers l'objectif. Les graphiques Burndown affichent les tâches terminées durant un sprint. Ces derniers sont très utiles pour aider à évaluer la vélocité d'exécution active d'une équipe afin que ses membres sachent s'ils pourront terminer ce qui est prévu ou s'ils doivent hiérarchiser à nouveau les tâches du sprint.

Pendant la planification du sprint, les équipes peuvent se référer à des graphiques Burndown passés pour se faire une idée du nombre de tâches qu'elles peuvent terminer dans le sprint à venir. Elles peuvent consulter les graphiques Burndown en cours pour identifier si le sprint est en bonne voie. Lors de la revue de sprint, elles peuvent consulter à nouveau les graphiques Burndown pour voir si les attentes ont été satisfaites ou non. Au fil du temps, les graphiques Burndown permettent aux équipes d'affiner leurs estimations pendant les phases de planification de Scrum.

Il est important que les équipes aient une définition claire de « Terminé ». Cette définition peut être un autre type d'artefact, qui doit être documenté et partagé. Par exemple, pour une équipe de développement, la définition de « Terminé » désigne le moment où le code est couvert par des tests automatisés, qui correspondent à une spécification, et est déployé dans un environnement de production. Une équipe n'ayant pas une définition claire de « Terminé » se demandera sans cesse « est-ce terminé ? » lors de l'examen des tâches Scrum en cours dans la revue de sprint.

La définition de « terminé » permet de délimiter un incrément. Les incréments doivent être livrés sous forme de packages utilisables et terminés, qui s'ajoutent aux incréments précédents. « Terminé » correspond aussi au moment où les tâches sont terminées et peuvent être fermées pour le suivi de l'avancement.

Les artefacts Scrum représentent une aide puissante qui permet aux équipes de fonctionner plus efficacement. Par conséquent, il est important que toutes les équipes y aient accès et puissent les voir. Les Product Owners et les Scrum Masters doivent prendre l'habitude d'examiner les artefacts et d'en discuter régulièrement avec les équipes de développement. Cela permettra aux équipes de rester conscientes des inefficacités opérationnelles et de trouver des moyens créatifs pour améliorer la vélocité.