Qu'est-ce qu'un backlog et comment est-il utilisé dans les projets et le développement de produits ?

Partager!

Commençons sans détour, qu'est-ce que le arriéré de travail? Il s'agit d'un outil de gestion des exigences / besoins sur un produit, un service ou un projet. Pour paraphraser le Guide Scrumqui, soit dit en passant, a été mis à jour en novembre 2020, est une liste ouverte et ordonnée de demandes visant à améliorer ou à compléter la valeur de quelque chose - qu'il s'agisse de produits, de services ou de projets.

Le backlog, une liste hiérarchisée d'exigences pour un produit ou un service, est un mécanisme de ventilation idéal pour gérer les exigences lorsqu'elles sont variables et hautement dynamiques. Contrairement à d'autres mécanismes de découpage, comme le WBS (Work Breakdown Structure), le backlog présente plusieurs particularités que nous allons aborder ci-dessous et qui sont la clé de son succès dans la gestion de projets adaptatifs et le développement de produits et services.

Quels éléments entrent dans le Backlog ?

Le backlog est une liste ouverte d'éléments. Il peut contenir des exigences spécifiques pour un projet ou un produit, il peut inclure des tâches, il peut inclure des cas d'utilisation ou des histoires d'utilisateur, et surtout, il peut contenir une combinaison de tous ces éléments.

Le backlog ne peut contenir que des user stories

FAUX, FAUX, ABSOLUMENT FAUX !

En tant que consultant et agent de changement, je vois cela tout le temps. Des équipes qui souffrent, en essayant de documenter chacune de leurs exigences et des éléments du backlog en tant que user stories - c'est tout simplement stupide !

Chaque comment rédiger une injonction est particulière à la nature du produit ou du service en cours de développement. Certains "types" d'exigences favorisent le développement autonome, tandis que d'autres sont plus détaillés et orientés vers le respect strict de certaines conditions.

La maturité de l'équipe est également un facteur important pour déterminer dans quelle mesure les informations accompagnant les éléments de cette liste de priorités sont détaillées et approfondies.

Pourquoi Backlog en anglais et ne pas utiliser les traductions ?

Personnellement, je n'aime pas traduire le mot backlog, car en espagnol nous n'avons pas un seul mot qui représente la même chose. Il y a quelques années, lorsque j'étais bénévole dans le groupe de traduction de la Guide des pratiques agiles du PMIa été l'une des discussions les plus difficiles, voici donc quelques-unes des traductions les plus populaires dans le contexte des projets et de l'agilité :

  1. Pile
  2. Liste de priorités
  3. Pop-up et liste triée
  4. Liste des travaux en cours

Comme vous pouvez le constater, il s'agit de termes généraux qui, en espagnol, sont difficiles à ajuster, et pour terminer, je vous laisse avec un exemple de la raison pour laquelle il est si complexe de traduire le mot.

Le tableau d'épuisement du sprint est une représentation visuelle du travail restant à effectuer au fil des jours dans le backlog du sprint.

Ce serait quelque chose comme :

Le diagramme d'épuisement de l'itération est une représentation visuelle du travail en attente à partir de la liste des priorités du travail en attente de la même itération au fil des jours.

Product Stack - pourquoi traduit-on backlog par stack ?
Pile de produits ?

Pour éviter ce genre de choses, nous devrions appeler l'arriéré de différentes manières dans chaque situation. Liste, liste hiérarchisée, pile, et il n'y aurait aucun moyen, pour quelqu'un qui apprend, de comprendre que parfois la liste, la liste hiérarchisée et la liste des exigences - ou quelle que soit la traduction dans le contexte - sont le même instrument.

Comme vous pouvez le voir, ce n'est pas un terme simple à traduire, et encore moins s'ils utilisent des mots aussi hors contexte que batterie pile [1] J'admets que certaines traductions dans le cadre du management et de l'agilité arriéré de travail a batterie, Programmation a programmation, feedback comme feedback, graphique d'épuisement a diagramme de combustion, y graphique de combustion comme schéma de combustionJe suis profondément piqué par eux. .

Quels types de listes de priorités existent ?

