Tous les projets de développement Agile sont associés à des objectifs : périmètre du projet, délai de livraison et budget. Cependant, la gestion de ces trois contraintes peut être un exercice d'équilibriste complexe. Prenons l'exemple du fameux « triangle de fer » de la planification et découvrons comment l'ajustement de différentes variables peut aider les équipes de développement Agile à atteindre le paradis de la gestion de projets Agile.
Le « triangle de fer » traditionnel
Le « triangle de fer » de la gestion de projet répertorie les contraintes considérées comme « de fer », car on ne peut apporter de changement à une contrainte sans impacter les autres. À l'origine, le « triangle de fer » de la gestion de projet proposé par le Dr Martin Barnes en 1969 suit une approche du développement de produits en cascade : le périmètre est fixe, les ressources et le temps sont variables. Pour une équipe de développement, cela signifie qu'elle commence un projet en définissant les exigences produit afin de déterminer le périmètre (une liste de tâches). Les ressources et le calendrier sont variables et estimés en fonction du périmètre fixé.
- Le périmètre désigne le travail à effectuer (comme les caractéristiques et fonctionnalités) pour livrer un produit fonctionnel.
- Les ressources comprennent le budget ainsi que les membres de l'équipe qui travaillent à la réalisation et à l'exécution.
- Le temps désigne le moment où les équipes doivent livrer des produits, et correspond aux versions ou encore aux étapes importantes.
Le but du « triangle de fer » de la gestion de projet est de donner aux équipes produit les informations nécessaires pour faire des compromis qui aideront l'entreprise. Par exemple, si les équipes sont confrontées à un périmètre fixe, elles peuvent être au plein milieu d'un projet et réaliser qu'elles ne respecteront pas leur date de livraison. Les seules variables avec lesquelles elles peuvent jouer sont les suivantes : 1) le temps : elles peuvent accepter une date de livraison ultérieure ; ou 2) les ressources : elles peuvent ajouter quelques personnes supplémentaires au projet, ce qui augmentera les coûts. À mesure que le développement évoluait au XXIe siècle, la nécessité d'optimiser la collaboration et la capacité de répondre rapidement aux commentaires des clients sont devenues cruciales. C'est ainsi qu'est née la méthodologie Agile.
Cartographier le « triangle de fer » pour devenir agile
Si votre équipe pratique la gestion de projet en cascade ou débute dans le développement Agile, il est important de retenir la différence entre ce qui est fixe et ce qui est estimé. Contrairement au développement en cascade, les projets Agile ont un calendrier et des ressources fixes, tandis que leur périmètre varie. Alors que le périmètre d'un projet peut changer dans le développement Agile, les équipes s'engagent à des itérations de travail fixes : sprints si vous utilisez un framework Scrum, limites WIP si vous utilisez un framework Kanban. C'est également une bonne pratique pour maintenir les équipes fixes tout au long du processus de développement. En s'assurant qu'elles travaillent sur un même produit ou projet, les équipes gagnent en efficacité grâce à la confiance et à la continuité développées.
Le concept de périmètre est le même dans le développement Agile : quel logiciel développer et livrer. Toutefois, l'agilité se concentre sur des exigences de haut niveau plutôt que d'essayer de présenter des exigences profondes et détaillées dès le départ. Le périmètre d'un projet est régulièrement géré et préparé (définition de priorités) par le responsable produit dans un outil comme Jira. Le responsable produit décide du travail à accomplir lors du prochain sprint sur la base d'un feedback qualitatif et quantitatif Agile provenant de divers canaux (conditions du marché, commentaires des clients, concours, et bien plus). Et comme les ressources et le temps sont fixes, il est plus facile pour les équipes de développement de réagir à l'évolution du marché et de fournir plus rapidement de la valeur aux clients. Grâce à cette transparence des contraintes, les équipes restent honnêtes, et adoptent une cadence de livraison cohérente et rapide, l'un des principes clés du développement Agile. En examinant les projets sous l'angle du « triangle de fer », les équipes sont capables de s'adapter sans abandonner un plan.
La planification Agile à long terme et le « triangle de fer » de la gestion de projet
Les projets devenant plus importants, il faut davantage d'équipes, et le délai s'allonge. Ainsi, même si son périmètre varie, la notion de définition des ressources et du temps n'est pas une approche valable pour tous les projets Agile. Une planification Agile à long terme nécessite un « triangle de fer » plus flexible, qui permet aux équipes de planifier à l'avance et de s'assurer qu'elles atteignent les objectifs métier. Pensez, par exemple, à la méthode « Lean Startup » et à la notion de produit minimum viable (Minimum Viable Product, MVP). Par définition, un MVP est un petit ensemble de fonctionnalités (périmètre) qui apporte une valeur ajoutée au client. Pour parvenir à ce MVP, les équipes devront peut-être s'en tenir à un périmètre fixe (le nombre de fonctionnalités), le temps étant leur seule variable. Par exemple, vous ne pouvez pas livrer sans certaines fonctionnalités, donc la date de livraison est repoussée. Ce n'est qu'après le lancement du MVP que les équipes passent à un périmètre variable.
Quelles que soient les différences entre le modèle en cascade et le développement Agile, lorsqu'on utilise le « triangle de fer », il n'y a pas de bonne ou de mauvaise approche. Le triangle est là pour vous aider à prendre les meilleures décisions et à faire les meilleurs compromis afin d'atteindre vos objectifs métier. Un outil comme Chronologies permet de visualiser les éléments constitutifs d'un plan (périmètre, ressources et temps) pour aider les équipes à planifier en temps réel. Vous pouvez facilement jouer avec le périmètre, les équipes et le temps pour planifier la prochaine livraison de votre produit grâce aux données existantes de l'équipe dans Jira.