Introduction à Scrum

Histoire de Scrum

Depuis la publication du rapport "Managing the Development of Large Software Systems" de Winston Royce en 1970, beaucoup ont essayé de trouver une méthodologie qui pourrait éliminer les inconvénients du modèle de développement Waterfall. Une alternative à la "cascade" était la méthode Scrum, qui sera discutée maintenant.

Scrum tire son nom en 1986 du travail de Takeuchi et Nonaki The New Rules for New Product Development. Ce document soutient que le moyen le plus efficace d'atteindre l'objectif est de donner aux développeurs un plan d'action clair.

En 1995, un autre guide, "Software Development with Scrum", de Sutherland et Schweiber, est apparu. Cette publication a depuis été mise à jour plusieurs fois. Maintenant, il est considéré comme le principal guide pour le développement de cette méthode. La version actuelle du Guide Scrum contient des informations mises à jour en 2020.

Les principales dispositions du Guide Scrum suggèrent que le modèle de gestion de projet doit être basé sur le fait que les développeurs livrent le produit fini dans les délais convenus - les sprints. Pour une implémentation réussie de Scrum, il est recommandé d'utiliser une structure composée de plusieurs éléments : rôles, événements, règles et artefacts.

Rôles dans Scrum

Il existe trois rôles dans Scrum, qui forment tous une équipe Scrum :

Le client du produit logiciel est la personne la plus importante du projet, car lui seul comprend pleinement sa valeur pour l'entreprise. Le client explique les besoins des utilisateurs du futur produit aux développeurs, mais il n'est pas responsable de la partie technique du processus de développement. Le client détermine également la priorité lors de la création de certains éléments ou fonctions dans le produit.

Les développeurs se voient confier la mise en œuvre de tâches techniques dont la transversalité dépend du périmètre d'application. Les développeurs sont occupés à créer le backlog de sprint, à écrire du code, à adapter le projet à l'objectif du sprint et à d'autres tâches.

Le Scrum Master est le facilitateur de l'équipe Scrum. Il fournit une assistance au client et aux développeurs. En termes simples, le Scrum Master est occupé à communiquer entre ceux qui ne sont pas impliqués dans le projet et les personnes qui écrivent le code. Parfois différentes équipes de codeurs d'une même grande entreprise communiquent et se coordonnent lors des assemblées générales des scrum masters de ces équipes.

Événements dans Scrum

Il existe 5 types d'événements Scrum :

Sprint est la partie la plus importante de Scrum. Il comprend la planification du sprint, les stand-ups quotidiens (daily scrum), la revue et la rétrospective du sprint.

Planification des sprints. Tous les membres de l'équipe Scrum participent à l'élaboration d'un plan pour le futur sprint. C'est ici que l'idée du produit est présentée et chaque membre de l'équipe peut exprimer son avis, ce qu'il en pense. Ensuite, lors de la réunion, les priorités sont déterminées et les échéances sont annoncées.

Daily Scrum est un événement quotidien de mêlée courte, qui ne dure pas plus de 15 minutes. Habituellement, cela est fait pour planifier le travail des encodeurs pour aujourd'hui ou demain. Au Daily Scrum, vous pouvez discuter des problèmes actuels. Tous les développeurs impliqués dans le projet sont tenus de participer à un tel atelier. La présence d'un Scrum Master est autorisée, mais pas obligatoire.

Sprint Review (Demo) - Afficher les résultats créés pendant le sprint. Habituellement, cet événement a lieu au stade final. Toutes les personnes intéressées y participent.

Rétrospective du sprint - discussion des résultats du sprint. Les membres de l'équipe partagent leur opinion sur la façon dont ils ont fait face aux tâches qui leur ont été confiées et sur la manière d'améliorer les résultats du travail à l'avenir.

De plus, un raffinement du backlog est parfois effectué - Backlog Refinement. Il traite des éléments du backlog, de la préparation du prochain sprint et de la hiérarchisation des tâches en cours.

Artefacts

Les artefacts Scrum sont le travail qui se produit à la fin d'un projet ou d'un sprint. Il existe trois artefacts : le backlog de produit, le backlog de sprint et l'incrément. Chacun d'eux est nécessaire pour la livraison en temps voulu des logiciels aux utilisateurs. Il existe également des artefacts auxiliaires (graphiques brûlés, etc.).

Composants inclus dans les artefacts de sprint :

Backlog de produit - fonctionnalités d'interface et de backend.

Un backlog de sprint est une liste de tâches qui doivent être effectuées au cours d'une itération. Ils sont convenus avant le début du sprint.

Incrément - Le nombre total d'éléments de backlog logiciel créés pendant le sprint et la valeur des incréments qui ont été effectués avant. Le nouvel incrément terminé doit être affiché avant la fin du sprint. Cela signifie que vous disposez d'une version de travail qui répond aux exigences de l'équipe Scrum.

Élément de backlog de produit - il doit être complété lors de l'itération du sprint. En règle générale, l'élément est divisé en plusieurs petites tâches.

L'objectif du sprint est les tâches qui doivent être complétées (créer un élément de backlog ou une autre tâche).

Un burndown de sprint est le travail restant avant la fin du sprint. Le burn down chart est soit ascendant soit descendant. Tout dépend des difficultés auxquelles les membres de l'équipe sont confrontés dans le cadre de leur travail. Ce n'est pas un indicateur de progrès, mais seulement un moyen de résoudre des problèmes et une incitation.

Product Release/Product Burn-Down Chart est un graphique dessiné par le Scrum Master avant la fin du sprint suivant. L'axe horizontal représente les sprints, l'axe vertical représente la quantité de travail restant.

Règles du cadre Scrum

Les rôles, les événements et les artefacts sont à la base de Scrum, mais il existe d'autres règles que celles-ci. Tous améliorent l'efficacité du processus de travail. Voici une liste de ces règles :

• L'équipe scrum comprend le client du logiciel, le scrum master et les développeurs.
• Tous les sprints doivent être de la même durée.
• Après avoir terminé un sprint, le travail sur un nouveau commence immédiatement.
• Un sprint commence toujours par un plan.
• Les membres de l'équipe ont une mêlée matinale au début de leur journée de travail.
• Chaque sprint est revu lors de chaque sprint. Cela améliore la communication entre l'équipe et les parties prenantes.
• Il n'est pas recommandé de modifier le backlog de sprint pendant le sprint.

Les limites de Scrum

Outre les avantages évidents, Scrum présente également des inconvénients :

• Scrum conduit souvent à une diminution de la quantité de travail effectuée en raison de l'absence d'un délai commun.
• Avec une faible implication ou une réticence à coopérer parmi les participants au projet, il y a des chances considérables d'échouer le résultat.
• La structure Scrum est difficile à utiliser dans les grandes équipes, mais c'est toujours possible. Il existe des cadres de mise à l'échelle pour cela : LeSS, SAFe, Nexus et autres.
• Le départ d'un ou plusieurs membres de l'équipe en milieu de projet n'affecte pas très bien le projet.