Dans le développement logiciel on avait l’habitude de travailler avec une méthode qui partait d’un besoin en les analysant de la manière la plus exhaustive possible, d’écrire un cahier des charges pour en définir la manière la plus précise possible puis de développer en se basant sur ce cahier des charges jusqu’à ce que le projet soit fini. Le problème est que souvent, le produit fini ne correspondait pas aux besoins. La difficulté est de savoir exactement ce dont on a besoin de bien l’exprimer. Mais les besoins peuvent changer. Cette façon de travailler
Une autre manière de travailler est venue en prônant 4 grandes valeurs : Les personnes sont plus important que les outils, les logiciels opérationnels plus que la documentation, la collaboration avec les clients plus que les négociations et l’adaptation aux changements. Ce sont les principes de l’agilité.
L’idée est de se concentrer sur le produit finie et d’avoir des retours le plus souvent possible pour coller au plus près du besoin. L’autre idée est d’avoir une équipe auto géré.
Scrum est un cadre de travail pour la méthode agile.
Qu’est-ce que SCRUM
Scrum est un cadre de travail (Framework) pour le développement, la livraison et la maintenance de produits complexes.
Scrum est fait pour des problèmes complexes. Il s’adapte en continue et améliore régulièrement le produit l’équipe et la façon de travailler
Scrum n’est pas en soi un processus, une technique ou une méthode définitive
Scrum est utilisé pour développer des logiciels, du matériel, des réseaux, des véhicules autonomes, des écoles, des gouvernements, du marketing, gestion des organisations bref tout ce qui est complexe
Théorie : l’empirisme
Scrum est basé sur l’empirisme qui affirme que la connaissance provient de l’expérience, la prise de décision est basée sur des faits connus. Son approche itérative et incrémentielle
Scrum c’est 3 piliers, 5 valeurs, 3 rôles, 3 événements et 3 artéfacts.
3 Piliers
- Transparence: Les aspects du processus doivent être visibles à tous les intervenants. Il faut donc une définition d’un standard commun pour une bonne compréhension (ex qu’est-ce qu’on comprend par fini)
- Inspections fréquentes: les utilisateurs doivent inspecter les documents pour suivre l’avancement du projet par rapport aux objectifs (sprint goal)
- Adaptation: en cas de dérive, un ajustement doit être fait.
Pour cela 4 évènements sont prévus
- Le Sprint Planning : planification du Sprint
- Daily SCRUM : mêlée quotidienne
- Sprint Review : Revue du sprint
- Sprint Retrospective
5 Valeurs
- L’engagement (Commitment)
- Le courage: un échec est un moyen d’apprendre. L’échec n’est pas trop grave à cause des itérations fréquentes
- La concentration (Focus): Concentration sur l’objectif
- L’ouverture (openness): Ouverture voir le pilier sur la transparence
- Le respect (Respect): écouter, prendre en considération les opinions des autres tout en partageant sa vision
Les 3 rôles
Une équipe Scrum est composé d’un Product Owner, de développeurs et d’un Scrum Master. Elles sont autogérées.
Le responsable du produit (Product Owner)
C’est le responsable du produit. C’est lui qui gère le Backlog Product. Il doit bien avoir en vue ce qui est important (ce qui a de la valeur) pour l’ordonnancement
- Il doit avoir la vision du produit et la partager
- Expression claire du Backlog Product
- Ordonnancement : structure et ordre dans le but de réaliser les objectifs (value organiser)
- Optimisation du travail des développeurs
- Rendre le Backlog Product visible par tous (transparence et inspection)
- S’assure que les développeurs ont compris
Il est seul à décider des priorités et du contenu du Backlog Product. Si quelqu’un veut ajouter un élément il doit passer par lui.
Il fait le suivi de l’avancement vers le produit fini au moins une fois par sprint.
L’équipe de développement (Development Team)
L’équipe travaille pendant le sprint pour fournir un incrément fini publiable. L’équipe de développement s’organise elle-même.
- Auto organisation. Décident elle-même comment faire
- Pluridisciplinaire multi compétences
- Pas de titre
- Pas de sous équipes
- Pas de responsabilité individuelles mais c’est une responsabilité collective de l’équipe
Nombre : entre 3 et 9 car si le nombre est trop faible il y a un risque d’avoir des limitations de compétences et si c’est trop grand, il faut faire trop de coordination et c’est moins efficace.
Le Scrum master : le conducteur serviteur
Il est au service des développeurs, du Product Owner et de l’organisation. Il fait la promotion de SCRUM pour tous comprennent bien la théorie, les pratiques et les règles. Il facilite les choses et détecte les freins.
- Au service du Product Owner : Est-ce que les objectifs sont bien compris ? Le Backlog Product est-il compris par l’équipe ? Comprendre la planification ? Organisation du Backlog Product Faciliter les événements si besoin, Il aide à trouver des bons outils.
- Au service de l’équipe de développement : coach pour l’auto organisation – aide l’équipe pour avoir un produit de grande valeur – Supprime les obstacles à la progression – Facilite les événements si besoin – forme sur Scrum. Il veille à ce que les réunions ait bien lieu et soient efficaces et pas trop longues.
- Au service de l’organisation : accompagne dans l’adoption de Scrum – planifie des implémentations – accompagne l’organisation dans les changements pour augmenter la productivité – collabore avec d’autres Scrum Masters
Les 3 événements (réunions)
Le but est de cadrer les réunions pour éviter une perte de temps.
Le Sprint contient est un évènement mais il contient d’autres évènements. La durée du sprint ne peut pas être changer. La durée des autres évènements peuvent se terminer si leur objectif est atteint. Chaque évènement sont conçus pour permettre la transparence et l’inspection. Chaque évènement est une occasion d’inspecter et d’adapter.
Le sprint
Le sprint est au cœur de Scrum. Durée 1 mois maximum. A la fin du Sprint un incrément Produit fini fonctionnel et publiable est créé. Un nouveau Sprint commence dès que le précédent est fini.
Un Sprint comprend : un Sprint planning, des Daily Sprint, du développement, une Sprint Review et une rétrospective Sprint.
Un sprint est fixe : on ne fait pas de changement dans la durée. L’objectif est la qualité. Le Product Owner est toujours présent pour aider l’équipe de développement à bien comprendre ce qu’il faut faire.
Chaque Sprint est un projet d’un mois ayant pour objectif de faire un incrément.
Le Product Owner peut annuler un Sprint si l’objectif est obsolète par exemple si l’organisation change de direction. Il n’a donc plus de sens. Il est le seul à avoir ce pouvoir.
La planification (Sprint planning)
Ce travail est fait par tous les membres de l’équipe Scrum.
Durée maximum 8 heures
Le Scrum Master veille à ce que l’événement ait lieu et que tous en comprennent le but. Il fait attention à sa durée. Il y a deux parties dans cette planification
Première partie : que va-t-on faire ?
L’équipe de développement s’occupe des fonctionnalités à développer. Le PO lui se focaliser sur l’objectif et des éléments du Backlog qui seront fait. On se base sur la Backlog Product et le dernier incrément. L’équipe de développement doit se projeter pour évaluer ce qu’elle pourra faire.
Deuxième partie, comment va-ton faire ?
L’équipe de développement décompose le travail par jour ou moins. Le travail pour les premiers jours et déjà bien défini. Il faudra bien détailler les premiers jours quitte à laisser des tâches grossières pour après. On va dégrossir les choses après au fur et à mesure de l’avancement du travail.
Le Product Owner aide à la clarification du Backlog Product. Il y a négociation avec l’équipe de développement lui si il y a trop ou pas assez de travail.
D’autres personnes peuvent être invités pour apporter des conseils techniques ou des compléments d’informations fonctionnelles sur le métier
A la fin de la planification, l’équipe devrait pouvoir expliquer au Product Owner et au Scrum Master COMMENT elle s’organise pour réaliser l’objectif.
Sprint Goal : l’objectif du sprint
Durant ce Sprint Planning on fixe l’objectif du sprint (Sprint Goal). L’équipe aura ce but en tête et cela l’aidera à être plus motiver et produire un meilleur travail.
Daily Scrum
C’est une réunion coute quotidienne pour l’équipe de développement qui aura lieu à la même heure et au même endroit, sa durée est de 15 mn maximum. Le but est de faire un point pour que tout le monde soit informer de l’avancement du projet. Chacun partagera ce qu’il a fait et ce qu’il va faire aujourd’hui et si il y a un problème. Cette réunion n’est pas prévu pour de longue discussions.
Le Scrum Master ne participe pas à cette réunion qui est interne pour le développement mais il veille à ce qu’elle ait bien lieu et à ce qu’elle ne sorte pas du cadre. Si il y a des personnes externes, elle écoutent juste.
La revue : Sprint Review (présentation de ce qui a été fait)
A la fin du Sprint l’équipe de développement va présenter quelque chose de montrable. Le responsable du produit va expliquer les éléments qui sont fini. L’équipe de développement va faire la démo des fonctionnalité qu’elle a développé. C’est l’occasion de recevoir les retours des utilisateurs qui vont inspecter l’incrément. On pourra tenir compte des remarques et faire des adaptations pour le prochain sprint. Le Résultat est un Backlog Product révisé. Cet événement dure 4 heures maximum pour un sprint d’un mois.
La rétrospective
Durant cette réunion on va inspecter non plus le produit mais la manière de travailler et l’équipe. Comment le sprint s’est déroulé ? Quels sont les problèmes rencontrés etc.. On va prendre des décisions à mettre en priorité pour améliorer les choses pour le prochain sprint à mettre dans la Sprint Backlog. Cette réunion dure maximum 3 heures et seule l’équipe Scrum y participe.
Les artéfacts (documents)
Ils représentent soit un travail soit une valeur aidant à la transparence pour permettre l’inspection et l’adaptation
Carnet du produit (Product Backlog)
C’est le Product Owner qui en est responsable. C’est une liste des éléments identifiés comme nécessaires du produits. Il est en évolution continue. Il liste les fonctionnalités, les fonctions, les exigences, les améliorations et les corrections.
Les éléments se composent d’une description, d’un ordre, d’une estimation et d’un valeur. La description du test peut y figure pour les valider.
Plusieurs équipes peuvent travailler sur le même Backlog Product.
Product Backlog Raffinement : c’est la raffinement pour ajouter des détails d’estimations et d’ordonnancement. C’est la Product Owner avec l’équipe de Dev qui fait ça. Le temps passé est au plus de 10%.
C’est l’équipe de développement qui est responsable de l’évaluation.
Sprint Backlog
C’est l’équipe du développement qui en est responsable.
C’est l’ensemble des éléments sélectionnés pour le Sprint plus un plan pour livrer l’incrément et réaliser l’objectif du sprint. Qu’est-ce qu’on va faire et comment. Il comprend une amélioration prioritaire identifié lors de la réunion rétrospectives précédente. Le Backlog Sprint est une vue en temps-réel et très visible du travail que l’équipe de développement prévoit d’accomplir durant le Sprint et il appartient uniquement à l’équipe de développement.
Il faut que la progression soit facilement identifiée pour les Daily Sprints.
L’équipe de développement modifie le Backlog Sprint tout au long du sprint
Chaque jour pendant le Daily Scrum, il y a un suivi de la somme de travail qui reste à faire pour évaluer la probabilité d’atteindre l’objectif du sprint.
Incrément
Ce sont les éléments du Backlog Produit qui sont finis durant le sprint (ceux qui ont répondu à la définition de ce qui est terminé) plus ce qui a été déjà livré lors des sprints précédents. On peut le publier. Il est fini. Il faut s’entendre sur la définition de « fini ».
Les artéfacts de transparence
Scrum repose sur la transparence. Si la transparence est incomplète, les décisions peuvent être faussées et engendrer des risques. Le Scrum master est responsable de cette transparence.. Ce travail implique l’apprentissage, la persuasion et le changement. La transparence est un cheminement.
Définition de ce qui est terminé (Definition of Done)
Cette définition doit être la même pour tout le monde à l’intérieure d’une équipe Scrum. Cette définition peut évoluer et être plus juste au fur et à mesure des Sprints.
Si il n’y a pas de définition de ce qui est fini, c’est à l’équipe de développement de la créer. Si plusieurs équipes travaillent sur un même produit il y aura une définition pour le produit. Donc toutes les équipes devront avoir la même définition.
Conclusion
Les rôles, les événements, les artéfacts et les règles sont immuables. Scrum est : léger – simple à comprendre – difficile à maitriser
Trouvez ces informations sur le guide scrum officiel
Le guide scrum existe en plusieurs langues dont le français en version pdf téléchargeable gratuitement.
