Pyxis

Scrum est née au cours de année 90 en réaction aux problématiques de gestion rencontrées par les projets de développement logiciel. Scrum est une approche agile de gestion de projet. En tant qu’approche agile, Scrum intègre les préocupations prioritaires des approches agiles. A savoir mettre les individus et leur intéractions au centre de tout, privilégier le logiciel fonctionnel, la collaboration avec le client et la réponse au changement en cours de projet.

Faire une seule phrase présentant Scrum pourrait donner ce qui suit : Scrum est un processus empirique qui se concentre sur la livraison d’incréments de logiciel développés dans des blocs de temps par une équipe auto-organisée qui choisit itérativement son engagement dans un carnet de produit priorisé par un Product Owner.

C’est simple à expliquer mais souvent très difficile à réaliser.

Un processus empirique prévoit à différentes échelles des mécanismes d’inspection de la situation, et d’adaptation des pratiques. Un haut niveau de transparence est nécessaire pour donner un maximum d’efficacité au processus. Transparence entre Equipe et Product Owner ; transparence interne également entre les membres de l’Equipe. A propos des plusieurs niveaux de mécanisme d’inspection et d’adaptation dans Scrum, voir ce précédent post :

Les trois rôles de Scrum sont l’Equipe, le Product Owner et le ScrumMaster.

Le Product Owner (PO) a autorité pour fixer les priorités du carnet de produit et est responsable du retour sur investissement du produit. Il a par exemple autorité pour arrêter un projet si le retour sur investissement de ce qui reste à faire est trop faible. Tout le monde peut suggérer des éléments à ajouter au carnet de produit (Product Backlog). Le Product Backlog représente le chemin incrémentalimaginé pour atteindre les objectifs du projet. Ce chemin peut changer au cours du projet mais il ne doit jamais perdre de vue l’objectif. Une analogie commune est celle des oiseaux migrateurs qui ré-ajustent tous les jours leurs itinéraires en fonction des constats qu’ils font de leur situation.

L’Equipe est responsable des activités de création du logiciel. C’est elle qui en estime les coûts. L’Equipe s’engage à chaque début d’itération (qu’on appelle sprint) à livrer un incrément terminé du logiciel au PO. Cette notion de terminé est essentielle dans Scrum. La définition de terminéest rarement fixe dans un projet. Elle évolue au cours des itérations jusqu’à englober toutes les activités nécessaires à la livraison d’incréments de qualité production. Une préocupation majeure dans un Scrum consiste à atteindre cet état le plus vite possible ; idéalement dès le premier sprint. Un autre point fondamental dans Scrum est que l’Equipe doit être autonome pour livrer l’incrément choisit. Une équipe non autonome pourra profiter de l’approche itérative incrémentale pour identifier ses compétences à acquérir; ce qui peut vouloir dire intégrer des membres supplémentaires et prévoir une diffusion des compétences.

Le ScrumMaster se concentre sur le respect de Scrum par tous les intervenants. Il enseigne au Product Owner et à l’Equipe leur rôle et responsabilités. Il protège l’équipe des turbulences extérieures pendant un sprint. Il aide le Product Owner à maximiser la valeur de son Product Backlog. De coach sportif à chien de berger, les analogies ne manquent pas pour expliquer ce rôle de facilitateur qui doit sans aucune autorité aider tout le monde à tirer le meilleur profit de Scrum.