Gestion de projet Agile et en cascade

Les premiers adeptes du développement Agile étaient souvent de petites équipes autonomes, qui travaillaient sur de petits projets indépendants. Ces équipes ont démontré l'efficacité du modèle Agile, à la grande joie des développeurs de logiciels dans le monde entier, qui ont pu améliorer leur travail. Il s'avère que le modèle en cascade n'était pas aussi efficace pour le développement logiciel que la gestion de projet Agile pour la plupart des équipes.

La popularité de la gestion de projet Agile a poussé davantage d'organisations à adapter Agile au-delà de simples équipes ou de simples projets, et à l'appliquer à des programmes entiers. Agile s'est même propagé au-delà des équipes de développement pour inclure l'informatique, le marketing, le développement des affaires, et plus encore.

La gestion de projet Agile est une approche itérative de la livraison d'un projet, qui se concentre sur des livraisons continues intégrant le feedback client. Sa capacité d'ajustement à chaque itération favorise la vélocité et l'adaptabilité. Cette approche est différente d'une approche de gestion de projet linéaire, en cascade, qui suit une trajectoire définie impliquant des écarts limités.

De nos jours, comme les clients et les entreprises nécessitent des réponses et des changements rapides, Agile offre la flexibilité nécessaire pour s'adapter et itérer pendant le développement. La gestion de projet Agile est également la pierre angulaire des pratiques DevOps, dans le cadre desquelles les équipes de développement et opérationnelles travaillent en collaboration.

L'approche de gestion de projet en cascade implique une séquence d'exécution clairement définie, le projet ne progressant pas tant que la phase en cours n'a pas reçu l'approbation finale. Lorsqu'une phase est terminée, il peut s'avérer difficile et coûteux de revenir à une étape antérieure. Les équipes Agile peuvent suivre un processus similaire, mais leurs incréments sont plus petits et intègrent des boucles de feedback régulières.

L'approche de gestion de projet en cascade suit un modèle linéaire et séquentiel. Elle s'avère efficace dans le cadre d'un travail impliquant des processus prévisibles et récurrents, mais peut amener les équipes de développement à être prises au dépourvu et les laisser dans l'incapacité de s'adapter plus rapidement qu'un concurrent.

Lors d'un projet en cascade, le moindre manquement à une échéance ou changement dans le périmètre peut avoir des effets dévastateurs sur les livraisons ultérieures. Par ailleurs, lorsqu'une équipe est entièrement focalisée sur la prochaine phase de travail, la résolution de la dette technique ou la correction des bugs peut s'avérer pénible si ses membres travaillent à 100 % sur de nouvelles fonctionnalités et s'efforcent constamment de faire avancer les choses.

Vous trouverez ci-dessous une illustration d'un projet standard en cascade impliquant un calendrier strict. Il en résulte un sentiment d'obligation à agir sous peine de passer à côté d'une opportunité, qui peut encourager toutes les parties concernées (développeurs, Product Owners et parties prenantes) à demander le plus d'efforts possible à chaque période, en pensant qu'il n'y aura peut-être aucune possibilité d'itération à l'avenir. Généralement, les équipes appliquant l'approche en cascade essaient de contrôler la dérive des objectifs en « limitant les changements », c'est-à-dire que tout le monde s'accorde sur le fait que le contrat initial ne doit pas être modifié.

Le modèle en cascade peut exacerber certains des défis connus liés au développement de produits :

• Gestion des bloqueurs et des dépendances : les styles traditionnels de gestion de projet créent souvent des « chemins critiques », où le projet ne peut pas progresser tant qu'un bloqueur n'est pas résolu.
• Difficulté pour obtenir le feedback des utilisateurs et la validation du produit : comme si cela ne suffisait pas, le client final est incapable d'interagir avec le produit tant que celui-ci n'est pas complètement terminé. Ainsi, les problèmes importants au niveau de la conception et du code du produit ne sont décelés qu'à la livraison.

Les avantages de la gestion en cascade

• Nécessite moins de coordination en raison de phases clairement définies et de processus séquentiels
• Une phase de projet transparente permet de définir clairement les tâches dépendantes
• Il est possible d'estimer le coût du projet une fois les exigences définies
• Focalisation accrue sur la documentation des conceptions et des exigences
• La phase de conception est plus méthodique et structurée avant la programmation du logiciel

