product backlog

Comment organiser les fonctionnalités du projet avec le Backlog de produit ?

**Ce texte en version anglaise est publié sur  www.softwarehut.com **

Le devoir du Propriétaire du Produit dans les pratiques de développement de produits orientées Agile est d’être en charge de la gestion du Backlog de Produit de chaque équipe de mêlée. Qu’est-ce que cela signifie exactement ?

Avant tout, la responsabilité du Propriétaire du Produit consiste à tenir à jour le Backlog de Produit en collaboration avec l’équipe et les parties prenantes externes, ainsi qu’à gérer un portefeuille de fonctionnalités. Cependant, ses responsabilités ne s’arrêtent pas là. Le Propriétaire du Produit doit fournir un travail organisé aux équipes de développement et optimiser les éléments, tels que les histoires de l’ utilisateur et les tâches.

Voici une liste de pratiques sur la façon d’organiser le projet avec le Backlog de Produit.

Backlog de Produit

Une vision claire

Pour bien gérer le Backlog de Produit, il faut définir une vision claire du produit. Une fois que c’est fait, il est beaucoup plus facile d’aider l’équipe à s’engager et de décrire le projet de manière claire et compréhensible. Vous ne savez pas comment le faire correctement et efficacement ? Je vous recommande de consulter l’explication de Roman Pichler.

Décrire comment gérer le Backlog de Produit

Comme je l’ai déjà mentionné, le Propriétaire du Produit a la responsabilité de maintenir le Backlog de Produit, mais tout le monde devrait y participer et le maintenir à jour. C’est à l’ensemble de l’équipe de fournir toutes les données nécessaires au Backlog de Produit. En créant un plan sur la façon de gérer le Backlog, nous pouvons facilement impliquer tous les membres de l’équipe dans ce processus.
Le minimum absolu est de décrire (dans un wiki par exemple) la signification de chaque état des éléments de travail.

Créez votre Backlog de Produit

Le Backlog de produit est créé en ajoutant les histoires de l’utilisateur et leurs tâches complémentaires. Ce processus repose sur la description des exigences d’une manière compréhensible, tout en montrant l’objectif du travail du développeur.
Ainsi, lorsque votre demande de devis consiste en une liste d’exigences, nous nous concentrons sur l’élément de travail lui-même. Pour le définir, effectuez les étapes suivantes :

  1. Titre
    Pour créer des éléments, il faut définir un titre approprié. Nous utilisons un schéma naturel :
    par ex. [nom de la vue] + titre de l’appel à l’action | nom de la fonction liée à une fonctionnalité principale
  2. Autorisation
    Toutes les informations collatérales et dédiées (telles que l’élément frontend, l’élément backend, l’élément de dépendance ou l’élément de jalon) doivent être décrites comme une balise.

  3. Description
    Le contenu de la description doit exprimer clairement les besoins de l’entreprise ou des utilisateurs et se composer de tout élément susceptible d’aider les développeurs dans leur travail. Il doit représenter le point de vue d’un utilisateur potentiel du produit. Voici l’exemple du format de l’user story :
    En tant que (rôle), j’ai besoin de (capacité), afin que (recevoir un avantage).

  4. Les critères d’acceptation
    En bref, les critères d’acceptation peuvent être définis comme les résultats attendus de la mise en œuvre d’un élément particulier du Backlog de produit et sont utilisés comme des directives strictes et prouvés par des tests d’application. De manière informelle, les critères d’acceptation expliquent quand l’élément de travail peut être considéré comme terminé.

  5. Lien externe
    J’utilise personnellement un champ « lien externe » distinct dans la description de l’histoire d’utilisateur. Si je dispose de matériel supplémentaire, d’exemples de solutions que le client apprécie ou d’analyses de données, je crée un lien vers ces documents dans un champ distinct. De cette façon, je souligne l’importance de ces documents de manière claire et évidente et, presque mécaniquement, je peux soutenir la discussion pendant la session de planification.

L’importance de la priorité et du risqué

