Temps de lecture estimé : 8 min

Cet article fait partie d’un groupe d’articles visant à bien préparer le backlog du premier sprint d'un projet avant de commencer à développer. C’est le dernier article de la série, si vous avez manqué le troisième, le voici : Comment bien démarrer un projet : exposer les règles métiers grâce à l'Example Mapping
Bonne lecture !

La semaine dernière, nous avons vu grâce à l'Example Mapping comment exposer les règles métiers de nos premières User Stories.

Nous sommes donc passés par une étape initiale de Domain Storytelling pour comprendre les différents scénarios utilisateurs de notre produit. Puis nous avons utilisé les User Stories comme support de discussion grâce au Story Mapping, avant l’atelier d’Example Mapping pour faire naître les règles métiers.

Ces 3 ateliers ne sont pas gravés dans le marbre, on fait des allers-retours réguliers entre chaque, et ce pour être le plus agile possible !

Mais au fait, c’est quoi être “agile” ?

L’objectif de l’agilité

L’objectif principal de l’agilité est de pouvoir obtenir un retour utilisateur le plus rapide possible pour livrer les bonnes fonctionnalités, au bon moment, en maîtrisant les coûts.

Ce faisant on tente de réduire les risques de partir dans une mauvaise direction et ainsi limiter les coûts, tout en optimisant le temps passé à développer des fonctionnalités, le tout en respectant un périmètre métier correspondant aux objectifs business.

La qualité d’un logiciel est donc fonction de ces trois composantes. Souvent résumée à travers le “iron triangle” de l’agilité :

Ce que signifie ce triangle est que pour éviter d’impacter la qualité logicielle (au sens large, technique et produit), si des compromis sont fait sur l’une des trois composantes, des ajustements doivent être faits sur les autres pour compenser.

L’agilité, c’est pouvoir être “agile” dans la gestion de chacun de ces éléments pour pouvoir à chaque itération revoir les priorités en fonction de ce que l’on a appris depuis la dernière itération (ou en cours d’itération), pour se rapprocher toujours plus de l’objectif métier, l’objectif “business”.

En résumé : l’agilité, c’est composer avec des compromis pour apporter de la valeur le plus fréquemment possible à l’utilisateur final, sans impacter la qualité.

Comment faire alors en sorte que les US ne restent pas des jours, voire des semaines entières dans le board avant d’être livrées ?

Le découpage des User Stories

Étant donné cette définition de l’agilité, il devient évident que découper les User Stories pour les livrer plus rapidement est nécessaire.

Mais attention à la définition de “livrer”.

Prenons en exemple l’une des User Stories de CraftOverflow :

Lorsque l’on veut découper une US, on a parfois tendance à la découper techniquement parlant :

on va d’abord créer une US pour gérer la création du schéma de la base de données par exemple…
…puis une autre US pour gérer l’ajout d’un vote dans la base de données…
…puis faire l’API nécessaire pour que ça puisse être appelé depuis le front…
…puis faire le composant front qui va gérer le vote, en prenant en compte la règle que si on re-clique sur notre vote ça l’annule.

Bref, vous voyez le genre. On a tous eu affaire à ce genre de découpage qui permet en effet de découper la User Story initiale en plusieurs petites User Stories.

Mission accomplie non ? Nous allons pouvoir livrer chaque petite story beaucoup plus rapidement !

Ok, mais quid de la valeur ajoutée pour l’utilisateur final ?

Avec ce genre de découpage, on livre de la technique. On ne livre pas de la valeur pour l’utilisateur final.

Vous avez probablement déjà joué au Rubik’s Cube dans votre vie ! Et probablement que vous avez déjà essayé de le démonter pour le “résoudre” plus rapidement (allez avouez-le c’est pas grave ;) ) :

En prenant chaque petit cube et le retournant dans le bon sens, le cube sera utilisable qu’après avoir remis tous les cubes en place !

C’est ce que l’on appelle un découpage horizontal. Découper une User Story en fonction de ses différentes couches techniques.

Pour un découpage réussi, il faut garder en tête que ce “bout” de User Story doit pouvoir être mis entre les mains de l’utilisateur final ! Ce “bout” de User Story doit donc contenir de la valeur ! Couper un gâteau horizontalement ne vous viendrait pas à l’esprit. Le couper verticalement, c’est donner un bout de l’essence même de ce gâteau à chaque personne.

Le découpage vertical

Vous l’avez compris, il va donc falloir se concentrer sur le découpage vertical de nos US plutôt que sur le découpage horizontal. Pour ce faire, il existe trois grands leviers pour chaque US à découper :

Les aptitudes / besoins : qu’est-ce que l’utilisateur final veut pouvoir faire ?
Les fonctionnalités : quelles fonctionnalités avons-nous besoin pour que l’utilisateur puisse atteindre ses objectifs liés à ses besoins ?
La technique : quelles tâches / étapes avons-nous besoin pour implémenter les fonctionnalités ?

“Découper la technique ? Mais je croyais que c’était justement ce qui était à éviter ?”

Le découpage horizontal de la technique oui, tout à fait ! Mais pas le vertical :) J’y viens.

Les aptitudes / besoins

Parfois une User Story est considérée trop grosse car elle aborde finalement plusieurs choses.

Quand une US contient des mots comme “et”, “ou”, c’est un signe qu’il est probablement préférable de séparer en deux US distinctes, chacune gérant un cas précis.

