Penser Agile, SCRUM, pour la Gestion de Projet : « Améliorer les méthodes d’enseignement »

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.

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,

• 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

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 , je veux afin de

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

• 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

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).

Backlog-Product

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

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.

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

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

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)

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

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.

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.