De l’utilité de découper les éléments du backlog

Une des constantes que j’ai rencontrée lors de mes différents accompagnements d’équipes se situe sur l’utilité du découpage des éléments du backlog. Souvent, je fais face aux remarques suivantes (que j’ai pu moi-même dire ou penser lorsque j’étais développeuse IT) :

• “Ça sera la même personne qui va s’occuper de tout le travail, à quoi bon le découper ?”
• “À part perdre du temps administratif à créer 100 tickets dans Jira, ça sert à quoi ?”
• “Non, mais ce truc, là, c’est impossible à découper”

J’ai également pu voir de beaux changements dans la manière de faire lorsque l’équipe comprend vraiment pourquoi c’est intéressant de découper des éléments du backlog. Pour cette raison, j’avais envie de formaliser par écrit toutes les bonnes raisons que je vois à découper des éléments que ce soit en petites fonctionnalités ou en tâches techniques.

Je vois trois raisons principales pour découper des éléments du backlog :

• Recevoir du feedback plus rapidement
• Améliorer la collaboration au sein de l’équipe
• Rendre l’ensemble plus facile et efficient

Recevoir du feedback

La meilleure manière de fournir de la valeur au client est de pouvoir mettre une fonctionnalité sur le marché le plus rapidement possible. En découpant notre travail de manière fonctionnelle, il sera possible de livrer des éléments plus petits, plus rapidement. Ceci nous permet de recevoir du feedback sur la valeur de ce qui a été livré et si nous faisons bonne ou fausse route. Il sera plus facile et moins couteux de nous adapter après un petit développement plutôt qu’un gros.

Mettre sur le marché rapidement est le but à rechercher. Cependant, ce n’est pas toujours possible de le faire. Dans ce cas, nous recevons tout de même du feedback plus rapidement de la part des testeurs, Product Owner, SME (Subject Matter Expert) ou partie prenante qui effectuent les tests ou sont présents par exemple lors de la revue. Ces feedbacks nous permettent également de nous adapter pour la suite des développements.

Je me souviens d’un gros développement de formulaire pour lequel nous avions pris le temps de découper la fonctionnalité. Lors d’une revue, l’une des parties prenantes nous a signalé que telle partie du formulaire était complètement obsolète ! Heureusement, nous avons pu retirer de notre backlog tous les autres éléments liés qui étaient obsolètes. Pour finir, nous n’avons perdu que 2 jours de développement ! Ouf !

Collaboration au sein de l’équipe

Le découpage fonctionnel

Le découpage fonctionnel permet d’améliorer la collaboration au sein de l’équipe, car le travail peut être mieux réparti, ce qui a comme influence de mieux partager les connaissances.

Chez un client travaillant sur les transmissions télévisuelles, nous avions un expert dans l’équipe sur le sujet des planifications des transmissions, un sujet très complexe. Cela était un gros risque… le “bus factor” comme on dit gracieusement.

Lorsqu’une nouvelle fonctionnalité est apparue dans le Backlog à ce sujet, nous avons pris le temps de découper le sujet fonctionnellement pour que plusieurs développeurs dans l’équipe puissent s’en occuper. Les personnes ont pris un peu plus de temps que l’auraient fait l’expert, elles ont pu s’adresser à ce dernier pour poser des questions, mais au moins, la connaissance du sujet était partagée et peu à peu un plus grand nombre de personnes est monté en compétence dessus.

Le découpage technique

Le découpage technique permet quant à lui un meilleur alignement des développeurs sur la manière de développer la fonctionnalité, cela engendre également plus de cohérence dans les développements et un nivellement (par le haut) des connaissances techniques.

La collaboration est plus aisée lors d’une absence, tout ne repose pas sur un seul développeur. C’est également le cas en cas de blocage, il est plus facile de constater qu’un développement bloque lorsqu’il devrait prendre un jour plutôt que dix jours.

