Penser Agile, SCRUM, pour la Gestion de Projet :
« Améliorer les méthodes d’enseignement »
Houda Nakkach 1, Nadia Hachani 2
1ISET Charguia, Tunisie 2ISET 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.
User-stories [2]
Figure 1 : Le processus Scrum
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.
Publicité
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 ressources en ligne
Relation avec les professionnels
Etablir des formations professionnelles
Améliorer la tâche d’encadrement
En tant qu’étudiant je des veux supports de cours numériques déposés en ligne
En tant qu’étudiant j’ai de besoin communiquer avec des de experts domaine
En tant qu’étudiant j’ai de besoin formations professionnelles qui appliquent la théorie
En tant qu’étudiant j’ai besoin de plus d’encadrement et de suivi
Thème 1 : Application de la pédagogie Active
Bas
Haute
Thème 2 : Partenariat avec les entreprises
Moyen
Moyenne
Thème 2
Moyen
Haute
Thème 3 : Relation Enseignant-Etudiant
Moyen
Moyenne
Intégration des étudiants au sein des groupes
En tant qu’étudiant de besoin j’ai travail en groupe
Thème 4 : Implication des étudiants
Bas
Moyenne
Réalisation des travaux dirigés
En tant qu’étudiant besoin j’ai la d’appliquer théorie
Meilleure Intégration à la vie
En tant qu’étudiant j’ai besoin d’améliorer
Thème 4
Moyen
Haute
Thème 2
Haut
Moyenne
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 étudiants
Optimiser le nombre d’heures d’enseignement
Utilisation des outils d’enseignement innovants
Etre objectif au niveau des séances des cours
Mettre en ligne la bibliothèque universitaire
Enrichir la formation avec des stages
Implanter la culture d’entreprenariat
Participer à la vie associative
Avoir des formations certifiées
Organiser des compétitions
En tant qu’étudiant j’ai besoin d’avoir des stages payants pour me motiver
En tant qu’étudiant de j’ai besoin minimiser le volume horaire
En tant qu’étudiant j’ai besoin que l’enseignant utilise des outils d’enseignement innovants En tant qu’étudiant j’ai besoin que l’enseignant minimise l’ouverture parenthèses
des
En tant qu’étudiant j’ai besoin d’avoir bibliothèque une universitaire en ligne riche
En tant qu’étudiant j’ai besoin d’avoir des stages professionnels en parallèle avec ma formation théorique.
En tant qu’étudiant besoin j’ai d’implanter la culture d’entreprenariat.
En tant qu’étudiant j’ai de besoin participer à des pour me clubs et motiver améliorer mon esprit de groupe et de vie associative.
En tant qu’étudiant je des veux formations professionnelles certifiées.
En tant qu’étudiant je avoir l’organisation des
veux
Thème 2
Haut
Basse
Thème 5 : Gérer l’emploi du temps
Moyen
Moyenne
Thème 1
Moyen
Haute
Thème 3
Bas
Moyenne
Thème 1
Moyen
Moyenne
Thème 5
Moyen
Haute
Thème 2
Moyen
Moyenne
Thème 4
Moyen
Haute
Thème 2
Moyen
Moyenne
Thème 4
Elevé
Haute
Nom
Description
Thème1
Risque
Publicité
Priorité
au compétitions la niveau de réalisation des mini-projets pour motiver les étudiants
En tant qu’étudiant je veux avoir des stages à l'étranger pour l'échange de de cultures de méthodes travail
et
En tant qu’étudiant je veux établir des Echanges d'étudiants interuniversitaires.
En tant qu’étudiant je veux organiser des voyages pour améliorer les niveaux linguistiques l'échange cultures
et des
En tant qu’étudiant je veux que les critères d’évaluation soient clairs et objectifs
En tant qu’étudiant j’ai besoin d’un support de cours clair et actualisé
En qu’étudiant j’ai besoin d’améliorer mon esprit d’initiative
En tant qu’étudiant j’ai besoin de prendre des décisions et des risques
En tant qu’étudiant j’ai besoin d’échanger l’information
En tant qu’enseignant j’ai besoin d’établir un site collectif de cours
Offrir des stages à l’étranger
Etablir des protocoles d’échange d’étudiants
Organiser des voyages
Prévoir des évaluations claires et objectives
Mettre en œuvre des supports de cours clairs et actualisés
Améliorer l’esprit d’initiative
Améliorer la capabilité d’auto- apprentissage chez l’étudiant
Echange de l’information
Implantation d’un site collectif du cours
Thème 2
Elevé
Moyenne
Thème 2
Elevé
Moyenne
Thème 2
Elevé
Moyenne
Thème 1
Bas
Haute
Thème 1
Moyen
Haute
Thème 4
Moyen
Haute
Thème 4
Elevé
Haute
Thème 4
Bas
Haute
Thème 1
Bas
Haute
Nom
Description
Thème1
Risque
Priorité
Collaboration entre enseignants
Utilisation des outils d’enseignement innovants
Pénaliser les étudiants indisciplinés
Avoir des formations certifiées
En tant qu’enseignant je veux améliorer la collaboration entre les enseignants
En tant qu’enseignant j’ai besoin d’outils pédagogiques innovants
En tant qu’enseignant je veux pénaliser les étudiants indisciplinés
En tant qu’enseignant j’ai besoin de certifications
Organiser des formations continues pour enseignants
En tant qu’enseignant j’ai besoin de formation continue
Participer l’enseignant à des stages de recherche ou appliqué
En tant qu’enseignant j’ai besoin de stage de recherche ou appliqué
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
En tant qu’administration je veux finaliser les formations
En tant qu’administration j’ai besoin d’évoluer l’apprentissage
En tant qu’administration je veux des enseignants disciplinés
En tant qu’administration je veux des étudiants disciplinés
En tant qu’administration j’ai besoin d’améliorer les
Thème 6 : Relation Enseignant- Enseignant
Moyen
Moyenne
Thème 1
Elevé
Haute
Thème 3
Bas
Moyenne
Thème 2
Elevé
Moyenne
Thème 1
Elevé
Moyenne
Thème 1
Elevé
Moyenne
Thème 7 : Mettre les protocoles d’organisation du processus d’enseignement Thème 7
Elevé
Haute
Elevé
Moyenne
Thème 7
Bas
Haute
Thème 7
Bas
Haute
Thème 7
Elevé
Moyenne
Nom
Description
Publicité
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
2Backlog 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"
Collaboration entre enseignants
Histoire utilisateur
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 pratiques4, 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.