Paraphrasant un concept bien connu en gestion de projet, on pourrait dire: « La planification est indispensable, mais les plans sont inutiles. Par conséquent, inspectez et adaptez. »
Les plans traditionnels sont déterminés par des dates – très probablement, la date de fin étant le principal facteur moteur. Dans la gestion de projet traditionnelle, vous rassemblez les exigences de vos parties prenantes, construisez la portée du projet et décomposez le projet en tâches gérables. Ceci, à son tour, crée une structure de répartition du travail (WBS). Ensuite, le niveau le plus bas de WBS, c’est-à-dire les lots de travail, est décomposé en activités. Les activités sont ensuite liées aux dépendances, et les ressources sont estimées et appliquées aux activités pour créer un calendrier de bout en bout pour le projet. Ce calendrier est ensuite surveillé et contrôlé à l’aide d’un plan de gestion du calendrier, qui est généralement un plan subsidiaire du plan de gestion de projet consolidé.
Mais, combien de fois est-il arrivé que ce que vous aviez prévu et ce qui s’est réellement passé sur le terrain correspondent ? Vous connaissez déjà la réponse ! La citation d’ouverture signifie que la planification est essentielle, mais s’attendre à ce que nous puissions suivre exactement le plan n’est pas une chose sage à faire. Lorsqu’il y a des exigences élevées et une incertitude élevée en matière de technologie ou de plate-forme, les PMS suivent généralement des cycles de vie adaptatifs (ou agiles).
En fait, la quatrième valeur du Manifeste Agile dit: » Répondre au changement plutôt que de suivre un plan. »Agile est axé sur le changement, et très probablement, ces changements seront pilotés par les clients. Cela conduit à un concept appelé Planification Agile des versions.
La planification de la libération est différente de la planification traditionnelle, où le plan complet est considéré dès le départ, élaboré en détail et ne peut être modifié qu’avec des demandes de changement formelles. Un plan de publication peut être mis à jour plusieurs fois en fonction des commentaires des itérations précédentes.
Les cycles de vie adaptatifs étant de nature incrémentale, les organisations peuvent les publier à la fin de chaque itération. Ils peuvent également choisir de publier après quelques itérations ou même en continu. Cela nécessite une planification à plus long terme, mais peut être efficacement facilité en utilisant la technique de planification de la libération, qui a été récemment introduite dans la 6e édition du Guide PMBOK.
Pour les aspirants Professionnels de la Gestion de Projet (PMP) et les Associés Certifiés en Gestion de Projet (CAPM), la Planification Agile des versions est un concept clé à connaître. La 6ème édition du Guide PMBOK a introduit des considérations agiles pour chaque domaine de connaissances. Ceci est également utile pour les praticiens certifiés Agiles (ACP) en herbe.
Au fur et à mesure que nous entrons dans ce domaine, voyons d’abord comment les plans de publication sont développés à un niveau élevé.
De la Vision à la Feuille de route en passant par les Plans de publication
Dans les projets Agiles, le travail commence par une vision produit. La vision se traduit ensuite par une feuille de route produit. La feuille de route contient les fonctionnalités à développer sur une période de temps. Vous pouvez également dire qu’une feuille de route représente la portée du produit, qui est livré dans diverses versions. Cela conduit aux plans de libération et est illustré dans la figure ci-dessous.
Feuille de route et carnet de commandes des produits
Un élément de la séquence ci-dessus est la feuille de route des produits, et pour comprendre la feuille de route des produits, nous devons d’abord comprendre le carnet de commandes des produits. Dans les approches Agiles, toutes les exigences – à la fois les exigences du projet et les exigences du produit – font partie du carnet de commandes du produit (PB). Chaque élément du carnet de commandes de produit est appelé un élément de carnet de commandes de produit (ou PBI). Outre les fonctionnalités (exigences), un élément de backlog produit peut être une demande de modification, un défaut, un bogue, un problème ou même un travail technique spécifique.
Comme nous le savons, dans les projets Agiles, les exigences évoluent en permanence et il existe des incertitudes / risques importants. Par conséquent, nous priorisons généralement les PBIS. Les PBI priorisés sont pris en haut du carnet de commandes et livrés au(x) client(s). Les articles hautement prioritaires restent au sommet de l’arriéré et sont à grain fin, tandis que les articles à faible priorité sont au bas de l’arriéré et à grain grossier. La hiérarchisation des éléments dans le PB détermine le niveau de détail de cet élément dans le carnet de commandes du produit. Ceci est représenté dans la figure ci-dessous.
Si vous utilisez des outils agiles tels que Microsoft Project, vous pouvez développer rapidement le backlog produit. Un exemple de carnet de commandes produit, dessiné avec MS Project, est illustré ci-dessous.
Ici, nous avons un carnet de commandes de produits affichant les éléments du carnet de commandes de produits (IPB) de « Créer un nouvel utilisateur », « Se connecter au système de trading en ligne », « Transférer un stock », etc. Si vous souhaitez ajouter un autre élément de backlog, il vous suffit de cliquer sur l’icône « + » de la boîte de commande « Nouvelle tâche ».
Les éléments de niveau supérieur de l’arriéré de produits peuvent être écrits dans des histoires d’utilisateurs, qui sont estimées en points d’histoire – une mesure relative sans unité.
Maintenant, en ce qui concerne la feuille de route du produit, vous pouvez simplement dire qu’il s’agit d’un carnet de commandes de produits avec un calendrier. Une feuille de route décrit l’avenir prévu du projet (c.-à-d. les versions de produits planifiées et / ou proposées) ou les thèmes de publication, en énumérant les fonctionnalités de haut niveau du produit. La feuille de route indique quelles fonctionnalités ou épopées (une épopée, tout simplement, est une grande histoire d’utilisateur) seront livrées dans chaque version.
Plan de publication
La feuille de route du produit pilote les plans de publication. Un plan de publication donne le calendrier de publication – chaque version étant généralement de trois à six mois. Une version contient de nombreuses itérations – de l’itération 0 (itération zéro) à l’itération N. L’itération 0 peut être utilisée pour les approbations de projet, la configuration de l’environnement du projet, la présentation initiale et les discussions de conception, etc. Certains praticiens Agiles utilisent Iteration-H (itération de durcissement), qui est l’itération finale à la fin de la version pour se préparer à la livraison. Cette itération peut inclure des éléments de travail finaux tels que du matériel de formation et de marketing, des notes de version finales, des guides d’installation, des guides système / utilisateur, etc. Ceci est illustré ci-dessous.
Comme indiqué, le plan de publication comporte des itérations – de « Itération-0 » à « Itération–N ». Vous pouvez décider d’avoir une version après quelques itérations et / ou une version finale après la dernière itération.
Le plan de sortie présente une feuille de route de la manière dont l’équipe entend réaliser la vision du projet dans le cadre des objectifs et des contraintes du projet. Il aide le propriétaire du produit et toute l’équipe à décider combien de temps doit être développé et combien de temps il faudra avant d’avoir un produit libérable. Il exprime des attentes quant à ce qui est susceptible d’être développé et dans quel délai. Le plan de sortie peut également servir de guide vers lequel l’équipe peut progresser. Le plan de publication peut être mis à jour à la fin d’une itération, et il reflète les attentes actuelles qui seront incluses, afin qu’elles puissent être livrées lors des itérations suivantes.
Planification des versions avec Backlog produit
Pour mieux comprendre la planification des versions, vous pouvez visualiser les plans de versions à l’aide de product backlog.
Nous savons déjà que les articles du carnet de commandes sont classés ou commandés, en fonction de leur priorité. Les articles de niveau supérieur à grain fin seront prêts à être consommés dans la prochaine itération (sous la prochaine version immédiate). L’arriéré hiérarchisé, avec les fonctionnalités et autres éléments, est affiché sur le côté gauche de la figure ci-dessous.
 |
 |
