Un aperçu de Scrum pour néophyte …
Au cours d’une mission, j’ai été confronté à l’utilisation de Scrum comme méthodologie de projets. Suite à cette première expérience qui m’a parut satisfaisante, j’ai eu l’envie de partager ce que j’ai pu apprendre et comprendre pour en faire profiter d’autres qui n’ont pas eu ce privilège.
L’objectif de ce billet se résume en deux points :
- Conserver le souvenir de cette expérience, et mettre en avant ma vision de ce que j’ai pu vivre et ressentir au cours de cette période
- Faire partager et mettre à profit cette connaissance. J’espère donner envie de s’intéresser au sujet, et pourquoi pas, de remettre parfois en cause certaines autres méthodes toujours adoptées sans vraiment pouvoir comparer
Un aperçu de Scrum pour néophyte …
- SCRUM
- En aparté
- Références
MÉTHODES AGILES
Avec un cycle de développement classique, nous nous retrouvons toujours face à un contrat liant un Client, à la Maîtrise d’Ouvrage (MOA / AMOA) et à la Maîtrise d’Œuvre (MOE). Le client émet son besoin et fixe ses contraintes de temps et d’argent. La MOA joue le rôle de traducteur entre le Client et la MOE, en fournissant des documents tels que l’ « Expression de besoin » ou le « Cahier des Charges Fonctionnelles ». La MOE conçoit, réalise, recette et livre le projet.
Dans le meilleur des mondes, tout le monde sera content à la date fixée par le Client … seulement …
Le Client va faire évoluer son besoin, si ce n’est complètement le changer. Mais les contraintes temporelles, elles, seront toujours là et déjà bien entamées. La MOA, tiraillée de tous côtés, cherchera tant bien que mal à rééquilibrer le projet, en ajoutant, supprimant, modifiant certaines fonctionnalités. La MOE se justifiera par rapport au contrat initial.
Au final, le budget et la date de livraison seront revus à la hausse, le produit final ne sera pas à l’image du contrat initial, mais ne correspondra pas non plus aux attentes du Client. On repartira, alors, sur un nouveau contrat d’évolutions ou de mise à jour, dans un climat très tendu.
Là où le cycle de développement classique manque de souplesse, la méthodologie agile en injecte.
En effet, les méthodes Agiles permettent de concevoir des applications ou sites Web en impliquant au maximum le Client à toutes phases du projet. Ces méthodes cherchent à satisfaire au mieux le réel besoin de celui-ci grâce à une grande réactivité face à ses demandes. De cette idée, il en est sortit 4 grands principes, qui ont donnés naissance au Manifeste Agile, qui sera repris plus tard comme étant la clé de voûte des Méthodes Agiles.
Le manifeste Agile
C’est en 2001, aux États-Unis, que 17 figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles.
Les plus connus d’entre eux étaient Ward Cunningham l’inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l’extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l’ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Développement rapide d’applications).
Ces 17 experts venant tous d’horizons différents réussirent à extraire de leurs concepts respectifs des critères pour définir une nouvelle façon des développer des logiciels. De cette réunion devait émerger le Manifeste Agile (ou Agile Manifesto), considéré comme la définition canonique du développement Agile et de ses principes sous-jacents.
| Nous découvrons de nouvelles façons de développer les logiciels en pratiquant et en aidant les autres à pratiquer. De ce fait nous avons déduit des valeurs communes :
Autrement dit, alors que nous accordons une certaine valeur aux items de droite, nous en donnons plus à ceux de gauche. |
| Version originale : https://agilemanifesto.org/ |
En d’autres mots, les méthodes Agiles prônent donc les quatre valeurs suivantes :
- L’équipe (« Les personnes et leurs interactions, plutôt que les processus et les outils ») :
Dans l’optique agile, l’équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d’avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu’une équipe composée d’individualistes, même brillants. La communication est une notion fondamentale.
- L’application (« Un logiciel opérationnel, plutôt que des documentations exhaustives ») :
Il est vital que l’application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n’est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l’équipe (on en revient à l’importance de la communication).
- La collaboration (« La collaboration effective avec le Client, plutôt que les négociations de contrats ») :
Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes.
- L’acceptation du changement (« Répondre et accueillir les changements, plutôt que suivre le plan projet ») :
La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l’évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d’évolutions.
Principes de la méthodologie Agile
Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :
|
| Version originale : https://agilemanifesto.org/principles.html |
SCRUM en 100 mots
SCRUM est une méthodologie AGILE. Elle vise à satisfaire au mieux le besoin du PRODUCTOWNER en l’impliquant aux différentes phases du projet. Celui-ci est responsable du PRODUCT BACKLOG, liste priorisée des USERS STORIES. Lors du SPRINT PLANNING, le PRODUCT OWNER, le SCRUM MASTER et la TEAM définissent le SPRINT BACKLOG que la TEAM s’engage à réaliser au cours du SPRINT. Au quotidien, le SCRUM MASTER se réunit avec la TEAMpour le DAILY SCRUM et la BURN DOWN CHART est mise à jour. La TEAM conclut le SPRINT par une DEMO du travail réalisé, puis une un SPRINT REVIEW.
[/caption]
SCRUM
SCRUM est une méthodologie Agile, vous l’aurez compris. Elle se doit alors de respecter les quatre valeurs principales, ainsi que leurs douze principes sous-jacents. Mais ceci n’est que la base sur laquelle Scrum se repose. Cette méthodologie possède trois familles d’éléments utiles au quotidien afin de mieux avancer dans nos projets : les rôles, les réunions et les artefacts. Chacune de ces familles possède 3 éléments.
Les rôles
On s’attendrait à voir dans cette partie, les notions de Développeurs, Architectes, Chef de Projet, Responsable, MOA, MOE, Administrateurs de Bases de Données, Testeurs et j’en passe. Vous l’aurez compris, avec Scrum, on met tout cela de côté. Pour faire simple, je citerai le blog de Frédéric Doillon:
Il n’y a que trois rôles dans scrum, chaque rôle portant une responsabilité bien défini, sans chevauchement néfaste à la clarté des missions de chacun : l’équipe, le scrum master, le product owner.
La responsabilité de l’équipe est de produire.
La responsabilité du scrum master est d’assurer le suivi de la méthode.
La responsabilité du product owner est de créer de la valeur.
Chacun des rôles est complémentaire aux deux autres. Sans équipe, le scrum master ne sert strictement à rien, et le meilleur product owner du monde ne créera aucune valeur. Mais sans product owner, le scrum master aura beau être un super héros, animant une équipe de tueurs, le risque est grand de produire au mauvais moment un software qui ne servira à rien. Enfin, un product owner visionnaire ne sera pas d’une grande aide à l’équipe si le scrum master fait défaut : retard, désillusion, mal-être…
En résumé, un « bon » projet scrum, c’est une équipe de tueurs, animés par un super héros, travaillant pour un visionnaire !
Le directeur de produit
Le directeur de produit, aussi appelé « product owner », représente le client et les utilisateurs. C’est lui qui prend toutes les décisions importantes à propos de l’orientation du projet et notamment, c’est lui qui doit prioriser les fonctionnalités métiers qui seront développées et maintenir à jour cette liste. Il est important qu’il reste très disponible pour répondre aux questions de l’équipe et pour valider / rejeter les résultats attendus.
Le scrum master
Le Scrum master n’est pas un chef de projet. On pourrait plutôt le voir comme un « Coach ». Son but est d’assurer le suivi de la méthode comme indiqué plus haut, mais il a bien sur d’autres rôles. Il protège l’équipe des éléments perturbateurs extérieurs et l’aide à résoudre ses problèmes non techniques. C’est lui aussi qui va s’assurer de l’efficacité fonctionnelle de l’équipe, de sa productivité et donc émettre les différentes résolutions possible en cas de problèmes.
L’équipe SCRUM
L’équipe Scrum, ou la « Team », s’occupe de la partie technique. Elle est composée de 5 à 9 membres maximum. Elle doit s’autogérer … en fait, mieux que ça, au sein de l’équipe personne n’a rôle désigné. Bien entendu, l’expérience technique passée d’un membre de l’équipe va aider et influencer la répartition des tâches au quotidien, mais personne ne doit être confiné dans son coin à développer sa partie. En Scrum, toute l’équipe avance ensemble et au même rythme sur le même front.
Les réunions et les artefacts
Il me parait difficile de séparer les réunions des artefacts tant les uns impliquent les autres.
Nous savons maintenant que trois grands rôles vont prendre part à la vie du projet. Scrum offre à chacun des outils ou documents qui vont contribuer orienter et faire avancer le projet en plusieurs phases itératives appelées Sprint. Un Sprint ? C’est une période de 2 à 4 semaines durant laquelle l’équipe va développer une partie du projet et au bout de laquelle il y aura un livrable. Ce livrable sera présenté lors d’une démo en fin de sprint. Mais revenons tout d’abord au lancement du projet.
Artefact #1 : Le Backlog de produit
Nous avons vu que le directeur de produit est en charge de lister et prioriser les fonctionnalités métiers à développer. Cette liste de tâches est appelé « Product Backlog » (ou backlog de produit). Chaque élément de la liste est appelé « User Stories ». C’est une unité fonctionnelle qui peut être directement livrée au client.
Le Product Backlog définit avec une multitude de User Stories les exigences fonctionnelles du produit à livrer.
Cette liste peut être réalisée lors d’une réunion de lancement de projet avec les principaux intéressés. Ceci permet en général d’ouvrir les discussions autour du projet et de mieux définir le besoin. Les priorités sont définies initialement par le directeur de projet et elles sont revues à chaque début de sprint.
| Priorité | # N° | User Stories |
| 1.0 | 0001 | En tant qu’utilisateur, j’ai accès à un site via une URL donnée. |
| 2.0 | 0002 | En tant qu’utilisateur connecté, je peux modifier mon mot de passe. |
| 3.0 | 0003 | En tant qu’administrateur, je peux créer un nouvel utilisateur. |
| 1.1 | 0004 | En tant qu’utilisateur, je peux m’identifier sur le site et obtenir un profil spécifique. |
| … | … | … |
Dans la pratique, les user stories sont notées sur des Post-It et ils sont positionnés sur un mur ou sur un tableau. L’idée étant d’avoir une vision globale, et en même temps ponctuelle, de ce qui fait, ce qui est en cours et ce qui reste à faire, et de pouvoir facilement manipuler ces user stories tout au long du projet.
Il y a également plusieurs offres logicielles permettant de gérer tout cela numériquement.
Réunion #1 : La planification du Sprint
La planification du sprint a pour but de spécifier quel va être l’aboutissement de celui-ci. L’équipe, son scrum master et le directeur de projet vont alors sélectionner des user stories du backlog de produits. L’équipe va s’engager à livrer pour la fin du sprint toutes les user stories sélectionnées. Cette réunion ne doit pas durer plus de deux heures.
Nous arrivons au moment le plus divertissant de la planification, le Planning Poker !
Chacune des user stories vont être estimées en « User Story Points ». C’est une notation abstraite qui sera propre à chaque projet. Chaque personne dispose d’un jeu de carte un peu spécial composé de 9 cartes avec les valeurs de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55), ou plus simplement les valeurs 1, 2, 3, 5, 8, 13, 20, 50, 100. Certains rajoutent des cartes 0 et 0.5. D’autres, des cartes à usage unique « Pause Café », ou « Joker ».
Le directeur de produit va expliquer une user story sortie du backlog de produit selon la priorité qu’il aura défini. Tout le monde va pouvoir demander des explications et réagir sur la fonction qu’elle doit remplir. Une fois qu’elle sera claire et comprise de tous, chaque participant va évaluer individuellement cette user story et retourner devant lui la carte correspondant au nombre de user story points qu’il souhaite affecter à cette tâche.
Evidement, il sera rare que tout le monde donne la même estimation, et donc les extrémités vont expliquer aux autres leurs choix. Dès lors, tous les participants vont estimer de nouveau la tâche, et l’opération se répètera tant que l’unanimité ne sera pas votée.
L’avantage est simple à comprendre … le dialogue est facilité. Tout le monde va pouvoir s’exprimer clairement et simplement sur sa propre vision.
Certaines user stories vont être sélectionnées pour le sprint, d’autres vont être laissées de côté pour un sprint suivant. Les user stories sélectionnées devront être réalisées pour la fin de ce sprint. On appelle « vélocité » le nombre de user story points qu’une équipe est capable de réaliser par sprints.
| # N° | User Stories | U.S.Pts |
| 0001 | En tant qu’utilisateur, j’ai accès à un site via une URL donnée. | 1 |
| 0004 | En tant qu’utilisateur, je peux m’identifier sur le site et obtenir un profil spécifique. | 3 |
| 0002 | En tant qu’utilisateur connecté, je peux modifier mon mot de passe. | 2 |
Les user story points sont reportés sur les différents post-it définissant les user stories afin de toujours avoir à l’esprit leurs poids les unes par rapports aux autres.
Artefact #2 : Le Backlog de sprint
Le « Sprint Backlog » (ou backlog de sprint) est constitué des user stories qui ont été sélectionnées et estimées lors du « Sprint Planning ». Mais pour le backlog de sprint, nous allons plus loin. Ces user stories aussi sont découpées en petites tâches indivisibles (métier ou non) et elles sont estimés en heures.
Ces tâches ne sont pas tout de suite réparties au sein de l’équipe, chaque membre, selon son envie, son humeur va décider avec les autres de ce qu’il souhaite faire au fur et à mesure. Tous les jours, le backlog de sprint est remis à jour par le scrum master au cours des « Daily Scrum ».
| #0001 – En tant qu’utilisateur, j’ai accès à un site via une URL donnée. – 1 USP | ||
| # N° | Tâches | Durée (h) |
| 0001-01 | Demander à Roland (l’administrateur réseau) de créer le DNS, et le faire pointer sur le bon répertoire … | 0.5 |
| 0001-02 | Créer une ébauche de page d’accueil pour notre site | 0.5 |
| 0001-03 | Publier la page dans le site d’exploitation | 0.5 |
| 0001-04 | Tester le bon fonctionnement | 0.5 |
| #0004 – En tant qu’utilisateur, je peux m’identifier sur le site et obtenir un profil spécifique. – 3 USP | ||
| # N° | Tâches | Durée (h) |
| 0004-01 | Définir la structure de la base de données | 2 |
| 0004-02 | Créer la base de données | 1 |
| 0004-01 | Créer le formulaire | 1.5 |
| 0004-04 | Implémenter les requêtes liant le formulaire à la base de données | 0.5 |
| 0004-05 | Tester le bon fonctionnement | 1 |
| #0002 – En tant qu’utilisateur connecté, je peux modifier mon mot de passe. – 2 USP | ||
| # N° | Tâches | Durée (h) |
| 0002-01 | Créer le formulaire | 2 |
| 0002-02 | Implémenter les requêtes liant le formulaire à la base de données | 0.5 |
| 0002-03 | Tester le bon fonctionnement | 1.5 |
Ces tâches et leurs estimations en heure sont reportées sur des post-it d’une autre couleur. Elles sont placées sous la user story auxquelles elles appartiennent.
Réunion #2 : Les scrums au quotidien
Le daily scrum se fait à chaque début de journée. Il doit durer au maximum 15 minutes. Cette réunion se déroule face au mur portant les user stories, ce qui permet d’avoir un œil sur le sprint en cours. Tous les participants directs (directeur de produit, équipe et scrum master), debout afin que la réunion ne s’éternise pas, vont répondre tour à tour aux questions suivantes :
- Qu’est-ce que j’ai fait hier ?
- Quels sont les problèmes que je rencontre ou que j’ai résolus ?
- Qu’est-ce que je vais faire aujourd’hui ?
Ceci a pour but de tenir informé tous les participants afin que personne ne s’isole dans son coin. En Scrum, on avance, oui, mais on avance en groupe.
Pour terminer le daily scrum, le backlog de sprint est mis à jour : les tâches terminées sont retirées ou déplacées, les durées mises à jour.
Il est courant de retrouver sur notre mur portant les user stories trois colonnes dans lesquelles nos post-it sont triés : A faire, En cours, Terminés.
Le graphe de charge de travail restant est également mis à jour.
Artefact #3 : Le graphe de charge de travail restant
Le graphe de charge de travail restant, ou plutôt la « Sprint Burndown Chart », est une visualisation graphique du temps de travail restant sur le sprint en cours. Il représente le nombre d’heures totales restant à faire au cours du sprint, au jour le jour, et permet ainsi de suivre son bon avancement.
Il existe également la « Release Burndown Chart » qui permet de suivre sprint par sprint le nombre de user story points restant avant la fin du projet. Elle est mise à jour lors de chaque sprint planning. Cependant, ce graphique n’est possible que si toutes les user stories du backlog de produit ont été estimées en user story points.
Ces graphes sont également positionnés sur le mur auprès des post-it.
Réunion #3 : Le compte-rendu de sprint
La fin du sprint arrive, c’est l’heure pour l’équipe de faire une démo des user stories réalisées. Tout le monde peut-être invité à cette réunion qui ne doit pas dépasser deux heures … et dont la préparation ne doit pas durer plus de trente minutes. Cette démo a pour but de ne pas s’isoler et de montrer à un maximum de personnes l’avancement du projet. Le directeur de produits va pouvoir valider les user stories terminées. C’est à ce moment là aussi qu’il va pouvoir commencer à remettre en question la priorisation des user stories du backlog de produits. Lors de cette démo, tout le monde peut prendre la parole et ainsi débuter des échanges d’idées et de points de vue. Le dialogue est encore une fois facilité.
Suite à la démo, et à la fin du sprint, l’équipe de développement et son scrum master vont pouvoir débriefer lors de la rétrospective de sprint. Celle-ci vise à tirer des leçons de ce qui s’est passé tout au long du sprint. Chacun tour à tour va répondre aux questions :
- Quels sont les points positifs me concernant lors de ce sprint ?
- Quels sont les points négatifs me concernant lors de ce sprint ?
- Quels sont les points à améliorer qu’ils soient individuels ou collectifs ?
En aparté
Scrum implique au cœur du projet le directeur de produit. Ceci permet d’accueillir au mieux les changements pendant la phase de réalisation. Cependant, ceci induit une disponibilité accrue du directeur de produit ce qui n’est pas toujours la chose la plus simple.
Scrum propose, par itérations, ou au jour le jour, plusieurs outils permettant de suivre l’état d’avancement des tâches et plus généralement du projet avec des versions partiellement utilisables. C’est un point positif pour lutter contre le fameux et redouté de plus d’un chef de projet : l’effet tunnel. Pour des projets plus volumineux, il est possible également de gérer des « Release ». Ce sont des successions de Sprint, qui permettent de fournir à leurs termes un produit potentiellement livrable. Ces release sont contrôlées par le directeur de produit et permettent d’avoir un meilleur contrôle sur les dates prévisionnelles.
« Une application opérationnelle, plutôt que de la documentation exhaustive » … c’est l’un des principes de base de Scrum qui malheureusement est souvent mal compris. Scrum ne remet pas en cause la documentation mais plutôt sa manière prédictive de création. En ce sens, il vaut mieux avoir une application qui marche plutôt qu’une documentation complète sans application … Scrum ne donne pas d’indications quant à la réalisation de cette documentation mais le plus souvent, la documentation est rédigée au fur et à mesure de l’avancement du projet de manière incrémentale. Il n’est pas rare de voir des tâches du Sprint spécifiques à la création ou à la modification des documents fonctionnels et techniques, ou même des plans de recette et cas de tests.
Pour conclure, disons que Scrum offre certains avantages, s’emploie sur un large panel de projet mais ne doit pas être employé “à moitié”. Il appartient maintenant à chacun de se faire son propre avis, et de décider si pour tel ou tel projet dans telle et telle circonstance la méthodologie Scrum est adaptée ou non.
Références
Pour aller plus loin, vous trouverez une mine d’informations énorme en parcourant les blogs ou sites spécialisés, français ou étrangers, sur le sujet.
Certains prônent cette méthodologie, d’autres la dénigrent. Faites vous votre propre avis, l’important est toujours de comparer de son propre chef.
Je vous laisse quelques sites dont j’ai pu m’inspirer pour écrire cette présentation.
- Scrum Log de Jeff Sutherland
https://www.jeffsutherland.com/ - Mike Cohn’s Blog
https://blog.mountaingoatsoftware.com/ - Manifesto for Agile Software Development
https://agilemanifesto.org/ - Frederic Doillon – Manager une équipe de développement Web
https://www.fredericdoillon.com/ - Claude Aubry – Son blog
https://www.aubryconseil.com/ - https://www.agiliste.fr/Home/bien-demarrer-avec-scrum
- https://www-igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/index.php
- Wikipedia – Méthodes Agiles
https://fr.wikipedia.org/wiki/Méthode_agile - Wikipedia – Scrum
https://fr.wikipedia.org/wiki/Scrum
Illustration extraite de “Les Rugbymen” de Poupard et Beka