Site Overlay

Accélérer les particules

“Livrer à chaque sprint un incrément directement utilisable et apportant de la valeur”, c’est l’objectif de l’équipe Scrum, par extension d’une équipe agile.

Pourquoi livrer fréquemment ?

Livrer fréquemment permet tout d’abord de se confronter aux utilisateurs, d’obtenir du feedback et de valider les directions à prendre. En même temps que le feedback, livrer fréquemment permet aussi d’éclairer les décisions des parties prenantes sur ce qui plait ou plait moins au clienbts et donc d’argumenter. Toujours par rapport aux parties prenantes, le fait qu’elles voient le produit se développer sous leurs yeux peut les amener à changer d’idée, modifier leurs convictions, en bref pivoter plus facilement.

De plus livrer fréquemment permet de lever certains des éléments de complexité, les mises en production fréquentent permettent ainsi de se confronter aux utilisateurs plus fréquemment et donc de vérifier s’il est nécessaire de pivoter ou si on est sur la bonne voie. De même, livrer rapidement permet en réduisant les “morceaux” de logiciels de tester en continue le fonctionnement effectif du système et de pouvoir réparer plus vite via la réduction du champ d’investigations.

Comment livrer fréquemment ?

Il faut voir le flow de production comme un tout, un système industriel qui sert la fabrication, la transformation, d’une idée, la user story, en un bout de code utilisable.

Ainsi, l’input passe par plusieurs phases de transformation (estimation, découpage, developpement, tests,…) pour aboutir à l’output, le code intégré dans le produit et mis en production.

Il n’y a que deux manières d’accélérer le mouvement. Soit on facilite le passage de l’input dans la chaine de fabrication afin que celui ci passe plus facilement les étapes (action sur le process), soit on reduit la taille de l’entrant, un plus petit morceaux passera plus facilement (action sur l’input).

Pour faciliter le passage on va donc tout d’abord agir sur le process : test automatiques, liens entre les environnements, utilisation de framework, pratique du clean code, meilleure intégration des ops… Bref la CI/CD. Ces pratiques sur le process seront d’autant plus facilitées qu’on travaillera sur l’amont, l’idée, la user story de manière a la rendre la plus petite possible : en faire une particule.

En effet, plus la story est petite plus le process sera efficient. Passer un plus petit morceau dans le process va permettre de gagner du temps sur la conception, le développement, mais aussi sur les tests, tant techniques que fonctionnels.

On le voit la découpe des user story est l’élément primordial pour permettre au process d’être optimum. Il existe plusieurs manières de découper, il faut trouver celle qui va le mieux à l’équipe au moment ou elle travaille, comme d’habitude c’est à l’équipe de décider. Voici quelques pistes pour vous aider à couper plus “fin” : selon le parcours client et les scenarios d’usage, selon les regle metiers, selon l’effort,… On peut tout imaginer. En revanche, pour un product owner, il me semble primordial d’intégrer très en amont l’équipe qui va faire, les developpeurs, et de surtout ne pas présupposer de ce qui va leur faciliter le travail. Ce sont eux qui connaissent l’applicatif et sa structure et ils sont en capacité d’aider à prioriser et découper.

J’ai trop souvent vu des user story découpées à priori et dont la quatrième remettait en cause les choix effectués pour la première. Il sera plus facile à un développeur de poser les bonnes questions s’il est confronté au besoin le plus général dès le départ pour aider ensuite a trouver les étapes pour y arriver. Une équipe agile est une seule équipe, la transparence et la vision de l’objectif doit être partagée.

Pour en savoir plus sur la découpe :

https://blog.eleven-labs.com/fr/ecrire-et-decouper-ses-users-stories-comme-un-ninja/

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *