Guy Paquet Gestion de projet et agilité - Expérience de l'Agence de Revenu Constats  Ne pas toujours attendre que toutes les conditions de succès soient réunies  Exige de l’adaptation et beaucoup de volonté. Mais les ressources en veulent!  Les développeurs ont évolué… et l’outillage de développement aussi!  Les PM doivent évoluer :  Au fil des années, les chargés de projet sont devenus des gestionnaires « fonctionnels ».  La gestion de projet visait (et vise toujours) à livrer MALGRÉ les règles administratives.  Les difficultés avec le matriciel ont toujours existé.  Les chargés de projet sont maintenant responsables d’appliquer les règles qui ont été insérées dans les cadres de gestion de projet et de développement…  L’Agilité vient défier cette façon de gérer.  Viser la qualité, la valeur d’affaires et la pérennité et non le respect d’une méthode….  On annonce un succès

1. Gestion de projet et Agilité :
Expérience de l’Agence du Revenu
Guy Paquet et Guy Rochette
13 janvier 2015

2. Mise en garde
« La présentation, les interprétations et conclusions partagées lors de cette rencontre
n'engagent que leurs auteurs et ne reflètent pas nécessairement les points de vue de l’Agence du
Revenu du Québec.
Le contenu est diffusé uniquement à des fins d'information. Les auteurs n'offrent aucune
garantie quant à l'exactitude et à l'exhaustivité du contenu. Ils ne peuvent également pas
endosser de responsabilités pour les éventuelles informations erronées, ni pour la disponibilité
des informations publiées. »
« Ceci n’est pas un cours sur l’Agilité. »
Cette présentation comporte des
nouveautés, des prises de position et un
langage pouvant ne pas convenir à un
public de tous âges. Une ouverture
d’esprit et une maturité de l’auditoire sont
conseillées.

3. Plan de la présentation
 Réchauffement : mise à niveau sur l’Agilité
 Mise en contexte : le projet
 L’apprentissage
 Constats
 Questions

4. Réchauffement : mise à niveau sur l’Agilité
 Forme habituelle :
Chargé de projet vs Scrum Master :
la même chose?
Analyste d’affaires vs PO?
Architectes?
Le triangle?
La gestion du changement?

5. Réchauffement : mise à niveau sur l’Agilité
 Une nouvelle approche de réalisation axée sur :
 Des communications « face à face » plutôt
qu’utiliser la documentation
 Des livraisons fréquentes
 La qualité vs efficience : respect de la valeur
d’affaires incluant la pérennité
 La facilitation de la re-priorisation
 Des équipes autogérées
Thierrycros.net

6. Mise en contexte : le projet
 Révision majeure d’un programme essentiel à RQ
 Révision des processus, de l’organisation du travail, du langage de programmation, etc.
 Plus de 25 M$, architecture détaillée de plus de 1,5 M$ réalisée.
 Avant-projet : plus de 2 ans et réalisé selon l’approche traditionnelle jusqu’à l’architecture détaillée
 Réalisation sur 36 mois
 Avancement : 14/36 mois complété. Démarrage de la réalisation en Agile
 500 utilisateurs
 Forte visibilité dans l’organisation
 Envergure :
 7 équipes de 8 à 10 membres + 23 équipes contributrices pour autres systèmes + fonctions horizontales
 Équipe d’essais d’environ 7 personnes
 Équipe de gestion du changement de 4 personnes
 Bureau de projet 1 personne

7. Mise en contexte : le projet
 Premier projet d’envergure à utiliser l’Agilité et l’intégration continue
 On bâtit le projet et l’Agilité au fur et à mesure
 Environnements de développement doivent évoluer : on introduit l’intégration continue, le
TDD, …
 Nouveaux rôles pour tous les membres des équipes
 Indicateurs de gestion à redéfinir
 Recours à des coachs agiles et à l’expérience d’un gestionnaire pour y arriver.

8. Mise en contexte : le projet
 Selon les « meilleures pratiques », on doit :
 introduire progressivement l’Agilité avec un projet de petite
taille;
 limiter fortement le nombre d’équipes;
 limiter le nombre de membres par équipe.
 En bref : attendre les conditions gagnantes.
 Et pourtant, le projet avance! Non sans rencontrer des