Avant de commencer, je tiens à préciser que, bien que Scrum est à la mode De nos jours, le backlog n'est pas un outil exclusif de Scrum. Par exemple, XP très bien défini en retard il y a quelques décennies. Alors, commençons :

1. Backlog de produit ou de service - Backlog de produit

Lorsque nous parlons de Backlog de produit ou de service, nous faisons référence à toutes les demandes associées au développement, à la maintenance ou au fonctionnement d'un produit ou d'un service. Le carnet de commandes comprend, entre autres, les tâches, les exigences associées aux produits livrables, les améliorations, les demandes de changement, la maintenance et tout ce qui mérite d'être gardé "sur le radar" pour un produit ou un service donné.

2. Carnet de projet

Un backlog de projet est utile dans certains contextes spécifiques et ne remplace pas de manière absolue d'autres outils de ventilation tels que la structure de répartition du travail (WBS). Dans un gamme variableL'utilisation de l'arriéré est plus efficace et plus pratique que l'utilisation de l'OTP.

DTD/WBS ou Backlog pour gérer la ventilation ?

Cette discussion pourrait être longue et approfondie, mais voici une liste de 3 différences essentielles dans le choix entre un WBS ou un backlog comme outil d'analyse.

  1. Nature de la portée du projet. Si le projet est de portée limitée et que la direction a pour mission de contrôler les demandes supplémentaires, la structure de répartition du travail est la bonne. Si, en revanche, une partie du projet consiste à découvrir, à mûrir ou à affiner la portée du produit ou du service en cours de développement, alors le backlog est imbattable.
  2. Tout n'est pas inclus. L'une des choses les plus difficiles à comprendre pour un chef de projet est le fait que les éléments du backlog ne sont pas nécessairement engagés pour la livraison. C'est le contraire de l'OTP. Tout ce qui se trouve dans le WBS, et seulement cela, fait partie de la portée. Dans un WBS, le supplémentaire est considéré Placage d'or. Le backlog est un instrument de hiérarchisation ou d'ordonnancement et, par conséquent, les changements ou les découvertes naturelles du processus de développement du produit ou du service peuvent déplacer d'autres caractéristiques ou demandes qui, à la lumière de nouvelles découvertes, n'ont pas la même priorité.
  3. Au-delà du projet, l'opération. L'OTP est un instrument fermé qui tente de contenir l'ensemble du champ d'application, et n'est donc pas utile dans les environnements où il n'y a pas de champ d'application défini. Comment gérer un ensemble de demandes inattendues ou imprévues pour une équipe ? L'OTP n'est pas conçu comme un instrument dynamique et flexible, et bien qu'il puisse recevoir des modifications et des mises à jour tout au long d'un projet, il n'est pas un "élément dynamique", comme l'est un backlog.

3. Iteration Backlog - Backlog d'itération ó Backlog du sprint dans Scrum

Le backlog d'itération fait référence à un ensemble de choses à faire ou à terminer au cours d'une période donnée. Si nous parlons de ScrumSi l'on parle de Scrum, version 2020, le Sprint dure entre une semaine et un mois. Si nous parlons de Scrum, des versions précédentes ou d'autres auteurs, entre deux et huit semaines. Mais en général, le backlog d'itération est la liste hiérarchisée des "choses à faire" pendant une période de temps déterminée.

Le carnet d'itérations n'est pas nécessairement un sous-ensemble du carnet de produits ou du carnet de projets. Bien sûr, il doit y avoir une relation entre les deux, lorsqu'ils sont utilisés, mais une partie du processus de planification des itérations consiste à détailler, décomposer et compléter le backlog du produit/projet pour l'itération qui commence. Et, en ce sens, il est possible que le Backlog d'itération contienne des éléments qui n'ont pas été inclus dans le Backlog de produit ou de projet.

4. Backlog du portefeuille

Considérez un instant que votre portefeuille stratégique - qui comprend plusieurs projets et autres composants - est une liste de priorités. Pourquoi ne pas utiliser le backlog au niveau du portefeuille ? L'établissement de priorités est une excellente idée pour éviter ce que j'ai défini comme la le syndrome du glouton - o considérer que l'argent est le seul facteur à prendre en compte pour inclure ou retirer une initiative du portefeuille.

