LivraisonsFrequentes

Un article de Agora2ia.


Livrant en fin de chaque itération, le rythme des livraisons en XP est d’une toutes les quelques semaines. Il est important de s’accorder avec le client sur une fréquence donnée et de s’y tenir. Par exemple, une période de 2 semaines, pour la durée d’une itération, donc pour la durée séparant deux livraisons, est un bon compromis.


Si le client a besoin de livraisons plus fréquentes, on peut éventuellement raccourcir cette période, mais ne surtout pas faire de livraison en cours d’itération. Par expérience, ce « bad smell » traduit un dysfonctionnement dans le processus (voir le chapitre « Paul et Mick dans l'eXtrême »).


Techniquement, les livraisons fréquentes impliquent d’avoir un mécanisme d’intégration fiable, à savoir performant et automatisé.

Performant pour être compatible avec une fréquence de livraison élevé : notamment les tests release doivent se jouer relativement rapidement.

Fiable pour être capable de reproduire une livraison à partir des sources versionnées : en effet, seules les sources sont versionnées, les livraisons sont reproduites si besoin. Au-delà des sources, c’est l’environnement de développement qui doit être versionné : si l’on souhaite reproduire la livraison produite il y a 14 itérations, il faut repartir des sources de l’époque, mais aussi rétablir l’environnement de développement si l’on veut reproduire la livraison de l’époque à l’identique, avec les mécanismes de l’époque.

Un processus d’IntégrationContinue efficace va de paire avec des livraisons fréquentes réussies.

La livraison est le livrable qui ponctue l’itération. Il est important de conserver cette notion de BoiteDeTemps. Quoi qu’il arrive, il est important de systématiquement produire un livrable qui fonctionne en fin de chaque itération :

  • Tant en début de projet pour valider le processus de livraison lui-même (construction, test, déploiement)
  • Qu’après pour valider les nouvelles fonctionnalités.

Pour être fonctionnel, l’ensemble des fonctionnalités peut être :

  • Toutes celles prévues au début d’itérations plus d’autres ajoutées après,
  • Toutes celles prévues en début d’itération,
  • Seulement les prioritaires selon le client lorsque les développements ont pris plus de temps que prévu.

Dans tous les cas, le client devra comprendre que, si il décide d’ajouter en cours d’itération des fonctionnalités non prévues sur l’itération en cours, et il peut le faire, cela devra ce faire en deux étapes :

  1. Tout d’abord l’équipe devra estimer le temps de développement de cette (ces) nouvelle(s) fonctionnalité(s).
  2. Le client devra ensuite retirer des tâches de celles restant à faire (pour la fin d’itération) pour une même durée de développement : il s’agit bien d’un remplacement de tâches et non d’un ajout.

Cette pratique doit profiter de sa grande sœur, à savoir le ClientSurSite, sans pour autant tomber dans le piège : il faut livrer, installer, déployer le logiciel sur une machine dédiée, vierge de toute installation et configuration, par opposition à une machine de développement qui est déjà configurée.


La motivation de cette pratique est de donner au client, le plus fréquemment possible, un aperçu de l’état de l’application, afin qu’il puisse faire un retour qui conditionnera les développements à venir : on est bien là dans une démarche itérative.

Un des effets de bord est l’installation progressive d’un climat de confiance. Quel dommage ;o)


Paul et Mick dans l'eXtrême

XP insiste donc sur le fait de fournir au client un livrable en fin de chaque itération. A titre de comparaison Scrum est moins extrême. En effet, selon la taille du projet, une livraison ne sera intéressante que toutes les 2 ou 3 itérations. On pourra alors fournir au client le livrable au bout de 2 ou 3 itérations. Mais on continuera de produire à chaque fin d’itération un livrable qui vérifie les tests release identifiés en début d’itération, afin de rester dans une démarche incrémentale.


L’équipe doit vraiment voir cette pratique comme une chance : celle d’avoir le plus tôt possible la possibilité de corriger d’éventuelles erreurs ou mauvaises interprétations.

