Qu’est-ce que la gestion de projet ? Si ce terme parait simple pour toute personne déjà dans le monde actif, ce n’est pas nécessairement le cas pour ceux qui découvrent le monde professionnel.
Etant sur un blog agile, nous allons d’ailleurs profiter de l’article pour comprendre comment la gestion de projet a basculé en agile ; et qu’elles sont les différences par rapport aux méthodes traditionnelles.
Gestion de projet – définition
La gestion de projet est un mode de fonctionnement des entreprises permettant de faire émerger des produits, services ou solutions sur le marché. Ce mode de fonctionnement est structuré par des méthodes, des pratiques et des outils adapté à l’émergence de ces produits.
Définition officielle de projet
Sachez que l’Afnor a définie la notion de projet avec l’ISO 10006-1997 écrit ci-dessous :
» un ensemble d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans le but d’atteindre un objectif conforme à des exigences spécifiques «
Et si les agilistes tentaient de creuser cette définition, ils pourraient finalement ne pas se retrouver dans cette définition.
Gestion de projet agile ?
Du coup, peut-on parler de gestion de projet agile ? Et c’est une véritable question que nous allons creuser ici.
1/ « un objectif conforme à des exigences spécifiques » -> en agile l’objectif change régulièrement. D’ailleurs en scrum, nous créons un objectif pour chaque itération. Doit-on dire que chaque itération représente un projet à part entière ?
Décortiquer la définition est peut-être exagéré à première vue mais en réalité, nous nous apercevons que ce n’est pas dénoué de sens.
En agile, on fait de la gestion de produit
En effet, en agile nous préférons parler de « mode produit » et d’éliminer peu à peu ce terme de « gestion de projet ». Pourquoi ?
Un projet peut correspondre à toute idée engagée, hors en agile, nous focalisons le travail sur des produits (services/solutions). Alors, vous allez me dire qu’on fait aussi de la gestion de projet sur des produits… Oui en effet mais c’est différent.
Pas convaincu ? Vous avez raison, je dois expliquer avec un exemple concret.
Fonctionnement produit
En agile, nous allons de plus en plus vers des équipes travaillant sur des applications qui offrent de la valeur directement aux utilisateurs. Si une application centrale (fournisseur de données sous forme d’API) existe, on va privilégier que l’équipe produit la modifie selon ses besoins. Cela permet à l’équipe d’être 100% autonome.
Ce type d’organisation a encore beaucoup de mal à s’ancrer dans les entreprises, car les manager ressentent un besoin de mettre une équipe dédiée à cette application centrale… Ca rassure.
Cependant, certains diront que l’application centrale a pour client les autres applications… Ca peut s’entendre.
Mais cette répartition marche moins bien car l’équipe de l’application centrale devra mettre en attente les demandes pour répondre aux différents besoins ce qui ralenti tous les projets liés à cette application. Ce n’est vraiment pas optimal.
Les craintes sont que l’application centrale soit modifiée sans la moindre rigueur et qu’une modification peut casser le service des autres produits.
Plusieurs solutions :
- plateforme microservices pour que chaque fonctionnalité soit indépendante des une des autres
- rajouter un concept d’alignement des compétences liées à cette application centrale dispersées dans différentes équipes. En Spotify on peut comparer cela à un chapter.
- Ce chapter doit mettre en place une definition of done solide sur cette application centrale
Oui cela peut faire peur au début mais c’est un fonctionnement beaucoup plus optimal. Comme dans tout type d’organisation, il sera important que les équipes trouvent les bonnes règles de fonctionnement.
Soyez le premier à commenter