Vous êtes sur la page 1sur 13

Penser Agile, SCRUM, pour la Gestion de Projet :

« Améliorer les méthodes d’enseignement »

Houda Nakkach 1, Nadia Hachani 2


1
ISET Charguia, Tunisie
2
ISET Bizerte, Tunisie

(h_nakkach, nadia.hachani)@yahoo.fr

Résumé:

L’objectif de notre étude de cas est de vulgariser les méthodes agiles de gestion de projet, précisément “SCRUM”, pour tous
types de projet. Cette étude de cas portera sur « Améliorer les méthodes d’enseignement ». La première étape consiste à
interviewer les acteurs principaux pour générer les user-stories. La deuxième étape, c’est l’élaboration d’un carnet de produit
« Backlog Product » basée sur les user-stories classifiés par priorité basée sur les critères tels que les risques, la faisabilité et
la dépendance. Au niveau de la troisième étape, le backlog-product validé sera détaillé sous forme de backlog-sprint afin de
dégager les déférents releases. Au sein de chaque release, des mêlées quotidiennes seront planifiées et des révisions des
sprints seront réalisées pour faire un suivi des objectifs à réaliser.

Mots Clés : Gestion de projet, Méthode Agile, SCRUM, Backlog-Product, Sprint, Release, user-Stories.

Introduction
L’objectif de notre étude de cas est de mettre en évidence une scénarisation pour l’utilisation de la méthode Agile
« SCRUM » : les étapes à suivre et les concepts à respecter. Pour ce faire, nous avons choisi comme problème à résoudre
« l’amélioration de la méthode d’enseignement », qui est un sujet d’actualité et qui vise à voir des solutions pour des besoins
finaux des acteurs qui entrent en jeu pour la réussite du système éducatif en particulier universitaire.

A l’égard de ces circonstances, nous proposons le plan suivant pour notre étude de cas :

- La première section intitulée « Terminologies » : présente des définitions aux concepts mis en jeu au niveau de la
méthode « SCRUM ».
- La deuxième section « Collecte des User-stories » : consiste à définir les acteurs, ainsi que leurs besoins en terme
de critères d’évaluation de l’adéquation du système éducatif à leurs attentes.
- La troisième section « Backlog-Product », a pour objectif la classification des users-stories au niveau des sprints, et
la réalisation de ses derniers dans le cadre d’un release.
- La quatrième partie « planification des sprints »
- Et à la fin, Nous clôturons avec la phase closure.

1 Terminologies
Notre étude de cas est basée sur une méthode de développement assez originale, issue des méthodes agiles, à savoir la
méthode « SCRUM ». Nous essayons à travers cette étude de cas de mettre en évidence les avantages de ladite méthode,
surtout le plan de la productivité et de l’efficacité. Mais avant d’entamer l’exécution de notre démarche stratégique, nous
commençons par un parcours définissant les différentes terminologies utilisées pour assurer la bonne conduite de toutes les
phases :

Scrum

« Scrum signifie mêlée au rugby, elle utilise les valeurs et l’esprit du rugby et les adapte aux projets de développement.
Comme le pack lors d’un ballon porté au rugby, l’équipe chargée du développement travaille de façon collective, soudée vers
un objectif précis. Comme un demi de mêlée, le Scrum Master aiguillonne les membres de l’équipe, les repositionne dans la
bonne direction et donne le tempo pour assurer la réussite du projet.» [1]

Scrum est issu des travaux de deux des signataires du Manifeste Agile, Ken Schwaber et Jeff Sutherland, au début des années
1990. Elle appartient à la famille des méthodologies itératives et incrémentales et repose sur les principes et les valeurs agiles.
Le plus souvent, les experts de Scrum, même ses fondateurs, le décrivent comme un cadre ou un patron de processus orienté
gestion de projet et qui peut incorporer différentes méthodes ou pratiques d’ingénierie. S’il est difficile de définir la nature de
Scrum, sa mise en place est beaucoup plus simple et peut être résumée par la Figure 11.

