Méthode de gestion de projet Agile Scrum

Méthode de Gestion de Projet Agile Scrum

 

Nous utilisons pour réaliser la plus part de nos projets, la méthode Scrum, un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ».

Le framework s’appuie sur le découpage d’un projet en boîtes de temps, nommées « sprints ». Les sprints peuvent durer entre quelques heures et un mois (avec une préférence pour deux semaines). Chaque sprint commence par une estimation suivie d’une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé. Avant de démarrer un nouveau sprint, l’équipe réalise une rétrospective. Cette technique analyse le déroulement du sprint achevé, afin d’améliorer ses pratiques. Le flot de travail de l’équipe de développement est facilité par son auto-organisation, il n’y aura donc pas de gestionnaire de projet.

 

Transparence

Scrum met l’accent sur le fait d’avoir un langage commun entre l’équipe et le management. Ce langage commun doit permettre à tout observateur d’obtenir rapidement une bonne compréhension du projet.

 

Inspection

À intervalle régulier, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable.

Ces inspections ne doivent pas être faites trop fréquemment, ou par un inspecteur mal formé : cela nuirait à l’avancement du projet.

 

Adaptation

Si une dérive est constatée pendant l’inspection, le processus doit alors être adapté. Scrum fournit des évènements, durant lesquels cette adaptation est possible. Il s’agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint.

 

Rôles, artefacts et événements

 

Le cadre du scrum consiste en la définition des rôles projets, activités ou artefacts, et réunions ou événements. Ceux-ci sont décrits dans le guide rédigé par les créateurs de la méthode.

 

Rôles

Scrum définit trois rôles : le propriétaire du produit (product owner), le scrum master et le développeur. Il est à noter que le rôle de développeur couvre plusieurs métiers d’une organisation traditionnelle.

 

Propriétaire du produit

Le propriétaire du produit (product owner) est le représentant des clients et des utilisateurs. Il est « responsable de maximiser la valeur du produit et du travail de l’équipe de développement ». Il s’agit d’« une personne et non d’un comité ». Il est seul à orienter l’activité de l’équipe de développement : il ne lui est « pas permis de suivre les instructions d’une autre personne. »

De ce fait, cet acteur se charge de différents rôles et responsabilités.

  • Il explicite les éléments (items) du carnet du produit.
  • C’est lui qui définit l’ordre dans lequel les fonctionnalités seront développées. Il prend les décisions importantes concernant l’orientation du projet.
  • Il s’assure que le carnet du produit soit visible et compris par l’équipe de développement.

Il participe avec l’équipe à la définition de l’objectif du sprint au début de celui-ci (sprint planning). L’objectif peut être fonctionnel, technique ou organisationnel. Si l’objectif devient obsolète pendant le sprint, il a alors la possibilité d’interrompre le sprint en cours.

Dans l’idéal, le propriétaire du produit travaille dans la même pièce que l’équipe. Il est important qu’il reste très disponible pour répondre aux questions de l’équipe et pour lui donner son avis sur divers aspects du produit.

 

Maître de mêlée

 

Le maître de mêlée (scrum master) est responsable de la compréhension, de l’adhésion et de la mise en œuvre du framework. C’est un « leader au service de l’équipe », il assiste chaque rôle de l’équipe scrum dans son activité et promeut le changement des interactions entre les rôles dans le but de maximiser la valeur de ce que produit l’équipe. Son autorité s’exerce sur le processus de développement (définition de la durée des sprints, des modalités de tenues et de l’ordre du jour des réunions scrum…), mais il ne dispose d’aucune autorité sur les autres membres de l’équipe scrum.

Ce n’est pas un chef de projet, ni un développeur, ni un intermédiaire de communication avec les clients. Le rôle de scrum master ne peut pas être cumulé avec celui de propriétaire du produit. Les attributions du « chef de projet » présent dans d’autres approches sont distribuées dans les différents rôles de l’équipe scrum. L’existence du rôle de chef de projet dans un contexte scrum est le signe d’une « méconnaissance fondamentale de scrum » et est perçue comme contre-productive et menant à de « piètres résultats ».

En tant que facilitateur, il aide l’équipe à déterminer quelles interactions avec l’extérieur lui sont utiles, et lesquelles sont freinantes. Il aide alors à maximiser la valeur produite par l’équipe.