En gestion Portefeuille LeanLe Portfolio Backlog est un instrument fondamental. Il apparaît également dans le Scaled Agile Framework.

5. Carnet de programmes

Lors de la gestion de produits ou de projets complexes, il est possible d'avoir une catégorisation du backlog. À l'instar de ce qui se passe avec un programme et un projet, le carnet de commandes peut être un outil précieux pour gérer le carnet de commandes et les priorités à grande échelle, au sein de plusieurs équipes - bien sûr, lorsque l'échelle le justifie, c'est-à-dire lorsqu'il y a tellement de personnes qui interagissent que le fait de garder tout centralisé aide et entrave en même temps.

6. Arriéré d'équipement

S'il y a un backlog de programme, il doit y avoir un backlog d'équipe. Si, pour les besoins de la vue d'ensemble, nous unifions notre "pile", pour les besoins de la gestion d'une équipe - presque toujours agile - nous avons besoin d'une version réduite et ciblée à gérer. C'est ce que l'on appelle le retard en matière d'équipement.

Comment gérer correctement une liste de priorités ?

Le backlog, comme nous l'avons déjà vu, est un instrument lié au travail à effectuer, qu'il soit associé à la portée du produit ou du service, ou aux tâches associées à son développement, sa maintenance et son exploitation. Par conséquent, l'arriéré exige beaucoup de travail et d'efforts pour le maintenir à jour et ne pas perdre de valeur.

Dans certains modèles de gestion, une personne est désignée comme le "gardien" du backlog. Dans Scrum, ce rôle est connu sous le nom de Product Owner, ou Propriétaire de produit. Cependant, puisque le backlog en tant qu'artefact n'est pas unique à Scrum, il y a des rôles associés au soin et à la maintenance du backlog.

Rôles en charge de la création et de la gestion des éléments de la liste prioritaire

Bien que cette liste ne soit pas exhaustive, il s'agit des rôles les plus populaires ou les plus courants.

  • Gestionnaire de produits/ Chef de produit
  • Propriétaire de produit / Propriétaire de produit
  • Clientèle / Client
  • Représentant des clients ou des consommateurs / Proxy client
  • Analyste des exigences/ Analyste commercial
  • Documenter
  • Chef de projet* / Chef de projet

Le chef de projet est-il en charge du backlog ?

Cela dépend. Le directeur ou gestionnaire de projet est chargé de gérer la portée du projet et, par conséquent, s'il est chargé de gérer, dans les projets prédictifs, la structure de répartition de la portée, pourquoi ne serait-il pas chargé du backlog ?

Cependant, dans les projets agiles, où le backlog est utilisé comme un outil de gestion de la portée, le chef de projet n'apparaît pas comme un rôle prédominant. Par exemple, dans le Équipes Scrum Il s'agit d'une séparation claire entre la gestion du champ d'application, c'est-à-dire la concentration sur la création de valeur commerciale, et la gestion de l'équipe. De cette façon, un équilibre est assuré entre l'envie de faire et la capacité de faire. De plus, cette séparation des responsabilités permet d'éviter d'ignorer les besoins de l'équipe et ses performances afin de rechercher et de fournir une valeur commerciale.

Bien que ce rôle ne soit pas explicitement attribué, il est courant de trouver des chefs de projet chargés de gérer le champ d'application - en tant que Product Owners - et qui gèrent ou dirigent l'équipe - de manière similaire à ce qui pourrait être compris comme le rôle du Scrum Master. [2]On discute toujours longuement de la question de savoir si un gestionnaire de projet peut exercer le rôle de Scrum Master. Personnellement, je pense qu'il s'agit de rôles complémentaires et que, avec les bonnes compétences, ils peuvent être assumés par la même personne.

Conseils aux chefs de projet.

Le backlog est un outil dynamique qui, contrairement à la SRT, exige beaucoup plus d'engagement et de dévouement. Si vous aimez, en tant que chef de projet, être en charge de la portée, n'hésitez pas à ajouter un Scrum Master à l'équipe pour faciliter et médiatiser la relation que vous avez avec l'équipe. Évitez d'être juge et partie.

