La méthodologie Scrum

La méthodologie Scrum

L’agilité, c’est quoi ?

L’Agile Manifesto a été créé pour rassembler un ensemble de valeurs et de principes permettant de définir un nouveau paradigme de développement informatique. Le but est de favoriser un niveau de performance élevé, et garantir des livraisons rapides, tout en s’adaptant à l’évolution constante des besoins en particulier, et à la gestion du changement de manière plus générale. Parmi les méthodes “Agiles” les plus connues on peut notamment citer : l’eXtreme Programming, le Lean, ou encore Scrum.

Le Framework Scrum

Comme son nom l’indique, Scrum apporte un cadre de développement aux projets informatiques, mais s’adapte également à tout autre type de projets. Il est empirique, incrémental, et s’appuie sur trois piliers : Transparence (de l’information entre toutes les parties prenantes), Inspection (du travail réalisé) et Adaptation (au besoin). La dénomination Scrum (mêlée) tient son nom du rugby : l’ensemble des parties prenantes, quelles que soient leur poste (rôle), se regroupent dans le but de “pousser” le ballon (projet) pour transformer l’essai.

Le Guide Scrum défini trois rôles et cinq événements qui encadrent le projet.
Le Scrum Master est le garant de la méthodologie, et agit en tant que facilitateur auprès du reste de l’équipe et des intervenants extérieurs.
Le Product Owner a quant à lui la responsabilité du besoin, et priorise les tâches à la valeur.
Enfin, la DevTeam est responsable de la manière dont seront réalisées les tâches identifiées par le Product Owner. Elle est pluridisciplinaire, et auto-organisée.

Cette équipe s’organise autour du Sprint, durée prédéfinie (typiquement, entre une et quatre semaines, selon l’organisation choisie) qui contient l’ensemble des activités Scrum suivantes. Celui-ci démarre par le Sprint Planning Meeting lors duquel est défini ce qui va être fait, et de quelle manière, avec une priorisation à la valeur. Chaque jour du Sprint, se déroule le Daily Scrum meeting. Il permet à la DevTeam de préparer les tâches du jour, et d’identifier les points de blocage. A l’issue de la période prédéfinie, on procède à la Sprint Review, qui permet de passer en revue l’incrément, de vérifier si le But a été atteint, de faire un feedback, et redéfinir le reste à faire. Le Sprint se conclu par le Sprint Restrospective Meeting, dont le but est de réfléchir aux moyens de s’améliorer en tant qu’équipe. Les Sprints s’enchaînent jusqu’à complétion du projet.

L’apport de Scrum

Scrum se différencie de l’approche classique par son pilotage à la valeur et son adaptabilité. Exit les cahiers des charges immuables et parfois incomplets ou mal compris, les chiffrages sous/surestimés et engageants, les plannings contractuels, et autres engagements figés dès le démarrage du projet.

Dans un projet Scrum, la livraison régulière d’un produit fonctionnel (valorisé) permet de réduire le Time-to-Market. Elle permet également de s’assurer de la bonne compréhension du besoin grâce à l’inspection de chaque incrément, limitant ainsi l’impact des corrections liées à une incompréhension. De la même manière, le client a aussi la possibilité d’adapter son besoin, et de le faire évoluer tout en maitrisant le coût du changement. Par ailleurs, la communication directe et la transparence préconisées dans le Manifeste Agile et le Guide Scrum permettent un niveau d’information homogène au sein de l’équipe, et des échanges fréquents grâce à une disponibilité permanente du Product Owner, garant du besoin et de ses évolutions.

Livraison incrémentale d’un produit fini et fonctionnel : le pilotage à la valeur

Le Product Owner définit la valeur des différentes fonctionnalités du produit. La DevTeam prendra en charge le développement de celles-ci selon la priorisation, en livrant à l’issue de chaque sprint un produit fonctionnel. L’infographie ci-dessous permet d’imager la différence entre un pilotage classique (partie haute), et un pilotage à la valeur (partie basse) :

Le besoin du client est un moyen de locomotion. Dans une approche classique, l’équipe en charge du développement livrera les roues, puis le châssis, l’habitacle, et procèdera au montage final. Ce n’est qu’à la fin du projet que le client pourra profiter de son moyen de locomotion.

L’approche Scrum, mettra en avant la réponse au besoin du client, en livrant à chaque étape un moyen de locomotion fonctionnel, et en y apportant des améliorations au fur et à mesure (direction, motorisation, protection).

Scrum, dans la pratique

Dans cet exemple simplifié, le projet consiste en la conception d’une voiture pour répondre aux besoins du client de se déplacer.

Le Product Owner a la responsabilité de la mise en place du Product Backlog. Il s’agit de l’expression des besoins du client d’un point de vu métier, organisé à la valeur. Ce Backlog est composé de l’ensemble des User Stories (à un instant t) qui décrivent de manière courte un besoin :

• En tant que commercial, je veux pouvoir téléphoner, afin d’optimiser mon temps sur la route
• En tant que responsable financier, je veux un véhicule économique, afin de limiter les coûts de déplacement

Démarrage du premier sprint : Le Sprint Planning Meeting.
Lors de cette réunion, l’équipe Scrum définit le but du Sprint et son contenu à partir d’une sélection de User Stories du Backlog, selon les éléments priorisés par le Product Owner. La DevTeam va alors décomposer les stories en tâches, et définir ainsi le Sprint Backlog, représenté sous forme de Scrum Board, avec une répartition des tâches (sous forme de post-it) à faire, en cours ou terminées. Si on reprend le premier exemple, les tâches seront:

• Ajout d’un micro
• Ajout d’une connexion Bluetooth
• Développer une interface entre le véhicule et le téléphone
• …

L’équipe connait donc son objectif et peut commencer la réalisation de ses tâches.

Chaque jour, la DevTeam se réunie lors du Daily Scrum, autour du Scrum Board, pour faire un point rapide sur le travail accompli depuis la veille, planifier le travail à faire, et remonter les éventuels obstacles.

Une fois le temps imparti au Sprint écoulé, l’équipe va procéder à l’inspection de l’incrément lors de la Sprint Review, en présence des parties prenantes (client) invitées par le Product Owner. Cet incrément doit être un produit fini, fonctionnel, potentiellement livrable (à la discrétion du client). La DevTeam présente les fonctionnalités développées, en détaillant les problèmes rencontrés et les solutions apportées. Les participants organisent la suite du projet (Product Backlog, délais, budget, prochaines priorités, …), afin de fournir un apport important pour le prochain Sprint Planning Meeting.

Le Sprint se conclut par le Sprint Restrospective Meeting, lors duquel l’équipe Scrum va procéder à son auto-inspection, en identifiant les points d’amélioration des parties prenantes, des échanges, des outils, des process, et en planifier la mise en oeuvre.

Le cycle reprend directement par le démarrage d’un nouveau Sprint, jusqu’à épuisement du Product Backlog.

Offre de Service

Partenaire et Spécialiste SAP, Cubis peut vous accompagner dans vos projets Business Intelligence pilotés à la valeur, grâce au Framework Scrum. Nous pouvons également vous assister dans la mise en place de Scrum au sein de projets déjà existants grâce à l’expertise de nos consultants certifiés. Convaincus, mais adeptes de la BI Microsoft ? Notre société soeur Lytix, Partenaire et Spécialiste Microsoft, se tient également à votre disposition.

Contactez-nous pour en savoir plus sur notre offre de service complète !