Parmi ses attributions :

  • communiquer la vision et les objectifs à l’équipe ;
  • apprendre au propriétaire du produit à rédiger les composantes du carnet du produit ;
  • faciliter les rituels de scrum ;
  • coacher l’équipe de développement ;
  • faciliter son intégration à l’entreprise, surtout si celle-ci n’est pas pleinement agile ;
  • écarter les éléments pouvant perturber l’équipe ;
  • aider l’adoption de la culture agile au niveau de l’entreprise ;
  • travailler avec les autres facilitateurs/animateurs pour coordonner plusieurs équipes, s’il y a lieu.

 

Équipe de développement

 

L’équipe de développement est constituée de 3 à 9 personnes et a pour responsabilité de livrer à chaque fin d’itération une nouvelle version de l’application enrichie de nouvelles fonctionnalités et respectant le niveau de qualité nécessaire pour être livrée.

L’équipe ne comporte pas de rôles prédéfinis ; elle est « structurée et habilitée par l’entreprise à organiser et gérer son propre travail ».

Elle est auto-organisée et choisit la façon d’accomplir son travail, sans que ce soit imposé par une personne externe. Il n’y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble. Ce mode d’organisation a pour objectif d’augmenter l’efficacité de travail de l’équipe.

Elle est pluridisciplinaire et comporte toutes les compétences pour réaliser son projet, sans faire appel à des personnes externes à celle-ci.

L’objectif de l’équipe est de livrer le produit par petits incréments. Ainsi, à tout instant, il existe une version du produit « potentiellement utilisable » disponible.

L’équipe s’adresse directement au propriétaire du produit, et ne prend ses instructions que de lui. Son activité est issue du carnet de produit uniquement. Elle ne peut pas être multi-produits.

 

Évènements

Toutes les activités (sprint, réunions de planning, revues, rétrospectives et mêlées) décrites dans le framework scrum sont effectuées lors de boites de temps.

 

Sprint

Le sprint est une période d’un mois au maximum, au bout de laquelle l’équipe délivre un incrément du produit, potentiellement livrable. Une fois la durée choisie, elle reste constante pendant toute la durée du développement. Un nouveau sprint démarre dès la fin du précédent.

Chaque sprint possède un but et on lui associe une liste d’éléments du carnet du produit (fonctionnalités) à réaliser.

Durant un sprint :

  • l’objet du sprint ne peut être modifié ;
  • la composition de l’équipe reste constante ;
  • la qualité n’est pas négociable ;
  • la liste d’éléments est sujette à négociations entre le propriétaire du produit et l’équipe de développement.

La limitation est d’un mois afin de limiter la complexité et donc les risques liés au sprint.

Si l’objet du sprint devient obsolète pendant celui-ci, le propriétaire du produit peut décider de l’annuler. Dans ce cas, les développements terminés sont revus par le propriétaire du produit, qui peut décider de les accepter. Les éléments du sprint n’étant pas acceptés sont ré-estimés et remis dans le carnet du produit. Un nouveau sprint démarre alors.

 

Mêlée quotidienne

La mêlée quotidienne (daily scrum) est une réunion de planification « juste à temps » et permet aux développeurs de faire un point de coordination sur les tâches en cours et sur les difficultés rencontrées. Cette réunion dure 15 minutes au maximum. Seule l’équipe de développement intervient. Le scrum master peut intervenir comme facilitateur en début de mise en place de Scrum. Toute autre personne peut assister mais ne peut pas intervenir.

À tour de rôle, chaque membre aborde trois sujets :

  • ce qu’il a réalisé la veille ;
  • ce qu’il compte réaliser aujourd’hui pour atteindre l’objet du sprint ;
  • les obstacles qui empêchent l’équipe d’atteindre le but du sprint.

Si le besoin s’en fait sentir, des discussions sont alors menées librement après la clôture de la mêlée pour traiter des sujets levés en séance.

Cette réunion permet la synchronisation de l’équipe, l’évaluation de l’avancement vers l’objectif de l’itération, la collecte d’information nécessaire à l’auto-organisation. C’est le niveau quotidien des principes inspection et adaptation de scrum.

 

Réunion de planification d’un sprint

