Les Artefacts Scrum : Transformer pour Avancer !

De nouvelles manières de travailler basées sur des principes agiles (SAFE, SCRUM…) se sont développées ces dernières années provoquant l’apparition de nouveaux métiers (Product Owner, Scrum Master…), la mise en place de nouveaux outils (Jira, Trello, Confluence...) mais aussi l’utilisation d’un nouveau vocabulaire.

Ce vocabulaire parfois abstrait mérite d’être appréhendé surtout lorsque l’on débute dans l’agilité. Probablement que nous avons été plusieurs à se « gratter la tête », lorsque nous avons croisé pour la première fois la notion d’Artefact Scrum. Qui sont-ils ? Quel est leur rôle et leur fonction ? En quoi sont-ils utiles durant le développement d’un produit ? C’est ce que nous allons découvrir ensemble à la lecture de cet article.

Un Artefact c’est quoi ?

Il convient de comprendre que ce mot admet plusieurs significations en fonction du domaine de référence. Ainsi, en électronique un artefact est considéré comme un effet indésirable, un parasite. En biologie il désigne une altération d'une structure biologique sous l'effet de réactifs(fixateurs, colorants...).

D’autre part, sous l'influence du faux-ami anglophone Artifact, le mot est aussi employé de manière générale pour nommer un produit ayant subi une transformation, même minime, par l’homme et qui se distingue ainsi d’un autre provoqué par un phénomène naturel.

Et l’informatique dans tout ça ? Pourquoi parle-t-on d’Artefact en informatique notamment quand on évoque la méthode Scrum ?

Les Artefacts Scrum

Dans le domaine du développement logiciel, le terme artefact fait référence aux informations clés nécessaires à tous les acteurs, durant le développement d'un produit.

En effet, les artefacts Scrum sont des informations utilisées par les équipes Scrum et les parties prenantes pour détailler le produit en cours de développement ou les actions à mettre en place pour y parvenir. On dit aussi que ce sont des outils essentiels à chaque équipe Scrum, car ils favorisent la transparence, l'inspection et l'adaptation caractéristique de ce framework.

Scrum possède 3 artefacts classiques : Le product backlog, le sprint backlog et le product incrément. En tant qu’Artefact, ces 3 éléments subissent des transformations tout au long de la vie du produit. C’est le moment de se rappeler ce que l’on a dit en introduction sur l’Artefact et sa transformation par l’homme… car nous y sommes !

Le Product Backlog

Au début du développement d’un produit Agile, on va regrouper dans un« réservoir » toutes les « spécifications » qui vont décrire le produit afin que l’équipe de développement puisse commencer à le réaliser. C’est le Product Backlog.

Le Product Owner va regrouper les différents sujets du Product Backlog dans des Epic (Thèmes) elles-mêmes découpées par Feature (grosses fonctionnalités). Ces dernières seront redécoupées en User Story (US).

Ce « réservoir » va permettre à l’équipe d’avoir une vision du produit et de son objectif. Le backlog est constitué de différents Items : les user stories décrivant une fonctionnalité métier, les anomalies (bugs), les études (spike) et les user stories techniques écrites par les développeurs.

Le Product Owner a l’entière responsabilité du Product Backlog et de la priorisation des US à traiter.

Pour mieux comprendre, voici un exemple de ce fameux « réservoir ».

Le sprint backlog

Dans le framework Scrum un projet est découpé en plusieurs cycles nommés sprints qui ont une date de début et une date de fin fixe. En général, les sprints ont une durée de deux à trois semaines.

Le sprint backlog peut lui aussi être considéré comme un « réservoir » contenant différents items issus du Product backlog. Le sprint backlog est construit durant le sprint planning*.

Dans le sprint backlog les user stories sont en générale, découpées en petites tâches indivisibles (métier ou techniques) et elles sont souvent estimées en point d’efforts. Chaque membre de l’équipe de réalisation (développeurs et testeurs), selon son envie va décider avec les autres de ce qu’il souhaite faire au fur et à mesure. Nous comprenons ainsi que cette équipe est responsable du Sprint Backlog et des différentes tâches qui sont engagées.

Pour revenir à notre exemple, nous allons voir comment est découpée l’US N°02.

*Le sprint planning : cérémonie scrum qui permet d’identifier ce qui sera développé pendant le sprint et livré à la fin de celui-ci.

L’incrément

Durant chaque Sprint, l’équipe de développement réalise un bout de produit qui peut être livré « en production », c’est l’incrément produit. L’incrément est le reflet de la valeur produite pendant le sprint. Chaque incrément s’ajoute aux incréments existants et ces derniers vont fonctionner ensemble.
L’objectif est que l’incrément produit contienne l’ensemble des User Stories estimées par l’équipe lors de la constitution du Sprint Backlog. Il arrive que certaines User Stories ne soient pas terminées à la fin du sprint. Elles seront alors reportées dans le sprint suivant.

Artefacts étendus

Les artefacts que nous avons vus sont des Artefacts officiels au sens Scrum. Toutefois, il existe des artefacts dits « non officiels ». Ils ajoutent de la valeur et il convient de ne pas les oublier !

Le Burn Down Chart

Cet artefact, peut être qualifié d’artefact de transparence. L’équipe l'utilise durant le sprint pour suivre l'avancement du nombre de points réalisés et comparer la réalité à un avancement idéal. Au fil de l’eau ces graphiques vont permettre à l’équipe d’évaluer sa vélocité c’est-à-dire l’effort qu’elle est capable de réaliser dans un sprint. Dans l’exemple ci-contre l’effort est mesuré en nombre de points de complexité.

La Définition Of Done

Connue sous l’acronyme DOD, c’est littéralement la définition du travail terminé. Une fois que l’on a écrit ça il est légitime de se demander ce qu’est un travail terminé… et c’est là que la DOD intervient !

En effet, la DOD est constituée de critères qu’il convient d’avoir fait pour considérer le travail comme terminé. Prenons l’exemple d’un Product Owner et des développeurs. Ces deux parties peuvent se baser sur les critères de la DOD pour définir ensemble que le développement d’une US est terminé et qu’elle peut être démontrée. Pour être concret prenons l’exemple ci-dessous.

Dans notre cas, le PO et les développeurs pourront se mettre d’accord sur l’aspect terminé d’une US au travers des critères suivants : les tests unitaires couvrent 70% du code par exemple, le code a été revu par deux développeurs, les documentations sont actualisées, les cas à démontrer et leurs jeux de données associés sont identifiés.

Attention rien n’est gravé dans le marbre il s’agit ici d’un exemple mais il en existe bien d’autres évidemment !

La Définition Of Ready

La Definition of Ready, connue sous l’acronyme DOR, est la liste des critères sur lesquels l’équipe va s’appuyer pour définir si l’US est prête à être développée. Si elle répond favorablement à tous ces critères, l’US peut passer du backlog produit au backlog sprint. La DOR est considérée comme un contrat entre le PO et les développeurs. Ci-dessous quelques exemples de critères…

Pour finir..

Concluons par ce schéma qui montre l’articulation entre les différents Artefacts dits officiels. Vous l’avez compris l’idée principale à retenir est la suivante : ces derniers évoluent dans leur contenu au fur et à mesure de l’avancée des développements et du projet. N’oublions pas également les artefacts non officiels qui sont tout aussi importants. En effet, ces deux types d’Artefact aident l’équipe à faire preuve de transparence et à mesurer son avancement vers l’objectif final.

Retrouvez l’essentiel de l’article :