Il est aussi intéressant à ce niveau de bien séparer chaque US en fonction des types d’utilisateurs finaux, voire de leur plateforme (mobile, web, etc.).

Quand on y réfléchi bien, et c’est tout sauf un hasard, nos ateliers précédents de Domain Storytelling / Story Mapping et Example Mapping permettent de mettre en avant ces différents scénarios, en fonction des différents types d’utilisateurs, et en ce sens participe directement du découpage fin et vertical des User Stories ;)

Les fonctionnalités

Quelque chose que l’on entend souvent quand on doit découper une US c’est :

“Non mais là c’est impossible de découper plus…Nos utilisateurs ne vont pas se contenter d’avoir quelque chose d’à moitié terminé ! Mieux vaut attendre d’avoir tout terminé”

En effet, c’est une remarque légitime ! Imaginez que vous aillez des centaines, voire des milliers d’utilisateurs et que vous livriez une page sans quasiment aucun design, très “brut de décoffrage”. Que vont-ils pensez de votre boîte ?

Rappelez-vous : l’objectif est d’avoir des retours utilisateurs le plus rapidement possible afin d’être sûr de ne pas aller dans une mauvaise direction.

Avoir des retours des utilisateurs n’est pas synonyme de “mettre en production et attendre de voir ce que vont en penser nos utilisateurs” !

Un échantillon d’utilisateur suffit, parfois même une ou deux personnes peuvent suffire au début. Ces personnes seront bien moins regardantes sur les “jolis détails” que sur l’aspect fonctionnel et donc la valeur apportée pour répondre à leur besoin.

En prenant conscience de cela, on peut, par exemple :

se contenter d’abord d’un formulaire extrêmement basique sans aucune validation
ne pas avoir un design extrêmement léché tout de suite
ne gérer que le “happy path”
gérer qu’une seule règle métier dans un premier temps avant d’implémenter les autres
ne gérer qu’un seul type de données en entrée avant de gérer les types les moins fréquents
etc.

La technique

Nous y voilà, la technique ! Lorsque l’on commence un projet ou une toute nouvelle fonctionnalité, on a souvent tendance à croire qu’il faut commencer par la technique. La base de données, l’API, etc.

En effet, comment livrer l’US sinon ?

Eh bien j’apporterais la même réponse qu’au paragraphe précédent sur les fonctionnalités : c’est le retour utilisateur qui est le plus important, et l’utilisateur il s’en tamponne complètement qu’il y ait telle ou telle base de données derrière ou que vous utilisiez une API REST ou GraphQL.

À la place, vous pourriez donc :

commencer par une simple base de données en mémoire temporaire, comme le localStorage du navigateur
mettre des données “en dur” dans la page, sur lesquelles il est possible d’interagir comme si c’était de vraies données
décider de privilégier la version mobile plutôt que la version desktop dans un premier temps
faire une fausse authentification avec des utilisateurs prédéfinis pour chaque rôle
etc.

On comprend ainsi l’importance de commencer un projet par le frontend finalement ! C’est ce qui permet de découvrir le plus vite si l’on est dans la bonne direction ou non :)

Attention cependant ! Pouvoir faire ce genre de découpage verticale technique implique une haute qualité de code pour pouvoir simplement “remplacer” une fausse implémentation par la vraie. À la fin, il y aura bien une vraie API, une vraie base de données, etc. D’où l’importance d’avoir un code bien découplé pour ne pas être dépendant des choix techniques. D’où l’importance de se pencher sur les pratiques comme le TDD, l’architecture hexagonale, les principes SOLID, etc. Ce n’est pas un hasard sur le manifeste agile a été écrit avec pour objectif de promouvoir la qualité logicielle ;)

À quelle “finesse” de découpage s’arrêter ?

“It Depends” ™

Rappelons-nous l’objectif initial du découpage des US : pouvoir livrer rapidement les fonctionnalités les plus impactante pour le business afin d’avoir une boucle de feedback la plus efficace possible.

Livrer rapidement signifie pouvoir mettre entre les mains des utilisateurs (afin d’obtenir du feedback, donc pas nécessairement en production, mais dans un environnement proche de la production) plusieurs fois par semaine idéalement, voire plusieurs fois par jour si vous pouvez vous le permettre !

Si vous souhaitez pouvoir livrer plusieurs fois par jour, vous devrez ainsi faire un découpage nécessairement plus fin que si vous souhaitez livrer plusieurs fois par semaine.

Cela dépend aussi de la vélocité de l’équipe évidemment !

Ces différentes heuristiques de découpages ne sont donc, elles non plus, pas gravées dans le marbre ! Vous devez en analyser les résultats, et réadapter au fur et à mesure pour voir ce qui fonctionne le mieux dans votre projet, dans votre contexte, avec votre équipe :)

Dans le cadre de Craft Overflow par exemple, comme je compte faire des vidéos relativement courtes, j’aimerais a priori pouvoir livrer au moins une fois par vidéo ou une fois toutes les deux vidéos. Cela va donc m’imposer d’avoir un découpage très fin ! Si je faisais ce projet en équipe, à temps plein, un découpage moins fin aurait pu suffire pour le même résultat en termes de livraison, car plus d’heures de travail auraient pu être allouée :)

Et maintenant, bon découpage et Happy Coding ! :)

[4/4] L'arme ultime de l'agilité : comment b…

Create your profile

Only paid subscribers can comment on this post

Check your email