La mise en service

La mise en service est l’action de donner de la valeur aux utilisateurs en déployant une version d’un produit ou service à leur intention.

La mise en service

C’est un principe fondateur de l’agilité que de mettre fréquemment en service des résultats de valeur pour les utilisateurs.

Le résultat de la mise en service

Mettre en service une version est aussi appelé livraison (release) ou mettre en production.

Quelle différence avec le résultat d’un sprint ? Le résultat d’un sprint sert à apprendre tandis que le résultat de la mise en service a un impact sur la vie des utilisateurs : il change leur comportement.

Dans le premier cas, la demande vient de l’équipe qui souhaite apprendre par le feedback. Dans le second, le don de l’équipe est une réponse à la demande (au besoin) initiale des utilisateurs.

Apprendre augmente les capacités de l’équipe, se servir du résultat mis en service augmente les capacités des utilisateurs.

La valeur d’apprentissage est pour l’équipe tandis que la valeur d’usage concerne les utilisateurs.

Le feedback de la mise en service

La mise en service est aussi une boucle de feedback. Le feedback récolté ira alimenter le backlog et sera inclus dans la mise en service suivante pour améliorer le produit ou service.

Le feedback après mise en service est différent, plus complet et plus riche que celui récolté en fin de sprint, car il repose sur une utilisation en situation réelle des utilisateurs finaux.

Valeur et revenu

La valeur – plus exactement la promesse de valeur – pour les utilisateurs a servi à définir les priorités dans le backlog et donc le contenu de ce qui est mis en service. Elle ne se mesure pas une fois la mise en service effectuée, pas plus que la valeur (d’apprentissage) d’un résultat de sprint.

En revanche, en plus du feedback, l’équipe (ou son organisation, en général le sponsor) peut recevoir des revenus après une mise en service. Quand l’équipe travaille dans le cadre d’un contrat avec son client, celui-ci peut stipuler que certaines mises en service déclenchent le paiement. Un autre type de revenu potentiel concerne les produits ou services commerciaux. Une mise en service est une opportunité pour acquérir de nouveaux clients ou, éventuellement, pour augmenter le tarif pour les clients actuels.

Il n’y a pas de lien direct entre le revenu (réel) que récolte le sponsor et la valeur (estimée) pour les utilisateurs qui a servi à prioriser.

Dans le cas d’utilisateurs internes, la valeur d’usage obtenue par une mise en service leur permet d’être plus efficaces, ce qui produit de la valeur économique pour l’entreprise.

Qui décide de la mise en service ?

C’est le Product Owner qui décide de la mise en service. Sa décision s’appuie sur les avis des parties prenantes et ceux des coéquipiers qu’il aura sollicités.

La date de mise en service est souvent communiquée à l’avance et devient une deadline pour l’équipe. Or si les stories sont mal finies ou s’il reste du travail (par exemple de la documentation ou des tests de charge) nécessaire pour la mise en service et qui n’a pas été fait au fil de l’eau, cela peut entraîner la mise en service d’un résultat mal fini. Un résultat mal fini qui est mis en service, c’est de la dette technique et des bugs, donc moins de valeur qu’attendu et du travail en plus.

À quel rythme mettre en service ?

L’objectif est de procurer rapidement de la valeur, mais le contexte fait que le rythme des mises en service varie énormément. La décision de mettre en service se basant sur cette notion, elle ne coïncide pas toujours avec une fin de sprint. Cela peut être pendant un sprint pour une équipe, ou après plusieurs sprints pour une autre équipe.

La tendance est de raccourcir les boucles de mise en service. Du point de vue technique, c’est l’outillage DevOps qui permet d’être prêt.

Déploiement continu ne signifie pas mise en service continue. La mise en service possède en plus une notion de valeur pour les utilisateurs finaux.

La notion clé est la fonctionnalité de valeur, l’idéal étant de mettre en service dès qu’elle est finie.

Ce texte reprend et adapte le début du chapitre 10 Autres boucles du livre Scrum édition 6. La suite du chapitre décrit les notions de fonctionnalité et de saison.

Voir aussi