Pourquoi les exigences changent-elles ?

L'arriéré est un instrument dynamique et ouvert. Cela signifie que les éléments du backlog sont régulièrement déplacés vers l'intérieur, l'extérieur et la priorité. Bien sûr, avec certains critères et une certaine structure - qui dépendent du modèle de gestion ou de l'organisation de l'entreprise. paradigme que vous utilisez dans votre projet ou avec votre équipe.

Par conséquent, le backlog est idéal dans les environnements où, par exemple, le retour d'information est essentiel pour définir l'avenir du projet (ou du produit). L'esprit d'entreprise est un exemple de ce contexte. Les entrepreneurs ont besoin de nouveaux clients et, pour les satisfaire, ils présentent rapidement et fréquemment leurs idées de nouveaux produits, services et campagnes publicitaires. Si la réponse est positive, ils poursuivent l'idée ; si la réponse est négative, ils "pivotent" et passent à autre chose.

Le backlog accepte et exploite le retour d'information. Une bonne équipe profite du retour d'information pour améliorer les capacités d'un produit ou d'un service en cours de développement.

Raffinement et mise à jour du backlog

Rappelons que le backlog est un outil précieux dans les contextes où la portée du produit, du service ou du projet exige un certain dynamisme. La gestion du backlog est une tâche exigeante et très nécessaire pour la réussite du projet. Il ne s'agit pas seulement d'identifier ce qui doit être fait, mais aussi de structurer, de hiérarchiser et d'ordonner le travail pour obtenir le plus grand impact.

L'une des activités qui a pris de l'importance ces dernières années est ce que l'on appelait autrefois le Backlog Grooming et qui, pour des raisons évidentes, est maintenant connu sous le nom de Backlog Refinement.[3]Le site Dictionnaire de Cambridge présente parmi ses définitions du mot toilettageLe terme "activité criminelle", qui a gagné en popularité au fil des ans, a été associé à l'activité criminelle. Cela a conduit à une modification du terme dans le Guide Scrum de toilettage a raffinement. .

Dans le cadre de SAFe Agile at Scale, le raffinement du backlog est défini plus ou moins comme suit : [4]La traduction de backlog refinement n'est pas littérale et s'inscrit un peu dans le contexte de cet article - sans en changer l'essence. Pour voir le texte original, je vous invite à parcourir la page du Scaled Agile Framework.

Le backlog doit toujours contenir quelques histoires prêtes à être mises en œuvre. C'est-à-dire sans risques majeurs, sans incertitudes profondes ni surprises majeures. Les équipes agiles, en adoptant une approche basée sur le flux, visent à maintenir un certain niveau de "préparation" dans leur backlog. Pour ce faire, ils organisent au moins une session d'affinage du backlog par itération, voire par semaine. Au cours de cette session de raffinement, les histoires plus prioritaires sont analysées et une compréhension initiale des critères d'acceptation est discutée, estimée et établie.

Agile à l'échelle

Conseils pour maintenir un bon arriéré

J'aimerais avoir une formule magique à partager sur la façon de gérer et de maintenir un bon backlog. Je serais probablement millionnaire, mais cela ne veut pas dire que nous ne pouvons pas laisser de côté quelques bons conseils pour améliorer les chances d'avoir un bon backlog dans nos projets ou avec nos équipes.

1. dévouement et engagement

L'arriéré exige du temps et du dévouement.

Contrairement aux projets prédictifs, la nature variable et dynamique du champ d'application exige un dévouement et un engagement envers le carnet de commandes. Dans Scrum, par exemple, le rôle du Product Owner est à temps plein. La gestion du backlog prend du temps. Oubliez l'idée de revoir le backlog de temps en temps.

Donnez la priorité et le pouvoir à la personne qui est la gardienne de l'arriéré. Tous les membres de l'équipe, et même les parties prenantes, sont invités à proposer de nouveaux éléments, des modifications et de nouvelles priorités pour le backlog, mais une seule personne doit être celle qui, en fin de compte, accepte, approfondit et hiérarchise le backlog - c'est pourquoi j'aime le mot "gatekeeper". Si vous pratiquez Scrum, n'hésitez pas à affecter votre meilleur Product Owner disponible à plein temps.

