Scrum est un Framework méthodologique qui a le vent en poupe depuis quelques années et qui fait partie intégrante aujourd’hui du paysage informatique. Largement répandu et mis en œuvre dans les entreprises et DSI, ce cadre est devenu familier à de nombreux intervenants et acteurs dans les projets informatiques.
Cependant, au-delà de certains aspects et artefacts bien connus de l’agilité, sa parfaite application peut encore être sujette à un certain nombre d’écueils en tout genre comme les modalités de sa mise en pratique, sa compréhension ou encore le rôle des différents intervenants.
La difficulté provient notamment de la sous-estimation des changements organisationnels et d’état d’esprit qu’il implique, qui sont souvent bien plus profonds que ceux anticipés ou imaginés.
1. Les valeurs de l’agilité
Le Manifeste Agile définit 4 valeurs fondamentales :
- Les individus et leurs interactions plus que les processus et les outils ;
- Un logiciel qui fonctionne plus qu’une documentation exhaustive ;
- La collaboration avec les clients plus que la négociation contractuelle ;
- L’adaptation au changement plus que le suivi d’un plan.
Scrum est actuellement l’implémentation Agile la plus répandue et l’un des cadres méthodologiques agiles pour le développement logiciel. (Bien que l’on parle souvent de méthodologie Agile, cette appellation est erronée, dans le sens où une méthodologie propose une recette à appliquer ce qui n’est pas le cas ici.)
2. Les différents rôles
Elle définit 3 rôles importants :
- Le product owner (PO) : décide de ce qui doit être développé. Il établit et priorise le Product Backlog (liste qui contient la description de l’ensemble des besoins du client, les fonctionnalités du produit, ainsi que les tâches à réaliser afin de parvenir à la réalisation du produit). Le product owner travaille avec les parties prenantes et prend en considération les « inputs » des utilisateurs finaux.
- L’équipe de développement : comme son nom l’indique, elle met en œuvre les développements demandés par le PO (product owner). Quel que soit leur rôle au sein de l’équipe (développeur, business analyst (BA), testeur, architecte …) les membres de cette équipe sont appelés « développeurs » car ils contribuent tous au développement du produit.
- Le scrum master: il est le garant du cadre méthodologique Scrum. Il joue le rôle de de conseiller, de coach de l’équipe agile. Il a également un rôle de facilitateur en essayant de soustraire tous les obstacles pouvant être rencontrés au cours du projet. Il met en place tout ce qui peut aider l’équipe à réaliser ses objectifs.
3. Les sprints
L’équipe SCRUM travaille au travers de séries de Sprints, limités dans le temps (souvent 2 semaines et pouvant aller jusqu’à un mois).
Avant chaque sprint a lieu la 1ere cérémonie, « le Sprint Planning », où l’équipe de développement et le PO se rencontrent. Le PO présente le Product Backlog à l’équipe. Les users stories constituants le Back Log sont déjà priorisées par le PO et chiffrées en termes de charge par l’équipe de développement qui choisit un certain nombre d’items de ce backlog. L’équipe de développement ne peut choisir n’importe quelle user stories et doit respecter la priorisation donnée par le PO. Ces items forment le sprint backlog qui doit être délivré en fin d’itération par l’équipe de développement.
Au cours de ce sprint, chaque jour se tient le « Stand up Meeting » ou « Daily Scrum Meeting » où chaque membre de l’équipe de développement répond à 3 questions rituelles :
- Ce sur quoi j’ai travaillé hier ?
- Ce sur quoi je vais consacrer ma journée d’aujourd’hui ?
- Et quelles sont les difficultés rencontrées et les points bloquants ?
A la fin du sprint, le travail est packagé pour la release.
Le Sprint prend fin avec 2 autres cérémonies :
– La sprint review avec la démonstration qui montre le travail accompli aux parties prenantes. Cette cérémonie donne la possibilité aux parties prenantes de voir ce qui a été accompli et de donner les retours aux équipes de développement.
– La rétrospective qui est un retour sur ce qui a bien marché, ce qui a pu poser problème et ce qui peut être amélioré. L’objectif de la rétrospective étant que le sprint suivant soit plus efficace.
Comme nous venons de le voir Scrum présente une approche relativement simple, cadrée du développement logiciel. Cependant derrière cette apparente simplicité, la parfaite implémentation de Scrum reste subtile et peut donner lieu à des erreurs que nous allons aborder dans la suite de cet article.
Maintenant que vous avez pris connaissance de ce qu’est l’agilité, nous aborderons dans les prochains épisodes les difficultés de la mise en application de l’agilité SCRUM. Nous tenterons également de suggérer des pistes et des recommandations afin de les corriger.
