En plus de faciliter la planification des versions et des it\u00e9rations, un backlog agile bien hi\u00e9rarchis\u00e9 communique tout ce \u00e0 quoi votre \u00e9quipe a l'intention de consacrer du temps, m\u00eame si le client ne le verra pas. Les ing\u00e9nieurs peuvent s'en servir pour d\u00e9finir les attentes des parties prenantes et des autres \u00e9quipes, en particulier lorsqu'ils vous apportent de nouveaux travaux.<\/p>\n
Dans Scrum, la m\u00e9thode agile carnet de commandes du produit <\/strong>est une liste de toutes les caract\u00e9ristiques qui doivent \u00eatre incluses dans le produit, avec une br\u00e8ve description de chacune.<\/p>\n Scrum \u00e9limine la n\u00e9cessit\u00e9 de passer beaucoup de temps au d\u00e9but d'un projet \u00e0 documenter toutes les exigences. Typiquement, une \u00e9quipe Scrum et son propri\u00e9taire de produit commencent le processus de priorisation du backlog agile en d\u00e9taillant tout ce qui leur vient \u00e0 l'esprit. Typiquement, ce backlog de produit agile est suffisant pour le sprint initial. Ensuite, lorsque de nouvelles informations sont d\u00e9couvertes sur les produits et leurs utilisateurs, le backlog de produit Scrum est encourag\u00e9 \u00e0 s'adapter.<\/p>\n Comme mentionn\u00e9 ci-dessus, le backlog de produit est la liste de toutes les t\u00e2ches ainsi que des user stories qui doivent \u00eatre r\u00e9alis\u00e9es pour que le projet dans son ensemble soit termin\u00e9. Chaque \u00e9l\u00e9ment d'un bon backlog de produit est d\u00e9compos\u00e9 en une s\u00e9rie d'\u00e9tapes qui facilitent le processus de d\u00e9veloppement.<\/p>\n Alors que d'autre part, le backlog de sprint est une partie du backlog de produit. Le backlog de sprint est compos\u00e9 uniquement des \u00e9l\u00e9ments du backlog de produit qui peuvent \u00eatre termin\u00e9s au cours de chaque sprint agile. Consid\u00e9rez-le comme les instructions de l'\u00e9quipe avant qu'elle n'ex\u00e9cute son court sprint.<\/p>\n Le backlog de sprint sera bas\u00e9 sur le degr\u00e9 de difficult\u00e9 du projet, mais l'id\u00e9e principale est que l'\u00e9quipe ne doit travailler que sur des t\u00e2ches qui peuvent \u00eatre termin\u00e9es pendant le sprint. \u00c9videmment, si le projet est compliqu\u00e9, le backlog du sprint peut aussi devenir plus compliqu\u00e9 et plus long.<\/p>\n Alors que le backlog de produit change au fil du temps, le backlog d'un sprint ne change pas. Il est possible de faire des ajustements, mais vous devez le faire pendant la r\u00e9union de planification du sprint. Une fois que tout le monde est d'accord, les \u00e9l\u00e9ments et les \u00e9tapes n\u00e9cessaires pour les terminer sont fix\u00e9s pour l'ensemble du sprint.<\/p>\n Les cat\u00e9gories de choses suivantes sont g\u00e9n\u00e9ralement incluses dans un backlog Scrum standard :<\/p>\n Les \u00e9l\u00e9ments de votre backlog de produit servent de r\u00e9servoirs pour de futures discussions sur les diff\u00e9rentes mani\u00e8res d'atteindre votre objectif. Il n'est pas n\u00e9cessaire qu'une \u00e9quipe soit enti\u00e8rement pr\u00e9par\u00e9e avant d'ajouter un concept au backlog. Lorsqu'un \u00e9l\u00e9ment du backlog de produit est ajout\u00e9 pour la premi\u00e8re fois \u00e0 un backlog de produit, il doit juste inclure suffisamment d'informations pour rappeler \u00e0 l'\u00e9quipe l'alternative qu'elle a pr\u00e9c\u00e9demment envisag\u00e9e. Lorsqu'une \u00e9quipe est sur le point de commencer \u00e0 travailler sur un \u00e9l\u00e9ment du backlog de produit, il suffit de fournir une description d\u00e9taill\u00e9e de cet \u00e9l\u00e9ment.<\/p>\n La structure dynamique d'un backlog de produit permet au personnel de collaborer ses connaissances sur le r\u00e9sultat souhait\u00e9 et les diff\u00e9rentes fa\u00e7ons de l'atteindre. Les \u00e9l\u00e9ments du backlog de produit n'ont pas besoin d'\u00eatre compl\u00e9t\u00e9s lorsqu'une \u00e9quipe commence \u00e0 travailler, de sorte que l'\u00e9quipe peut commencer avec une id\u00e9e de base et ajouter d'autres \u00e9l\u00e9ments au fur et \u00e0 mesure qu'elle acquiert de l'exp\u00e9rience.<\/p>\n Si un \u00e9l\u00e9ment du backlog de produit ne contribue pas au r\u00e9sultat souhait\u00e9, une \u00e9quipe peut le supprimer du backlog et passer \u00e0 l'\u00e9l\u00e9ment suivant de la liste. Cela signifie qu'une \u00e9quipe peut \u00e9viter de produire des produits improductifs et se concentrer sur de r\u00e9elles am\u00e9liorations.<\/p>\n En raison du peu d'informations disponibles, les \u00e9quipes peuvent utiliser le backlog de produit pour gagner du temps en discutant de la valeur des diff\u00e9rentes options. Un nouveau concept peut \u00eatre ajout\u00e9 au carnet de commandes pour rappeler \u00e0 l'\u00e9quipe de le rechercher. Dans ce cas, l'\u00e9l\u00e9ment du backlog de produit peut \u00eatre retir\u00e9 de la consid\u00e9ration si la proposition ne progresse pas vers l'objectif souhait\u00e9.<\/p>\n Il ne faut pas confondre le backlog de produit avec une liste d'exigences. Il s'agit d'un point d'entr\u00e9e pour les informations relatives aux exigences du produit, mais il se distingue d'un document d'exigences de la mani\u00e8re suivante :<\/p>\n L'utilisation d'un outil \u00e9lectronique peut influencer la strat\u00e9gie de gestion du carnet de commandes d'une \u00e9quipe s'il est mis en \u0153uvre avant que la strat\u00e9gie n'ait \u00e9t\u00e9 d\u00e9cid\u00e9e. Par exemple, l'\u00e9quipe peut s'emm\u00ealer les pinceaux au lieu de d\u00e9cider d'un processus qui r\u00e9pond le mieux \u00e0 ses besoins.<\/p>\n Si le carnet de commandes d'un produit devient trop volumineux, l'\u00e9quipe est incapable de le g\u00e9rer efficacement. Si une \u00e9quipe inclut toutes les solutions possibles \u00e0 un probl\u00e8me, mais ne les \u00e9tudie jamais ou \u00e9limine celles qui ne seront pas mises en \u0153uvre, cela peut se produire.<\/p>\n Les backlogs de produit peuvent \u00e9galement devenir ing\u00e9rables si tous les \u00e9l\u00e9ments importants du backlog de produit sont divis\u00e9s \u00e0 l'avance en \u00e9l\u00e9ments plus petits.<\/p>\n Les propri\u00e9taires de produits intelligents maintiennent un backlog de produit digne de confiance et partageable pour leur programme.<\/p>\n C'est une bonne chose que les parties prenantes remettent en question les priorit\u00e9s. En discutant des priorit\u00e9s, tout le monde peut s'aligner. Ces s\u00e9ances permettent de d\u00e9velopper une culture de fixation des priorit\u00e9s du groupe et de s'assurer que tout le monde a la m\u00eame perspective du programme.<\/p>\n Le backlog de produit guide la planification des it\u00e9rations. Les histoires d'utilisateurs, les d\u00e9fauts, les modifications de conception, la dette technique, les demandes des clients, les actions r\u00e9trospectives, etc. doivent figurer dans le backlog. Chaque it\u00e9ration inclut le travail de chacun. Ainsi, les membres de l'\u00e9quipe peuvent communiquer au propri\u00e9taire du produit les compromis \u00e0 faire avant de commencer une it\u00e9ration.<\/p>\n FoxPlan aide les \u00e9quipes agiles \u00e0 planifier des sprints et \u00e0 g\u00e9rer leurs backlogs de produits. Avec les multiples vues de projet de FoxPlan, les \u00e9quipes agiles peuvent utiliser les outils qu'elles pr\u00e9f\u00e8rent, tandis que les autres d\u00e9partements peuvent obtenir les fonctionnalit\u00e9s dont ils ont besoin pour faire leur travail de la mani\u00e8re qui leur convient le mieux. Toutes les vues de projet partagent des donn\u00e9es en temps r\u00e9el, de sorte qu'il existe un centre qui permet \u00e0 tous de collaborer ensemble.<\/p>\n Vous pouvez utiliser le tableau Kanban pour assurer le suivi de votre backlog. Gr\u00e2ce \u00e0 cette fonction de flux de travail visuel, les \u00e9quipes peuvent suivre leur carnet de commandes sur des cartes et planifier ensuite des sprints ensemble. Comme le cycle de production est illustr\u00e9 par les cartes qui se d\u00e9placent d'une section \u00e0 l'autre, les responsables peuvent voir ce qui se passe. S'il y a un \u00e9ventuel goulot d'\u00e9tranglement, les responsables peuvent rapidement modifier la fa\u00e7on dont les ressources sont utilis\u00e9es pour l'\u00e9liminer et permettre aux joueurs de continuer \u00e0 avancer.<\/p>\n Lorsqu'il s'agit de planifier des sprints ou de g\u00e9rer un backlog, les \u00e9quipes agiles ont besoin d'un logiciel comme FoxPlan, qui est fondamentalement collaboratif. Au niveau des t\u00e2ches, il est possible de faire des commentaires, et si vous voulez un retour, il suffit de les mentionner ou de les \u00e9tiqueter. Les membres de l'\u00e9quipe peuvent \u00e9galement partager des documents entre eux. Toutes les mises \u00e0 jour sont envoy\u00e9es par courriel ou par des alertes dans l'application afin que tout le monde soit toujours sur la m\u00eame longueur d'onde.<\/p>\n Lors de l'\u00e9laboration d'un backlog de produit et d'un backlog de sprint, il est essentiel d'avoir acc\u00e8s aux outils appropri\u00e9s afin d'organiser, de hi\u00e9rarchiser et de distribuer efficacement les t\u00e2ches.<\/p>\nBacklog de produit VS Backlog de sprint<\/h2>\n
Types de backlog de produit<\/h2>\n
\n
L'avantage du Backlog de produit<\/h2>\n
Pi\u00e8ges courants du Backlog de produit<\/h2>\n
\n
Le backlog de produit maintient l'\u00e9quipe agile<\/h2>\n
G\u00e9rez votre backlog de produit avec FoxPlan<\/h2>\n