Planification Agile des Versions dans les Projets Hybrides et Agiles

Lorsque vous travaillez dans un projet agile ou que vous souhaitez utiliser des méthodes agiles, la planification agile des versions peut être une technique essentielle pour les projets centrés sur l’informatique et les produits. La planification agile des versions est répertoriée comme une technique d’ordonnancement dans le PMBOK (Corpus de connaissances en gestion de projet de PMI). Il est donc également pertinent pour la certification Professionnelle en Gestion de projet (PMP).

Bien que cette méthode ne soit pas nécessairement une exigence dans toutes les approches agiles authentiques, c’est un bon outil pour les projets agiles et hybrides pilotés par la publication. En effet, la planification agile des versions peut combler le fossé entre la planification de projet plus traditionnelle et le développement de produits agiles ou itératifs.

Lisez la suite pour en savoir plus sur cette technique.

Comment Fonctionnent Les Versions ?

Une version se compose généralement d’un ensemble de fonctionnalités ou de composants logiciels qui sont développés et testés dans un certain laps de temps. Lors du développement et des tests, ces fonctionnalités sont déployées en une seule fois dans le cadre de la version.

Les versions peuvent inclure des fonctionnalités et des améliorations de logiciels ainsi que des portions et des morceaux de projets de développement plus importants. Par exemple, la mise à niveau d’un système auto-développé ou prêt à l’emploi peut être divisée en différentes versions pour assurer une transition en douceur, la poursuite des opérations et éviter les risques inhérents aux migrations « big bang ».

Qu’est-ce qu’un Plan de libération ?

Le plan de publication est le document qui définit la portée, le calendrier et, dans certaines organisations, les ressources et les coûts liés à une publication.

Un plan de sortie décrit les composants du système qui sont développés, testés et mis en œuvre pendant une période de temps fixe (souvent entre 1 et 6 mois). Le plan de publication peut être considéré comme une liste hiérarchisée de fonctionnalités, similaire aux arriérés de produits dans certains frameworks agiles. Cela nécessite généralement une certaine hiérarchisation car il est souvent vrai que toutes les exigences du système ne peuvent pas être couvertes par une seule version. Cela est particulièrement vrai dans les environnements organisationnels et informatiques plus complexes.

Outre les fonctionnalités ou produits nouvellement développés, un plan de mise à jour peut également inclure des corrections de défauts et des améliorations ou modifications critiques des systèmes existants.

Les plans de publication sont souvent établis à l’avance pour quelques versions à venir (par exemple, des plans pour 4 versions dans un délai d’un an). Cela permet d’attribuer des composants à une version cible en fonction de la priorité individuelle, du risque et de la criticité des fonctionnalités. Habituellement, le plan pour la version la plus proche est détaillé tandis que les plans pour les versions ultérieures ont tendance à être approximatifs. Cependant, ces plans sont normalement affinés et de plus en plus détaillés à mesure que la version respective se rapproche. Ceci est comparable au concept d’élaboration progressive dans la gestion de projet.

Plans de publication dans les projets traditionnels et Agiles

Dans les projets informatiques traditionnels, les plans de publication sont une technique très courante pour gérer le développement et le déploiement de logiciels.

De plus, certains frameworks agiles utilisent des releases et des plans de release. Dans Extreme Programming (XP), par exemple, une version se compose de plusieurs itérations plus courtes et plus faciles à gérer, car les livrables sont divisés en parties plus petites de la portée d’une version.

L’approche générique Scrum, en revanche, définit les sprints au lieu des itérations et des releases qui peuvent prendre entre 2 et 4 semaines. Par conséquent, le développement de logiciels avec Scrum n’implique pas nécessairement les versions et la planification des versions, mais il peut y avoir des versions Scrum dans la pratique (en savoir plus ci-dessous).

Cependant, les exigences sont également gérées dans des listes hiérarchisées: le backlog sprint et le backlog produit sont de telles listes qui sont priorisées dynamiquement par le propriétaire du produit.

Qu’est-ce qu’une Release Candidate dans Agile ?

Une release candidate est généralement définie comme une version logicielle ou un ensemble de fonctionnalités fonctionnelles mais non prêtes à être commercialisées, par exemple pour finaliser les tests et recevoir les commentaires des utilisateurs (source).

Dans la planification agile des versions, une release candidate peut souvent faire référence à une fonctionnalité qui a été développée, est fondamentalement fonctionnelle et est en cours de test au cours d’une itération. Une fois qu’il a été entièrement testé et que toutes les erreurs ont été corrigées, il est inclus dans la version globale.

Si les release candidates échouent lors d’une itération, leur correction d’erreur et leur finalisation sont souvent effectuées lors de l’itération suivante.

Qu’est-ce que la Planification Agile des versions ?

La planification agile des versions fait référence à la définition de la portée et du calendrier d’un projet de développement de produit itératif ou incrémentiel. Il est utilisé dans les projets agiles ou hybrides où une planification à moyen et long terme du développement ou de l’intégration du produit ou du système est requise.

La planification agile des versions est souvent considérée comme le processus de création d’une vue d’ensemble qui relie la vision du produit et la feuille de route au calendrier des versions et la version aux itérations qui utilisent à leur tour un plan d’itération qui définit les fonctionnalités et les tâches à un niveau plus granulaire.