Le principe de base de Scrum est le suivant :

 Dégager dans en premier lieu le maximum des fonctionnalités à réaliser pour former le backlog du produit,
 En second lieu définir les priorités des fonctionnalités et choisir lesquelles seront réalisé dans chaque itération,
 Par la suite focaliser l'équipe de façon itérative sur l’ensemble de fonctionnalités à réaliser, dans des itérations
appelées Sprints,
 Un Sprint aboutit toujours sur la livraison d’un produit partiel fonctionnel appelé incrément.

Figure 1 : Le processus Scrum

User-stories [2]

Dans les méthodes agiles, un user story est une phrase simple dans le langage de tous les jours permettant de décrire avec
suffisamment de précision le contenu d'une fonctionnalité à développer.

La phrase contient généralement trois éléments descriptifs de la fonctionnalité : Qui ? Quoi ? Pourquoi ?

En tant que <qui>, je veux <quoi> afin de <pourquoi>.

Le pourquoi est optionnel. Il permet cependant d'identifier l'intérêt de la fonctionnalité.

D’après Thierry Cros Organisation, Le "jeu de la planification" consiste à maximiser la valeur ajoutée produite par une
itération puis un release. Pour cela, le Product Manager/Owner précise l'importance ou valeur ajoutée de chaque story
permettent d'en déduire sa priorité, tout en mettant en évidence le premier principe agile : « Notre plus grande priorité est de
satisfaire le Client en livrant tôt et continuellement un logiciel qui lui apporte une valeur ajoutée. »

Equipe et rôles

Scrum définit trois rôles [3] : le Propriétaire du produit (Product Owner), le Scrum Master et le Développeur.
 Le Propriétaire du produit (Product Owner) est le représentant des clients et des utilisateurs. Il est responsable
de maximiser la valeur du produit et du travail de l'équipe de développement. Il s'agit d'une personne et non d'un
comité. Il est seul à diriger l'activité de l'équipe de développement à qui il n'est pas permis de suivre les instructions
d'une autre personne.
 Le Scrum Master est responsable de la compréhension, de l'adhésion et de la mise en œuvre de la méthode. C'est
un leader au service de l'équipe, il assiste chaque rôle de l'équipe Scrum dans son activité et promeut le changement
des interactions entre les rôles dans le but de maximiser la valeur de ce que produit l'équipe. Son autorité s'exerce
sur le processus de développement (définition de la durée des itérations, des modalités de tenues et de l'ordre du
jour des réunions Scrum, etc), mais il ne dispose d'aucune autorité sur les autres membres de l'équipe Scrum.
 L'équipe de développement est constituée de 3 à 9 personnes et a pour responsabilité de livrer à chaque fin
d'itération une nouvelle version de l'application enrichie de nouvelles fonctionnalités et respectant le niveau de
qualité nécessaire pour être livré.

Backlog-Product [3]

Le backlog-product présente le carnet de produit exhibé sous la forme d’une liste ordonnée des besoins relatifs à notre
produit. C'est un document qui évolue constamment au cours de la vie du produit et n'est jamais fini. Chaque élément du
carnet représente une fonctionnalité, besoin, amélioration et correctif, auquel sont associés une description, une estimation de
l'effort nécessaire à la réalisation de l'élément et une grandeur permettant d'ordonner les éléments entre eux.
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).

Sprint [3]

Le sprint est le cœur de Scrum, généralement il présente un bloc de temps durant lequel un incrément du produit sera réalisé
et incrémenté. Cependant, tous les sprints d’une release ont une durée constante et ne se chevauchent jamais, c'est-à-dire
qu’un sprint ne peut pas démarrer tant que le précédent n’est pas encore terminé.

Un sprint doit avoir un but défini en terme métier et non pas en terme technique pour qu’il soit compréhensible par les
membres en dehors de l’équipe. Il s’agit de répondre à une question fondamentale « pourquoi faisons-nous ce sprint ? ». Et
une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires inclure dans ce dernier. Plus
précisément, quelles histoires de notre backlog du produit seront incluses dans le backlog du sprint.

Release

Un release correspond à la livraison d'une version, en d’autre terme, on parle de release pour considérer la période de temps
qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs. Peu importe
quelle définition nous utilisons, une release est constituée d'une suite d'itérations (sprint) qui se terminent quand les
incréments de ces derniers construisent un produit présentant suffisamment de valeur aux utilisateurs finaux.

