Comment gérer votre carnet de produit avec Quire –

Cet article a été créé en partenariat avec Quire . Merci de votre soutien aux partenaires qui rendent SitePoint possible.

Le backlog de produits est probablement l’un des artefacts les plus controversés et les moins bien compris d’une organisation agile. Tout le monde semble avoir une opinion sur ce qui devrait être abordé, comment il devrait être organisé et qui devrait le gérer. En conséquence, la création et la gestion des arriérés de produits sont devenues plus un art sombre qu'une science. Les outils optimisés pour gérer une équipe agile ne fonctionnent parfois pas bien pour un propriétaire de produit qui essaie de garder une trace des histoires sur lesquelles l’équipe n’a pas encore commencé à travailler.

Une des options que les propriétaires de produits pourraient envisager est Quire un outil logiciel de gestion de projet en ligne avec suivi des tâches et des sous-tâches ainsi que des fonctionnalités de tableau Kanban, pouvant suivre le rythme d’une équipe agile tout en restant indifférents. comment un propriétaire de produit conçoit les fonctionnalités à venir et les améliorations de produit. Les employés de Quire m'ont contacté pour examiner leur produit et ils ont peut-être trouvé une solution qui conviendrait aux propriétaires de produit pour créer et gérer un arriéré pour leurs équipes.

Qu'est-ce qu'un arriéré de produit, et Comment en gérer un?

Un backlog de produit est un ensemble d'histoires potentielles décrivant les fonctionnalités sur lesquelles une équipe peut éventuellement travailler, chacune apportant une valeur ajoutée au client. Dans scrum et Kanban, les histoires sont des morceaux distincts de fonctionnalités pour l'utilisateur final, tranchés verticalement, qui sont indépendants, négociables, précieux, estimables, petits et testables .

C’est très différent d’une organisation en cascade, où chaque morceau de travail peut être une tâche bien pensée dans un plan beaucoup plus vaste qui devrait à terme ajouter de la valeur pour un client. Les tâches relatives aux diagrammes de Gantt sont généralement présentées sous forme de blocs séquentiels et interdépendants à partir d'un document d'exigences de produit représenté par un diagramme de Gantt détaillé ou quelque chose de similaire.

Une équipe agile ne met pas en défaut les diagrammes de Gantt ou les plans de devant. Avant que l’équipe n’assiste au propriétaire du produit, une histoire agile est généralement beaucoup moins détaillée qu’une tâche typique du diagramme de Gantt, motivée par les objectifs du client qui ajoutent de la valeur et des critères d’acceptation écrits dans la syntaxe lisible de Gherkin . ] pour plus de clarté. Une histoire potentielle non soignée devrait créer une discussion d'opportunité avec le reste de l'équipe sur ce qui devrait être développé et comment.

En conséquence, les modifications apportées au carnet de produit peuvent ressembler à celles que le propriétaire du produit souhaite voir afin de stimuler la discussion. Il est donc difficile de trouver un moyen cohérent de gérer et de stocker les histoires non corrigées afin qu'elles puissent être suivies et organisées dans le contexte d'une équipe de développement active.

À quel endroit stocker le backlog de produits?

Contrairement à de nombreux artefacts agiles. , qui prospère à la lumière de la transparence, le carnet de commandes de produits bénéficie en réalité d’un peu de secret. C'est un endroit où le propriétaire du produit peut fantasmer sur ce que l'utilisateur peut vouloir, et suivre les exigences externes ainsi que les expériences en cours lors des tests d'expérience utilisateur. Une fois que les fonctionnalités ont été préparées et que l’équipe commence son développement, ces histoires potentielles doivent être converties en un format pouvant être partagé avec le reste de l’équipe.

C’est là le point le plus difficile. Souvent, un propriétaire de produit développe par défaut ses fonctionnalités à venir dans le même outil qui sera utilisé pour les partager et les suivre sous forme d'histoires, telles que JIRA Agile. La plupart de ces outils s’attendent à ce que leurs récits soient peuplés d’estimations, de récits épiques, de dépendances, de propriétaires, etc.

Les outils de suivi agiles complets doivent souvent être configurés par un Scrum Master ou un autre membre de l’organisation pour respecter les normes convenues qui limiter la façon dont les histoires peuvent être écrites et éditées. Ces paramètres peuvent ne pas donner à un propriétaire de produit la possibilité de garder les histoires potentielles privées avant d'être prêtes à être partagées avec l'équipe, à moins que les histoires ne soient écrites sur un tableau séparé, puis transférées plus tard au tableau d'équipe. C’est beaucoup plus complexe qu’un fabricant de produits auquel il faut penser au tout début de l’arriéré de produits.