Le terme est mentionné dans le Corpus de connaissances de Gestion de projet du PMI en tant que technique dans le cadre du processus « Développer un calendrier » (PMBOK®, 6e éd., ch. 6.5.2.8). Bien que le PMBOK ait tendance à se concentrer sur les approches de gestion de projet plus prédictives et traditionnelles, cette technique est introduite dans le cadre de PMI pour envisager des projets agiles basés sur l’itération.

Le terme  » agile basé sur l’itération  » est défini dans le Guide de pratique Agile de PMI (ch. 5.2.6). Cela implique une planification initiale (approximative) des itérations, qui sont des parties d’une version. Lorsque l’on connaît plus d’informations permettant une projection plus précise, les équipes agiles replanent leurs itérations pour prendre en compte ce raffinement. Cela peut également nécessiter des ajustements au plan de libération.

Comment la Planification Agile des Versions est-elle utilisée dans la pratique ?

La planification agile des versions peut servir à plusieurs fins, en fonction de l’approche du projet et des exigences organisationnelles

Voici quelques exemples:

Planification des versions dans les projets Agiles

Dans les approches et les projets agiles qui utilisent des versions et des itérations, la planification des versions est une technique permettant de mettre en œuvre la feuille de route du produit dérivée de la vision du produit. La feuille de route du produit contient les exigences de haut niveau divisées en versions.

Le plan de publication définit le nombre d’itérations au sein d’une version. À un niveau plus granulaire, le plan d’itération définit les fonctionnalités à développer dans une version.

Bien que les versions et les plans de publication aient une perspective à moyen et à long terme, les itérations sont beaucoup plus courtes et donc plus étroites en termes de portée. Cela facilite le développement agile et, en particulier, le traitement des commentaires et des modifications à court terme des exigences et des fonctionnalités.

Reportez-vous au graphique ci-dessous pour un exemple de planification des versions dans des frameworks agiles tels que XP.

La planification des versions agiles peut être effectuée manuellement ou à l’aide d’un logiciel de gestion de projet. Par exemple, Lucidchart a publié un guide pour développer un plan de publication agile à l’aide de son logiciel.

Planification des versions dans des projets hybrides

En plus du lien mentionné ci-dessus entre la feuille de route du produit et les itérations, les plans de versions agiles peuvent également aider à intégrer des projets de développement agile dans une organisation ou une architecture orientée vers les versions.

Par exemple, un système orienté client pourrait être développé en utilisant des approches agiles. Cependant, ce système devrait être intégré à l’architecture informatique complexe de l’entreprise, impliquant également des interfaces avec d’autres systèmes. Ainsi, le développement et le déploiement de ce système orienté client seraient nécessairement soumis à la planification centrale des versions de l’organisation.

Dans de tels cas, la technique de planification des versions agiles peut lier les versions de l’organisation aux itérations et fonctionnalités développées dans un (sous) projet agile.

Qu’est-ce qu’un plan de Release Agile dans Scrum ?

Un plan de release dans Scrum représente l’allocation d’éléments d’un backlog de produit (la liste des fonctionnalités et des exigences d’un produit) aux releases. Ces fonctionnalités sont ensuite développées dans les sprints.

Conformément aux valeurs et principes de Scrum, un plan de publication se veut une ligne directrice et un document vivant qui est mis à jour dynamiquement lorsque les choses changent ou que de nouvelles informations sont connues.

Selon le Scrum Institute ™, un plan de sortie de scrum nécessite un backlog produit priorisé et estimé, l’indicateur de vitesse de l’équipe et la « condition de satisfaction » (ou définition de terminé) qui comprend l’objectif du développement du produit.

Sur la base des estimations d’effort pour les fonctionnalités (la quantité de travail nécessaire) et la vitesse de l’équipe (la productivité de l’équipe), les fonctionnalités peuvent être attribuées à différentes versions et sprints.

Quelle est la différence entre les versions, les Itérations et les Sprints ?

Les versions font référence au développement et au déploiement planifiés de fonctionnalités ou de modifications logicielles sur une période typique de 1 à 3 (voire plus) mois. Dans les projets agiles, itératifs et certains projets hybrides, les versions sont divisées en plusieurs itérations qui ont une portée plus petite et un délai plus court, souvent entre 1 ou 2 semaines et 1 mois. Dans certains frameworks agiles tels que Scrum, les itérations sont également appelées sprints.

Combien de temps dure un Sprint en Agile/Scrum ?

Un sprint en mêlée dure généralement de 2 semaines à 1 mois. Cependant, il peut également être plus court ou plus long si cela est jugé plus approprié pour le projet de développement.

Conclusion

Que vous travailliez en tant que chef de projet ou propriétaire de produit dans un projet agile, itératif ou hybride ou que vous vous prépariez à votre examen PMP, comprendre la planification des versions agiles est essentiel pour permettre un développement agile ou basé sur l’itération en combinaison avec la planification des versions et des projets à moyen et long terme. Lisez nos articles sur les autres techniques de gestion des plannings si vous souhaitez en savoir plus sur le développement et la gestion des plannings de projets.

Grâce au plan de publication agile, un périmètre, sujet à affiner, et un calendrier peuvent être définis quelques mois à l’avance. Dans le même temps, les équipes de développement agiles peuvent conserver leur liberté de planifier et de replanifier régulièrement la portée exacte de chaque itération. Dans une certaine mesure, la planification agile des versions est une technique qui permet aux chefs de projet et aux propriétaires de produits de combiner les avantages de la gestion de projet traditionnelle (par exemple, planification à moyen / long terme) et des approches de projet agiles (par exemple, réactivité au changement et rétroaction).