30 mars 2015

Article

Gestion de projets et processus

Les meilleures pratiques de la gestion de projets agile

Bienvenue à cette quatrième chronique de GPLOGIE® où la gestion de projets agile sera à l’honneur.

La gestion de projets traditionnelle est souvent confrontée à des changements de contenu (scope) faisant suite à l’évolution des besoins des utilisateurs. Dans les technologies de l’information, où tout va vite, les logiciels et systèmes qu’on développe prennent souvent plusieurs mois à concevoir, développer, tester, implanter. Puis, c’est lors de la livraison, à la toute fin, qu’on se rend parfois compte qu’on avait au départ mal ciblé les besoins des utilisateurs ou encore que certains besoins ont évolué, voire radicalement changé en cours de route!

C’est là que la gestion de projets agile intervient!

Tout d’abord, il est important de clarifier ce qu’est la gestion de projets agile.

Définition GPLOGIE® :

La gestion de projets agile est une approche de gestion incrémentale, itérative et adaptative. Contrairement aux approches traditionnelles centrées généralement sur le contenu (livrables), les approches agiles se focalisent sur les délais (timeboxing). Le projet est ainsi découpé en itérations de durée fixe (de 1 à 4 semaines) et le projet est doté d’une date de fin fixe.

Au lieu de tenter de concevoir à 100 % la solution, de développer à 100 % la solution et d’implanter à 100 % la solution (en cascade ou « waterfall »), la gestion de projets agile va livrer progressivement des incréments de la solution qui pourront être implantés, selon la volonté du client-payeur (Product Owner). De plus, l’approche est adaptative et permet de rajouter du contenu au gré du client-payeur, mais, comme le projet a une date de fin fixe, il y a souvent des exigences qui ne seront pas livrées.

Dans les méthodes agiles, l’approche la plus utilisée est le « Scrum ».

Dans cette approche, une équipe multidisciplinaire et autogérée développe progressivement un produit via plusieurs livraisons. Chaque livraison est subdivisée en une série d’itérations (sprints) et chacune de ces itérations va produire un incrément de produit (une série de fonctionnalités ou d’exigences importantes qui génèrent une grande valeur aux yeux du Product Owner).

gestion-agile-schema-scrum

Voici un résumé de ces étapes :

1. Démarrage ou « Sprint 0 » (Sprint zéro)

Une fois le projet approuvé, le Sprint 0 permet au Scrum Master (rôle similaire au chef de projet) et au Product Owner de bâtir l’Équipe Scrum (équipe multidisciplinaire), de construire la Vision du produit (souvent une maquette ou un visuel du produit) et de créer le Backlog du produit (liste de fonctionnalités priorisées et estimées), lequel est découpé en sprints, selon la capacité de l’équipe (vélocité). À partir de ce découpage en sprints, on peut élaborer le Plan de livraison.

2. Planification du Sprint 1

La deuxième étape consiste à produire le Backlog du Sprint 1 : c’est la liste de toutes les tâches nécessaires pour livrer les fonctionnalités incluses dans le Sprint 1, donc pour créer le premier incrément de produit. L’Équipe Scrum s’engage à livrer le tout selon sa capacité.

3. Sprint 1

Lors du Sprint 1, l’Équipe Scrum, le Scrum Master et le Product Owner se réunissent tous les jours le matin (mêlées quotidiennes) afin de faire un suivi des tâches de la journée précédente, de planifier les tâches de la journée à venir et d’identifier les problèmes qu’ils rencontrent. En fonction du reste à faire, le Scrum Master peut produire le Burndown Chart (équivalent du rapport d’avancement).

4. Revue du Sprint 1

Cette étape est très importante! Elle consiste à faire une démonstration (demo), c'est-à-dire à « démontrer » que l’incrément de produit (les fonctionnalités livrées) FONCTIONNE. Cette revue permet d’inspecter le produit, d’aller chercher de la rétroaction des utilisateurs et permet, si nécessaire, à l’Équipe Scrum de s’adapter rapidement aux besoins évolutifs et émergents des utilisateurs.

5. Rétrospective du Sprint 1

Cette dernière étape permet à l’Équipe Scrum, au Scrum Master et au Product Owner de voir si on peut améliorer la démarche Scrum (post-mortem de l’itération), et ce, dès le prochain sprint.

On répète les étapes 2 à 5 jusqu’à ce qu’il y ait assez de fonctionnalités dans le produit pour qu’il puisse être implanté auprès des utilisateurs (livraison).

Et voilà, c’est tout! PRACTICE AND ENJOY!

Pour encadrer la pratique de gestion de projets agile, le Project Management Institute (PMI) a publié la 1re édition du « Software Extension to the PMBOK 5th Edition ». Lancée en 2014, cette norme présente les meilleures pratiques de gestion de projets agile. Le PMI a aussi lancé une certification en gestion de projets agile : ACP (Agile Certified Practitioner).

Pour en savoir plus sur ces meilleures pratiques en gestion de projets agile, inscrivez-vous à la formation intitulée « Gestion de projets agile (GE502) ». Ce cours est basé principalement sur cette norme du PMI.

N’hésitez pas également à lire ou relire les précédentes chroniques de GPLOGIE®.

GPLOGIE : [je-pe-lo-ji] n. f. - la science de la gestion de projet
« GPLOGIE » et « PMLOGY » sont des marques déposées de Carl M. Gilbert

Carl M. Gilbert est le titulaire d'encadrement de choix pour représenter quatre des cursus de cette branche. Impliqué au PMI-Montréal depuis 1996, il comprend parfaitement les enjeux des gestionnaires de projets. Il a formé plus de 15 000 personnes en gestion de projets, tant au PMI® que chez Technologia. Carl est également directeur des programmes certification et formation au PMI-Montréal depuis 1999.