Scrum, la méthode de gestion de projet par excellence

Petite introduction :

Scrum est une méthode de gestion de projet qui a fait ses preuves et qui est surtout très performante en informatique. Je vais parler des points les plus importants, car il faudrait plus d’une journée pour tout comprendre et l’appliquer.

Petit rappel historique : à la base, cette méthode a été « conçue » par Toyota pour sa production de voitures dans les années 60-70, puis a été « reprise » par les américains qui l’ont écrit sur papier pour l’appliquer à l’informatique (entre autre).

Chez Toyota, on écoute l’avis et les problèmes de tout le monde, de toutes les couches de conception d’une voiture, ainsi on apporte des solutions au problème à tous les niveaux.

Le nom Scrum vient du rugby, autrement dit la « mêlée ».

Elle est dite « lean », qui signifie dégraissée, maigre, en gros ne faire que ce qui est nécessaire et « Agile ».

Objectif :

Elle s’applique généralement pour les grands projets, plus difficiles à développer mais aussi pour les plus petits projets. Son objectif est de rendre un produit tel que le client le voudrait, sans dévier dans un « hors sujet », ou ne pas répondre aux attentes exactes du client, grâce à un suivie avec ce dernier durant tout le projet !

Il est difficile de répondre aux attentes du client car celui-ci n’a pas pu tout prévoir dans le cahier des charges, ou les développeurs ont interprété certaines fonctions qui n’étaient pas très clair. Après 4 mois de développement, si vous livrez un produit sans avoir consulté le client régulièrement, il doit s’attendre à des surprises !

Scrum répond en autre à cette problématique.

Les rôles :

Tous les intervenants d’un projet en Scrum ont un rôle, y compris le client lui-même !

D’un côté, vous avez les développeurs et le ScrumMaster (en gros le chef de projet), ce dernier est chargé de veiller au bon fonctionnement du développement, mais surtout d’intervenir régulièrement auprès du client, comme je vais l’expliquer par la suite.

De l’autre, vous avez le client, appelé Product Owner, qui suit l’avancement du projet et qui est en étroite relation avec le ScumMaster.

Vous pouvez aussi avoir des intervenants auprès du Product Owner, qui travaillent avec lui et qui lui suggèrent des idées, mais qui ne doivent en aucun cas intervenir directement dans le projet en passant par les développeurs (le client doit toujours être au courant de ce qui est fait pour son projet !).

Le Client doit décider de toutes les fonctionnalités, de ce fait, il ne peut pas être déçu par le produit final !

Fonctionnement :

Scrum fonctionne par cycle, à chaque cycle, le client doit pouvoir tester un module qui fonctionne et l’approuver. C’est la règle d’or de Scrum. Un cycle, appelé « Sprint », dure généralement 2 semaines.

Au début du cycle, le client et le ScrumMaster décident ensemble une partie du projet à faire, et à la fin de ce cycle, le ScrumMaster lui offre une démo.

Le client approuve ou explique ce qui ne lui va pas. Si cela ne lui plait, on refait un cycle sur la même partie du projet afin d’obtenir ce que veut le client. Cela ne vous prendra que 2 semaines à corriger, contrairement à un projet livré au bout de 4 mois qui serait tout à revoir à cause d’un module, dont d’autres modules dépendraient de celui-ci, etc, dont le client serait insatisfait… j’imagine le désastre.

Retenez plutôt le nom de Sprint que cycle.

Lors du lancement du projet, il faut bien expliquer au client qu’il devra faire un contrôle et un suivi du développement pour éviter les mauvaises surprises.

De plus, cette méthode vous évite d’élaborer un dossier UML complet sur toute l’application. Vous n’élaborez l’UML que pour le « Sprint » à venir.

Devoir changer toute la conception, et donc l’UML d’un projet de 4 mois, parce que vous n’avez pas exactement compris ce que voulait le client, ça fait mal !

