Démarche méthodologique de développement d’un projet en Utilisant

SCRUM
Démarche centrée sur le Sprint
L’objectif du Sprint est un but fixé pour le Sprint et peut être réalisé par l’implémentation
d’une partie du Product Backlog. Il fournit à l’Équipe de Développement la raison pour laquelle
elle construit l’incrément du produit. Il est créé lors de la réunion de planification du Sprint.
L’objectif du Sprint fournit à l’Équipe de Développement une certaine flexibilité quant à la
fonctionnalité implémentée durant le Sprint. Les items du Product Backlog sélectionnés offrent un
fonctionnement cohérent, ce qui peut faire office d’objectif de Sprint. Par ailleurs, l’objectif de
sprint peut être toute autre source de cohésion poussant l’Équipe de Développement à travailler
ensemble au lieu d’entreprendre des initiatives distinctes.

1. SPRINT BackLog (SPRINT 0) : Spécification des besoins et Elaboration du

Backlog du Produit
Il s’agit d’une période de préparation avant le commencement du premier Sprint, d’où le nom :
"Sprint 0" durant laquelle nous retrouvons les actions suivantes :
 Constitution de l’équipe Scrum (Product Owner, Scrum Master, Équipe de
développement).
 Définition du projet (vision )
 Définition des acteurs (fiches acteurs)
 Écriture du Product Backlog et Priorisation du Product Backlog.
 Elaboration de uses case
 Estimation et planification des Sprints et éventuellement des Releases.
 Mise en place de tout élément nécessaire au commencement du Sprint 1 (configuration
des environnements de développement, achat de licence, mise en place de l’architecture
applicative…).
Cette période de temps est également propice à la conduite du changement via la mise en place
de formations Scrum si nécessaire, mais également un moment privilégié pour l’équipe Scrum qui
va apprendre à se connaître et à...

Le Backlog du Produit
Le backlog du produit est l’artefact le plus important de Scrum, c’est l’ensemble des
caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les
caractéristiques fonctionnelles sont appelées des histoires utilisateur (user story) et les
caractéristiques techniques sont appelées des histoires techniques (technical story).

Les étapes de l’élaboration du product backlog présentées ici permettront de répondre

aux 3 questions suivantes :
• Quelles seront les fonctionnalités à créer ?
• Dans quel ordre devront-elles être livrées ?
• À qui sont-elles destinées ?
Première étape : établir la vision du projet

Il s’agit en quelques lignes de définir quel est l’objectif que le projet devra atteindre
avant que le Product Owner n’en arrête le développement. Il est important que cette
vision soit acceptée et comprise de tous, elle doit faire consensus puisque l’équipe
va devoir se rallier derrière le PO pour réaliser ce projet selon cet objectif.

Exemple1 de vision pour notre système de gestion des locations vidéos:

« Offrir une solution de gestion complète, incluant suivi, statistiques et
facturation ainsi qu’un module de prélocation en ligne et d’analyse statistique
pour les vidéoclubs. »

Exemple 2 de vision pour la plateforme d’un Système de soutien éducatif :

« Nous proposons de concevoir et d’implémenter une plateforme web en ligne qui

regroupe les fonctionnalités essentielles d’e-learning qui englobe à la fois le
sharing (document, webcam) et le partage d’idées, des connaissances et des
formations en ligne pour faciliter et renforcer les relations entre les tuteurs et les
apprenants ».

Deuxième étape : Identification des acteurs

Un acteur représente l’abstraction d’un rôle joue par des entités externes (utilisateur,
dispositif matériel ou autre système) qui interagissent directement avec le système
étudie.
Il va falloir identifier puis détailler tous les intervenants, utilisateurs du système dans
tous ses aspects. Pour chaque intervenant on voudra préciser les informations suivantes :
 Surnom : donner un Surnom aux acteurs rendra plus agréable leur
utilisation et il sera plus simple de s’y identifier.
 Icone / image : ajouter une représentation graphique de l’acteur rend
l’identification encore plus facile.
 Rôle : c’est en fait une description courte souvent juste un mot ou nom
commun.
 Description : on décrit pourquoi et/ou comment cet acteur utilisera le
système.
 Critères de satisfaction : ce qui rendra cet acteur satisfait de l’utilisation
qu’il fait du système.
 Valeur commerciale : élevée, moyenne, basse, bloquante (les autres
acteurs ne pourront utiliser le système).
 Fréquence d’utilisation : permanente, quotidienne, occasionnelle, rare.
 Nombre d’instances : combien d’intervenants comme celui-ci utiliseront
le système. 1, 10, 100+.
 Niveau de connaissance technologique : élevée, moyenne, basse.
 Niveau de connaissance métier : élevée, moyenne, basse.
 Exemple pour le Projet de gestion de club de location des vidéos (Acteur Bob)
Acteur : Bob
• Une image d’homme
• Rôle : Commis à la location de vidéo
• Description : Bob utilise le système pour enregistrer les locations de vidéos,
ainsi que les retours de location.
• Critères de satisfaction : Comme Bob utilise le système en présence de clients
qui attendent, Bob veut que le système soit rapide et facile à utiliser, avec une
ergonomie limitant les clics.
• Valeur commerciale : Élevée
• Fréquence d’utilisation : Permanente
• Nombre d’instances : 10 par installation
• Niveau de connaissance technologique : Moyenne (souvent des jeunes à ce
poste)
• Élevée

Troisième étape : regroupement de fonctionnalités

Dans notre exemple1, la vision est « Offrir une solution de gestion de location vidéo
complète, incluant suivi, facturation ainsi qu’un module de pré-location en ligne et
analyse statistique pour les vidéoclubs ».
On en tire donc facilement les thèmes suivants :
• location et suivi
• statistiques
• facturation
• pré-location en ligne