2 Collecte des User-stories


Identification des users

Un acteur ou un user est une entité qui existe en dehors du système de l'étude et prend part à une série d'activités dans un
dialogue avec le système, afin d'atteindre certains objectifs. Il peut s’agir d’utilisateurs finaux, d'autres systèmes ou des
périphériques matériels. En réponse à l'action d'un acteur, le système fournit un service qui correspond à son besoin. Pour
notre étude de cas, nous spécifions ci-après les acteurs de notre système et le rôle associé à chacun d’entre eux :

 L’étudiant : Qui assiste au processus d’enseignement.

 L’enseignant : .qui simule et réalise le processus d’enseignement.

 Administration de l’université : qui supervise et assure le bon déroulement du processus de l’enseignement.


Quête des users-stories

Imaginer toutes les stories possibles : Brainstorming [4]

Le brainstorming est une technique de créativité qui facilite la production d’idées d'un individu ou d'un groupe.
L'utilisation du brainstorming permet de trouver le maximum d’idées originales dans le minimum de temps grâce
au jugement différé. Le jugement différé consiste à énoncer d'abord un grand nombre d’idées et de les évaluer
uniquement dans un deuxième temps ou lors d'une autre rencontre.

Application à notre étude de cas

Pour la requête des users-stories correspondantes à notre étude de cas, nous avons appliqué la méthode Brainstorming pour
interviewer les acteurs (étudiant, enseignant, administration) en interférence avec notre problématique « Améliorer la
méthode d’enseignement », notre enquête est faite avec des acteurs experts du domaine d’enseignement (selon leur type :
étudiant ,enseignant, administration), au niveau de l’école nationale d’ingénieur de Tunis (ENIT) et au niveau de l’institut
supérieur des études technologiques de Charguia (ISET-Ch). Et pour bien présenter les stories, nous focalisons sur la
méthode des règles 3C (Card, Conversation, Confirmation) et les critères INVEST.

 Card : qui consiste à écrire l’histoire, courte en une ou deux phrases sur une carte.
 Conversation

Les détails de l’histoire sont discutés par les équipes avec le métier, les ergonomes, etc. Pour bien piloter notre
projet Scrum, il faudra commencer par mettre en valeur : l’équipe avec des rôles bien définis, les priorités et enfin
les Pattern et critère de qualité Invest.
o Priorité
Le choix des priorités d’une User Story se base sur l’influence et l’importance d’une tâche sur notre
système. Nous pouvons la diviser sous une échelle de Low- Medium –Top.

o Pattern et critère de qualité INVEST


 Independent : Une bonne User Story est indépendante (des autres User Stories, bon autant que
possible) notamment pour faciliter son traitement; car le choix de l’inclure dans tel ou tel sprint (=
itération) est avant tout fondé sur la priorité qu’on lui donne.
 Négociable : Elle est négociée, discutée (c’est le second C, Conversation) dés les réunions
d’estimation et de planification du Sprint mais aussi tout au long de ce dernier.
 Valuable : Elle est source de valeur pour le client final ou l’utilisateur.
 Estimable : Elle est estimée par les équipes de développement ; une estimation relative c’est à dire
les unes par rapport aux autres, en story points.
 Size Appropriately : le plus souvent petite car susceptible d’être traitée (livrée et testée) par l’équipe
sur une seule itération de 2/ 3 semaines. Le niveau de granularité est une question fréquente.
L’affaire est très contextuelle mais je conseille le plus souvent une petite taille qui va faciliter là
aussi son estimation, sa décomposition en tâches puis son traitement (codage et test) sur un
maximum de quelques jours. Il existe des User Stories plus « grosses », nommées « epics », des
stories qui ne sont pas envisagés sur les tous prochains sprints et qui seront splittées en User Stories
le moment venu.
 Testable : Un User Story « de qualité » est avant tout testable, déjà dans sa forme et surtout dans le
sens où les critères d’acceptation sont envisagés d’entrée (le troisième C, Confirmation). Si elle n’est
pas testable ou vérifiable ce n’est pas une User Story. La définition de ces critères d’acceptation est
un premier pas vers la qualité qui aidera à la fois la décomposition en tâches et l’activité de
développement.
 Confirmation