Certains propriétaires de produits écrivent simplement leurs plans dans un traitement de texte en copiant-collant le texte dans l’outil approprié, le cas échéant. Bien que cela présente l’avantage d’être un environnement d’écriture familier et pratique, il est difficile de garder une trace de multiples fonctionnalités en développement avec différents niveaux de détail. Les traitements de texte ne fournissent pas non plus un moyen facile de garder trace des histoires sur lesquelles travaille actuellement l'équipe pendant que vous développez de nouvelles fonctionnalités.

Les tableurs facilitent le suivi des relations et des associations, mais ils inciter un propriétaire de produit à approfondir les conséquences d'un processus plus complexe en cascade, en considérant les récits comme des éléments séquentiels plutôt que comme des éléments individuels indépendants ayant leur propre valeur. De plus, les feuilles de calcul ne prennent pas en charge un environnement d'édition très pratique pour la rédaction et la manipulation d'histoires.

Un des meilleurs solutions pourrait donc être un système de suivi de projet léger et indépendant, comme Quire. En utilisant l'interface basée sur les tâches de Quire, il est possible de conserver un historique de toutes les histoires sur lesquelles travaille l'équipe et de développer simultanément de nouvelles idées pour réfléchir à la manière dont elles pourraient s'intégrer et être classées par ordre de priorité une fois qu'elles sont prêtes. équipe pour commencer à travailler sur eux.

Quelles informations doivent entrer dans un carnet de produit?

Dans une organisation agile, les récits représentent des pistes possibles pour amener le produit dans son ensemble à ajouter de la valeur pour le client, et non des exigences fixes avec des délais intermédiaires qui peuvent ou non être dictés par la valeur intrinsèque qu'ils livrent. Quire permet au propriétaire du produit de conserver une liste aussi complète que possible des modifications et fonctionnalités potentielles, dans différents états de préparation et avec ou sans documentation, en les réorganisant et en les brassant selon les besoins avant de les présenter à une équipe pour leur préparation et leur développement. Quire appelle ces tâches, ce qui est une convention de nommage utile car elles peuvent ou non devenir des histoires vraies jusqu'à ce qu'une équipe les prépare, les accepte et commence à travailler sur elles.

C’est au propriétaire du produit de déterminer le peu ou pas d’informations contenues dans l’arriéré des produits. Il est donc essentiel de disposer d’un outil flexible qui permette de faire le travail correctement. Chaque tâche dans Quire doit capturer juste assez d’informations pour transmettre la vision du propriétaire du produit et stimuler la créativité de l’équipe lorsqu’elle est présentée. Quire prend même en charge le balisage et le filtrage, de sorte que les tâches peuvent être étiquetées comme étant en cours, des corrections de bugs, ou tout ce qui a du sens pour une situation particulière.

Il peut y avoir des fonctionnalités entièrement étoffées…

… de minuscules corrections de bugs, y compris éventuellement des sous-tâches…

… ou bien elles peuvent être fantaisistes, inspirées par des sous-tâches et des sous-tâches secondaires, même pourrait ne pas être techniquement possible.

Parfois, les critères d'acceptation peuvent être très clairs, bien que ces critères d'acceptation doivent généralement être précisés lors d'une conversation avec l'équipe. Quire n'est pas avisé de l'endroit où vous les créez, mais l'emplacement logique est dans le champ de description de la tâche.

Les tâches de backlog de produits peuvent également être dictées par des exigences techniques très spécifiques, utilisateur Les tests d’expérience et la documentation qui doit y être associée sont donc pratiques si vous utilisez un outil tel que Quire, qui vous permet de joindre d’autres documents à une tâche donnée. Il intègre même Google Drive.

Qui a besoin de consulter le backlog de produit?

Les tâches de Quire peuvent être conservées dans le backlog de produit à toutes les étapes de la planification, mais au moment où elles ' re présentés à l’équipe, ils devraient être prêts pour une discussion complète. J'aime penser que le carnet de produit est un paquet magique de secrets qu'un propriétaire de produit contrôle. Au fil du temps et avec une fanfare appropriée, le responsable du produit peut révéler des plans à l'équipe et les engager avec la valeur que ces nouvelles fonctionnalités promettent à l'utilisateur final.

Ce qui ne veut pas dire que l'équipe doit rester dans le noir quant à la direction que prend le produit. La raison pour laquelle un propriétaire de produit s'assoit avec l'équipe de développement est pour qu'il puisse y avoir un dialogue constant au fur et à mesure du développement des fonctionnalités et de la création des plans pour les fonctionnalités futures. Mais l'un des avantages de travailler de manière agile est que l'équipe peut se concentrer de manière productive sur les histoires telles qu'elles sont définies et préparées sans craindre qu'elles ne soient interrompues par une dérive de la portée des exigences changeantes après le début du travail.

