Scrum (développement)

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 rugby approach (« méthode du rugby »), une nouvelle méthode holistique qui augmente vitesse et flexibilité dans le développement de nouveaux produits logiciels[1]. L'ensemble du développement est réalisé itérativement par une équipe multidisciplinaire en passant par différentes phases [2] et que les phases et itérations peuvent se chevaucher fortement [3]. 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[4].

En 1995, Ken Schwaber présente une communication décrivant les fondements de ce qui deviendra la méthode Scrum à l'OOPSLA[5]. Il présentera ensuite plus en détail les principes de Scrum dans l’article Controlled Chaos: Living on the Edge en 1996[6].

En 2002, Ken Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre Agile Software Development With Scrum[7].

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[8].

Scrum est un processus empirique qui s'appuie sur trois piliers[9] : 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é[10]. 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[11] 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 (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 burndown charts (« graphiques d'avancement »)[12]. Les burndown charts ne sont cités dans le Scrum Guide qu'à titre d'exemple et ne sont pas une pratique requise.

• product owner (« directeur de produit[13] ») :

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 ;

• scrum master (« chef de mêlée[14] ») :

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 ;

• product backlog (« carnet du produit[15] ») :

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.

• definition of done ou DoD (« 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 ;

• sprint backlog (« carnet de sprint[16] ») :

Liste des tâches à accomplir pendant un sprint. Elles correspondent à la réalisation des éléments de carnet de produit affectés au sprint ;

• daily scrum (« mêlée quotidienne[17] ») :

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 ;

• sprint (« sprint[18] ») :

Nom d'une itération dans Scrum. Cette itération dure 1 mois maximum en théorie, mais en pratique entre 2 et 4 semaines. 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 ;

• burndown chart (« 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).