L’histoire est confirmée par des tests d’acceptation rédigés au même moment que celle-ci, au dos de la carte, c’est
un élément majeur d’où vient le backlog qui est le Artefact le plus important de Scrum, c’est la liste de tâches
jugées essentielles et suffisantes pour la réalisation satisfaisante du projet.

3 Backlog-Product

Le backlog produit de notre application est présenté par le Tableau 1 Backlog-Product. Il est à noter que nous n’avons pas
cité les histoires techniques comme la préparation de la maquette graphique, les travaux de conception et les jeux de tests, etc.
Dans ce tableau chaque histoire utilisateur est caractérisée par un rang déduit à partir de ses risques et sa priorité.

Pour le traitement de nos histoires utilisateur nous choisissons de commencer avec les cas d’utilisation les plus prioritaires et
ayant le risque le moins élevé.

La priorité est basée sur la dépendance entre les fonctionnalités de l’application. Par conséquent, nous pouvons dégager trois
niveaux de priorité qui sont : priorité haute, moyenne et faible.

L’identification des risques critiques présente une étape indispensable pour la réussite de notre projet. Pour notre cas, le seul
risque qui peut nous ralentir est lié la complexité du domaine traité et aux différentes contraintes à respecter.

Tableau 1 Backlog-Product

Nom Description Thème1 Risque Priorité

Mettre les En tant qu’étudiant Thème 1 : Bas Haute


ressources en je veux des Application de la
ligne supports de cours pédagogie Active
numériques
déposés en ligne

Relation avec les En tant qu’étudiant Thème 2 : Moyen Moyenne


professionnels j’ai besoin de Partenariat avec les
communiquer avec entreprises
des experts de
domaine

Etablir des En tant qu’étudiant Thème 2 Moyen Haute


formations j’ai besoin de
professionnelles formations
professionnelles
qui appliquent la
théorie

Améliorer la En tant qu’étudiant Thème 3 : Relation Moyen Moyenne


tâche j’ai besoin de plus Enseignant-Etudiant
d’encadrement d’encadrement et
de suivi

Intégration des En tant qu’étudiant Thème 4 : Bas Moyenne


étudiants au sein j’ai besoin de Implication des
des groupes travail en groupe étudiants

Réalisation des En tant qu’étudiant Thème 4 Moyen Haute


travaux dirigés j’ai besoin
d’appliquer la
théorie

Meilleure En tant qu’étudiant Thème 2 Haut Moyenne


Intégration à la j’ai besoin
vie d’améliorer

1
Thème : c’est la traduction du mot « features » selon Claude Aubry
Nom Description Thème1 Risque Priorité

professionnelle l’insertion
professionnelle

Motiver les En tant qu’étudiant Thème 2 Haut Basse


étudiants j’ai besoin d’avoir
des stages payants
pour me motiver

Optimiser le En tant qu’étudiant Thème 5 : Gérer Moyen Moyenne


nombre d’heures j’ai besoin de l’emploi du temps
d’enseignement minimiser le
volume horaire

Utilisation des En tant qu’étudiant Thème 1 Moyen Haute


outils j’ai besoin que
d’enseignement l’enseignant utilise
innovants des outils
d’enseignement
innovants
Etre objectif au En tant qu’étudiant Thème 3 Bas Moyenne
niveau des j’ai besoin que
séances des cours l’enseignant
minimise
l’ouverture des
parenthèses

Mettre en ligne la En tant qu’étudiant Thème 1 Moyen Moyenne


bibliothèque j’ai besoin d’avoir
universitaire une bibliothèque
universitaire en
ligne riche

Enrichir la En tant qu’étudiant Thème 5 Moyen Haute


formation avec j’ai besoin d’avoir
des stages des stages
professionnels en
parallèle avec ma
formation
théorique.

Implanter la En tant qu’étudiant Thème 2 Moyen Moyenne


culture j’ai besoin
d’entreprenariat d’implanter la
culture
d’entreprenariat.

