Manifeste Agile, un changement culturel (2)

Le manifeste Agile contient l'essence et la philosophie de l'approche en question. Il illustre à lui seul le changement culturel profond qui est en jeu.

Nous découvrons dans cet article, comment mieux appliquer le manifeste agile par la pratique et en aidant les autres à le faire dans le développement d'une solution logicielle. Dans la pratique, nous sommes amenés à valoriser les éléments suivants :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuel
• L’adaptation au changement plus que le suivi d’un plan

ATTENTION AUX IDÉES REÇUES

La dernière phrase a son importance car si on néglige sa lecture, on peut tomber dans les idées reçues très répandues du style: "Sur un projet agile, il n'y a pas de spécifications, de plan, de processus, d'outil et même pas de contrat".

Au passage, passons en revue d'autres idées reçues "Un projet Agile ne fonctionne que sur des projets de développement web, qu'avec une dizaine de personnes maximum, qu'avec des super développeurs" ou encore "sur un projet agile, le client change d'avis tout le temps et on tourne en rond à faire et défaire des choses".

Principes sous-jacents au Manifeste Agile

Nous suivons ces principes pour développer des projets agiles :

1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
3. Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
5. Réaliser les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
7. Un logiciel opérationnel est la principale mesure d’avancement.
8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
9. Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.
10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Le cadre méthodologique Scrum

Je vous propose maintenant de se vocaliser sur l'une des méthodes Agile existantes afin de vous montrer plus concrètement le fonctionnement. Pourquoi nous utilisons la méthode Scrum en particulier ? Tout simplement parce que Scrum soit de très loin la méthodologie la plus utilisée parmi les méthodes agiles existantes. Elle est donc la plus éprouvée, documentée et supportée. Livres, blogs, formations, vidéos, associations, conférences traitant de Scrum ne manquent pas et bon nombre de ces ressources sont accessibles gratuitement. On pourrait pratiquement parler d'un standard Agile. Un autre atout important: Scrum est simple à comprendre. Sa maîtrise est en revanche difficile.

Le "package" Scrum

Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d'une définition des rôles, de réunions et d'artefacts.

Processus Scrum

Scrum définit 3 rôles :

• Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le client).
• Le « Scrum Master » garant de l'application de la méthodologie Scrum.
• L'équipe de développement qui réalise le produit.

La vie d'un projet Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps (timeboxing):

• Planification du Sprint (Sprint = itération) : au cours de cette réunion, l'équipe de développement sélectionne les éléments prioritaires du « Product Backlog » (liste ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu'elle pense pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
• Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l'équipe de développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks du Product Owner et des utilisateurs finaux. C'est également le moment d'anticiper le périmètre des prochains sprints et d'ajuster au besoin la planification de release (nombre de sprints restants).
• Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint est l'occasion de s'améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du "vécu" sur le sprint écoulé (principe d'amélioration continue).
• Mêlée quotidienne (Daily Scrum meeting ) : il s'agit d'une réunion de synchronisation de l'équipe de développement qui se fait debout (elle est aussi appelée "stand up meeting") en 15 minutes maximum au cours de laquelle chacun répond principalement à 3 questions : « Qu'est ce que j'ai terminé depuis la dernière mêlée ? Qu'est ce que j'aurai terminé d'ici la prochaine mêlée ? Quels obstacles me retardent ? »

L'organisation générale

Travaux préparatoires

L'approche Scrum propose de commencer par lister les exigences du client afin de produire le « Product Backlog ». Voir l'exemple ci dessous pour la réalisation d'un site d'e-commerce:

L'unité de coût (ou complexité) de la colonne "Estimation" est arbitraire, nous procèdons généralement par relativité en définissant un étalon de base. Par exemple, "voir le détail d'un article" étant une exigence simple, elle servira d'étalon et son estimation convenue sera par exemple de "1 point", "modifier les caractéristiques d'un article" étant 2 fois plus compliquée, son estimation sera de "2 points", etc. Le recours à une telle unité (plutôt que des jh ou €) permet de faciliter l'ordonnancement du Product Backlog, la planification des sprints et des releases. D'autre part il souligne le fait qu'il ne s'agit que d'une estimation (par définition fausse) et non pas un chiffrage en tant que tel.

Le Product Owner ordonnance ensuite la liste en fonction de la valeur ajoutée métier, du coût estimé de chaque exigence et des risques identifiés. Les exigences seront réalisées dans l'ordre ainsi défini selon les contraintes de l'équipe de développement et les éventuelles dépendances (exigence D à faire avant l'exigence X). Nous fixons ensuite la durée des sprints durant laquelle un certain nombre d'éléments du « Product Backlog» seront réalisés. L'objectif de Scrum consiste à produire le plus tôt possible la plus grande valeur possible, afin de créer des opportunités d'accélération du "Time to market".

Enchaînement des sprints

Une fois que le Product Backlog est prêt et que la durée du sprint est fixée en accord avec le client, il n'y a plus qu'à remplir le sprint avec des éléments du Product Backlog (planification de sprint). C'est également à ce moment que le Product Owner exprime plus précisément son besoin (qu'il aura affiné au préalable) pour permettre à l'équipe de développement d'estimer plus précisément la charge de travail du sprint. Inutile pour autant de réaliser la conception détaillée en séance, des ateliers dédiés pourront avoir lieu en cours de sprint. Le Product Owner peut à tout moment revoir la priorité des exigences qui n'ont pas encore été planifiées dans le sprint en cours. En revanche, les exigences engagées dans le sprint en cours sont "sanctuarisées", seule l'équipe de développement à le pouvoir de modifier le périmètre du sprint en cas d'avance ou de retard.

Chaque sprint se termine par la revue de sprint suivie de la rétrospective. Le sprint suivant s’enchaîne à la suite selon le même cycle et ainsi de suite jusqu'au dernier sprint de la release.

Mesure de l'avancement

Grâce aux estimations individuelles des exigences du « Product Backlog » ainsi qu'à la segmentation en sprints, nous pouvons aisément produire un graphique de suivi d'avancement représentant l'évolution du travail accompli en fonction du temps (voir illustration ci contre : total de "points" d'estimation des exigences terminées en bleu et charge totale de "points" de la release en rouge).

Exemple de graphique d'avancement de release.

La contractualisation agile

La contractualisation d'un projet agile n'est pas la partie la plus facile étant donné que le périmètre est par définition variable. La régie ferait bien l'affaire mais difficile de rassurer le client avec un tel contrat. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Malheureusement pour le fournisseur - dans le cadre d'un forfait classique - tous les risques sont pour lui (aussi bien sur un projet agile que sur un projet traditionnel). Nous pouvons limiter ces risques en prenant quelques précautions, mais nous limitons également la souplesse offerte par une approche Agile.

Cela ne veut pas dire qu'il n'existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d'arrêter le contrat à la fin de chaque itération est assez intéressante. Ainsi que le principe de troc d'exigence : réalisation d'une exigence imprévue en échange du retrait d'une autre moins importante, de priorité faible et de même coût.

Vous souhaitez allez plus loin ?

Je vous conseille de lire ce livre pédagogique "L' art de devenir une équipe agile" de l'auteur Claude Aubry.