Scrum, gestion de projet agile


Un éclairage sur les différences et les convergences de la méthode Scrum avec les processus classiques de gestion de projet définis par PMI.

Devis développement informatique


Comparez 5 devis de professionnels pour vos projets de développements spécifiques

Scrum est la méthode de gestion de projet qui, depuis 2005, s’est répandue le plus largement chez les éditeurs de logiciels et commence à être utilisée sur des projets informatiques d’ingénierie mais également en dehors du domaine informatique, dans l’industrie ou les administrations. En tant que méthode agile, Scrum répond efficacement à des problématiques qui restent des écueils redoutés dans la plupart des projets impliquant conception et innovation : gestion du changement, des risques, des ressources humaines, de la qualité sont adressés efficacement. Scrum est simple et peu couteuse à mettre en place. La formation est rapide et ne suppose pas de compétences spécifiques de la part des participants du projet.

L’adoption de Scrum par une organisation implique toutefois des changements dans les pratiques et les responsabilités des intervenants. Dans sa simplicité, la méthode peut remettre en question certains fondamentaux de la gestion de projet. La comparaison des pratiques Scrum avec les processus classiques de gestion de projet décrits par le PMI (Project Management Institute) dans le PMBOK permet d’apporter des réponses.

Nous allons démontrer dans cet article en quoi Scrum répond aux fondamentaux de la gestion de projet, et expliciter les différences d’approche par rapport à la démarche projet classique.

Les lecteurs désireux d’avoir plus d’informations sur Scrum plus en détail se reporteront aux liens qui figurent à la fin de l’article.

Scrum, une démarche avant tout collective

Scrum signifie « mêlée » en anglais. Le terme est tiré du vocabulaire du rugby, et la métaphore sportive souligne l’importance du collectif dans la démarche projet. Cette dimension intervient au niveau interne à l’équipe projet, mais également en ce qui concerne le pilotage du projet.

Fonctionnement collectif de l’équipe projet :

Dans une équipe Scrum, les points suivant contribuent à développer un esprit d’équipe et à responsabiliser l’individu dans le groupe :
  • Une équipe de 3 à 7 personnes travaillant dans un même lieu physique
  • Le travail se déroule en temps limité, comme pour un match sportif
  • La réalisation est itérative (sprint) et toute l’équipe est mobilisée sur le but de l’itération
  • Au cours d’une itération, l’équipe organise elle-même son travail et personne ne vient perturber son plan de travail (c’est le rôle du Scrum Master d’y veiller)
  • La communication est directe, multidirectionnelle, provoquée lors des « Scrum meetings » quotidiens
  • L’utilisation de post-it déplacés sur un tableau blanc concrétise l’avancement vers le but commun et favorise l’implication et la valorisation individuelle au sein du groupe
  • La réunion rétrospective est l’occasion pour l’équipe de travailler sur des axes d’amélioration à long terme, toujours dans une approche collective

Par opposition, dans un projet traditionnel le chef de projet doit fournir un effort constant pour contrôler l’exécution du travail et la communication, identifier les risques et motiver les membres de l’équipe. Dans Scrum, tout cela s’effectue naturellement au sein du groupe.

Fonctionnement collectif du pilotage du projet

Les méthodes Agiles prônent une collaboration étroite avec le client. Parties-prenantes et utilisateurs sont en contact direct avec l’équipe projet :
  • Le client est directement impliqué dans le travail du projet à travers le rôle du Product Owner
  • Des utilisateurs peuvent participer aux tests du produit en cours d’itération. Ils intègrent alors l’équipe en tant que membres temporaires

L’équipe entière et les parties-prenantes (client, sponsor) sont réunies lors de la réunion de revue de sprint pour :
  • définir le contenu de l’itération (product backlog)
  • valider les réalisations et revoir la planification

Le Product Backlog, du fait de sa forme très simple et concise, est communiqué à l’ensemble des intervenants du projet et constitue un vocabulaire-projet commun à toutes les partie-prenantes et intelligible à tous les niveaux.
Cet aspect de Scrum tend à effacer la frontière traditionnelle MOE/MOA au profit d’une collaboration pragmatique et d’une communication fluide.

Scrum couvre les processus majeurs de la gestion de projet

Voici quelques un des processus clé de la gestion de projet, pour lesquels l’approche Scrum semble de prime abord être assez éloignée de l’approche classique :

Scrum et la gestion du changement

Selon l'approche classique, le plan projet est figé et validé aussi tôt que possible. Il ne doit être modifié qu’au travers d’un processus formel de demande de changement, étude d’impact, validation en commission, planification de la réponse, etc.