Le but du Backlog de produit est de spécifier l’ordre. Nous devons classer la liste des fonctionnalités et des exigences par ordre de priorité. Plus le nombre est élevé, plus la valeur commerciale est grande.
Les responsabilités les plus importantes atterrissent en haut de la liste, afin que chaque membre de l’équipe sache toujours ce qu’il doit faire ensuite. L’ordre du Backlog de produit peut être basé sur la priorité, la valeur, les dépendances, le risque ou la gravité (en cas de défauts).
Il existe de multiples techniques de hiérarchisation. Je décris ci-dessous celles que j’utilise fréquemment dans mes projets :

 

  1. Squelette ambulant
    Il présente le preuve de concept (produit minimum viable MVP). Il s’agit d’une petite implémentation du système qui remplit une petite fonction de bout en bout. Il ne doit pas nécessairement utiliser l’architecture finale, mais il doit relier les principaux composants architecturaux.

  2. MoSCoW
    L’acronyme MoSCoW signifie Must have, Should have, Could have, Won’t have des exigences. MoSCoW est l’approche la plus simple et la plus populaire de la hiérarchisation des priorités.

  3. Valeur commerciale
    Approche très efficace si vous avez une idée commerciale validée. Pourquoi ? Dans cette technique, c’est une partie prenante ou le propriétaire du produit qui estime et décide quelles histoires d’utilisateur apportent la plus grande valeur financière.

  4. Risques technologiques
    Il s’agit de hiérarchiser le montant estimé des risques pour la mise en œuvre des fonctionnalités. L’approche consiste à mettre en œuvre les fonctionnalités les plus risquées en premier et à terminer par des tâches d’ingénierie entièrement prévisibles. Malheureusement, pour autant que je sache, les tâches d’ingénierie entièrement prévisibles n’existent pas. Cela fonctionne si vous avez une idée commerciale validée ou un produit fonctionnel en cours de mise à jour.

  5. HiPPO – Opinion de la personne la mieux payée
    Malheureusement, il n’offre pas suffisamment de transparence aux membres de l’équipe et peut empêcher la prise de décision basée sur les données. Je la recommande donc comme une méthode supplémentaire et complémentaire.

Affinez souvent votre Backlog de Produit

Révisez et hiérarchisez fréquemment votre backlog pour :

  • définir le travail à faire en ajoutant des détails aux éléments de travail, si nécessaire,
  • définir les critères d’acceptation et la définition de ce qui est fait,
  • vous assurer que les exigences sont dimensionnées de manière appropriée,
  • maintenir le travail en ordre ou le réorganiser pour créer un ordre de priorité,
  • aidez votre équipe à savoir ce qui est le plus important à livrer ensuite,
  • maintenir la clarté de l’objectif du projet,
  • suivre les dépendances.

L’accès au Backlog de Produit est une source de transparence

Comme vous le savez déjà, le Backlog de produit est considéré comme une liste d’éléments nécessaires à la création du produit. Une bonne idée est de fournir un accès à toutes les parties concernées, telles que le bureau de gestion, les équipes de produits et les parties prenantes à tout moment et d’avoir des droits d’utilisateur suffisants. En outre, afin de rendre le travail plus transparent pour les parties prenantes, il est conseillé de partager le Backlog de Produit avec elles, de sorte qu’elles puissent vérifier en permanence le dernier statut et fournir des commentaires.

Le Backlog de produit est utilisé pour partager des informations, organiser le travail et bien plus encore. Ce qui fonctionne vraiment bien pour moi, c’est que j’ai le contrôle total.

Un Backlog de produit bien géré aide votre équipe à accélérer la progression du développement. Il est également considéré comme une alternative à la documentation détaillée dans les pratiques agiles de gestion de projet, qui sert de guide à la fois aux équipes de produits et aux parties prenantes commerciales.

Ainsi, si vous n’avez pas besoin de documenter la portée et les exigences initiales détaillées ou l’approbation formelle des phases de documentation, c’est le meilleur moyen de rassembler toutes les connaissances sur le produit.

Wersja polska
English version
Chère lectrice / cher lecteur, le français n’est pas ma langue maternelle, mais je vais faire de mon mieux ici. Merci pour votre aide à l’amélioration de la traduction.

Posts created 110

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles similaires

Commencez à saisir votre recherche ci-dessus et pressez Entrée pour rechercher. ESC pour annuler.

Retour en haut