Toute l’équipe scrum est présente à cette réunion, qui ne doit pas durer plus de 8 heures pour un sprint d’un mois. Pour un sprint plus court, la durée est en général réduite mais peut durer 8h. À l’issue de cette réunion, l’équipe a décidé des éléments du carnet du produit qu’elle traitera dans le cadre de la prochaine itération, et comment elle s’organisera pour y parvenir.

La réunion de planification de sprint (sprint planning meeting) se passe en deux temps. Dans la première partie, l’équipe de développement cherche à prévoir ce qui sera développé durant le prochain sprint. À l’entrée de cette phase, l’équipe doit avoir à sa disposition :

  • le carnet du produit priorisé;
  • la capacité de production (vélocité) prévue pour ce sprint (estimation théorique pour le premier sprint et basée sur la productivité réelle obtenue pour les suivants).

L’équipe et le propriétaire du produit déterminent le but du sprint. Dans un second temps, l’équipe, aidée du propriétaire du produit, se focalise sur la manière dont ses membres atteindront le but du sprint, en découpant en activités d’une durée limitée (généralement une journée au plus) le travail à effectuer pendant le sprint.

 

Revue de sprint

À la fin du sprint, l’équipe scrum et les parties-prenantes invitées se réunissent pour effectuer la revue de sprint, qui dure au maximum quatre heures. L’objectif de la revue de sprint est de valider l’incrément de produit qui a été réalisé pendant le sprint. L’équipe énonce les éléments du carnet de produit sélectionnés en début de sprint. L’équipe fait une démonstration des éléments finis (complètement réalisés). Les éléments non finis (partiellement réalisés) ne sont pas présentés.

Une fois le bilan du sprint réalisé, l’équipe de développement et le propriétaire du produit mettent à jour le carnet du produit en fonction de ce qui a été réalisé (fini). Ils discutent avec les parties-prenantes de l’état courant du projet (budget, financement, conditions du marché), pour ajuster les éléments de carnet de produit et la planification selon les opportunités découvertes.

 

Rétrospective du sprint

La rétrospective du sprint est faite en interne à l’équipe scrum (équipe de réalisation, propriétaire du produit et scrum master). Elle dure trois heures pour un sprint d’un mois. Elle a pour but l’adaptation aux changements qui surviennent au cours du projet et l’amélioration continue du processus de réalisation.

L’objectif est d’inspecter l’itération précédente, afin de déterminer quels sont les éléments du processus de développement qui ont bien fonctionné et ceux qui sont à améliorer. L’équipe de développement déduit un plan d’actions d’amélioration qu’elle mettra en place lors de l’itération suivante.

 

Artéfacts

 

Carnet du produit (product back log)

Le carnet de produit est « une liste ordonnée de tout ce qui pourrait être requis dans le produit et est l’unique source des besoins pour tous les changements à effectuer sur le produit »12. C’est un document qui évolue constamment au cours de la vie du produit et n’est « jamais fini ».

Chaque élément du carnet représente une fonctionnalité, un besoin, une amélioration ou un correctif, auquel sont associées une description, une estimation de l’effort nécessaire à la réalisation de l’élément et une grandeur permettant d’ordonner les éléments entre eux. Le carnet de produit, son évolution et sa publication sont de la responsabilité du propriétaire du produit. Il peut changer à discrétion l’ordre des éléments, en ajouter, modifier le découpage en éléments, modifier leur description, ou supprimer des éléments qui n’ont pas encore été réalisés par l’équipe de développement. Les éléments en tête du carnet de produit sont destinés à être traités dans la prochaine itération et sont les plus finement décrits et estimés. Ils sont dits « prêts » dans la terminologie scrum. Les éléments moins prioritaires peuvent être découpés plus grossièrement en attendant de devenir prioritaires et affinés à leur tour.

L’activité d’affinage du carnet de produit et de ses éléments est effectuée conjointement par le propriétaire du produit et par l’équipe de réalisation. C’est notamment elle seule qui a le mot final sur les estimations des éléments du carnet du produit.

 

Carnet de sprint (sprint backlog)

En début de sprint, un but est décidé. Pour atteindre cet objectif, l’équipe de développement choisit lors de la réunion de planification de sprint quels éléments du carnet de produit seront réalisés. Ces éléments sont alors groupés dans un carnet de sprint.

Chaque équipe met à jour régulièrement le carnet de sprint au cours de son activité, afin que celui-ci donne une vision la plus précise possible de ce que l’équipe prévoit de réaliser pour atteindre l’objectif du sprint. Le carnet de sprint est sous la responsabilité de l’équipe et elle est seule à pouvoir le modifier en cours d’itération.

