Les valeurs de Scrum

crédits : http://guntherverheyen.com/tag/scrum/

À la suite de la Master Class du mois d’avril sur les principes de la méthode Agile la plus utilisée, Scrum, voici une synthèse de ce qui a été évoqué.

L’origine

Les méthodes Agiles ont été développées dans les années 90 afin de fluidifier la gestion de projet informatique.

Elles replacent, et Scrum en particulier, l’équipe au centre du développement de projet. Scrum est une démarche de gestion de projet avant tout collective qui doit d’ailleurs son nom au terme de rugby anglais : « mêlée ».

Les méthodes Agiles s’articulent autour de 4 valeurs fondamentales

  • Les individus et leurs interactions plus que les processus et les outils ;
  • Du logiciel qui fonctionne plus qu’une documentation exhaustive ;
  • La collaboration avec les clients plus que la négociation contractuelle ;
  • L’adaptation au changement plus que le suivi d’un plan.

Et 12 principes qui en sont la colonne vertébrale

  • Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
  • Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  • Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  • Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  • La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  • Un logiciel opérationnel est la principale mesure d’avancement.
  • Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  • Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.
  • La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  • Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  • À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

La méthode Scrum repose donc logiquement sur l’essentiel de ces points, et fonctionne comme suit :

  • Avec une équipe responsable, en auto-organisation ;
  • Elle propose un avancement du produit par une série de « sprints » d’un mois, ou moins ;
  • Les exigences produit sont définies comme des éléments d’une liste appelée « backlog de produit » ;
  • Il n’y a pas de prescription de pratiques d’ingénierie ;
  • On utilise des règles génériques permettant de créer un environnement agile pour un projet.

Si la méthode Scrum est une méthode de gestion de projet somme toute basée sur des principes de bon sens, il convient néanmoins de connaître l’ensemble de la trilogie qui la compose (les rôles, les événements et les documents nécessaires) ainsi que le vocabulaire utilisé pour apprécier son efficacité redoutable !

Vocabulaire du scrum

Les rôles

Le Product Owner

  • Définit les fonctionnalités du produit ;
  • Choisit la date et le contenu de la release ;
  • Responsable du retour sur investissement ;
  • Définit les priorités dans le backlog en fonction de la valeur « métier » ;
  • Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire ;
  • Accepte ou rejette les résultats.

Le Scrum Master

  • Représente le management du projet ;
  • Responsable de l’application par l’équipe des valeurs et des pratiques de Scrum ;
  • Élimine les obstacles ;
  • S’assure que l’équipe est complètement fonctionnelle et productive ;
  • Facilite une coopération poussée entre tous les rôles et fonctions ;
  • Protège l’équipe des interférences extérieures.

L’équipe

  • 5 à 10 personnes ;
  • Regroupant tous les rôles : architecte, concepteur, développeur, spécialiste IHM, graphistes, ergonomes, testeur, etc. ;
  • À plein temps sur le projet, de préférence ;
  • Des exceptions sont possibles (administrateur…)‏ ;
  • L’équipe s’organise par elle-même ;
  • La composition de l’équipe ne doit pas changer pendant un Sprint.

Les parties prenantes

Les commanditaires, clients, sponsors ou tout autre personne participant de près ou de loin au développement du projet et qui seront associés à son avancée via notamment certaines réunions ou l’accès à certains documents, en toute transparence.

Les événements

schéma d'un projet en scrum

Le sprint

C’est une période variant d’une semaine à 1 mois (majoritairement 2 semaines) permettant à l’équipe de développer un incrément du produit final, potentiellement livrable. La durée est choisie au début du projet et doit rester constante. Chaque sprint possède un but et doit réaliser un certain nombre de fonctionnalités inscrites dans le Product Backlog.

Le daily scrum

C’est une réunion quotidienne, débout, avec l’ensemble des membres de l’équipe et n’excédant pas quinze minutes. Lors de cette réunion, chacun des membres répond à trois questions : « Qu’ai-je fait hier ? », « Que fais-je aujourd’hui ?», et « Quels problèmes ai-je rencontré ? ».

Planification du sprint

  • L’équipe choisit, à partir du backlog de produit, les éléments qu’elle s’engage à finir ;
  • La liste des tâches est créée :
    • Les tâches sont identifiées et estimées (en points-récits)‏ ;
    • Elle est créée collectivement, pas seulement par le ScrumMaster.
  • Cette réunion ne doit pas excéder plus de 2 heures.

La revue de sprint

  • L’équipe présente ce qu’elle a fait pendant le sprint ;
  • Se fait avec une démonstration des nouvelles fonctionnalités ou de l’architecture ;
  • C’est une réunion informelle :
    • Préparation en moins de deux heures ;
    • Pas de slides.
  • Toute l’équipe participe ;
  • On invite du monde.