Scrum – l’Agilité en général – accueille le changement, c'est-à-dire part du principe que le contenu, comme l’environnement du projet, vont surement évoluer en cours de réalisation. Le plan projet, bien que contrôlé, se construit de manière itérative tout au long du projet.
En réalité, Scrum met en œuvre un processus de gestion du changement : d’une part en interdisant toute modification du périmètre en cours d’itération, et d’autre part à travers la réunion de planification de sprint, au cours de laquelle le plan est révisé et validé pour le sprint suivant. La différence entre les approches ne se situe pas au niveau des processus, mais plutôt dans la conception même du projet : l’approche classique postule que le plan doit être prédictif, là où l’approche agile postule que le produit final du projet n’a pas nécessairement à être prédéfini de façon précise.

Scrum et la gestion du contenu

Scrum limite les spécifications fonctionnelles au « product backlog », simple liste ordonnée de « user stories ». La user story capture un besoin utilisateur en une seule phrase stéréotypée (« l’utilisateur X effectue l’action Y afin d’obtenir le résultat Z »). Une pratique courante consiste à compléter la user story d’une condition d’acceptation (« comment le démontrer ? »), embryon de plan de test. Scrum ne précise pas les modalités d’identification des user stories. Il renvoie pour cela à des techniques de l’ingénierie des exigences. Mais ceci est vrai également pour le PMBOK. Dans les deux cas, on suppose que l’on est arrivé au début de la phase de planification avec une liste d’exigences qui constituent le contenu du projet. Dans Scrum, la constitution du backlog initial s’effectue dans une « itération zéro », correspondant à la phase d’initiation du projet.
La différence d’approche réside, là encore, dans la manière de concevoir le projet. L’approche classique, prédictive, se traduit par la production d’un cahier de spécifications détaillées couvrant la totalité du projet. Ce document, souvent volumineux, est typiquement long à produire, difficile à valider, lourd à maintenir lors de changements intervenant en cours de projet. Scrum se focalise sur la ou les premières itérations et laisse délibérément dans le flou les fonctions de moindre priorité. Le product backlog est un document léger, rapide à produire, conçu pour évoluer facilement et être validé sans ambiguïté.

Scrum et la gestion de la qualité

A l’issue d’une itération Scrum, le produit livré (il ne s’agit que d’une partie du produit final du projet), est réputé être potentiellement exploitable en production. La recette du produit, comme la décision de mettre en production le produit livré, revient en définitive au client, tout comme pour un projet classique.

Qu’est-ce qui rend l’approche Scrum meilleure en termes de qualité du produit ?

On touche ici à la relation étroite qui existe, dans le domaine logiciel, entre Scrum et les pratiques agiles d’ingénierie telles que le Test Driven Development (TDD), ou l’ Acceptance Test Driven Development (ATDD). En effet, la spécification fonctionnelle via les User Stories s’accompagne d’un travail sur les critères d’acceptation de chaque story. La spécification de test vient remplacer la spécification fonctionnelle très tôt dans le projet, en amont du développement. Ceci permet, dans le temps d’une itération, d’effectuer les tests d’une user story dans la foulée de son développement. Par opposition, la gestion de projet classique tend à repousser les tests en fin de phase, ce qui amène à des compromis calendrier/qualité qui sont trop souvent au détriment de la qualité. Notons que la démarche « Développement piloté par les tests » peut tout à fait être mise en œuvre dans le cadre d’un projet classique. Ici encore, c’est la démarche Agile qui fait la différence, pas le processus.

Scrum et la gestion des risques

Scrum met en œuvre un processus de gestion des risques de fait : les différentes réunions permettent d’identifier les risques, d’évaluer leur impact et de décider des réponses à leur apporter. Ceci a lieu au niveau interne à l’équipe, en cours de sprint lors du Scrum Meeting quotidien, ou bien encore au niveau du pilotage projet, lors de la revue de sprint. Bien qu’informelle, cette façon de gérer les risques sans le dire est avant tout efficiente: gérer les risques devient naturel. Avec un peu de recul, on pourrait dire de Scrum que c’est un processus de gestion de risques. La gestion de projet est-elle autre chose qu’une gestion de risques ?

Correspondance Scrum / PMI

Les tableaux suivants proposent des correspondances pour chacun des groupes de processus et domaines de connaissances répertoriés dans le PMBOK.

Correspondance des pratiques Scrum avec les processus PMI

Image

Correspondance des domaines de connaissance PMI vs Scrum :

Image

Auteur :
Olivier DESTRADE

IOCEAN

Devis développement spécifique
  Envoyer à des amis  |  
S'informer Comparer Décider
S'informer Comparer Décider
Powered by Prestataires.com
Powered by Prestataires.com