L'arriéré

Le Backlog (ou Product Backlog, comme l'appellent certaines méthodes Agile telles que Scrum) est une liste ordonnée d'éléments qui apporteront valeur métier au client. Il peut être constitué d'une liste hétérogène de types d'éléments allant des Fonctionnalités , User Stories et Exigences (y compris Exigences non fonctionnelles) aux Défauts , aux Changements et plus encore. En fait, dans Enterprise Architect n'importe quel élément peut être placé dans un Backlog ; ceux qui sont répertoriés et ceux qui apparaissent dans la Boîte à outils sont tout simplement les plus courants. Le Backlog est une liste ordonnée basée sur la valeur métier, les éléments de plus grande valeur se retrouvant en haut de la liste. La liste est détenue et gérée par le Product Owner ou son équivalent ; c'est-à-dire une personne agissant en tant que substitut du client.

Commander Items dans une voie de backlog

Lorsque vous travaillez avec un flux de travail en une seule étape, les éléments du backlog sont généralement contenus dans la première voie du Kanban et peuvent être déplacés vers un nouvel emplacement dans la voie pour modifier l'ordre des éléments dans le backlog.

Prioriser un backlog

En règle générale, l'ordre des éléments du Backlog est déterminé avec soin et réflexion par le Product Owner et reflète la valeur commerciale - les éléments prometteurs pour l' valeur sont situés en haut. La priorisation du Backlog est la responsabilité du Product Owner, mais elle n'est pas décidée indépendamment des autres membres de l'équipe et le Product Owner s'appuie sur l'accès à des informations importantes provenant d'un éventail de parties prenantes, des parties prenantes de niveau exécutif, des responsables commerciaux et opérationnels, des analystes des exigences et analystes métier , jusqu'aux équipes de mise en œuvre.

Une gamme de diagrammes et de documents stratégiques fournit une source pour de nombreuses décisions de priorisation. Il s'agit notamment des cartes stratégiques, des moteurs Métier , des buts et objectifs et diagrammes Feuille de Route qui décrivent le séquençage temporel des paquetages de travail. L'exemple diagramme Feuille de Route peut être utilisé par le propriétaire du produit comme une entrée pour ce qui est hautement prioritaire pour le Métier , ou ce qui a été planifié par les équipes Architecture de l'entreprise ou Métier . Le diagramme s'avérera utile dans les discussions avec les parties prenantes de l'entreprise et les exécutants, qui peuvent obtenir un contexte commercial pour le travail qu'ils accomplissent.

Les commentaires fournis par les développeurs et les autres parties prenantes constitueront également une source précieuse d'informations et de contributions pour la priorisation du backlog. Enterprise Architect dispose d'une fenêtre Discuss & Révision , qui est un facilité hautement collaboratif grâce auquel tout membre de l'équipe peut saisir des messages de discussion sur un élément et d'autres utilisateurs peuvent répondre et rejoindre la discussion. Cela peut créer une mosaïque de connaissances riche et utile qui aidera non seulement le propriétaire du produit à décider de la position de l'élément dans la liste du backlog, mais aidera également les développeurs lorsqu'ils seront prêts à mettre en œuvre l'élément.

Une autre information essentielle qui aidera le Product Owner est l'estimation des éléments complétés par les implémenteurs, qui font leur meilleure estimation du temps que l'élément est susceptible de prendre. Les équipes agiles qui utilisent des User Stories ont tendance à utiliser des Story Points, mais n'importe quelle unité de mesure peut être utilisée tant que l'équipe s'accorde sur une norme. Certaines équipes utiliseront les temps réels basés sur des unités telles que le nombre d'heures, tandis que d'autres utiliseront des estimations basées sur l'effort. Enterprise Architect dispose d'un facilité d'allocation des ressources flexible et intégré où les membres de l'équipe peuvent ajouter des estimations, le temps autorisé, les temps réels, les pourcentages d'achèvement et plus encore. Cela sera inestimable pour le Product Owner, qui peut avoir une idée générale du temps nécessaire pour terminer un élément mais qui s'appuiera fortement sur les détails fournis par l'équipe. L'estimation du temps peut être saisie dans le champ « Temps prévu » de la fenêtre d'allocation des ressources.

Exemple

Ce diagramme montre comment un backlog peut être défini dans un flux de travail en une seule étape, permettant de faire glisser et de déposer des éléments dans une seule colonne pour définir l'ordre des éléments dans le backlog.

Ordonner Items dans un Diagramme de backlog

Lorsque vous travaillez avec des flux de travail à deux ou trois étapes, les éléments du Backlog sont contenus dans un tableau Kanban représentant l'intégralité du Backlog, ce qui leur permet d'être déplacés entre les voies de faible à moyen, élevé ou critique ou en utilisant n'importe quel nom de voie défini par l'utilisateur ou propriété liée.

Sécurisation d'un backlog

Le Backlog est un outil de communication qui isole les implémenteurs de la nécessité de décider sur quoi ils doivent travailler. Il appartient au Product Owner et est géré par lui, qui décide en dernier ressort de ce qui doit figurer dans le Backlog et de l'ordre des éléments qu'il contient. Il doit donc être protégé contre les modifications involontaires. L'équipe d'implémentation doit avoir accès au Backlog, mais dans le but de tirer des éléments d'une file d'attente de travail vers la voie En cours, qui peut être basée sur un flux continu (Kanban) ou sur une période de temps (comme un Sprint). L'équipe de développement doit également fournir des estimations de temps pour les éléments du Backlog, ce qui aidera le Product Owner à décider de l'ordre des éléments, en particulier lorsque deux éléments ou plus ont valeur commerciale comparable. L'élément avec l'estimation d'achèvement la plus basse se verra généralement attribuer une position plus élevée. Les développeurs sont également censés et encouragés à commenter les éléments du Backlog afin que le Product Owner puisse comprendre les problèmes éventuels ou avoir accès à formation d'initiatives ou d'idées antérieures.

Le système de sécurité d' Enterprise Architect peut être utilisé pour verrouiller le Backlog tout en permettant aux utilisateurs d'apporter les contributions nécessaires en termes d'estimations de temps et de commentaires sous forme de discussions.

Avec le système de sécurité activé et un groupe de propriétaires de produits ou des utilisateurs individuels qui sont des propriétaires de produits ajoutés, un diagramme de backlog peut être verrouillé par l'utilisateur propriétaire de produit individuel ou par un membre du groupe de propriétaires de produits. Cet exemple montre que le backlog est verrouillé par le groupe de propriétaires de produits, mais pour un référentiel auquel accèdent plusieurs propriétaires de produits, il peut être plus pratique de verrouiller le diagramme sur une personne.

Lorsque le diagramme du backlog a été verrouillé par le propriétaire du produit, les autres membres de l'équipe pourront diagramme visualiser, mais un petit marqueur rouge à gauche du nom diagramme dans la fenêtre Navigateur indiquera qu'il est verrouillé. Le chef de projet verra un marqueur bleu indiquant qu'il a accès à la modification du diagramme .

Sécurisation d'un Diagramme de backlog

Sécurisez un diagramme de Backlog, en gardant à l'esprit qu'il peut être verrouillé au niveau d'un utilisateur ou d'un groupe.

Notes

• Le modèle doit avoir la sécurité utilisateur activée pour verrouiller le diagramme Kanban du backlog
• Pour sécuriser un Backlog, un flux de travail en deux ou trois étapes est nécessaire, le Backlog étant un diagramme Kanban distinct.