La structure de Scrum permet aux \u00e9quipes de combiner des pratiques provenant d’autres cadres qui sont significatives pour leur environnement. Dans le monde agile, Scrum est devenu la m\u00e9thode de r\u00e9f\u00e9rence pour le d\u00e9veloppement logiciel. Le concept de Scrum est fiable et a \u00e9t\u00e9 valid\u00e9 par des milliers d’\u00e9quipes de d\u00e9veloppement \u00e0 travers le monde. Scrum convient particuli\u00e8rement bien aux \u00e9quipes pluridisciplinaires travaillant dans des environnements de d\u00e9veloppement de produits o\u00f9 il existe une grande quantit\u00e9 de travail \u00e0 d\u00e9composer en plusieurs it\u00e9rations de 2 \u00e0 4 semaines.<\/p>\n
Origines de Scrum<\/h2>\n
1986 : Takeuchi et Nonaka ont publi\u00e9 leur article \u00ab Le Nouveau Jeu du D\u00e9veloppement de Produits<\/a> \u00bb dans Harvard Business Review. L’article d\u00e9crivait une approche de type rugby o\u00f9 \u00ab le processus de d\u00e9veloppement produit \u00e9merge d’une interaction continue entre une \u00e9quipe soigneusement s\u00e9lectionn\u00e9e et pluridisciplinaire dont les membres travaillent ensemble du d\u00e9but \u00e0 la fin. \u00bb Cet article est fr\u00e9quemment cit\u00e9 comme source d’inspiration du cadre Scrum.<\/p>\n Les principes suivants soutiennent la nature empirique de Scrum :<\/p>\n Transparence<\/strong> Inspection<\/strong> Adaptation<\/strong> Propri\u00e9taire du produit<\/strong><\/p>\n Le Propri\u00e9taire du produit<\/a> est un r\u00f4le responsable de la gestion du backlog produit afin d’atteindre les r\u00e9sultats attendus que l’\u00e9quipe vise \u00e0 livrer.<\/p>\n Le r\u00f4le de propri\u00e9taire du produit existe dans Scrum pour r\u00e9pondre au d\u00e9fi de multiples directions contradictoires ou d’un manque de direction auxquelles les \u00e9quipes de d\u00e9veloppement de produits sont confront\u00e9es lorsqu’elles doivent d\u00e9cider quoi construire.<\/p>\n Master Scrum<\/strong><\/p>\n Le Master Scrum<\/a> est responsable de veiller \u00e0 ce que les membres de l’\u00e9quipe incarnent les valeurs et principes agiles et suivent les processus et pratiques que l’\u00e9quipe s’est engag\u00e9e \u00e0 utiliser.<\/p>\n Le titre \u00e9tait initialement utilis\u00e9 pour d\u00e9signer un expert Scrum capable de guider les autres.<\/p>\n Ce r\u00f4le n’a g\u00e9n\u00e9ralement aucune autorit\u00e9 formelle. La personne occupant ce r\u00f4le doit mener \u00e0 partir d’une position influente, en adoptant g\u00e9n\u00e9ralement une posture de leadership servant.<\/p>\n \u00c9quipe de d\u00e9veloppement<\/strong> La responsabilit\u00e9 principale de l’\u00e9quipe de d\u00e9veloppement est de livrer une incr\u00e9mentation qui cr\u00e9e de la valeur \u00e0 chaque Sprint. La mani\u00e8re dont le travail est attribu\u00e9 est d\u00e9termin\u00e9e par l’\u00e9quipe en fonction des circonstances actuelles.<\/p>\n Artifacts Scrum<\/p>\n Product Backlog<\/strong> Le Product Owner maintient continuellement<\/a> le Product Backlog, y compris son contenu, sa clart\u00e9 et son tri.<\/p>\n Sprint Backlog<\/strong> Increment<\/strong> D\u00e9finition de fin<\/strong> Sprint<\/strong> Planification du Sprint (Planification du Sprint<\/a>)<\/strong> La planification du Sprint est g\u00e9n\u00e9ralement divis\u00e9e en deux parties. Dans la premi\u00e8re partie, le Propri\u00e9taire du produit<\/a> et les autres membres de l’\u00e9quipe s’accordent sur les \u00e9l\u00e9ments du Backlog produit qui seront inclus dans le Sprint.<\/p>\n Dans la deuxi\u00e8me partie de la planification du Sprint, l’\u00e9quipe d\u00e9termine comment elle r\u00e9ussira \u00e0 livrer les \u00e9l\u00e9ments du Backlog produit identifi\u00e9s dans le cadre d’une am\u00e9lioration potentiellement livrable du produit. Si c’est leur pratique, l’\u00e9quipe peut identifier les t\u00e2ches sp\u00e9cifiques n\u00e9cessaires pour y parvenir. Les \u00e9l\u00e9ments du Backlog produit s\u00e9lectionn\u00e9s (le cas \u00e9ch\u00e9ant) et les t\u00e2ches identifi\u00e9es forment le Backlog du Sprint.<\/p>\n Une fois que l’\u00e9quipe et le propri\u00e9taire du produit s’accordent sur le p\u00e9rim\u00e8tre du Sprint sur la base de la description des \u00e9l\u00e9ments du Backlog produit, aucun autre \u00e9l\u00e9ment ne peut \u00eatre ajout\u00e9 au Backlog du Sprint. Cela prot\u00e8ge l’\u00e9quipe contre les changements de p\u00e9rim\u00e8tre pendant le Sprint.<\/p>\n R\u00e9union quotidienne (Daily Scrum)<\/strong> Revue du Sprint<\/strong> R\u00e9trospective du Sprint<\/strong> Scrum est un cadre qui permet aux \u00e9quipes de d\u00e9veloppement de r\u00e9agir de mani\u00e8re flexible aux changements de circonstances. Le cadre fournit suffisamment de points de contr\u00f4le pour garantir que les \u00e9quipes ne s’\u00e9cartent pas des r\u00e9sultats attendus et peuvent identifier et r\u00e9soudre les probl\u00e8mes tout en ajustant les processus pendant que le travail est encore en cours.<\/p>\n Le cycle de vie de Scrum commence par une liste de backlog prioris\u00e9e, mais il ne fournit pas de conseils sur la mani\u00e8re de d\u00e9velopper ou de prioriser le backlog.<\/p>\n Le cycle de vie de Scrum se compose d’une s\u00e9rie de Sprints, aboutissant \u00e0 une am\u00e9lioration potentiellement livrable du produit. Au cours de ces Sprints, toutes les activit\u00e9s n\u00e9cessaires au d\u00e9veloppement du produit ont lieu sur une petite partie du produit global. Voici une description des \u00e9tapes cl\u00e9s du cycle de vie de Scrum :<\/p>\nValeurs Scrum (Valeurs Scrum<\/a>)<\/h2>\n
\nLes \u00e9quipes doivent travailler dans un environnement o\u00f9 chacun est inform\u00e9 des d\u00e9fis auxquels les autres membres de l’\u00e9quipe sont confront\u00e9s. Les \u00e9quipes mettent en lumi\u00e8re les probl\u00e8mes internes \u2014 souvent des probl\u00e8mes anciens \u2014 qui entravent le succ\u00e8s de l’\u00e9quipe.<\/p>\n
\nLe cadre inclut des points de contr\u00f4le fr\u00e9quents qui permettent aux \u00e9quipes de r\u00e9fl\u00e9chir \u00e0 la mani\u00e8re dont leurs processus fonctionnent. Ces points de contr\u00f4le incluent les r\u00e9unions Daily Scrum et les r\u00e9unions de revue de sprint.<\/p>\n
\nLes \u00e9quipes \u00e9valuent continuellement leurs progr\u00e8s et ajustent les \u00e9l\u00e9ments qui semblent inefficaces.<\/p>\n\u00c9quipe de d\u00e9veloppement (\u00c9quipe de d\u00e9veloppement<\/a>)<\/h2>\n
\nLa \u00c9quipe de d\u00e9veloppement<\/a> se compose de ceux qui livrent une incr\u00e9mentation de produit au cours d’un Sprint.<\/p>\n
\nLa Product Backlog<\/a> est une liste ordonn\u00e9e de tous les changements possibles apport\u00e9s au produit. Les \u00e9l\u00e9ments du Product Backlog sont des options, pas des engagements \u2014 leur pr\u00e9sence sur la liste ne garantit pas leur livraison.<\/p>\n
\nLa Sprint Backlog<\/a> est l’ensemble des \u00e9l\u00e9ments du Product Backlog s\u00e9lectionn\u00e9s pour \u00eatre livr\u00e9s pendant le Sprint, ainsi que les t\u00e2ches que l’\u00e9quipe identifie comme n\u00e9cessaires pour livrer ces \u00e9l\u00e9ments et atteindre l’objectif du Sprint.<\/p>\n
\nL’Increment est l’ensemble des \u00e9l\u00e9ments du Product Backlog termin\u00e9s \u00e0 la fin d’un Sprint<\/a> qui r\u00e9pondent \u00e0 la D\u00e9finition de fin de l’\u00e9quipe. Le Product Owner peut d\u00e9cider de lib\u00e9rer l’Increment lors d’un Sprint futur ou d’y ajouter des \u00e9l\u00e9ments.<\/p>\n
\nLa D\u00e9finition de fin<\/a> est un consensus au sein de l’\u00e9quipe sur les crit\u00e8res que doit remplir un \u00e9l\u00e9ment du Product Backlog avant d’\u00eatre consid\u00e9r\u00e9 comme termin\u00e9.<\/p>\n\u00c9v\u00e9nements Scrum<\/h2>\n
\nUn limit\u00e9 dans le temps<\/a>\u00e9v\u00e9nement d’un mois ou moins, pendant lequel l’\u00e9quipe livre une am\u00e9lioration potentiellement livrable du produit. Caract\u00e9ristiques typiques d’un Sprint :<\/p>\n\n
\nUne \u00e9quipe commence un Sprint en discutant des \u00e9l\u00e9ments du Backlog produit qu’elle va traiter pendant le Sprint. Le r\u00e9sultat final de la planification du Sprint est le Backlog du Sprint<\/a>.<\/p>\n
\nLa R\u00e9union quotidienne<\/a> est une r\u00e9union courte (g\u00e9n\u00e9ralement pas plus de 15 minutes) o\u00f9 l’\u00e9quipe coordonne les activit\u00e9s pour le lendemain. La R\u00e9union quotidienne n’est pas destin\u00e9e \u00e0 \u00eatre un rapport d’\u00e9tat ou une session de r\u00e9solution de probl\u00e8mes.<\/p>\n
\n\u00c0 la fin du Sprint, toute l’\u00e9quipe (y compris le propri\u00e9taire du produit) examine les r\u00e9sultats du Sprint avec les parties prenantes du produit. Le but de cette discussion est de revoir, d\u00e9montrer et \u00e9ventuellement permettre aux parties prenantes d’utiliser l’am\u00e9lioration pour fournir des retours. La Revue du Sprint n’a pas pour but de fournir un rapport d’\u00e9tat. Les retours de la Revue du Sprint sont int\u00e9gr\u00e9s au Backlog produit pour une \u00e9valuation future.<\/p>\n
\nApr\u00e8s la Revue du Sprint, \u00e0 la fin du Sprint, l’\u00e9quipe (y compris le propri\u00e9taire du produit) r\u00e9fl\u00e9chit sur le Sprint pr\u00e9c\u00e9dent et identifie les ajustements qu’elle peut apporter \u00e0 l’avenir. Cette r\u00e9trospective<\/a> aboutit \u00e0 au moins un point d’action inclus dans le Backlog du Sprint suivant.<\/p>\n5 valeurs fondamentales<\/h2>\n
\n
![\"What](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2021\/11\/3355-scrum-framework-1.png\")
<\/p>\nCycle de vie<\/h2>\n
\n
Principaux avantages<\/h2>\n