difficultés, mais il avance!

9. Actuellement
 Un retard d’environ 10% sur la valeur acquise (sensiblement équivalent à un projet
traditionnel)
 Respect prévu de la date de fin
 Respect prévu du budget
 Beaucoup de changements dans l’organisation du projet

10. L’apprentissage
Perceptions Réalité
Le fait d’avoir une architecture détaillée
va faciliter la réalisation du projet
Les limites des approches traditionnelles sont ressorties : beaucoup de
documents approuvés, mais on ne sent pas vraiment une maîtrise ou
même une forte compréhension du projet de la part de tous les
intervenants.
Un exercice équivalent à une architecture de vision a été réalisé 12 mois
après le début du projet et en moins d’un mois, on a senti un virage
important dans la compréhension du projet.
La structure de projet selon le cadre de
gestion (voir page suivante)
Une structure de projet allégée, facilitée par les équipes autogérées.
Réduction de 50% des coûts de gestion.
La même stratégie de livraison peut
s’appliquer
Révision de la stratégie en fonction de mettre en production
« rapidement » les éléments à forte valeur d’affaires
Le passage en mode agile va demander
environ 6 mois
On a dû compter sur environ 10 mois. On a livré pendant tout ce temps.

11. Maître d’ouvrage
Maître d’oeuvre
Directeur de
projetTI
Chef de projetTI
Directeur de
projet UT
Chef de projet UT
Chargé de projetTI Chargé de projet UT
Équipes de
réalisationTI
Équipes de
réalisation UT
Comité
stratégique
Comité
directeur
Comité de
gestion
Comité
aviseur
Autres
contributeurs
TI
Autres
contributeurs
UT
Essais
Gestion du
changement

12. L’organigramme
fonctionnel
demeure
Maître d’ouvrage
Directeur de
projetTI
Responsable
Réalisation
Responsable
Carnet de
commandes et essais
Équipes de
réalisation
Comité
stratégique
Comité
directeur
Comité de
gestion
Autres
contributeursEssais
Gestion du
changement
Coordonnateur
contributeursResponsable
Mise en oeuvre
Bureau de
projet

13. L’apprentissage
 L’importance des rituels agiles
 Les DÉMOS
 Les Daily Scrums
 LesWall Sessions (pénibles au début)
 Les rétrospectives et bilans d’itérations
 Le pointage
 Chaque équipe a son étalon
 Le carnet de commandes doit être pointé. On a un horizon de trois
ans…
 Découpage en unités de traitements vs les points vs Stories/Epics…
 Comment donner une vélocité « commune »?

14. L’apprentissage
 Contrôle qualité des ressources
 Compétence
 Savoir-être
 Stabilité vs améliorations : changements de joueurs
 Comment?
 Examen, implication des coachs, des SM, des architectes, ….
 La planification (oui on a MS Project, mais d’autres outils aussi)
 Passage d’un plan selon livraisons et «WBS » à plan selon capacité et itération
fixe
 Gestion du « pour finir » du projet par les points, et non par les j-p
 Gestion du « pour finir » des tâches par les équipes, et non par les chefs de projet
 Conversion j-p ($) en points
 Coût d’un point

15. L’apprentissage
 Reddition de comptes
 Sunset Graph
 Intégration suivi agile
avec suivi traditionnel
 Évolution du carnet de
commandes
 Demandes de
changement
 Réévaluation
 Décisions

16. Constats
 Ne pas toujours attendre que toutes les conditions de succès soient réunies
 Exige de l’adaptation et beaucoup de volonté. Mais les ressources en veulent!
 Les développeurs ont évolué… et l’outillage de développement aussi!
 Les PM doivent évoluer :
 Au fil des années, les chargés de projet sont devenus des gestionnaires « fonctionnels ».
 La gestion de projet visait (et vise toujours) à livrer MALGRÉ les règles administratives.
 Les difficultés avec le matriciel ont toujours existé.
 Les chargés de projet sont maintenant responsables d’appliquer les règles qui ont été insérées dans les
cadres de gestion de projet et de développement…
 L’Agilité vient défier cette façon de gérer.
 Viser la qualité, la valeur d’affaires et la pérennité et non le respect d’une méthode….
 On annonce un succès…

17.  Questions?

18.  MERCI!