Participer à la vie En tant qu’étudiant Thème 4 Moyen Haute


associative j’ai besoin de
participer à des
clubs pour me
motiver et
améliorer mon
esprit de groupe et
de vie associative.

Avoir des En tant qu’étudiant Thème 2 Moyen Moyenne


formations je veux des
certifiées formations
professionnelles
certifiées.

Organiser des En tant qu’étudiant Thème 4 Elevé Haute


compétitions je veux avoir
l’organisation des
Nom Description Thème1 Risque Priorité

compétitions au
niveau de la
réalisation des
mini-projets pour
motiver les
étudiants

Offrir des stages à En tant qu’étudiant Thème 2 Elevé Moyenne


l’étranger je veux avoir des
stages à l'étranger
pour l'échange de
cultures et de
méthodes de
travail

Etablir des En tant qu’étudiant Thème 2 Elevé Moyenne


protocoles je veux établir des
d’échange Echanges
d’étudiants d'étudiants
interuniversitaires.

Organiser des En tant qu’étudiant Thème 2 Elevé Moyenne


voyages je veux organiser
des voyages pour
améliorer les
niveaux
linguistiques et
l'échange des
cultures

Prévoir des En tant qu’étudiant Thème 1 Bas Haute


évaluations je veux que les
claires et critères
objectives d’évaluation soient
clairs et objectifs

Mettre en œuvre En tant qu’étudiant Thème 1 Moyen Haute


des supports de j’ai besoin d’un
cours clairs et support de cours
actualisés clair et actualisé

Améliorer l’esprit En qu’étudiant j’ai Thème 4 Moyen Haute


d’initiative besoin d’améliorer
mon esprit
d’initiative

Améliorer la En tant qu’étudiant Thème 4 Elevé Haute


capabilité d’auto- j’ai besoin de
apprentissage prendre des
chez l’étudiant décisions et des
risques

Echange de En tant qu’étudiant Thème 4 Bas Haute


l’information j’ai besoin
d’échanger
l’information

Implantation d’un En tant Thème 1 Bas Haute


site collectif du qu’enseignant j’ai
cours besoin d’établir un
site collectif de
cours
Nom Description Thème1 Risque Priorité

Collaboration En tant Thème 6 : Relation Moyen Moyenne


entre enseignants qu’enseignant je Enseignant-
veux améliorer la Enseignant
collaboration entre
les enseignants

Utilisation des En tant Thème 1 Elevé Haute


outils qu’enseignant j’ai
d’enseignement besoin d’outils
innovants pédagogiques
innovants

Pénaliser les En tant Thème 3 Bas Moyenne


étudiants qu’enseignant je
indisciplinés veux pénaliser les
étudiants
indisciplinés

Avoir des En tant Thème 2 Elevé Moyenne


formations qu’enseignant j’ai
certifiées besoin de
certifications

Organiser des En tant Thème 1 Elevé Moyenne


formations qu’enseignant j’ai
continues pour besoin de
enseignants formation continue

Participer En tant Thème 1 Elevé Moyenne


l’enseignant à des qu’enseignant j’ai
stages de besoin de stage de
recherche ou recherche ou
appliqué appliqué

Suivi de la En tant Thème 7 : Mettre les Elevé Haute


finalisation des qu’administration protocoles
cours je veux finaliser d’organisation du
les formations processus
d’enseignement
Suivi de En tant Thème 7 Elevé Moyenne
l’évolution de qu’administration
l’apprentissage j’ai besoin
d’évoluer
l’apprentissage

Suivi de la En tant Thème 7 Bas Haute


discipline des qu’administration
enseignants je veux des
enseignants
disciplinés

Suivi de la En tant Thème 7 Bas Haute


discipline des qu’administration
enseignants je veux des
étudiants
disciplinés

Améliorer les En tant Thème 7 Elevé Moyenne


résultats qu’administration
j’ai besoin
d’améliorer les
Nom Description Thème1 Risque Priorité

résultats

4 Planification des Sprints


