Bonjour, comment faire quand on doit travailler sur un produit très complexe ? Pour donner plus de détails: le produit est censé être une refonte du produit précédent qui a été développé pendant 15 ans par une équipe d’environ 20 personnes. Ce produit n’est pas un site web mais est une machine avec des éléments mécaniques, électroniques, logiciels embarqués / débarqués. Peut on vraiment avoir un backlog petit alors qu’on a d’ores et déjà une liste de pb/ fonctionnalités longue comme le bras et de gros changements techniques en logiciel, poussés par des changements d’architecture matérielle vs l’ancien produit ?
Bonjour Lauriane, Je pense que oui car le backlog ne doit justement pas de focaliser sur la technique, mais bien sur ce que vous souhaitez accomplir. C'est difficile de te répondre plus précisément sans plus de contexte, mais si tu le souhaites contacte Jean-Pierre ou moi sur LinkedIn en direct pour en parler. -- Constantin
Ne pas mettre les anomalies, améliorations prévues, dans le backlog.... c'est embêtant, cela voudrait dire que l'on a que 2 listes pour, rappel : "It is the single source of work undertaken by the Scrum Team". Si c'est pour un problème de visibilité, on peut utiliser des filtres. On veut une seule liste parce que l'on la veut prioriser, on veut savoir à chaque moment qu'est-ce qui est prioritaire sans ambiguïté et ainsi pouvoir arbitrer, enfin ce n'est que mon avis.
Salut Patrice, non bien sûr, on ne préconise pas d'avoir 2 listes. Ce qu'on veut dire, c'est qu'on ne rentre pas "un bug" dans le backlog, mais une INFORMATION. On y pose une information de ce qu'un client/utilisateur veut faire et ne peux pas, quel est l'impact, etc. Par exemple : "Le bouton ne passe pas au rouge quand on click", c'est un bug, mais ça n'apporte pas d'information utile. On pourrait chercher l'impact que ça a, par exemple, "certains utilisateurs n'ont pas d'information de retour après un clic et rechargent la page ou abandonnent leur commande croyant que ça ne fonctionne pas". -- Constantin
![Hands-On Power BI Tutorial 📊Beginner to Pro [Full Course] ⚡](http://i.ytimg.com/vi/5X5LWcLtkzg/mqdefault.jpg)
Découvrez toute la communauté Scrum Life ! 👉 sl.run/6sOrQE
Efficace 👍🏻
Bonjour, comment faire quand on doit travailler sur un produit très complexe ? Pour donner plus de détails: le produit est censé être une refonte du produit précédent qui a été développé pendant 15 ans par une équipe d’environ 20 personnes. Ce produit n’est pas un site web mais est une machine avec des éléments mécaniques, électroniques, logiciels embarqués / débarqués. Peut on vraiment avoir un backlog petit alors qu’on a d’ores et déjà une liste de pb/ fonctionnalités longue comme le bras et de gros changements techniques en logiciel, poussés par des changements d’architecture matérielle vs l’ancien produit ?
Bonjour Lauriane,
Je pense que oui car le backlog ne doit justement pas de focaliser sur la technique, mais bien sur ce que vous souhaitez accomplir. C'est difficile de te répondre plus précisément sans plus de contexte, mais si tu le souhaites contacte Jean-Pierre ou moi sur LinkedIn en direct pour en parler.
-- Constantin
Ne pas mettre les anomalies, améliorations prévues, dans le backlog.... c'est embêtant, cela voudrait dire que l'on a que 2 listes pour, rappel : "It is the single source of work undertaken by the Scrum Team".
Si c'est pour un problème de visibilité, on peut utiliser des filtres. On veut une seule liste parce que l'on la veut prioriser, on veut savoir à chaque moment qu'est-ce qui est prioritaire sans ambiguïté et ainsi pouvoir arbitrer, enfin ce n'est que mon avis.
Salut Patrice, non bien sûr, on ne préconise pas d'avoir 2 listes. Ce qu'on veut dire, c'est qu'on ne rentre pas "un bug" dans le backlog, mais une INFORMATION.
On y pose une information de ce qu'un client/utilisateur veut faire et ne peux pas, quel est l'impact, etc.
Par exemple : "Le bouton ne passe pas au rouge quand on click", c'est un bug, mais ça n'apporte pas d'information utile. On pourrait chercher l'impact que ça a, par exemple, "certains utilisateurs n'ont pas d'information de retour après un clic et rechargent la page ou abandonnent leur commande croyant que ça ne fonctionne pas".
-- Constantin