Dans MS Project, il vous suffit de sélectionner, de faire glisser et de déposer des éléments de backlog et de les organiser selon votre besoin de les hiérarchiser. Ceci est montré sur le côté droit de la figure ci-dessus. Considérant l’exemple précédent montrant l’arriéré de produits dans MS Project, nous avons ce classement relatif: d’abord « Connectez-vous au système de trading en ligne », ensuite « Créez un nouvel utilisateur », puis « Achetez un stock », etc.
Comme indiqué ci-dessus, j’ai sélectionné et fait glisser l’élément de fonctionnalité « Se connecter au système de trading en ligne » et l’ai déposé devant l’élément de fonctionnalité précédent « Créer un nouvel utilisateur. »L’élément sélectionné a été légèrement grisé lorsque je l’ai traîné et laissé tomber.
En utilisant le backlog, vous pouvez décider lequel des éléments du backlog doit être livré dans les prochaines versions. Ci-dessous, nous voyons que les éléments de la prochaine version (c’est-à-dire la version 1) sont principalement priorisés. Les éléments de la version 2 peuvent également être classés par ordre de priorité, mais nous voyons que les éléments de la version 3 ne sont pas classés par ordre de priorité car ce sont des éléments de faible priorité.
Vous pouvez également visualiser la planification de cette version avec MS Project. Regardez la figure ci-dessous. Il est démontré que des IPB sont pris dans diverses versions. Rappelez-vous qu’une version contient des itérations ? Dans notre cas, pour la première version, nous avons trois itérations, et tous les éléments devraient être livrés dans ces itérations. Une itération est appelée sprint dans le framework Scrum, qui est un framework populaire utilisé par les PMS Agiles. Pour les deux prochaines versions (c’est-à-dire la version 2 et la version 3), nous avons les PBIs, mais nous n’avons pas encore décidé des itérations (ou des sprints).
Planification de l’itération
Si vous avez suivi, le plan de publication comprend l’itération 0 à l’itération N et nous pouvons décider de la publier à la fin de quelques itérations ou de chaque itération. Mais que se passe-t-il dans une itération? En termes simples, la portée d’un ensemble de fonctionnalités au sein de l’itération est confirmée au début de l’itération et délivrée à la fin de l’itération.
Les fonctionnalités confirmées et prises pour l’itération sont ventilées en tâches (ou activités) et estimées en heures par les membres de l’équipe. La séquence des étapes allant de la feuille de route du produit au plan de publication en passant par le plan d’itération est illustrée dans le diagramme ci-dessous.
Résumant la figure ci-dessus, ce seront les points clés:
- La vision du produit entraîne la feuille de route du produit
- La feuille de route du produit entraîne les plans de publication
- Un plan de publication comportera des itérations
- Les fonctionnalités, estimées en points d’histoire, sont développées en itération
- Les fonctionnalités sont ventilées en tâches, estimées en heures
En utilisant MS Project 2016, vous pouvez créer rapidement un plan de publication. Compte tenu de notre exemple de backlog précédent, nous avons trois itérations / sprints pour la première version (Sprint 1, Sprint 2 et Sprint 3). Chaque sprint a un ensemble de fonctionnalités à livrer. Ceci est illustré ci-dessous dans la vue « Tableau de planification de sprint ».
Vous pouvez également explorer pour voir ce qui se passe au niveau de l’itération / du sprint et savoir sur quels PBI sont en cours de travail. MS Project le montre dans la vue « Tableau de sprint actuel ». Voir la figure ci-dessous.
Pour Sprint 1, nous avons trois éléments à livrer– « Connectez-vous au système de trading en ligne », « Créez un nouvel utilisateur » et « Achetez un stock ». »Ceux-ci passent par trois états de flux de travail: « Suivant », « En cours » et « Terminé. »Bien sûr, vous pouvez ajouter, supprimer ou personnaliser ces états de flux de travail selon vos besoins.
Plan de Release Vs. Plan d’itération
Si vous passez l’examen, vous devez également connaître les différences entre le Plan de Release et le Plan d’Itération. Ils sont notés dans le tableau ci-dessous. En règle générale, les itérations sont timeboxées pendant deux à quatre semaines. Cependant, dans certains cas, comme XP (un autre framework Agile), les itérations peuvent durer une semaine.
Guide Du Corpus de Connaissances en Gestion de Projet (PMBOK), 6e Édition, par Project Management Institute (PMI)
Je Veux Être PMP: La Manière Simple et Simple D’Être Un PMP, 2e édition, par Satya Narayan Dash
Je Veux Être Un ACP: La Manière Simple et Simple D’Être Un ACP, par Satya Narayan Dash
Leçons En Direct de Microsoft Project 2016, par Satya Narayan Dash
Guide De Pratique Agile, par Project Management Institute (PMBOK) PMI)