Incrément de produit

L’incrément de produit est l’ensemble des éléments du carnet de produit finis pendant ce sprint, et aussi ceux finis pendant les sprints précédents. Les éléments sont finis lorsqu’ils remplissent la définition de fini. Cet incrément doit être utilisable, qu’il soit publié ou non.

 

Estimation et planification

 

Éléments de carnet de produit

Les éléments de carnet de produit sont souvent des récits utilisateur (user stories) empruntées à extreme programming. Ces récits sont estimés en points relatifs, sans unité. L’équipe prend un élément représentatif et lui affecte un nombre de points arbitraire. Cela devient un référentiel pour estimer les autres items. Par exemple, un élément qui vaut 2 points représente une complexité double par rapport à un élément qui en vaut 1 (le point n’est pas une mesure de charge car il deviendrait arbitraire). Pour les valeurs, on utilise souvent les premières valeurs de la suite de Fibonacci (1, 2, 3, 5, 8, 13), qui évitent les difficultés entre valeurs proches (8 et 9 par exemple).

L’intérêt de cette démarche est d’avoir une idée du travail requis pour réaliser chaque fonctionnalité sans pour autant lui donner une valeur en jours que le propriétaire du produit serait tenté de considérer comme définitivement acquise. En revanche, on utilise la vélocité pour planifier le projet à l’échelle macroscopique de façon fiable et précise.

 

 

Calcul de vélocité

Une fois que tous les éléments de carnet de produit ont été estimés, on attribue un certain nombre d’éléments à réaliser aux sprints successifs. Ainsi, une fois un sprint terminé, on sait combien de points ont été réalisés et on définit alors la vélocité de l’équipe, c’est-à-dire le nombre de points qu’elle peut réaliser en un sprint. Cette vélocité part du postulat que l’équipe est suffisamment stable d’un sprint à l’autre (en termes de présence humaine et de renouvellement des collaborateurs). À défaut, on peut utiliser une vélocité relative (par opposition à la vélocité habituelle, alors absolue) qui rapproche le nombre de points réalisés à la présence effective de l’équipe (en jours / homme). Cette pratique permet notamment d’aborder les sprints des périodes de congés en adaptant l’engagement de l’équipe.

En partant de cette vélocité et du total de points à réaliser, on peut déterminer le nombre de sprints qui seront nécessaires pour terminer le projet (ou la release en cours). L’intérêt est d’avoir une vision de plus en plus fiable (retours d’expérience de sprint en sprint) de la date d’aboutissement du projet, tout en permettant d’aménager les éléments de carnet du produit en cours de route.

 

Éléments de carnet de sprint

Les éléments de carnet de sprint sont généralement exprimés en heures et ne doivent pas dépasser deux journées de travail, sinon il convient de les décomposer en plusieurs éléments. Par abus de langage, on emploie le terme de tâches, les concepts étant très proches.

 

Lancement du projet

Scrum présuppose que le carnet de produit est déjà défini au début du projet. Une approche possible pour constituer ce carnet est de réaliser une phase de lancement. Cette phase de lancement s’articule autour de deux axes de réflexion : l’étude d’opportunité et l’expression initiale des besoins.

L’étude d’opportunité est très variable d’un projet à l’autre, tout dépend du contexte de l’entreprise, de la nature du projet (sous-traitance ou interne), etc. Chaque entreprise a sa propre politique sur cette activité.

L’expression initiale des besoins n’est pas un élément défini dans scrum, et n’est pas une activité de contractualisation d’un cahier des charges. L’esprit d’une telle activité dans les méthodes Agiles est de définir d’une part le cadre du projet (pour que l’équipe s’imprègne du contexte métier) et d’autre part une première analyse globale des besoins. L’objectif est d’identifier un maximum de fonctionnalités que le logiciel devra implémenter, en se limitant à un niveau de précision assez grossier. On peut par exemple utiliser une approche par raffinages successifs, en partant des secteurs métier concernés par l’application, puis en identifiant les activités métier, qu’on décompose en tâches métier qui correspondent à des fonctionnalités que l’on doit/peut ou non implémenter dans le logiciel final.

L’objectif pour scrum est de produire la première version du carnet de produit.

 

Vue globale