Considérons le projet comme la période d’essai d’un nouvel embauché. Le but est d’avoir un avis positif à la fin de la période d’essai, que l’employeur soit satisfait afin qu’il fasse de nouveau confiance pour la suite… Et bien les livraisons fréquentes sont autant de « bilans intermédiaires » qui visent à redresser le tir et augmentent les chances de satisfaction finale.


Mais il ne faut pas confondre fréquence et précipitation. J’ai rencontré un client qui nous a imposé durant une période de crise de livrer tous les 3 ou 4 jours (sur des itérations de 3 semaines), nous demandant de court-circuiter la phase d’intégration et de tests afin de tenir cette fréquence. Il nous a alors reproché les bugs inhérents aux livraisons, la baisse de qualité des livrables étant indéniable. Il nous imposa alors de corriger les nouveaux bugs tout en tenant la nouvelle fréquence : nous nous sommes alors enfermé dans cette logique de « livrer plus souvent principalement pour corriger les bugs qui apparaissent ».

La difficulté dans cette situation est d’arriver à faire comprendre au client qu’il perdra plus de temps, et donc plus d’argent, à corriger les bugs générés, qu’il pensait en gagner.

De plus, cette perte d’argent s’accompagne d’une perte de qualité dans l’image de marque, donc de confiance, ce qui est tout aussi déplorable.

La correction se fait au prix des autres fonctionnalités : d’où l’importance d’estimer toute demande de changement, notamment la correction de bug, afin de quantifier auprès du client les fonctionnalités qui ne seront délaissées en contrepartie.

Cette dynamique de livrer pour corriger des bugs est présente sur des projets non XP, où il n’y pas la pratique des LivraisonsFréquentes.


L’autre extrême est tout aussi préjudiciable. Pas plus tard qu’hier, j’ai entendu dire : « ça n’a pas de sens de faire une livraison intermédiaire sur ce projet ». Plus qu’un « bad smell », cela traduit à mon sens un (mauvais) conditionnement de l’esprit. Il est évident qu’une maison constituée de juste 4 murs avec les ouvertures pour les portes et les fenêtres n’a pas de « sens fonctionnel » : elle n’est pas habitable. Mais le but de cette « livraison intermédiaire » n’est pas d’y habiter mais de détecter d’éventuelles erreurs grossières au plus tôt, telles qu’une mauvaise orientation de la façade, ou une mésentente dans les dimensions des ouvertures ou la surface habitable. Parmi les quelques personnes que je connais et qui ont fait construire une maison, TOUTES SANS EXCEPTION, allaient constater l’état d’avancement du projet au moins une fois par semaine : ce n’était pas pour y habiter !

Il ne faut pas confondre le but d’une livraison intermédiaire (s’assurer que tout le monde travail dans la bonne direction) et celui de la livraison finale (satisfaire le besoin du client).


Enfin, la fréquence permet de diminuer la quantité de travail à valider.

Je vais encore prendre un exemple. J’ai récemment dû rédiger un document de spécifications fonctionnelles sous forme de « Use Cases ». Si je vous livre chaque semaine, une dizaine de pages correspondant à 2 ou 3 Use Cases, j’obtiendrais aisément de vous une relecture hebdomadaire, régulière, qui deviendra plus aisée à mesure que vous appréhendez la formule, que vous assimilez l’exercice. De plus, vous pourrez mûrir votre compréhension, et donc avoir un jugement de plus en plus critique. Maintenant si je débarque au bout de 2 mois avec un document de 80 pages se voulant complet, dont vous découvrez le fond et la forme pour la première fois… Ai-je une chance d’avoir un retour ? Voire une validation ? Et si oui, en temps et en heure ? Quelles en seront alors la finesse et la pertinence ? Il ne faut pas négliger cet aspect de l’effort nécessaire, que j’ai bien envie d’appeler le paradigme de « l’escalier et de la corde raide ». La tour « Taipei 101 » est actuellement la plus haute tour du monde avec ses 508 mètres : il est envisageable de la gravir via son escalier, mais pensez-vous envisageable de la franchir d’un trait avec une corde raide ?


Au final, cette pratique des LivraisonsFréquentes s’avère bien plus consensuelle, bien moins extrême que ce que l’on peut rencontrer traditionnellement sur les projets informatiques.