Dans notre exemple 2 de système de soutien éducatif, « Nous proposons de concevoir

et d’implémenter une plateforme web en ligne qui regroupe les fonctionnalités
essentielles d’e-learning qui englobe à la fois le sharing (document, webcam) et le
partage d’idées, des connaissances et des formations en ligne pour faciliter et
renforcer les relations entre les tuteurs et les apprenants ».
Les besoins fonctionnels identifiés pour ce projet sont regroupées en quatre espaces en
fonction des différents intervenants à savoir :
 Gestion des activités d’administrateur,
 Gestion des tuteurs,
 Gestion des apprenants
 Gestion des simples visiteurs

Elaboration des User Story

Ce sont les spécifications du projet présentées sous forme d’histoires
utilisateurs qui décrivent les interactions de l’utilisateur avec le système de
façon plus ou moins détaillées.

Chaque histoire utilisateur possède un effort (vélocité) qui est l’estimation initiale sur la
quantité de travail nécessaire pour implémenter cette exigence. Cet effort est calculé en point
d’histoire qui correspond aux jours hommes idéaux. Généralement, un point d’histoire vaut un
jour/homme.
Une user story s’écrit comme suit :
En tant que <rôle> Je veux <liste de tâches> Afin de <valeur ajoutée ou résultat>

Exemples
« En tant que Bob,Je peux créer un compte client, Afin de pouvoir leur louer des films »
« En tant qu’acheteur en ligne, je veux pouvoir ajouter des items à mon panier supprimer les
items afin de pouvoir n’acheter que ce dont je suis vraiment certain. »
« En tant que client, je peux consulter la liste des factures émises. »
« En tant que client (du projet), je peux consulter la liste de mes clients »
« En tant que client, je peux connaître le montant total des factures impayées »

Une bonne user story doit respecter l’acronyme INVEST (Indépendante, Négociable,
Verticale, Estimable, Small, Testable)

Le backlog de produit
Scrum n’impose pas de pratique pour identifier et nommer les éléments du backlog. L’usage le
plus courant est de définir un élément comme étant une story ou un cas d’utilisation
Dans un backlog de produit, les stories sont rangées (Classées) selon l’ordre envisagé pour leur
réalisation. Cette notion de priorité prend une grande importance dans le développement itératif.
Un backlog produit peut se présenter comme le tableau ci après :

Scénario ou story Priorité Effort Risque

En tant que client, je veux que mon robot puisse trier les M 1 1
pièces selon leur forme.
En tant que client, je dois pouvoir soumettre mon ordre M 2 3
de fabrication via internet.
En tant que donneur ordre de fabrication, je dois être M 2 2
informé par une notification sur mon smartphone à
chaque changement de l’état de l’OF.
Priorité :
 M pour Must Have : DOIT être fait.
 S pour Should Have : Il s’agit d’une exigence essentielle, qu’il faut faire dans la mesure
du possible (DEVRAIT).
 C pour Could Have: Il s’agit d’une exigence souhaitable
 W pour Won’t Have Il s’agit d’une exigence «Luxe». NE SERA PAS faîte cette fois
mais plus tard, mais intéressante et à garder pour la prochaine version

Effort :
5jours/homme : a une durée de 5 jours si le nombre de ressources qui travaillent en parallèle et à
temps plein est égal à 1. A une durée de 10 jours si le nombre de ressources qui travaillent en
parallèle et à mi-temps est égal à 1. A une durée de 1 jours si le nombre de ressources qui
travaillent en parallèle et à temps plein est égal à 5

La colonne risque : indique le niveau de complexité technique

Ce qu’il faut faire :

cultiver le backlog : la backlog évolue dans le temps, il faudra le mettre à jour.
partager le backlog avec toute l'équipe
surveiller la taille du backlog : ne pas avoir plus de 150 éléments à faire dans le backlog

Éviter :
D’avoir plusieurs backlog pour le même de produit
De ne pas avoir de backlog
De confondre le backlog de produit avec le backlog de sprint

Autre Exemple de Backlog Produit

Le Sprint Backlog (0) peut comporter en plus du backlog , le diagramme de cas d’utilisation Général
et éventuellement le diagramme de classes général.

Uses Case Général

Planification des sprints
La réunion de la planification des sprints est l’événement le plus important dans SCRUM. Le
but de cette réunion est de préparer le planning de travail et d’identifier le Backlog des sprints.
Le tableau ci après illustre un exemple de planification

Sprint Durée

Sprint 1 De 01/10/2019 jusqu’à 30/10/2019

Sprint 2 De 01/11/2019 jusqu’à 15/11/2019

Sprint 3 De 16/11/2019 jusqu’à 5/12/2019

Sprint 1
 Le Backlog de Sprint 1
ID User story Estimation
4 En tant que Magasinier je peux Créer un bon W4/W5
d’entrée.
5 En tant que Magasinier je peux Créer un bon de W6/W7
sortie.
6 En tant que Magasinier je dois pouvoir élaborer W8/W9
un bon de transfert.

 Analyse
 Conception
 Diagramme de séquence du sprint
 Diagramme de classes

 Réalisation du sprint

Répéter ce processus pour tous les sprints

Notion de Release
C’est l’achèvement d’un produit livrable au client répondant à ses besoins exprimés au départ
dans le product backlog.
Suite à l’exploitation du produit livré , le client peut signaler des nouvelles fonctionnalités
manquantes non ou mal spécifiées , ou encore demander l’amélioration de certaines
fonctionnalités. Dans ce cas un release 2 sera envisagée. ..