Livraison fréquente

L’agilité applique, pour la vie du produit, le principe de livraison fréquente plutôt que de suivre une méthode séquentielle.

La division verticale du travail qui a établi une distinction entre la conception et la réalisation, perdure dans bien des projets. Cela conduit à une façon de travailler avec la séparation stricte entre réflexion et exécution et des phases séquentielles. La première phase sert à concevoir et planifier, la suite n’étant que l’exécution de ce plan avec des contrôles effectués pour garantir sa bonne exécution.

Le cycle de vie en V (ou en cascade pour waterfall) en est un exemple. Il pousse à diviser le travail en étapes dédiées à des activités spécialisées. Le résultat est obtenu à la fin du déroulement de toutes les étapes, pour être livré aux utilisateurs.

Les problèmes liés au cycle de vie séquentiel

Le taylorisme ne se souciait pas des utilisateurs. Quand il s’est décliné pour autre chose que de la production de masse, on a donc cherché à définir ses besoins, à les spécifier en détail. Cela a conduit à la rédaction de documents : des cahiers des charges ou des spécifications détaillées.

L’intention en suivant une méthode séquentielle composée de phases et de jalons est de définir à l’avance tout ce qu’il va falloir faire faire aux exécutants. C’est à l’origine de bien des problèmes rencontrés depuis longtemps dans le développement de logiciel :

Effet tunnel

Le fameux effet tunnel, ça ne date pas d’aujourd’hui, j’en ai entendu parler pour la première fois chez Alcatel quand je travaillais dans les systèmes téléphoniques.

Quand on lance le projet, l’équipe rentre dans le tunnel et ne donne pas de visibilité sur l’avancement avant la fin du tunnel, souvent des mois après, au moment où elle livre son résultat. Il y a peu de chances qu’il corresponde au besoin.

Rien de tout cela avec l’agilité. On de déroule plus de longues phases séquentielles, elles sont remplacées par des boucles courtes (les itérations ou sprints).

De plus on n’attend pas la fin de toutes les boucles pour livrer. En fait, on livre dès que cela a du sens de le faire, c’est-à-dire quand on considère que cela apporte de la valeur.

Big design up front

Le cycle de vie séquentiel pousse à faire des choix de conception prématurés ; en effet il comporte une phase de conception qui est en fait de la production de document.

Avec l’agilité, on pratique la conception émergente, en expérimentant des solutions et en retardant une décision irréversible de conception.

Big bang à l’intégration

L’intégration de parties conçues séparément est source d’erreurs et de perte de temps pour faire fonctionner les morceaux ensemble. L’agilité a mis en avant l’intégration continue avec des tests d’acceptation inclus.

Rework tardif

Quand on déroule un cycle de vue séquentiel l’évolution des besoins est ignorée : on est censés les avoir pris en compte au début et on ne se soucie pas du fait qu’ils puissent changer. À la fin on se rend compte que le résultat ne convient pas, il faut alors revenir sur ce qu’on a fait, la conception parfois, ce qui va demander beaucoup d’efforts.

Avec l’agilité, on co-construit le résultat avec les utilisateurs en le faisant évoluer à chaque boucle.

Le principe de livraison fréquente

Ce principe consiste à donner un résultat pour recevoir le feedback en retour ET aussi à livrer aux utilisateurs finaux dès que c’est possible.

Dans le Manifeste Agile de 2001, on trouve deux principes qui y correspondent :

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Accueillez positivement les changements de besoins, même tard dans le projet.

Depuis 2001, l’évolution des technologies a grandement facilité la livraison de produits logiciels. L’intégration continue et le déploiement continu sont maintenant des pratiques courantes.

Antipatterns

Cependant cela peut engendrer de nouveaux problèmes :

• Surveillance des usages : la facilité avec laquelle on peut intégrer des outils de surveillance des usages peut inciter à aller trop loin dans la capture des données, sans demander la permission aux utilisateurs.
• Décision de livrer perdue par l’équipe si les personnes chargées des opérations n’en font pas partie.
• Croyance qu’il faut livrer aux utilisateurs à la fin de chaque sprint.

Définir les objectifs de livraison

La livraison du résultat répond à deux objectifs :

• apprendre,
• donner de la valeur d’usage.

Avec Scrum le résultat est livré aux parties prenantes — et montré lors de la revue — pour apprendre, à chaque sprint. La livraison aux utilisateurs finaux est décidée par le Product Owner, en fonction de ce qui aura été appris. La stratégie de livraison et les critères pour décider sont définis en commun.