2. La pensée incrémentielle pour les éléments

La pensée incrémentale pour le développement de produits ressemble à une échelle.

Le backlog n'est pas seulement une liste de priorités - quel est l'intérêt d'établir des priorités si pour achever les éléments de première priorité, je dois achever les éléments de moindre priorité ? Cette erreur ou anti-modèle agile est commune à de nombreux projets qui ne s'intéressent qu'à la fragmentation du plan en itérations, mais n'approfondissent pas suffisamment la manière de structurer les livrables et les composants pour permettre la livraison des avantages de manière continue. Pour éviter cela, le critère INVEST a été défini pour les éléments du backlog.

Critère d'investissement

Le backlog nécessite des éléments qui répondent au critère INVEST :

  • Indépendant (I) - éléments qui sont pour la plupart "autonomes" et ne nécessitent pas d'autres éléments pour démontrer leur valeur.
  • Négociable (N) - le backlog n'est pas un élément fermé et donc certains éléments du backlog doivent être complétés et d'autres non. Cela signifie que, à tout moment, nous devons être en mesure de négocier les priorités et d'inclure ou non un élément à un moment donné du produit.
  • Précieux (V) - si le backlog est une liste d'éléments classés par ordre de priorité, la valeur est ce qui nous permet de les classer par ordre de priorité. Bien qu'il puisse y avoir des éléments de faible valeur dans le carnet de commandes, les y maintenir alors que nous avons identifié qu'ils sont de faible valeur n'a pas beaucoup de sens.
  • Cher (E) - lorsqu'un élément du backlog s'approche du sommet de la liste des priorités - c'est-à-dire qu'il est sur le point d'être considéré comme devant être inclus dans le processus de développement ou de production - il doit pouvoir être estimé. En d'autres termes, l'équipe chargée du projet ou du produit doit être en mesure de discuter de l'ampleur de l'effort, de la complexité et du risque. Pour y parvenir, l'élément peut être détaillé - lors de séances de perfectionnement - ou fragmenté - en composantes plus petites qui permettent à l'équipe d'aller de l'avant.
  • Petit (Petit) - ce critère s'applique principalement aux backlogs d'équipe et d'itération. Les articles circulent mieux dans le système lorsqu'ils sont petits - un principe LEAN de base. Toutefois, un carnet de commandes de portefeuille ne comporte pas nécessairement de petits éléments.
  • Vérifiable (Testable) - en principe, chaque élément d'un backlog, comme les éléments d'un WBS, doit avoir certains critères d'acceptation et/ou de validation. Sinon, comment pouvons-nous savoir que quelque chose a été fait et que cela répond aux objectifs fixés.

3. Équilibre entre anticipation et adaptation

Comme le yin et le yang, le backlog nécessite un équilibre entre anticipation et adaptation.

Le backlog est classé par ordre de priorité. Il y a une raison à cela. Concentrez-vous sur ce qui est le plus important et le plus précieux pour le produit, le service ou le projet. S'il n'y a pas d'objectif, il est inutile de fixer des priorités. Il faut donc éviter à tout prix d'essayer de trop anticiper au début du projet, ou lorsque l'équipe est en train de se former. Trouver l'équilibre entre l'anticipation avec la pré-conception et l'adaptation est fondamental pour faire un usage judicieux du temps des experts métier et du gardien du backlog - c'est-à-dire du temps du Product Owner.

4. Critères préliminaires de priorisation

Algorithme de hiérarchisation des exigences

Une grande partie du problème de la hiérarchisation de l'arriéré réside dans la subjectivité du gardien, ou dans les divers intérêts de toutes les parties prenantes - également connu en anglais sous le nom de "gatekeeper". parties prenantes. Une excellente technique peut consister à établir un algorithme, un processus ou un mécanisme de hiérarchisation pondéré qui permet de prendre en compte plusieurs dimensions lors de la hiérarchisation. Scaled Agile Framework, par exemple, présente le WSJF comme un exercice de priorisation pour le backlog du portefeuille.

