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 :

  • 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.
  • 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.
  • 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.

Commentaires

1. Le lundi 27 novembre 2006, 15:26 par Stéphane Boisson

Et si l'écriture du manuel, la préparation de la formation faisaient partie travail effectué lors des sprint?
Et si le deploiement ou installation faisait partie de la démonstration?

2. Le lundi 27 novembre 2006, 17:22 par Oaz

On pourrait même rajouter "Et si la démonstration faisait office de formation pour l'ensemble des utilisateurs ?"

Mais je rejoins l'avis de Claude, "ce n'est généralement pas possible de mettre en production à la fin de chaque itération", en tout cas pas dans les contextes que je connais bien. Ce qui ne veut pas dire que cela n'est pas possible lorsque l'on a un faible nombre d'utilisateurs ou que déploiement et formation des utilisateurs sont largement simplifiés (typiquement pour un produit grand public accessible via Internet).

3. Le lundi 27 novembre 2006, 22:38 par claude aubry

Avec l'essor du Web2.0, on aura de plus en plus d'applications pouvant être déployées à chaque itération.

Un bémol cependant : il faut un certain temps (disons au moins 3 ou 4 itérations) avant de déployer pour la première fois une nouvelle application, le temps de développer suffisamment de fonctionnalités pour que ce soit vraiment utilisable. J'en fais l'expérience actuellement.

Les 2 premières utilisations d'une version que j'évoque dans mon billet seront toujours utiles au moins pour ces débuts de projet.