SCRUM

Scrum est un cadre de travail agile destiné à la génération de valeur pour des produits complexes dont le principe est de permettre aux équipes de développer, livrer et maintenir un ensemble d'éléments de manière itérative et incrémentale afin de créer un produit / délivrer un projet final. Il se caractérise par des cycles de développement courts appelés sprints, une collaboration étroite entre les membres de l'équipe et une adaptation continue aux changements.

Scrum team

Un Product Owner (PO) est chargé au sein d'une organisation d'encadrer la réalisation d'un produit / projet - majoritairement lié au domaine digital comme par exemple un modèle d'apprentissage. Le Product Owner est responsable d'un Product Backlog - une liste comprenant un ensemble de User Stories ( = phrases qui expriment selon les parties prenantes du projet un besoin « en tant que ... je dois / j'ai besoin... » ) -. Les user stories correpondent au découpage de la réalisation d'un produit / projet. Un user story peut être exprimé par n'importe quelle partie prenante ( un futur utilisateur, un développeur, un expert externe, un membre de la Scrum Team... ).

Le Product Owner aide à la définition / à l'identification des valeurs et du contexte des user stories. Il a la responsabilité de les ordonner de manière prioritaire pour assurer une coordination des différentes réalisations. Un user story peut être une tâche - explicitement exprimée - ou un besoin / problème que la Dev Team traduira en une ou un ensemble de sous-tâches à réaliser. Les tâches sont réalisées par la dev team. Des experts internes et ou externes. Les tâches de la dev team sont réalisées dans une temporalité précise - un sprint de 4 semaines.

L'équipe est également composée d'un Scrum Master ( SM ) dont la responsabilité est de s'assurer que le cadre scrum est bien appliqué et intégré dans l'organisation. Il veille surtout à débloquer les situations et vérifie la bonne pratique des évènements scrum.

Le Scrum Master et le Product Owner peuvent faire partie de la dev team.

Sprint planning

La Scrum Team, composée du Scrum Master du Product Owner et de la Dev Team définissent ensemble un Sprint Plannin,c’est-à-dire le lancement d’une phase de quatre semaines pour réaliser un ou plusieurs incréments du produit / projet. Chaque sprint a un but précis ( Sprint Goal ) définit par la Scrum Team qui identifie également la manière d'évaluer l'atteinte de ce but. Cet élément est fondamental car il donne une direction clair à la team et peut servir d'aide à la prise de décision pendant le sprint.

Le Sprint Planning est également le moment où la Dev Team va constituer le backlog du sprint ( Sprint Backlog ), c'est à dire sélectionner des Users Stories priorisées du Product Backlog par le Product Owner, les découper en tâches voir en sous-tâches journalières. L'objectif de la dev team est de transformer les tâches du product backlog en élément de valeur. Pour chaque tâches, ils vérifient qu'il existe bien une définition de ce qui permet de considérer la tâche comme étant terminée et validée ( Definition Of Done - DOD ).

Le Sprint Planning ( la planification des $4$ semaines ) est une réunion conditionnée à une temporalité de maximum 8h pour un sprint de 4 semaines. Le Sprint Planning lance le sprint. Elle démarre par l'intervention du Product Owner qui présente les User Stories prioritaires et explique leurs valeurs. La Team Scrum discute ensemble des User Stories pour clarifier les besoins et estimer le travail à réaliser. Ensuite la Dev Team décompose les user stories ou tâches en sous-tâches, et identifie les dépendances.

Daily Scrum

Tous les jours, la Dev Team se réunit pendant 15 minutes dans le cadre d'une mini réunion appelée Daily Scrum - si le Product Owner et le Scrum Master font partie de la dev team, ils participent en tant que tel -, autrement le présence n'est pas obligatoire mais ils peuvent y participer. Le Daily Scrum est tenu à la même heure et au même endroit, chaque jours ouvrés du sprint. L'objecitf des Daily Scrum est de planifier le travail de la journée dans le but de progresser vers l'objectif ainsi qu'améliorer la communication et identifier les éventuels obstacles. Chaque membre de la Dev Team explique ce qu'il a fait la veille pour atteindre l'objectif du sprint, ce qu'il compte faire aujourd'hui et s'il y a des blocages quelconques. Le Scrum Master veille à ce que les Daily Scrum soient respectés et surtout interviendra en cas de blocage pour favoriser l'avancement.