Je tiens à préciser que l'établissement de critères de hiérarchisation ne vise pas à éliminer le facteur humain de la hiérarchisation ; au contraire, il s'agit d'un outil auxiliaire qui vise à renforcer la discussion et le débat autour des priorités. Nous ne pouvons pas toujours choisir les éléments de l'arriéré simplement parce que la personne qui le demande a un bureau plus grand que le nôtre. En anglais, on utilise le terme HIPPO ou la personne la mieux payée du bureau pour souligner le fait que, parfois, il n'y a aucun critère et que c'est juste un caprice de quelqu'un qui a un meilleur salaire au sein de l'entreprise.

5. Limites et entonnoirs de pourcentages

Filtrer les éléments du backlog

Eh bien, si le backlog est un élément dynamique, et que les sessions d'affinage se produisent avec une certaine fréquence, il peut être judicieux de fixer des limites quant à la quantité de nouveaux éléments à discuter, ou d'améliorations et d'améliorations. refactors que nous itérons ou considérons pendant nos sessions.

Cela peut parfois aider à rester concentré et à éviter un excès d'expérimentation qui, au final, nous laisse avec trop d'essais et pas assez de valeur ajoutée.

De même, il est possible d'établir des règles de sortie ou de "mort" au sein du backlog. Par exemple, les éléments qui ne remontent jamais et qui sont toujours remplacés par d'autres éléments "plus importants".

6. Outil de gestion

Les outils de gestion sont utiles et établissent une structure pour inclure, gérer, mettre à jour et planifier les éléments. Des post-its et des tableaux acryliques aux outils de gestion avancés dans le cadre de l'initiative Systèmes informatiques.

Loin de remplir un outil avec une grande quantité d'informations, je recommande la constance dans sa mise à jour, l'ajustement des priorités, la saisie de nouveaux éléments et l'élimination de ceux qui ont été achevés ou qui ne sont plus considérés dans le plan - la plupart des outils font une grande partie de cela automatiquement.

Les choses à éviter

Comme tout autre outil, le backlog doit faire l'objet de plusieurs considérations afin d'éviter toute utilisation abusive ou inefficace dans le cadre d'un projet ou d'une équipe. Ces questions sont :

  1. Accumulation excessive. Évitez de tout inclure dans le carnet de commandes. Bien qu'il s'agisse d'un instrument flexible, il ne doit pas devenir un coffre à souvenirs ou un arriéré. St. SALLE D'ALLEJO. Il est fréquent que l'arriéré devienne une liste de souhaits sans fin.
  2. Besoin d'informations détaillées. Comme je l'ai déjà mentionné, il faut éviter de perdre l'équilibre entre anticipation et adaptation. Vous avez besoin d'une liste initiale de priorités à partir de laquelle travailler, mais ce sont les priorités qui déterminent ce sur quoi le contrôleur doit se concentrer. Évitant de tout prévoir, le backlog est conçu pour des contextes "adaptatifs complexes" où une partie du travail implique l'expérimentation et le retour d'information.
  3. Structure monolithique. Il empêche les éléments du backlog de dépendre les uns des autres. Ce n'est pas une tâche simple. Pour éviter cela, il est bon de développer une pensée entrepreneuriale, où les grandes réalisations sont la somme de chacune des petites réalisations.

Modèles pour la gestion du backlog

Existe-t-il un modèle définitif pour la gestion du backlog ? Bien sûr qu'il n'y en a pas. Mais ça ne veut pas dire que je ne peux pas en partager certaines très intéressantes. Mais ça ne veut pas dire que je ne peux pas en partager certaines très intéressantes. Voici une liste de modèles :

  • Outil de gestion du carnet de commandes
    Développé par Sperta Consulting. [5]Sperta Consulting est la société dont je suis l'associé. Elle est spécialisée dans le conseil, le coaching et la formation en matière de gestion d'équipe et de projet et de structure organisationnelle.. Il s'agit d'un outil que nous utilisons à des fins académiques pour discuter, avant tout, de l'impact des itérations sur l'avancement d'un projet. Loin d'être parfait, il aide à établir des discussions profondes avec les exercices que nous faisons dans nos cours.