Les inconvénients de la gestion en cascade

• Il est plus difficile de scinder et de partager le travail, car les séquences de phases sont plus strictes et les équipes, plus spécialisées
• Risque de perte de temps liée aux retards et contretemps pendant les changements de phase
• Recrutements supplémentaires nécessaires pour former des équipes spécialisées à chaque phase, tandis que le modèle Agile encourage la formation d'une équipe plus transverse
• Communication supplémentaire nécessaire pendant les transferts entre chaque phase
• La responsabilité des produits et l'engagement peuvent ne pas être aussi forts qu'avec Agile, car l'accent est mis sur la phase actuelle

Agile a d'abord été adopté par les équipes de développement logiciel, qui sont passées de l'approche traditionnelle et séquentielle en cascade à une méthode qui a donné lieu à un feedback et des ajustements constants tout au long du cycle de vie de développement.

La gestion de projet Agile adopte une approche itérative du développement, en créant plusieurs étapes incrémentielles avec un feedback à intervalles réguliers. Cela favorise l'adaptabilité en permettant à une équipe de s'adapter tout au long du processus de développement du produit, au lieu de se limiter à une trajectoire linéaire. Cette approche permet également de procéder à des livraisons régulières à fort impact, grâce auxquelles les équipes remportent une série de victoires au fil du temps.

Les livraisons itératives offrent à une équipe de nombreuses opportunités pour :

• s'adapter à des circonstances changeantes, allant de l'identification de nouvelles exigences à un blocage au niveau d'une tâche ;
• recueillir le feedback des parties prenantes au cours du processus et itérer en réponse sans être stressée par un délai de livraison finale ;
• établir des relations et des connexions entre les rôles qui permettent aux gens de tisser des liens et de communiquer efficacement.

Agile permet aux équipes d'être plus résilientes face aux changements qui surviennent inévitablement au cours d'un projet.

Mais il existe un avantage encore plus décisif : le partage des compétences au sein de l'équipe de développement logiciel. Le chevauchement des compétences au sein de l'équipe renforce sa flexibilité vis-à-vis des tâches, quelle que soit la partie affectée de la base de code. En cas de réorientation du projet, l'équipe ne perd ni son travail ni son temps. (Pour en savoir plus, consultez notre article dédié à la formation d'équipes Agile ultra performantes.)

• Un projet Agile est segmenté en plusieurs étapes incrémentielles incluant un feedback à intervalles réguliers.
• Les exigences d'un projet sont segmentées en petits éléments, qui sont ensuite classés par ordre d'importance.
• Favoriser la collaboration, notamment avec le client.
• Procéder à des ajustements à intervalles réguliers afin de s'assurer de répondre aux besoins des clients.
• Intégrer la planification à l'exécution pour permettre à une équipe de répondre efficacement à l'évolution des exigences.

Les avantages de la gestion de projet Agile

• Cycles de feedback plus rapides
• Identification précoce des problèmes
• Satisfaction client potentiellement accrue
• Délai de commercialisation considérablement amélioré
• Meilleure visibilité/responsabilisation
• Équipes dédiées qui se traduisent par une meilleure productivité au fil du temps
• Priorisation flexible axée sur la livraison de valeur

Les inconvénients d'Agile

• Le parcours critique et les dépendances inter-projets peuvent ne pas être clairement définis comme dans le modèle en cascade
• La courbe d'apprentissage de l'organisation a un coût
• Une véritable exécution Agile avec un pipeline de déploiement continu comporte de nombreuses dépendances techniques, et les coûts d'ingénierie doivent être établis

Passer à une approche Agile peut s'avérer difficile, surtout pour une équipe ou une organisation enracinée dans une approche plus traditionnelle de la gestion de projet. Le passage à des pratiques Agile peut nécessiter un certain nombre de changements de processus, en particulier lors de l'adoption d'une approche DevOps, dans le cadre de laquelle les équipes de développement et opérationnelles travaillent en étroite collaboration pour développer et gérer les logiciels. Lorsqu'elles adoptent les principes Agile, l'équipe et les parties prenantes doivent adhérer à deux concepts importants :

• La priorité du Product Owner est d'optimiser la valeur ajoutée du travail de l'équipe. Celle-ci s'appuie sur le Product Owner pour prioriser les tâches les plus importantes.
• L'équipe de développement peut uniquement accepter le travail qu'elle est capable de réaliser. Le Product Owner n'impose pas de travail à l'équipe ni ne l'engage dans des délais arbitraires. L'équipe de développement récupère le travail dans le backlog du programme en fonction de ses capacités à l'absorber.

Explorons les mécanismes utilisés dans les programmes agiles pour organiser, exécuter et structurer le travail de façon itérative.

Une feuille de route produit décrit le développement d'un produit ou d'une solution au fil du temps. Dans le cadre du développement Agile, une feuille de route fournit un contexte important qui donne aux équipes les moyens d'atteindre les objectifs incrémentiels et du projet. Les feuilles de route se composent d'initiatives. Celles-ci correspondent à des domaines de fonctionnalités généraux, avec des délais qui indiquent à quel moment une fonctionnalité sera disponible. À mesure que le travail avance et que les équipes en apprennent davantage, la feuille de route pourra évoluer, parfois de façon subtile, parfois de façon plus globale, afin de prendre en compte ces nouvelles données. L'objectif est que la feuille de route reste focalisée sur les conditions actuelles qui affectent les objectifs du projet et ceux à long terme, de manière à travailler efficacement avec les parties prenantes et à répondre à l'évolution du paysage concurrentiel.

Voici une feuille de route très simple pour une équipe produit, sur laquelle les initiatives apparaissent dans des cases et les échéances sont indiquées par les marqueurs rouges d'étape importante.

Chaque initiative de la feuille de route se décompose en une série d'exigences. Les exigences Agile sont de brèves descriptions des fonctionnalités requises (plutôt que les documents de centaines de pages que l'on trouve dans les projets traditionnels). Elles évoluent dans le temps et tirent parti de la compréhension commune, par l'équipe, du client et du produit souhaité. Elles restent modestes pendant que tous les membres de l'équipe forgent leur compréhension commune, par le biais de la collaboration et des conversations régulières. Ce n'est que lorsque l'implémentation est sur le point de démarrer que ces exigences sont définies en détail.

Le backlog définit les priorités du programme Agile. L'équipe inclut toutes les tâches dans le backlog : nouvelles fonctionnalités, bugs, améliorations, tâches techniques ou architecturales, etc. Le responsable produit priorise le travail sur le backlog pour l'équipe d'ingénierie. L'équipe de développement se sert alors du backlog hiérarchisé comme source de référence unique pour le travail à réaliser.

Les équipes Agile s'épanouissent grâce aux métriques. Les limites du volume de travail en cours (WIP) permettent à l'équipe, ainsi qu'à l'entreprise, de rester concentrées sur la livraison des tâches les plus prioritaires. Les graphiques Burndown ou encore de contrôle aident l'équipe à prévoir sa cadence de livraison, et les diagrammes de flux cumulé permettent d'identifier les goulots d'étranglement. Grâce à ces métriques et artefacts, tous se concentrent en permanence sur les objectifs globaux et renforcent la confiance de l'équipe dans son aptitude à mener à bien ses futures tâches.

Les processus Agile créent un climat de confiance absolue entre les membres de l'équipe, car ils ne peuvent pas fonctionner sans cela. Il faut beaucoup de franchise pour tenir des conversations difficiles afin de déterminer les besoins du programme et du produit. Comme les conversations se tiennent à intervalles réguliers, les idées et les préoccupations sont régulièrement exprimées. Les membres des équipes doivent donc avoir confiance dans les capacités (et la volonté) des autres d'exécuter les décisions prises lors de ces conversations.

La gestion de projet Agile est une approche innovante des projets, qui s'applique non seulement au développement logiciel, mais aussi aux autres secteurs. En offrant la flexibilité nécessaire pour s'adapter aux changements pendant le cycle de vie de développement, Agile permet aux équipes de livrer des produits de meilleure qualité qui répondent aux besoins des clients. Il leur fournit les armes dont elles ont besoin, renforce la responsabilité et encourage l'innovation tout en favorisant l'amélioration continue. Il vous permet de réagir au changement sans dévier de votre route. Et c'est une excellente nouvelle pour n'importe quel programme.

Apprenez-en plus sur la gestion de projet Agile et consultez notre modèle de gestion de projet gratuit. Découvrez aussi comment adopter Agile en utilisant des outils Agile adaptés aux équipes de développement et comment communiquer l'avancement du travail entre les équipes.