La rétrospective du sprint

  • Réfléchir régulièrement à ce qui marche et ce qui ne marche pas ;
  • Dure en général de 15 à 30 minutes ;
  • Fait à la fin de chaque sprint ;
  • Toute l’équipe participe :
    • Scrum Master
    • Product Owner
    • Équipe
    • Éventuellement clients et autres intervenants.

Les documents

Le Backlog

plan de backlog
C’est la liste ordonnée de toutes les choses à faire.

  • Il y a le backlog de produit qui énumère les exigences avec le point de vue du client ;
  • Et le backlog de sprint qui contient les tâches de l’équipe.

Le backlog est élaboré avant le lancement des sprints, dans la phase de préparation (ou sprint 0). Il est utilisé pour planifier la release, puis à chaque sprint, lors de la réunion de planification du sprint, pour décider du sous-ensemble qui sera réalisé.

Le Product Backlog

les bacs du backlog

  • Le backlog de produit est la liste des fonctionnalités attendues d’un produit ;
  • Il contient tous les éléments qui vont nécessiter du travail pour l’équipe ;
  • Les éléments y sont classés par priorité ce qui permet de définir l’ordre de réalisation.
    • Les priorités sont définies par le Product Owner ;
    • Elles sont revues à chaque sprint.
  • Il est sous la responsabilité du Product Owner.

Le Sprint Backlog

C’est la liste des tâches sur laquelle l’équipe s’est mise d’accord et qu’elle devra réaliser pendant la durée du sprint.

IMPORTANT : Mettez à jour votre backlog !

  • Avoir un backlog bien entretenu est essentiel et cela passe par une collaboration poussée entre le Product Owner et l’équipe.
  • La présentation du backlog en plusieurs bacs et l’identification des types de story y contribuent fortement.

La story

  • La Story est un élément identifiable du backlog ;
  • Elle correspond à une fonctionnalité dans la gestion de projet traditionnelle, mais contextualisée ;
  • Le périmètre temporel de la story est le sprint.

Il en existe 4 sortes différentes :

  • User Story ;
  • Correction de Bug ;
  • Story Technique ;
  • Remboursement de la dette technique.

Les attributs d’une story

Elle possède généralement un identifiant et une description brève, dès qu’elle est créée.
Ensuite, au cours de sa vie, d’autres informations vont être ajoutées.

Les conditions d’acceptation

Une User Story doit posséder au moins une condition d’acceptation.
Exemple : Pour la story « inscription en ligne à un MOOC », on peut identifier deux conditions :

  • Inscription acceptée – c’est le cas de succès, l’inscription de l’étudiant au MOOC est confirmée ;
  • Inscription refusée – l’inscription est refusée, le nombre maximal de participants ayant été atteint.

La feature

  • Une feature est un ensemble de story ;
  • Le périmètre temporel de la feature est la release.

S’il s’avère lors d’un sprint qu’une story est trop grosse (voir excellent article de Géraldine Legris sur la théorie du hamburger), elle sera soit réduite, soit considérée comme une feature, et par conséquent, découpée en plusieurs story.

La release

schema d'un projet en scrum

La définition de « fini »

  • « Finir » est toujours subjectif et doit être envisagé en équipe afin d’avoir la même signification et les même critères d’acception.
  • La définition de fini a pour objectif d’éviter la dette technique, ou du moins de la limiter, et d’éviter les bugs.

Les outils de mesure

Burndown Charts

Un burndown chart est une représentation graphique du reste à faire dans une période, actualisé aussi souvent que possible et permettant de montrer la tendance.

Planning Poker

  • C’est une façon ludique de produire des estimations sur la complexité de fonctionnalités à développer.
  • L’avantage principal : permettre à tous de s’exprimer librement. L’estimation serait meilleure parce que plusieurs personnes l’auront validée : des participants avec des niveaux d’expérience et d’expertise différents.
  • De plus, cette technique favorise les échanges entre le responsable de produits et l’équipe de développement.
  • L’estimation se fait en unités d’œuvre intitulées points de récits ou « journées idéales » (Ideal Day).

Vie de la liste des tâches

  • Chacun s’engage sur du travail qu’il choisit : le travail n’est jamais attribué par un autre ;
  • L’estimation du reste à faire est ajustée tous les jours ;
  • N’importe qui peut ajouter, supprimer ou changer la liste des tâches ;
  • Le travail du sprint émerge progressivement ;
  • Si un travail n’est pas clair, définir une tâche avec plus de temps et la décomposer après ;
  • Mise à jour du travail restant quand il est mieux connu.

Les bonnes pratiques

  • On adapte Scrum au projet, pas le projet à Scrum ;
  • Une personne ne travaille que dans un seul projet ;
  • On peut se planter ;
  • On a le droit de dire NON !