Le Saily Scrum est également l'occasion pour la Dev Team d'adapter le Sprint Backlog au besoin. Le Product Owner ne peut pas intervenir sur le Sprint Backlog - il est responsable du Product Backlog et non du sprint - mais il peut être consulté par la Dev Team en cas d'impacts sur le Product Backlog.

Sprint review

Après 4 semaines de sprint, l'équipe Scrum ainsi que les parties prenantes du projet se réunissent pour le Sprint Review. Le résultat - l'incrément produit pendant le sprint ( fonctionnalités terminées et livrables ) - est présenté, ainsi que les progression vers l'objectif et en cas de besoin, les adaptations futures sont discutées. Le Product Backlog peut être ajusté par le Product Owner en collaboration avec la Dev Team et les parties prenantes. Le Sprint Review n'est en effet pas une réunion de présentation de résultat uniquement mais bien une session de travail collaborative avec l'ensemble des parties prenantes. Le Sprint Review est l'avant dernier évènement d'un sprint et sera toujours limité à un maximum de quarte heures.

Sprint retrospective

Le Sprint Retrospective est l'évènement qui clôture le sprint. Il s'agit d'une réunion de maximum 3h entre les membres de la Team Scrum qui est organisée dans le but d'identifier les possibilités d'amélioration de la qualité et de l'efficacité du sprint. Les problématiques qui ont été rencontrées sont discutées et les origines ainsi que la manière dont ces problématiques ont été résolues ( ou non ) sont également abordés.

Les artefacts

Un artefact est un élément concret qui présente un travail ou de la valeur et permet d'assurer une transparence totale des éléments clés. Il existe trois artefacts dans scrum :

• L'objectif produit du product backlog
• L'objectif sprint du sprint backlog
• La définition of done de l'incrément

Product Backlog

Le Product Backlog est la source unique de travail de la Scrum Team et reprend, comme nous l'avons abordé précédemment, une liste ordonnées des User Stories assurant l'amélioration du produit. Le Product Backlog est affiné par la Dev Team ( par exemple découpage de User Stories en tâches et sous-tâches ), qui ajoute un ensemble de détails comme par exemple une description, un ordre, une taille,... ( les attributs diffèrent selon le domaine d'activité ). Le Product Owner est responsable du Product Backlog et de la priorisation mais ce sont les développeurs ( dont le product owner et scrum master peuvent faire partie ) qui sont responsables du redimensionnement

L'objectif produit décrit un avancement, une évolution du produit et aide la Scrum Team à clarifier le sprint planning.

Sprint Backlog

Le Sprint Backlog identifie les raisons de sélection des éléments du Product Backlog choisis pour le sprint. Il répond à la question «pourquoi» mais surtout définit le plan d'action pour obtenir l'incrément et par conséquent répond également à la question «comment». La dev team est responsable du sprint backlog dont les éléments sont détaillés pour correspondre à un travail quotidien. Le Sprint Backlog est mis à jour et adapté tout au long du sprint.

L'objectif sprint est un engagement pris par les développeurs pour atteindre la réalisation attendu et définie lors du Sprint Planning et est un élément du Sprint Backlog. Si les développeurs rencontrent des problématiques pour réaliser une partie du travail du Sprint Backlog, le périmètre du sprint peut être négocié avec le product owner mais l'objectif restera inchangé.

Incrément

Un incrément est un élément du Product Backlog qui répond à la Definition Of Done ( DOD ).

Chaque incrément concrétise l'avancement vers l'objectif produit et est le résultat d'un sprint présenté devant la Dev Team et les parties prenantes lors du Sprint Review. Attention toutefois qu'un même sprint peut comprendre plusieurs incréments et un incrément peut être délivré avant la fin du sprint. Un incrément est considéré comme tel dès lors qu'il réponds à la définition of done.

Cette définition décrit formellement l'état de réalisation d'un incrément de part le fait qu'il satisfait des mesures de qualité. Si ce n'est pas le cas, l'élément n'est pas présenté lors du Sprint Review et est renvoyé dans le Product Backlog pour être repris dans un futur sprint. Il est possible également que certains aspect de cet incrément soit revu.