La réunion de planification des sprints est l’événement le plus important dans Scrum. Suite à cette réunion, il faut préparer le
planning de travail et identifier le backlog des sprints2. L’un des produits de cette réunion est le choix de la durée des sprints
et qui diffère selon la complexité du projet et la taille de l’équipe. Pour notre projet nous avons choisi de développer deux
releases. Le premier sera nommé scénariser le processus d’enseignement et le second sera pour la gestion de la pédagogie
d’enseignement à implanter.

5 Release 1 : « Scénariser le processus d’enseignement »


Notre premier release sera composé de trois sprints. Tous au long de cette partie, nous allons traiter les histoires utilisateurs
de nos sprints pour produire un incrément potentiellement livrable.

Le premier sprint « Mettre les protocoles d’organisation du processus d’enseignement »

Ce sprint se résume au niveau de Tableau 2.

Tableau 2 Backlog-Sprint "Mettre les protocoles d'organisation du processus d'enseignement"

Histoire utilisateur
Suivi de la finalisation des cours
Suivi de l’évolution de l’apprentissage
Suivi de la discipline des enseignants
Suivi de la discipline des enseignants
Améliorer les résultats

Le Deuxième sprint «Partenariat avec les entreprises »

Ce sprint se résume au niveau de Tableau 3

Tableau 3 Backlog-Sprint « Partenariat avec les entreprises »

Histoire utilisateur
Relation avec les professionnels
Etablir des formations professionnelles
Implanter la culture d’entreprenariat
Avoir des formations certifiées
Offrir des stages à l’étranger
Etablir des protocoles d’échange d’étudiants
Organiser des voyages

2
Backlog du sprint : c’est l’ensemble des user story inclus dans le sprint
Le Troisième sprint « Gérer l’emploi du temps »

Ce sprint se résume au niveau du Tableau 4.

Tableau 4 Backlog-Sprint « Gérer l’emploi du temps »

Histoire utilisateur
Optimiser le nombre d’heures d’enseignement
Enrichir la formation avec des stages

6 Release 2 : « gestion de la pédagogie d’enseignement à implanter »


Notre deuxième release sera composé de quatre sprints. Tous au long de cette partie, nous allons traiter les histoires
utilisateurs de nos sprints pour produire un incrément potentiellement livrable.

Le premier sprint « Application de la pédagogie active »

Ce sprint se résume au niveau du Tableau 5.

Tableau 5 Backlog-sprint « Application de la pédagogie active »

Histoire utilisateur
Mettre les ressources en ligne
Utilisation des outils d’enseignement innovants
Mettre en ligne la bibliothèque universitaire
Utilisation des méthodes d’enseignement innovantes
Prévoir des évaluations claires et objectives
Mettre en œuvre des supports de cours clairs et actualisés
Implantation d’un site collectif du cours

Utilisation des outils d’enseignement innovants

Organiser des formations continues pour enseignants


Participer l’enseignant à des stages de recherche ou appliqué

Le deuxième sprint « Relation Enseignant-Etudiant»

Ce sprint se résume au niveau du Tableau 6.

Tableau 6 Backlog-Sprint "Relation Enseignant-Etudiant"

Histoire utilisateur
Suivi de la finalisation des cours
Suivi de l’évolution de l’apprentissage
Suivi de la discipline des enseignants
Suivi de la discipline des enseignants
Améliorer les résultats
Le troisième sprint «Implication des étudiants»

Ce sprint se résume au niveau du Tableau 7.

Tableau 7 Backlog-Sprint "Implication des étudiants"

Histoire utilisateur
Améliorer la tâche d’encadrement
Etre objectif au niveau des séances des cours
Pénaliser les étudiants indisciplinés

Le quatrième sprint «Relation Enseignant-Enseignant»

Ce sprint se résume au niveau du Tableau 8

Tableau 8 Backlog-Sprint "Relation Enseignant-Enseignant"

Histoire utilisateur
Collaboration entre enseignants

Les activités et le cycle de développement

Au niveau de chaque partie release, nous sommes invités à mettre le vif de notre sujet : les activités et le cycle de
développement. Pour chaque sprint nous pouvons dégager quatre activités principales qui sont la spécification fonctionnelle,
la conception, le codage et le test.

 Spécification fonctionnelle