Découper en « Sprint » vous permet de corriger le tir à temps (et donc d’éviter la catastrophe), de gagner du temps et de satisfaire le client. En plus, vous devenez du coup transparent et le client sait pourquoi il paye.

Je vais décortiquer en quelques étapes un « Sprint » :

1er jour – le ScrumMaster et le Client se voient et fixent ensemble les fonctions prioritaires du projet (par exemple, un module d’inscription n’est pas forcément le plus pressant à présenter, mais plus la fonction principale du produit).

Le ScrumMaster décortique en actions AVEC le client tous les besoins d’une fonctionnalité, et estime la complexité de mise en place pour chaque action, si possible avec ses développeurs.

Le client voit alors ce qui peut prendre du temps, et peut par ailleurs enlever des actions inutiles au bon fonctionnement du produit.

Les développeurs sont du coup un peu plus impliqués dans le projet et ont un pouvoir de décision (aussi minime soit-il).

Le ScrumMaster ne doit pas être un manager, quelqu’un qui dirige ses développeurs, mais juste le capitaine d’une équipe qui « oriente » cette dernière, en prenant compte de l’avis de tout le monde !

Le client s’y retrouve et les développeurs aussi…

Les actions décortiquées, on est prêt pour le Sprint, et on les affiche toutes sur un mur par exemple (avec des papiers), pour bien les avoir en tête.

2ème au 8ème jour – L’équipe analyse, développe puis teste et corrige la partie du projet dont ce Sprint est l’objectif.

Une réunion quotidienne OBLIGATOIRE de 15 – 30 min entre la team est nécessaire pour être bien fixé sur l’objectif de la journée, pour savoir qui développe quelle action du module, etc…

9ème jour – Le ScrumMaster rencontre le client et lui fait faire la démo du Sprint. Le client valide la fonctionnalité ou explique ce qui ne lui va pas.

Aparté : il se peut que le Sprint ne soit pas terminé à temps, dans ce cas on ne présente que ce qui fonctionne au client, en lui expliquant par exemple qu’il y a eu grève, ou un arrêt maladie, ou si l’équipe de développeur a buté sur un problème.

La transparence met de toute manière le client en confiance.

10ème jour – dit « jour de glande ». Tout le monde se repose, s’occupe de la veille informatique, rattrape le retard accumulé, se documente, etc…

Puis c’est reparti pour un cycle, on fait un nouveau Sprint pour implémenter une nouvelle fonctionnalité. On revoit le client (jour 1), etc… C’est à votre entreprise de trouver le bon rythme et de déterminer la durée d’un Sprint (2 à 4 semaines).

Vous pouvez déjà imaginer la puissance de cette méthode de projet !

A force, les fonctionnalités s’empilent et on ne fait pas de fausse route. Le client, de par le suivi, obtient ce qu’il désire, les taches des développeurs varient (UML, développement, intégration, tests unitaires…) toutes les semaines, chacun à droit à la parole, on ne développe pas plus que ce que le client nous demande…

Enfin, j’insiste sur un point, il est important que le ScrumMaster ne soit pas un pur dirigeant, et qu’il écoute les problèmes de chaque membre de son équipe. Il ORIENTE uniquement l’équipe, et sert d’arbitre.

Cette méthode, comme je le répète, est très efficace pour les gros projets sur plusieurs mois, mais est aussi à utiliser pour les petits projets, on peut du moins s’inspirer de plusieurs concepts mentionnés plus haut pour ces derniers !

A propos

J’ai eu une formation à Scrum ce mardi par la société Efidev, qui par ailleurs est très compétente et qui fournie de nombreux outils pour développer l’efficacité d’une équipe (des supports spéciaux comme des tableaux, des carnets pour les actions, et des logiciels open-source !). Je suis loin (très très loin) d’avoir détaillé chaque concept de Scrum, mais il y a des pratiques très utiles à savoir. Si vous êtes intéressé, n’hésitez pas à vous payer une formation, ça vaut le coup ! Et allez visiter leur site !