Les développeurs doivent être sollicités au besoin pour s’assurer qu’une fonctionnalité potentielle est possible, mais la discussion doit être gérée avec soin, afin que l’équipe n’interprète pas de manière erronée une nouvelle fonctionnalité ou amélioration potentielle comme un passage obligatoire au travail en cours.

Des outils tels que Quire, situés en dehors des outils traditionnels de scénarisation agile, sont très utiles pour préserver la confidentialité d'un arriéré de produits. Il n’est pas nécessaire de définir des autorisations spéciales pour les descriptions de fonctionnalités sur lesquelles on ne travaillera jamais, afin que l’équipe ne soit pas distraite. Cela permet au propriétaire d’un produit d’éviter de contaminer les travaux en cours et d’éventuels changements. Le backlog du produit étant géré avec un outil distinct, seul le propriétaire du produit doit avoir un accès direct.

Comment maintenir le backlog de produit synchronisé avec l'équipe?

Le dernier défi pour une solution de backlog de produit est à quel point il peut rester en phase avec le travail de l'équipe. L'un des principaux avantages de l'utilisation d'un outil partagé visible par tous les membres de l'équipe est que tous les changements sont immédiatement répercutés sur tous ceux qui utilisent le même tableau. Mais cela revient généralement au prix de pouvoir garder les futures fonctionnalités potentielles privées jusqu'au moment où l'équipe commence à préparer de vraies histoires.

Si le propriétaire du produit essaie de conserver l'arriéré à l'aide d'un outil non agile, tel qu'un tableur ou un traitement de texte, la difficulté est doublée. Cela nécessite non seulement de synchroniser manuellement l'arriéré avec le travail effectué par l'équipe, mais également de développer un système de codage des idées de manière à ce qu'il soit clair dans quel état elles se trouvent. Par exemple, comment un propriétaire de produit distinguerait-il dans un traitement de texte arriéré parmi les fonctionnalités en cours, qui pourraient ne jamais se produire ou qui sont pleinement développées et déployées?

Il nous faut un carnet de notes agile-friendly, et Quire répond parfaitement à cet objectif. L'interface par défaut de Quire inclut juste assez de détails pour créer et suivre l'avancement des tâches à mesure qu'elles se développent sans entraver le processus de création pour le propriétaire du produit. Mais Quire fournit également une vue de tableau Kanban personnalisable que le propriétaire de produit peut utiliser pour suivre le statut des tâches après qu'elles ont été préparées et transférées vers d'autres systèmes sous forme d'histoires estimées intégralement, sans interférer avec le reste de l'équipe.

En configurant la vue de tableau Kanban pour correspondre aux états utilisés par l'équipe, un propriétaire de produit a la possibilité d'ajouter des tâches Quire au tableau et de suivre leurs progrès tout au long du développement et du déploiement à mesure que l'équipe avance. C'est aussi simple que de cliquer sur l'icône du tableau dans la vue détaillée de la tâche…

… et en sélectionnant le tableau Kanban configuré, puis en basculant vers la vue Kanban pour déplacer des tâches.

S'il est utilisé de cette manière, Quire peut également générer des rapports sur l'état d'avancement des articles en développement à l'aide d'outils intégrés, à l'aide de tableaux et de graphiques attrayants et conviviaux. Celles-ci peuvent être référencées lors de discussions avec les dirigeants et les parties prenantes ou partagées avec l'équipe à la demande du responsable du produit.

Si l'équipe le trouve utile, il est disponible, mais le propriétaire du produit peut décider que certaines diagrammes, telles que la vue Diagramme de Gantt de Quire sur le travail planifié potentiel, ne le font pas. ajoute de la valeur ou peut en réalité être une source de distraction pour une équipe agile.

La création et la maintenance d'un carnet de produit sont un élément essentiel du rôle du propriétaire du produit. Le propriétaire du produit doit conserver un arriéré afin de faciliter la création et le suivi de la priorité des histoires potentielles sur lesquelles l'équipe doit travailler. En raison de son intégration native des fonctionnalités Kanban dans une interface orientée tâche et de son interface de sous-tâche imbriquée, Quire peut être une meilleure solution que d'essayer d'utiliser le même tableau que celui utilisé par l'équipe pour les histoires actives ou le pavage. ensemble une solution personnalisée avec des feuilles de calcul et des traitements de texte.

J'ai travaillé en tant qu'ingénieur Web, rédacteur, responsable des communications et directeur du marketing dans des sociétés telles qu'Apple, Salon.com, StumbleUpon et Moovweb. Mes recherches sur les sciences sociales des télécommunications à l'Université de Berkeley, et tout en obtenant un MBA en comportement organisationnel, m'ont montré que l'instinct humain de réseauter est suffisamment vital pour prospérer sur tout support permettant à une personne de se connecter à un autre.