Scrum (développement)
- REDIRECT Modèle:Voir homonymes
Scrum est un framework ou cadre de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ». Scrum est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du manifeste agile.
Scrum s'appuie sur le découpage d'un projet en « boîtes de temps », nommées sprints (« pointes de vitesse »). Les sprints peuvent durer entre quelques heures et un mois (avec un sprint médian à deux semaines). Chaque sprint commence par une estimation suivie d'une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé. Avant de démarrer un nouveau sprint, l'équipe réalise une rétrospective. Cette technique analyse le déroulement du sprint achevé, afin d'améliorer ses pratiques. Le flux de travail de l'équipe de développement est facilité par son auto-organisation, il n'y aura donc pas de gestionnaire de projet.
La création de frameworks de développement logiciels hybrides couplant Scrum et d'autres frameworks est commune puisque Scrum ne couvre pas le cycle de développement de produit. Par exemple, on pourra utiliser des pratiques issues de l'extreme programming, de la phase de construction structurée de la méthode RAD, ou un ensemble de pratiques de qualité du logiciel issues du vécu de l'équipe projet.
Scrum est utilisé dans différents domaines comme le logiciel, l'aéronautique ou le bâtiment.
Historique
La métaphore du scrum (la « mêlée du rugby ») apparaît pour la première fois en 1986 dans une publication de Hirotaka Takeuchi et Ikujiro Nonaka, intitulée The New New Product Development Game, qui s'appliquait à l'époque au monde industriel. Ils y décrivent, sous le nom de Modèle:Lang (« méthode du rugby »), une nouvelle méthode holistique qui augmente vitesse et flexibilité dans le développement de nouveaux produits logiciels<ref>Modèle:Article</ref>. L'ensemble du développement est réalisé itérativement par une équipe multidisciplinaire en passant par différentes phases <ref>alors qu'il n'y a pas de phases dans le framework Scrum actuel. Il y en avait trois dans la version initiale de 1995.</ref> et que les phases et itérations peuvent se chevaucher fortement <ref>ce qui est interdit dans le framework Scrum actuel.</ref>. Ils ont comparé cette nouvelle méthode au rugby à XV, sport où les membres de l'équipe en bloc tentent d'aller jusqu'à la ligne d'en-but, en se passant et repassant le ballon<ref>(Modèle:Citation étrangère).</ref>.
En 1995, Ken Schwaber présente une communication décrivant les fondements de ce qui deviendra la méthode Scrum à l'OOPSLA<ref>{{#invoke:Langue|indicationDeLangue}} Schwaber K., SCRUM Development Process, in : Proceedings of the 10th Annual ACM Conference on Object Oriented Programming Systems, Languages, and Applications (OOPSLA), 1995.</ref>. Il présentera ensuite plus en détail les principes de Scrum dans l’article Controlled Chaos: Living on the Edge en 1996<ref>{{#invoke:Langue|indicationDeLangue}} Schwaber K., Controlled Chaos: Living on the Edge, Cutter Business Technology Journal, 1996.</ref>.
En 2002, Ken Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre Modèle:Langue<ref>Modèle:Ouvrage.</ref>.
En 2010, Jeff Sutherland et Ken Schwaber décrivent les principes de la méthode dans le Guide Scrum. La dernière mise à jour remonte à 2020<ref>Modèle:Lien web.</ref>.
Caractéristiques essentielles
Scrum est un processus empirique qui s'appuie sur trois piliers<ref>{{#invoke:Langue|indicationDeLangue}} Guide officiel de Scrum : Modèle:Citation étrangère</ref> : la transparence, l'inspection et l'adaptation. Il suit également les principes de la culture agile. Scrum met l'accent sur le fait d'avoir un langage commun entre tous les acteurs liés au produit. Ce langage commun doit permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet et de son état d'avancement. À intervalles réguliers, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable. Si une dérive est constatée pendant l'inspection, le processus doit alors être adapté. Scrum fournit des « événements », durant lesquels cette adaptation est possible. Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective du sprint.
Scrum est fondé sur la conviction que le développement logiciel est une activité par nature non déterministe et que l'ensemble des activités de réalisation d'un projet complexe ne peut être anticipé et planifié<ref>Modèle:Lien web.</ref>. C'est en cela que Scrum s'oppose aux démarches prédictives telles que le cycle en V ou le CMMI. Pour répondre à cette imprédictibilité, la méthode Scrum propose un modèle de contrôle de processus<ref>{{#invoke:Langue|indicationDeLangue}} Ken Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004, Modèle:P..</ref> fondé sur l'empirisme, via l'adaptation continue aux conditions réelles de l'activité et une réaction rapide aux changements. L'analyse des conditions réelles d'activité lors des rétrospectives de fin de sprint et le plan d'amélioration continue qui en découle sont réalisés à intervalles de temps réguliers, donnant lieu à un cycle de développement incrémental (Sprint).
Scrum a été conçu lors de projets de développement de logiciels dans les années 1990 au début de l'ère numérique. Il peut aussi être utilisé par des équipes de maintenance. Dans le cas de très grands projets, les équipes se multiplient et on parle alors de scrum à grande échelle (Modèle:Ex le scrum de scrums ou LESS).
Hormis pour le maintien des carnets de produit et d'itération, il n'y a pas d'éléments de processus décrits dans la documentation de référence qui requièrent l'utilisation d'un outil particulier. Dans Agile Project Management with Scrum, Ken Schwaber donne l'exemple de carnets de produit et d'itération maintenus dans un tableur, lequel permet aussi le calcul des Modèle:Langue (« graphiques d'avancement »)<ref>{{#invoke:Langue|indicationDeLangue}} Ken Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004, p. 11 et 13.</ref>. Les Modèle:Langue ne sont cités dans le Modèle:Langue qu'à titre d'exemple et ne sont pas une pratique requise.
Glossaire
- Modèle:Lang (« directeur de produit<ref>Modèle:Lien web</ref> ») :
- Personne ayant la responsabilité de produire et de maintenir à jour le carnet de produit. C'est lui qui détermine les priorités et qui prend les décisions d'orientation du projet ;
- Modèle:Lang (« chef de mêlée<ref>Modèle:Lien web</ref> ») :
- Membre de l'équipe dont l'objectif principal est de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe ;
- Modèle:Lang (« carnet du produit<ref>Modèle:Lien web</ref> ») :
- Liste des fonctionnalités, des fonctions, des exigences, des améliorations et des correctifs qui sont nécessaires à l'évolution du produit ; celui-ci est dynamique sur tout le cycle de vie du produit.
- Modèle:Lang ou Modèle:Lang (« définition de fini ») :
- L'ensemble des conditions nécessaires pour considérer qu'un élément de carnet de produit est livrable. Sa définition varie selon les équipes, mais elle doit être la même pour tous les membres d'une équipe Scrum ;
- Modèle:Lang (« carnet de sprint<ref>Modèle:Lien web</ref> ») :
- Liste des tâches à accomplir pendant un sprint. Elles correspondent à la réalisation des éléments de carnet de produit affectés au sprint ;
- Modèle:Lang (« mêlée quotidienne<ref>Modèle:Lien web</ref> ») :
- Réunion quotidienne de quinze minutes maximum pour faire le point sur ce qui a été fait depuis la dernière mêlée, ce qu'il est prévu de faire jusqu'à la prochaine et quels sont les obstacles rencontrés durant le travail ;
- Modèle:Lang (« sprint<ref>Modèle:Lien web</ref> ») :
- Nom d'une itération dans Scrum. Cette itération dure 1 mois maximum en théorie, mais en pratique entre 2 et Modèle:Nobr. Pendant une itération, l'équipe doit développer la liste d'éléments du carnet de produit qui a été définie au début du sprint ;
- Modèle:Lang (« graphique d'avancement ») :
- Graphique qui représente l'évolution du reste à faire total de jour en jour (pour les sprints) ou de sprint en sprint (pour les nouvelles éditions).
Dérives
Flaccid scrum
L'expression Modèle:Langue (« mêlée flasque ») est utilisée par Martin Fowler en 2009 pour identifier une pratique de mêlée erronée où la qualité logicielle est négligée et où le produit développé accumule de la dette technique<ref>{{#invoke:Langue|indicationDeLangue}} Martin Fowler, Flaccid Scrum, 29 janvier 2009.</ref>. Fowler indique que même si Scrum ne décrit pas quelles pratiques techniques mettre en place, la méthode n'encourage pas l'absence de telles pratiques et que les Modèle:Langues de premier plan ont toujours insisté sur l'utilisation de pratiques techniques efficaces. Fowler mentionne que les pratiques techniques de l'extreme programming constituent un bon point de départ pour les équipes Scrum et valent mieux que l'absence de pratiques. En 2014, Fowler considère que le problème persiste et encourage les utilisateurs de Scrum et des méthodes agiles en général à se tourner vers des pratiques techniques efficaces<ref>{{#invoke:Langue|indicationDeLangue}} Martin Fowler, Five years of Flaccid Scrum, 29 janvier 2014.</ref>.
Maître de mêlée directif
Il n'est pas rare que le maître de mêlée soit un chef de projet déguisé ou officiel et qu'il applique un contrôle trop strict sur les membres de son équipe<ref>{{#invoke:Langue|indicationDeLangue}} Empowering Teams: The ScrumMaster's Role, 11 juin 2007.</ref>. Les conséquences dans ce cas peuvent prendre la forme de discussions houleuses ou de conflits plus ou moins durables entre membres de l'équipe. On constate aussi parfois à l'inverse une manière différente d'appréhender la réunion quotidienne : non-dit ou propos vagues en ce qui concerne les problèmes rencontrés. Ainsi, les réunions peuvent se passer de façon plus courtoise mais un risque de ne plus chercher le soutien de l'équipe en cas de difficulté pourrait apparaître. Ce qui va à l'encontre même des principes de Scrum<ref>Modèle:Ouvrage.</ref>.
Water scrum fall ou Vrum
Le water scrum fall ou Vrum (contraction de V, cycle en V, et de scrum, mêlée) consiste à conserver le cahier des charges initial avec un périmètre fixe décliné dans les étapes séquentielles d'un cycle en V. Les parties itératives du cycle en V sont introduites dans le développement sous forme de scrum et des tests globaux sont nécessaires avant la livraison.
Dans ce cas de figure, si l'équipe doit attendre la validation globale du cahier de charge pour commencer à découper ce besoin ferme en petits morceaux afin de l'introduire pas à pas dans les sprints, l'absence de négociation ou de discussion est antinomique du concept de rédaction et de finalisation des user stories (témoignages d'utilisateurs).
Il s'agit simplement de mener la phase de réalisation d'un projet cycle en V en suivant Scrum<ref>Modèle:Lien web.</ref>. La conséquence est d'enfermer Scrum dans un process où le périmètre est fixe et de passer d'un pilotage par la valeur (agile) à un pilotage par le plan (cycle en V).
Une alternative au water scrum fall est SAFe<ref>https://ichi.pro/fr/l-institutionnalisation-insidieuse-de-water-scrum-fall-82428450858425</ref>.
Notes et références
Voir aussi
Articles connexes
Bibliographie
- {{#invoke:Langue|indicationDeLangue}} Ken Schwaber , Modèle:Lang, Microsoft Press, 2004 Modèle:ISBN
- Claude Aubry, SCRUM : Le guide pratique de la méthode agile la plus populaire, Dunod, 2010 Modèle:ISBN
- {{#invoke:Langue|indicationDeLangue}} Jeff Sutherland, Rini van Solingen, Eelco Rustenberg, Modèle:Lang, Kindle Edition, 2011) Modèle:ASIN
- Jean-Pierre Vickoff, Agile, Scrum et au-delà, Pilotage de projets, Mise en œuvre rapide, QI, 2016 Modèle:ISBN
- Bassem El Haddad, Julien Oger, Scrum, de la théorie à la pratique : Initiation. Perfectionnement. Agilité. Avec un mémento de 14 pages à emporter partout !, Eyrolles, 2017 Modèle:ISBN
