L'arriéré

Le Backlog (ou Product Backlog, comme l'appellent certaines méthodes Agiles telles que Scrum) est une liste ordonnée d'éléments qui apporteront une valeur commerciale au client. Il peut s'agir d'une liste hétérogène de types d'éléments allant des Fonctionnalités , User Stories et Exigences (y compris les Défauts Exigences Changements et plus encore. En fait, dans Enterprise Architect , n'importe quel élément peut être placé sur 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 commerciale, avec les éléments de valeur supérieure valeur vers le haut de la liste. La liste est détenue et gérée par le Product Owner ou son équivalent ; c'est-à-dire quelqu'un agissant en tant que substitut du client.

Commande d' Items dans une voie de backlog

Lorsque vous travaillez avec un flux de travail en une étape, les éléments du backlog seront 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 dans le Backlog est soigneusement et judicieusement déterminé par le Product Owner et reflète la valeur commerciale - les éléments promettant une valeur commerciale valeur sont situés en haut. La hiérarchisation du Backlog relève de 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 au niveau de la haute direction, des responsables commerciaux et opérationnels, des exigences analystes 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, Métier moteurs de métier, des buts et objectifs et des diagrammes Feuille de Route qui décrivent l'enchaînement temporel des paquetages de travail. L'exemple de diagramme Feuille de Route pourrait être utilisé par le Product Owner comme entrée pour ce qui est hautement prioritaire pour le Métier , ou ce qui a été planifié par les équipes Entreprise ou Métier Architecture. Le diagramme s'avérera utile dans les discussions avec les parties prenantes commerciales et les exécutants, qui peuvent obtenir un contexte commercial pour le travail qu'ils accomplissent.

Les commentaires fournis par les responsables de la mise en œuvre et d'autres parties prenantes fourniront également une source précieuse d'informations et de contributions à la hiérarchisation de l'arriéré. Enterprise Architect a une fenêtre Discuss & Révision , qui est une facilité hautement collaborative à travers laquelle tout membre de l'équipe peut entrer des messages de discussion contre un élément et d'autres utilisateurs peuvent répondre et rejoindre la discussion. Cela peut créer une tapisserie de connaissances riche et utile qui aidera non seulement le Product Owner à décider de la position de l'élément dans la liste de backlog, mais aidera également les implémenteurs lorsqu'ils seront prêts à implémenter l'élément.

Un autre élément d'information essentiel qui aidera le Product Owner est l'estimation des éléments réalisée par les responsables de la mise en œuvre, qui font leur meilleure estimation du temps que l'élément est susceptible de prendre. Les équipes Agile utilisant 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 des 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 a une facilité d'allocation de ressources flexible et intégrée où les membres de l'équipe peuvent ajouter des estimations, du temps autorisé, des temps réels, des pourcentages d'achèvement et plus encore. Cela sera inestimable pour le Product Owner, qui pourrait avoir une idée générale du temps nécessaire pour terminer un article, mais qui s'appuierait fortement sur les détails fournis par l'équipe. L'estimation de temps peut être saisie dans le champ 'Temps prévu' de la fenêtre Allocation des ressources.

Exemple

Ce diagramme montre comment un backlog peut être défini dans un workflow en une étape, permettant aux éléments d'être glissés et déposés dans une seule colonne pour définir l'ordre des éléments dans le backlog.

Ordonner les Items dans un diagramme de Diagramme

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 à moyenne, élevée ou critique ou en utilisant des noms de voie définis par l'utilisateur ou une propriété liée.

Sécuriser un backlog

Le backlog est un outil de communication qui isole les exécutants de la nécessité de décider sur quoi ils doivent travailler. Il est détenu et géré par le Product Owner, 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 de mise en œuvre doit avoir accès au Backlog, mais dans le but d'extraire 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 limitée dans le 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 une valeur commerciale valeur . 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 attendus et encouragés à commenter les éléments du Backlog afin que le Product Owner puisse comprendre tout problème ou avoir accès à la formation à partir 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 gens d'apporter les contributions nécessaires d'estimations de temps et de commentaires sous forme de discussions.

Avec le système de sécurité activé et un groupe pour les Product Owners ou des utilisateurs individuels qui sont des Product Owners ajoutés, un diagramme de Backlog peut être verrouillé par l'utilisateur Product Owner individuel ou un membre du groupe Product Owner. Cet exemple montre que le Backlog est verrouillé par le groupe Product Owner, mais pour un référentiel auquel plusieurs Product Owners accèdent, il pourrait être plus opportun de verrouiller le diagramme à un individu.

Lorsque le diagramme Backlog a été verrouillé par le Product Owner, les autres membres de l'équipe pourront voir le diagramme mais un petit marqueur rouge à gauche du nom du 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 pour modifier le diagramme .

Sécuriser un diagramme de Diagramme

Sécurisez un diagramme Backlog, en vous rappelant 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 afin de verrouiller le diagramme Kanban du backlog
• Pour sécuriser un Backlog, un workflow en deux ou trois étapes est requis où le Backlog est un diagramme Kanban séparé