Un collègue travaillait sur une tâche devant prendre 10 jours. Lors de nos points de synchronisation en équipe, le collègue nous indiquait que tout allait bien, qu’il n’avait pas de difficulté particulière… ce n’est qu’au 9e jour que nous avons appris qu’il était bloqué et qu’il restait pratiquement la totalité du développement à faire. Certes, il y a eu un accompagnement à faire auprès de ce collègue pour l’aider à l’avenir à trouver le courage de demander de l’aide. Cependant, les autres membres de l’équipe et moi-même n’avons pas été en mesure de l’aider avant, car rien n’indiquait qu’il y avait un problème. Il a fallu attendre 9 jours pour pouvoir le soutenir et faire avancer le travail. Avec un découpage de cette demande en amont, nous aurions pu réagir bien plus vite.

N’oublions pas que ce découpage nous permet également de livrer de la valeur plus rapidement puisque les développements sont potentiellement parallélisés sur plusieurs personnes plutôt que d’être effectués séquentiellement.

Facilité et efficience

Découper fonctionnellement ou techniquement amène beaucoup de facilité dans le métier de développeur.

• Les revues entre pairs sont plus abordables.
• Le périmètre des tests à écrire est plus limité.
• Il est possible d’agréger le travail fait par plusieurs personnes plus régulièrement et, de ce fait, limiter les conflits et incompréhension.
• Il y a également moins de risques d’oubli ou d’erreur lors du développement lui-même : les cas à la marge et les exceptions sont plus facilement ciblées ; la demande est moins dense et plus claire.
• Dans un contexte IT, en buildant et fusionnant plus régulièrement, les tests automatiques sont également joués plus régulièrement ce qui permet de détecter les erreurs plus vites.

Les collègues ont souvent de la réticence à démarrer une revue entre pairs longue et complexe. C’est donc la double peine : non seulement le développement a pris beaucoup de temps, mais il risque d’y avoir également beaucoup de temps avant que la revue soit faite… et tout autant de temps pour intégrer les remarques qui auront été faites lors de la revue.

Au-delà de l’aspect technique, avoir un élément plus petit aide d’un point de vue fonctionnel.

• Plus souvent qu’on ne le croit, toutes les spécificités d’une demande ne sont pas indispensables. Découper les demandes nous permet d’enrichir un besoin au fur et à mesure en s’arrêtant dès que cela n’est plus utile ou qu’une autre demande à plus de valeur.
• En découpant le besoin, la complexité est souvent diminuée ce qui permet de mieux comprendre la demande, de limiter les parties inconnues et donc risquées et en conséquence de limiter le risque d’erreur et d’oubli.
• Les critères d’acceptance et les tests fonctionnels seront plus facilement déterminés, compris et effectués.

Une demande avait été faite afin de limiter les types de fichiers qui pouvaient être uploadés sur une plateforme. Le système d’upload était déjà en place en production et comme cette nouvelle demande fonctionnelle avait été estimée et semblait conséquente, j’ai demandé s’il était possible de découper cette fonctionnalité. Il m’a été répondu que les contrôles qui étaient prévus à la fois côté serveur et côté client devaient être faits tous les deux. En prenant le temps d’y réfléchir, il a été proposé de livrer d’abord le contrôle côté serveur qui permettait au moins de limiter les erreurs puis de livrer le contrôle côté client qui rendait l’expérience utilisateur plus agréable, mais qui malgré tout n’était pas complètement indispensable.

Conclusion

En conclusion, je dirai que oui, effectivement, cela va générer un peu plus d’administratif dans votre outil de gestion de backlog… mais cela vous simplifiera la vie de manière générale pour la suite que ce soit au niveau du développement, de la fonctionnalité elle-même et de la valeur. Prenons le réflexe de systématiquement nous demander “Pouvons-nous livrer cette partie sans le reste ?”

Et l’agilité dans tout ça ? J’espère que vous avez remarqué que je n’ai pas mentionné ce mot jusqu’à maintenant. En effet, le découpage n’est pas une demande ni de l’agilité, ni de Scrum. Pourtant, cette bonne pratique soutient l’utilisation des cadres agiles. Je peux mentionner par exemple certains des principes du Manifeste Agile :

• Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
• Accueillez positivement les changements de besoins, même tard dans le projet.
• Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
• Un logiciel opérationnel est la principale mesure d’avancement.
• La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

J’admets volontiers qu’il n’est pas toujours facile de savoir découper de la manière la plus logique et efficace. Cela demande un peu d’entraînement et quelques pistes… peut-être l’occasion de faire un nouveau billet de blog sur ce sujet.