Exécution de programmes Agile (sans perdre la tête)

Pour certains, la transition vers Agile a pour inconvénient de supprimer la visibilité globale. Nous ne sommes pas du tout d'accord.

Dan Radigan Dan Radigan

Les premiers adeptes du développement agile étaient de petites équipes autonomes qui travaillaient sur de petits projets autonomes. Elles 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. Depuis peu, de plus grandes structures adaptent Agile au-delà de simples équipes ou de simples projets. Elles cherchent à l'appliquer à des programmes entiers. 

Il y a évidemment certains défis à relever. Mais cela ne signifie pas que c'est irréalisable ! D'abord, voyons comment Gilt, un vendeur de prêt-à-porter en ligne, utilise Agile pour transformer son activité.

Cascade ou Agile

Commençons par les fondamentaux et examinons ce qui différencie Agile. 

Les styles traditionnels de gestion de projets, comme la gestion en cascade, se développent par phases. Vous trouverez, ci-dessous, une illustration d'un projet standard en cascade. Ce style de développement de produit incorpore tout dans une seule livraison « big bang », ce qui représente un risque élevé. Une fois qu'un projet passe une phase, il est très difficile d'y revenir étant donné que les équipes ne cessent de mettre la pression pour l'envoyer vers l'étape suivante.

Exemple de livraison en cascade | Atlassian – Le coach Agile

Les styles traditionnels de gestion de projets créent souvent des « chemins critiques », où le projet ne peut pas progresser tant qu'un problème n'est pas débloqué. Et 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.

Comparons cela avec le style de gestion de projet Agile, lequel adopte une approche itérative en matière de développement, avec un feedback à intervalles réguliers. Ces itérations permettent à l'équipe de dévier vers (et d'être productive dans) un autre aspect du projet pendant la résolution d'un ticket paralysant.

Exemple de gestion de projet Agile | Atlassian – Le coach Agile

Outre l'élimination des chemins critiques, les itérations vous permettent d'interagir avec le produit pendant son développement.

L'équipe bénéficie alors d'opportunités constantes de développer, délivrer, apprendre et ajuster. Les équipes ne sont pas prises au dépourvu par les changements du marché. Elles peuvent s'adapter rapidement aux nouvelles exigences.

Mais il existe un avantage encore plus décisif : le partage des compétences au sein de l'équipe de développement. 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 changement d'orientation du projet, celle-ci ne perd ni son travail ni son temps. (Pour en savoir plus à ce sujet, consultez notre article dédié à la formation d'équipes Agile d'excellence.)

Comment créer un programme agile d'excellence

Lorsqu'un programme migre de la gestion de projets traditionnelle vers Agile, l'équipe et les parties prenantes doivent adhérer à deux concepts importants :

  • La priorité du responsable produit est d'optimiser la valeur ajoutée du produit de l'équipe de développement. L'équipe de développement s'appuie sur le responsable produit qui distribue en priorité les tâches les plus importantes.
  • L'équipe de développement peut uniquement accepter le travail qu'elle est capable de réaliser. Le responsable produit 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.

Roadmaps

Une feuille de route décrit le développement d'un produit ou d'une solution dans le temps. 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. Au fur et à mesure du développement du programme, la feuille de route pourra évoluer, parfois de façon subtile, parfois de façon plus globale. L'objectif est que la feuille de route reste focalisée sur les conditions du marché et les objectifs à long terme. 

Exigences

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). Ces exigences évoluent au fil du le temps. Elles tirent profit de la vision commune de l'équipe, du client et du produit souhaité. Les exigences Agile restent modestes pendant que tous les membres de l'équipe forgent leur vision 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 commencer que ces exigences sont étoffées de façon détaillée. 

Backlog

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. 

Vecteurs de livraison agiles

L'implémentation d'Agile peut se faire avec différents frameworks (comme Scrum et Kanban) pour la livraison de logiciels. Les équipes Scrum utilisent des sprints comme guide de développement, tandis que les équipes Kanban travaillent souvent sans intervalles de travail fixes. Toutefois, ces deux frameworks s'appuient sur des grands vecteurs de livraison comme les epics et les versions afin de structurer le développement pour une mise en production synchronisée.

indicateurs agiles

Les équipes Agile se nourrissent de 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 présentant une priorité absolue. Les outils tels que le graphique d'avancement et les diagrammes de contrôle aident l'équipe à prévoir sa cadence de livraison, et les diagrammes de flux cumulatif permettent d'identifier les goulots d'étranglement. Grâce à ces métriques et artefacts, tous se concentrent en permanence sur les objectifs globaux et donnent à l'équipe la certitude qu'elle peut mener à bien ses futures tâches. 

Agile repose sur la confiance

Un programme agile ne peut fonctionner sans une confiance absolue entre les membres de l'équipe. 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 de l'équipe doivent donc également avoir confiance dans les capacités (et la volonté) des autres d'exécuter les décisions prises lors de ces conversations.

En résumé, le développement Agile est une approche structurée et itérative de la conception de logiciels. Il vous permet de répondre au changement sans dévier de votre route. Et c'est une bonne nouvelle pour n'importe quel programme. 

Up Next
Workflow