Consiste à identifier les cas d’utilisation présents au niveau d’un sprint, avec la schématisation du diagramme cas
d’utilisation, tout en présentant une description textuelle détaillée pour chaque cas.
 Conception

La conception est la deuxième activité dans un sprint. Elle se traduit par le diagramme de séquence, le diagramme
des classes participantes et le diagramme de classe d’UML.

o Diagramme de séquence système

Ce diagramme permet de présenter les interactions entre l’acteur et le système avec des messages
présentés dans un ordre chronologique. Le digramme de séquence système traite le système comme étant
une boite noire. Le comportement du système est décrit vu de l’extérieur sans avoir d'idée sur comment il
le réalisera.

o Diagramme des classes participantes

Le diagramme de classe est l’un des diagrammes statiques d'UML. Il permet de décrire la structure d'un
système tout en montrant les différentes classes, leurs attributs, leurs méthodes ainsi que les relations
entre eux. Tout au long de nos sprints, nous essayerons de construire ce diagramme au fur et mesure en
ajoutant les différentes classes déduites.

 Codage

Les travaux menés dans cette activité se résument tout simplement dans l’implémentation et la réalisation des
histoires utilisateurs analysés lors des étapes précédentes.

 Test
Le test est un processus manuel ou automatique, qui vise à établir qu’un système vérifie les propriétés exigées par
sa spécification, ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus
par la spécification. (Définition issue de la norme IEEE-STD729, 1983).

Les activités de test constituent un axe très important dans le cycle de réalisation d’un projet. Ils permettent de
détecter les erreurs afin de les corriger et d’assurer la qualité du logiciel fourni.

Contrairement aux cycles de développement séquentiel3, avec la méthodologie agile, le test n'est pas une phase qui
se déroule après la fin de développement. En effet, les tests seront intégrés dès le début du premier sprint jusqu’à la
livraison du produit final. En outre, la qualité du logiciel n’est pas négligeable, c’est dans ce cadre que Scrum doit
être complété par les bonnes pratiques d’ingénierie techniques du logiciel. Parmi ces pratiques 4, seulement deux qui
nous intéressent et qui sont le pilotage par les tests (TDD, Test Driven Developement) centrés sur les tests unitaires,
et le pilotage par les tests d’acceptation (ATDD, Acceptance Test Driven Development).

o Les tests unitaires

Le principe de cette pratique est d’écrire les tests avant même d’entamer la réalisation du sprint et de
profiter par la suite de l’existence des tests automatiques pour l’amélioration et le remaniement du code.
Cette technique permet aux équipes de travail de rester simples au niveau de l’implémentation et de
s’assurer de son bon fonctionnement après des changements.

o Les tests d’acceptation

Le test d'acceptation est un processus qui permet d'accepter une histoire utilisateur à la fin du sprint.
L’écriture des tests d'acceptation passe par quatre étapes comme le montre la Figure 2.

Figure 2 : Les étapes d'écriture du test d'acceptation

7 La phase closure
La phase closure ou de fermeture est la dernière phase dans le cycle de conduite d’un projet avec Scrum. Cette phase est
souvent appelée sprint de stabilisation [6]. Les tâches effectuées pendant cette phase ne sont pas claires, et ils dépendent
fortement du type de projet.

Pour notre projet, cette sera consacré pour la présentation des matériels, méthodes et outils utilisés pour remédier à notre
problématique « Améliorer les méthodes d’enseignement ».

8 Reference
[1] C. Aubry, SCRUM le guide pratique de la méthode agile la plus populaire, Dunod, 2010.

[2] Th. G. Cros, Priorité, Valeur ajoutée et urgence des user stories, Thierry Cros Organisation, 2009.

[3] K. Schwaber, J. Sutherland, Le Guide Complet de Scrum: Les Règles du Jeu, 2011.

[4] Swiners, J.,L., Briet, J.,M., L’intelligence créative au-delà du brainstorming, Édition Maxima, 2004.

3
Ce sont les méthodologies dont les activités de développement (spécification, conception, codage et test) se
déroulent séquentiellement notamment le modèle en cascade ou en V. (Nommage de Claude Aubry)
4
Les pratiques les plus connues sont : l’intégration continue, la programmation en binôme, etc.