Personnellement, je n'utilise pas de modèles dans mon travail quotidien - ou alors c'est très très rare, mais ils sont très utiles pour les processus académiques. Ils sont facilement manipulables et personnalisables pour faire valoir un point, un concept ou des avantages et inconvénients.

À notre époque, il est plus courant d'utiliser un outil de gestion d'équipe agile basé sur le cloud plutôt qu'un fichier de tableur partagé.

Considérations finales

L'arriéré est un instrument vraiment puissant. Un bon backlog est la clé de l'agilité de l'équipe et du développement incrémental de produits et de services. C'est un grand allié des projets agiles et un élément essentiel de la gestion allégée du portefeuille.

Toutefois, elle ne doit pas être considérée comme une simple liste de tâches à accomplir.

Partager!

Commentaires et notes de l'auteur[+]

Image par défaut
Alberto Dominguez
Diriger des équipes de la théorie à la réalisation réelle et durable de produits et services informatiques innovants.
Publications: 33

4 commentaires

  1. Bonjour Alberto, très bon article, il relate les principaux concepts du backlog et l'étend au niveau du portefeuille, ce qui m'invite à approfondir le sujet. J'ai un doute et c'est le concept de libération, est-il traité de la même manière pour tous les types d'arriérés ?

    • César, je suis heureux que l'article vous ait plu. Sur votre question, une petite réflexion. Si l'objectif de la hiérarchisation des priorités est de fournir une valeur commerciale de manière précoce et échelonnée, il est idéal d'utiliser le backlog conjointement avec un plan de publication. Mais cela ne signifie pas qu'il doit toujours y avoir un plan de libération. Ma recommandation est de toujours avoir des jalons liés à des dates et d'avoir ainsi un moyen de valider les progrès. En l'absence de jalons, il est impossible de mesurer les progrès accomplis à l'aide d'un outil tel que le backlog. Je suis sur le point de publier un autre article sur les métriques qui va dans ce sens. S'il n'y a pas de version, par rapport à quoi mesurez-vous vos progrès (surtout dans les projets) ?

  2. Bonjour Alberto,
    Excellent article, j'ai appris beaucoup de choses intéressantes en le lisant ! J'ai une question, à laquelle l'article répond partiellement, mais il serait intéressant d'avoir un point de vue très précis : dans les projets "open source", on trouve souvent des arriérés interminables, qui deviennent incontrôlables. Bien que cela soit cohérent avec un projet de portée variable (comme c'est souvent le cas avec ce type de projet), quelles stratégies les administrateurs/gestionnaires de projet peuvent-ils mettre en place pour éviter un arriéré incontrôlable et en même temps éviter la frustration des collaborateurs ?

    • Mauricio, excellente question ! En effet, de nombreux projets et produits souffrent d'un retard qui ressemble à une liste de souhaits. En particulier, l'arriéré des logiciels libres et open source semble être une liste sans fin, et c'est en partie l'idée. L'open source, c'est la décentralisation du code, et cela signifie souvent la décentralisation des priorités. Pour rester concentré - ce qui, je pense, est ce qui génère le plus de frustration, je recommande :

      • Définir la gouvernance sur le backlog. Voici quelques exemples de gouvernance :
            Effectuer régulièrement feuille de route. Ils peuvent être trimestriels, semestriels ou annuels - tout dépend du degré d'implication de la communauté des développeurs.
            Attribuer un point central de priorisation - similaire à ce qui se passe avec le noyau Linux et le rôle du Linus Tolvards.
            Établir des mécanismes de vote pour le grand public afin d'aider à prioriser les nouvelles fonctionnalités.
      • Utilisez différents niveaux de backlog. Bien que nous ayons l'habitude de parler du "backlog de produit" comme s'il s'agissait d'un seul et même document, la vérité est que vous pouvez avoir différents niveaux, et que ces niveaux vous aident à établir des priorités et à cibler les discussions de gouvernance. Nous ne voulons pas voter sur des millions de fonctionnalités chaque jour. Vous pouvez définir un Backlog de produit à un niveau élevé, et un Backlog de version qui est le résultat d'une session de roadmapping. Ce backlog de version peut être un sous-ensemble qui donne une orientation au groupe.

      J'espère que ma réponse vous aidera.

Laisser un commentaire

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

fr_FR