Traduction de l'artcile de Mike Cohn Bugs on the Product Backlog

Une question commune est si les bogues devraient se trouver dans le product backlog. Avant que j'adresse cette question, laissez moi clarifier que cette question réfère aux bogues qui ne sot pas reliés aux fonctionnalités développées au courant de l'itération. Si quelqu'un trouve un bogue durant une itération et qui est relié aux fonctionnalités qui sont développées, la meilleur chose à faire est de crier : "Hey, Mike, le code boojum échoue lorsque je…". La deuxième meilleur chose à faire est de coller une nouvelle carte sur le tableau en disant "Corriger le code boojum, ça échoue lorsque je ..".

 
Mais qu'en est-il d'un bogue trouvé aujourd'hui dans quelques choses qui a été codé il ya un mois ou un an? Et qu'en est il du gestionnaire des bogues qu'une équipe, nouvelle à Agile, va certainement apporter avec lui?

La situation idéale est de mettre les bogues directement dans le product backlog. Pour comprendre pourquoi, regarder le d'un point double down casino de vue utilisateur: Pensez vous qu'il lui importe si c'est un bogue ou une nouvelle fonctionnalité? Non. L'utilisateur veut juste que le système se comporte d'une manière différente d'aujourd'hui. Ils s'en foutent comment qu'on l'appelle.

Remarquez que j'ai appelée cette situation la situation idéale , ce n'est pas toujours très pratique, des fois pour des raisons hors du contrôle ou l'influence de l'équipe. Le gestionnaire de bogues à une manière à s'incorporer à l'organisation. Le groupe support technique l'utilise principalement pour communiquer avec les développeurs. Le groupe marketing l'utilise pour les mêmes raisons. L'utilisation d'un backlog mettrai un terme à l'utilisation du gestionnaire de bogue rapidement.

Dans ce cas, la solution la plus utilisée par les équipes est d'avoir deux backlogs.

• Un product backlog de fonctionnalité
• Un backlog de bogue

Cette approche est quelques peu plus difficiles pour les équipes et pour le product owner, mais permet à une équipe agile de travailler plus facilement avec les processus existants de l'organisation.

Des fois, en accommodant de telle sorte une organisation, l'accommodation peut endommager, voir détruire, l'adoption d'agile. Permettre à tout le monde de travailler sur 5 projets concurrents est un exemple d'accommodation dommageable. Accommoder une organisation à utiliser un gestionnaire de bogue n'est pas dommageable. C'est juste un peu plus de travail. Le product owner effectue la majorité du travail supplémentaire en ayant à prioriser deux liste de travail et à ensuite le présenter à l'équipe d'une manière plus ou moins consolidé (Mes hautes priorités sont les trois première items du backlog, les bogues #12340 et 12450 et ensuite ces deux items du backlog…). Cette façon n'est pas très couteuse, étant donné que les items devraient être priorisés même s'ils étaient tous dans un même backlog.

Alors, idéalement les bogues appartiennent au backlog comme toute autres fonctionnalité. Mais cette façon nécessites, souvent, un changement significatif pour le reste de l'organisation alors deux backlog sont utilisés.