Scrum (développement)

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.

Pour les articles homonymes, voir Scrum.

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

Caractéristiques essentielles
Vue synthétique du processus scrum.

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. 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.

Glossaire
  • 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).

Dérives

Flaccid scrum

L'expression flaccid scrum (« 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[19]. 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 scrummers 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 à prendre garde à l'utilisation de pratiques techniques efficaces[20].

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[21]. 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[22].

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 finalisation des user stories.

Il s'agit simplement de mener la phase de réalisation d'un projet cycle en V en suivant Scrum[23]. 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[24].

Notes et références
  1. (en) Hirotaka Takeuchi et Ikujiro Nonaka, « The new new product development game », Harvard Business Review,‎ , p. 137-146
  2. 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.
  3. ce qui est interdit dans le framework Scrum actuel.
  4. (« tries to go the distance as a unit, passing the ball back and forth »).
  5. (en) Schwaber K., SCRUM Development Process, in : Proceedings of the 10th Annual ACM Conference on Object Oriented Programming Systems, Languages, and Applications (OOPSLA), 1995.
  6. (en) Schwaber K., Controlled Chaos: Living on the Edge, Cutter Business Technology Journal, 1996.
  7. Ken Schwaber, Agile software development with Scrum, Prentice Hall, (ISBN 0-13-067634-9, OCLC 48241360, lire en ligne).
  8. « Scrum Guide Revisions | Scrum Guides », sur www.scrumguides.org (consulté le ).
  9. (en) Guide officiel de Scrum : « Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. »
  10. « Empirical Management Explored » [PDF], sur scrum.org, (consulté le ).
  11. (en) Ken Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004, p. 2.
  12. (en) Ken Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004, p. 11 et 13.
  13. « directeur de produit », sur gdt.oqlf.gouv.qc.ca (consulté le )
  14. « chef de mêlée », sur gdt.oqlf.gouv.qc.ca (consulté le )
  15. « carnet de production », sur gdt.oqlf.gouv.qc.ca (consulté le )
  16. « carnet de sprint », sur gdt.oqlf.gouv.qc.ca (consulté le )
  17. « mêlée quotidienne », sur gdt.oqlf.gouv.qc.ca (consulté le )
  18. « sprint », sur gdt.oqlf.gouv.qc.ca (consulté le )
  19. (en) Martin Fowler, Flaccid Scrum, 29 janvier 2009.
  20. (en) Martin Fowler, Five years of Flaccid Scrum, 29 janvier 2014.
  21. (en) Empowering Teams: The ScrumMaster's Role, 11 juin 2007.
  22. (en) Stefan Wolpers, The Scrum Anti-Patterns Guide : A Hands-on Manual from the Trenches, , 69 p. (lire en ligne), pp.21, 33, 44.
  23. (en) Eirian Legoux, « Il y a tant de dérives avec Scrum … :-( », sur Medium, (consulté le ).
  24. https://ichi.pro/fr/l-institutionnalisation-insidieuse-de-water-scrum-fall-82428450858425

Voir aussi

Articles connexes

Bibliographie
  • (en) Ken Schwaber , Agile Software Management with Scrum, Microsoft Press, 2004 (ISBN 978-0735619937)
  • Claude Aubry, SCRUM : Le guide pratique de la méthode agile la plus populaire, Dunod, 2010 (ISBN 978-2100540181)
  • (en) Jeff Sutherland, Rini van Solingen, Eelco Rustenberg, The Power of Scrum, Kindle Edition, 2011) (ASIN 978-0735619937)
  • Jean-Pierre Vickoff, Agile, Scrum et au-delà, Pilotage de projets, Mise en œuvre rapide, QI, 2016 (ISBN 979-1022746182)
  • 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 (ISBN 978-2212144703)

Liens externes

  • Portail de l’informatique
  • Portail du logiciel
  • Portail du management
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.