Le concept de « user story », apparu dans l’Extreme Programming (XP) en 2000, est aujourd’hui un standard en agile. Mais à quel prix ! Arrêtons le massacre.
User Story
Commençons par le commencement. Utilisons les vocabulaires de Scrum et d’XP : backlog et user story. Qu’est-ce qu’un élément de backlog (la liste des choses à faire, pas trop grande pour éviter le piège du « gros stock ») ?
Revenons au manifeste agile et à ses principes, le premier en particulier.
Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
Autrement dit, un besoin détaillé correspond à une valeur ajoutée pour le client. À la fin des années 90, XP utilise les tests d’acceptation en tant que base de l’expression de besoin détaillé. C’est en 2000 que naît le concept de user story. Il s’inspire des cas d’usage du marketing (et des étiquettes Kanban pour la planification, nous y reviendrons).
Une histoire d’utilisation reprend le point de vue des cas d’utilisation de Ivar Jacobson, que l’on retrouve dans UML depuis 1997. Autrement dit, le besoin est décrit sous forme d’interaction entre un Utilisateur – un acteur dans UML – et le système vu comme une boite noire.
D’où en synthèse la proposition bien connue :
En tant que [Utilisateur]
je peux [interaction]
afin de [bénéfice].
Avec l’avênement des features de plus haut niveau – services rendus par le système, fonctionnels ou non – le bénéfice perd de son intérêt car il est décrit au niveau avec ce nouveau concept. Il reste qu’une « valeur » (user value, business value…) reste pertinente lorsqu’il faut choisir entre plusieurs stories.
Le cadre dans lequel ce concept de user story a été élaboré est grosso modo le suivant. Il s’agissait de proposer un concept simple à un client, rôle emblématique d’XP, non technique. Même les use cases possèdent un formalisme graphique et des concepts finalement pas si simples (include…). D’ailleurs cette technique basée sur une décomposition en interactions est souvent dévoyée pour revenir aux sempiternelles fonctions. Bref…
La User story suppose donc un dialogue entre un Client, par exemple un responsable de PME, et une équipe de Développeurs, par exemple des freelances qui n’ont nullement besoin d’un ScrumMaster. Supposons que ce responsable de PME souhaite créer une nouvelle gestion de devis. Il pourra alors spécifier son système avec un ensemble de scénarios. Le plus simple pour lui est de raconter des histoires d’utilisation.
– Avec ce nouveau « devis », un Commercial pourra indiquer un pourcentage de remise sur son H.T.
Ce qui, en format plus « standard » US devient
En tant que Commercial
Je peux indiquer un pourcentage de remise
afin de mieux sécuriser ma vente.
Aïe aïe aïe…
Notez un point important ici : le concept de User Story est fait pour des non-techniques. Généralement, dans nos organisations, nous connaissons beaucoup trop de choses qui viennent « polluer » notre écriture et nous oublions cette base simple. D’où quelques aberrations inter-galactiques du style
En tant qu’ {Architecte Système | Ingénieur Qualité | Responsable Requirement… }
Je veux que…
Le responsable de la PME sait très bien qui seront les Utilisateurs de ce nouveau système. C’est le Client (pas le Product Owner, l’Analyste fonctionnel ou je ne sais quel intermédiaire).
Donc, aussi paradoxal que cela puisse être, les choses se compliquent lorsque vous n’êtes pas le Client au sens historique d’XP.
Mais… Qui sont les Utilisateurs ?
La toute première question est donc celle-ci. Elle parait tellement facile… Vous seriez étonné par le nombre de stories qui n’ont strictement aucune idée de leur Utilisateur !
Les cadres agiles proposent aujourd’hui des techniques utiles ici, par exemple la persona. Mais faisons simple. Commençons par exemple par des profils types. Un diagramme de contexte gentiment détourné peut aider à visualiser le système.
Ainsi, les stories de « Devis » et « Paramètres » s’inscrivent dans ce diagramme de contexte.
En tant que Commercial
Je peux indiquer un pourcentage de remise
afin de mieux sécuriser ma vente.
En tant que Directeur commercial
Je fixe le pourcentage maximum d’une remise sur devis
Lorsque ce n’est pas directement le Client (comme prévu dans XP), il convient donc de préparer la rédaction en travaillant – progressivement – sur la liste des profils d’Utilisateur. Ainsi, le Product Owner se met alors à la place de chacun d’eux pour rédiger ses histoires d’utilisation.
Nous verrons dans la suite les compléments à la phrase « lapidaire ». En effet, une story ne se résume pas à ces quelques mots. Ils en constituent uniquement le titre. Il reste toute l’histoire à raconter !
De même, un prochain billet évoquera la question de l’informatique industrielle, sensiblement différente de l’informatique de gestion ici.