Utilisation du produit obtenu en fin d'itération

A la fin de chaque itération on livre un produit potentiellement livrable. Quel usage en fait-on ?

Qu’est ce qui fait la différence avec la fin de release où on livre vraiment le produit ?

Avec les méthodes Agiles, on cherche à obtenir un produit partiel potentiellement livrable- pour reprendre la formulation Scrum- à la fin de chaque itération. Lors de la revue de fin d’itération, l’équipe fait une démonstration de ce produit. Et après ?

Dans Scrum en 100 mots, l’objectif annoncé est de permettre une prise de décision sur une prochaine fin de release. Cela signifie que la décision est prise lors de la revue de sprint, après la démonstration du produit.

Avec la définition de Scrum en 24 mots ajoutée par Stéphane : Scrum est un processus agile éprouvé permettant de livrer, tous les 30 jours, du logiciel fonctionnel ayant une valeur significative aux yeux des utilisateurs, on pourrait penser que la version de fin d’itération est toujours livrée aux utilisateurs.

D’après mon expérience, il y a 3 utilisations -après la démonstration- d’une version obtenue en fin d’itération :

  1. elle n’est pas utilisée en dehors de l’équipe de développement. Elle a été produite pour chercher à minimiser les risques liés à la technologie et à la capacité de l’équipe à intégrer pour produire un build. Elle n’est pas livrée à l’extérieur de l’équipe. Cela arrive surtout au début d’un nouveau développement : exemple avec les 2 premières itérations du projet Wilos, projet sur lequel je suis le directeur de produit.
  2. elle est utilisée par le client ou des clients privilégiés. Cela leur donne la possibilité de jouer avec, ce qui permet de réduire les risques portant sur l’IHM liées à la facilité d’utilisation des fonctionnalités. Les retours faits iront alimenter le backlog pour prise en compte ultérieure.
  3. elle est mise en production ou en exploitation et utilisée par ses utilisateurs finals. C’est évidemment ce qu’il faut viser puisque chaque nouvelle version apporte de la valeur. Autant l’apporter le plus tôt possible, dès qu’elle est disponible. Mais ce n’est généralement pas possible de mettre en production à la fin de chaque itération : trop de temps serait pris pour passer les tests de recette sur tout le système, déployer sur l’environnement de production, écrire les manuels utilisateurs, préparer et donner la formation aux utilisateurs… C’est pourquoi ce travail particulier nécessite souvent de spécialiser le dernier sprint avant la fin de release. Mais si on réussit à limiter le temps pour faire tout ça, on peut alors mettre en production plus souvent qu’à la fin des releases.

Voir aussi