SCRUM

SCRUM

 
Pour rappel Scrum est une méthode agile dédiée à la « gestion de projet ». Cette méthode de gestion, ou plutôt ce Framework de management de projet, utilisé à Rintio dans l’intégration des applications mises en place et à pour objectif d’améliorer la productivité de son équipe. 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.

La création de frameworks de développement logiciel hybrides couplant Scrum et d’autres frameworks est commune puisque Scrum ne couvre pas le cycle de développement de produit. Par exemple, on pourra utiliser des pratiques issues de l’extreme programming, de la phase de construction structurée de la méthode RAD, ou un ensemble de pratiques de qualité du logiciel émergeant du vécu de l’équipe projet.

Caractéristiques

Le cadre de travail Scrum est fondé sur la conviction que le développement logiciel est une activité par nature non-déterministe et que l’ensemble des activités de réalisation d’un projet complexe ne peut être anticipé et planifié7. C’est en cela que Scrum s’oppose aux démarches prédictives telles que le cycle en V. Pour répondre à cette imprédictibilité, la méthode Scrum propose un modèle de contrôle de processus fondé sur l’empirisme, via l’adaptation continue aux conditions réelles de l’activité et une réaction rapide aux changements. L’analyse des conditions réelles d’activité lors des retrospectives de fin de sprint et le plan d’amélioration continue qui en découle sont réalisés à intervalles de temps réguliers, donnant lieu à un cycle de développement incrémental (Sprint).

Le cadre de travail Scrum a été conçu lors de projets de développement de logiciels. Il peut aussi être utilisé par des équipes de maintenance. Dans le cas de très grands projets, les équipes se multiplient et on parle alors de scrum à grande échelle (ex. : le scrum de scrums ou LESS). Le cadre de travail Scrum peut théoriquement s’appliquer à n’importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but commun comme planifier un mariage, gérer des projets de recherche scientifique, des écoles et même des églises comme le précise le site de l’un des co-créateurs Jeff Sutherland.

Un principe fort des méthodes agiles est la participation active du client. Cela permet de choisir plus finement les fonctionnalités réalisées à chaque incrément. Avant le démarrage du sprint 1, les objectifs sont définis lors d’un sprint 0. La mêlée (scrum meeting) a lieu quotidiennement et des réunions spécifiques permettent de lever les obstacles bloquants. Le sprint a une durée variable (idéalement deux semaines). Après chaque sprint, une démonstration suivie d’une rétrospective ont lieu. Le propriétaire du produit peut à tout moment compléter ou modifier la liste des fonctionnalités à produire pour les prochains sprints. Sans modifier le but du sprint en cours, celui-ci peut être affiné et faire l’objet d’une renégociation entre le propriétaire du produit et l’équipe de développement à la suite de nouvelles connaissances. Si le but du sprint devient obsolète, le propriétaire du produit a la capacité d’annuler un sprint en cours.

Chaque sprint constitue donc un incrément, facilitant le pilotage du projet. La notion d’itération couvre l’adaptabilité au quotidien. Cette adaptabilité est limitée par le but immuable d’un sprint.

Les trois piliers de scrum

Scrum est un processus empirique : il se base sur l’expérience du terrain. Il s’appuie sur trois piliers.

Il suit également les principes de la culture agile.

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.

 

Le « package » Scrum

Processus de la méthode Scrum

                                                    Processus Scrum

Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d’une définition des rôles, de réunions et d’artefacts.

Scrum définit 3 rôles :​

  • – Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le client).
  • – Le « Scrum Master » garant de l’application de la méthodologie Scrum.
  • – L’équipe de développement qui réalise le produit.

La vie d’un projet Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps (timeboxing):

  • Planification du Sprint (Sprint = itération) : au cours de cette réunion, l’équipe de développement sélectionne les éléments prioritaires du « Product Backlog » (liste ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu’elle pense pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
  • Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l’équipe de développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks du Product Owner et des utilisateurs finaux. C’est également le moment d’anticiper le périmètre des prochains sprints et d’ajuster au besoin la planification de release (nombre de sprints restants).
  • Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint est l’occasion de s’améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du « vécu » sur le sprint écoulé (principe d’amélioration continue).
  • Mêlée quotidienne : il s’agit d’une réunion de synchronisation de l’équipe de développement qui se fait debout (elle est aussi appelée « stand up meeting ») en 15 minutes maximum au cours de laquelle chacun répond principalement à 3 questions : « Qu’est ce que j’ai terminé depuis la dernière mêlée ? Qu’est ce que j’aurai terminé d’ici la prochaine mêlée ? Quels obstacles me retardent ? »

Fonctionnement des méthodes agiles

Les méthodes agiles partent du principe que spécifier et planifier dans les détails l’intégralité d’un produit avant de le développer (approche prédictive) est contre productif. Cela revient à planifier dans les détails un trajet « Paris – Narbonne » en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l’heure de passage associée, chaque rue empruntée dans les agglomérations, litres d’essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d’arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc.

L’idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu’à atteindre la destination finale. On parle donc d’une approche empirique. Dans le cadre d’un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l’équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global.

L’équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c’est nécessaire, de développement et de test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l’alignement sur le besoin. L’utilisateur final quant à lui peut se projeter dans l’usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt.

Si le client a priorisé avec soin son besoin, il peut saisir l’opportunité d’accélérer le « time to market » si il estime que le produit en l’état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développées (prévues pour les itérations futures). Afin de retarder une fonctionnalité dont le besoin n’est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d’une autre (respectant ainsi budget et délais), etc.

Cette souplesse ainsi offerte est donc un véritable atout pour le client.

La contractualisation agile

La contractualisation d’un projet agile n’est pas la partie la plus facile étant donné que le périmètre est par définition variable. La régie ferait bien l’affaire mais difficile de rassurer le client avec un tel contrat. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Malheureusement pour le fournisseur – dans le cadre d’un forfait classique – tous les risques sont pour lui (aussi bien sur un projet agile que sur un projet traditionnel). On peut limiter ces risques en prenant quelques précautions, mais on limite également la souplesse offerte par une approche Agile.

Cela ne veut pas dire qu’il n’existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d’arrêter le contrat à la fin de chaque itération est assez intéressante. Ainsi que le principe de troc d’exigence : réalisation d’une exigence imprévue en échange du retrait d’une autre moins importante, de priorité faible et de même coût.

Tags: