Combien de retards avez-vous ? | heise en ligne

Moi.

Publicité

Il y a beaucoup à dire sur les retards, même si cela semble assez simple à première vue. C’est juste une liste de choses à faire pour arriver à un produit fini. Quelqu’un est chargé de s’assurer que les billets sont sur la liste dans le bon ordre et c’est tout, n’est-ce pas ?

J’observe souvent ce qui suit : Le backlog contient quelques centaines de tickets. Certains ont un an ou plus. Certains tickets donnent lieu au développement de nouvelles fonctionnalités ; on les appelle parfois histoires, user stories, exigences ou quelque chose de similaire. Bien sûr, il y a aussi des tickets de bogues, puis il y a des choses que l’on pourrait appeler des histoires techniques, des histoires de développement ou quelque chose de similaire. Alors que les demandes et exigences de fonctionnalités proviennent du propriétaire du produit ou des soi-disant parties prenantes, ce dernier type de tickets est rédigé par les développeurs.

Et maintenant se pose la question de la priorisation. Je ne comprends toujours pas comment mettre quelques centaines de tickets dans un ordre séquentiel. Mais même avec relativement « peu » de tickets, disons 80, 90 ou 100, trier les caractéristiques/exigences et les aspects techniques n’est pas une tâche facile. Si le propriétaire du produit est un ancien développeur, il peut comprendre les tickets techniques ; j’espère que dans ce cas, il comprend suffisamment bien l’entreprise pour bien faire son travail. Et s’il a une expérience en affaires, la question se pose de savoir s’il est capable d’évaluer de manière adéquate les éléments techniques du carnet de commandes pour garantir une commande judicieuse. Quoi qu’il en soit, il s’agit d’une tâche délicate qui peut difficilement être accomplie par une seule personne.

Ma suggestion pour maîtriser le problème de séquençage : utilisez deux arriérés. Le propriétaire du produit en est responsable (Product Backlog) et les développeurs en sont responsables (Dev Backlog).

Oui oui je sais. D’un point de vue dogmatique, je n’ai donc pas une seule source de vérité. Cela ne me dérange pas car les retards dans la nature sont plus souvent une source unique de chaos plutôt qu’une source unique de vérité.

Quel est l’intérêt de deux arriérés distincts ?

1. Le backlog produit représente exclusivement la vue métier/produit. Les demandes de fonctionnalités, les user stories, les exigences et les bugs sont inclus. Il est donc compréhensible pour quiconque comprend le métier et le produit.
2. Le backlog produit est donc forcément plus court. Créer un tri est plus facile simplement parce qu’il y a un plus petit nombre d’entrées.
3. Tout ce que les développeurs considèrent comme important se trouve dans le Dev Backlog. Il a le même statut que les éléments du Product Backlog ; du moins en théorie.
4. Les affaires quotidiennes déterminent l’égalité réelle. Qui détermine comment et comment si un ticket est extrait du Product Backlog ou du Dev Backlog ? Supposons qu’il existe une sorte de « planification de sprint ». Les objectifs du produit dont le PO est responsable sont ici cruciaux. Ils ont une influence sur les objectifs du sprint. Mais la décision sur la manière de remplir le Sprint Backlog ne peut être prise sans les développeurs.
   Avec un seul backlog, il est peu probable que vous puissiez simplement examiner les tickets de haut en bas dans Planning. C’est beaucoup plus facile avec deux arriérés distincts. Le PO peut lier ses idées sur les objectifs du sprint aux meilleurs tickets du backlog produit. Les développeurs apportent les meilleurs tickets du Dev Backlog dans le dialogue.
   Peut-être que cela fonctionne même si le Dev Backlog ne joue pas de rôle dans la conversation avec le PO. La planification axée sur le produit est rationalisée et le bon de commande est allégé. Les développeurs intègrent indépendamment les tickets de développement nécessaires dans le sprint. Cela nécessite une confiance entre le PO et les développeurs. Si cela n’existe pas, ce sera certainement difficile et j’ai encore un sujet pour un article de blog.

Enfin, je voudrais ajouter une autre perspective : les auteurs Craig Larman et Bas Vodde écrivent ce qui suit à propos des backlogs dans leur livre « Large Scale Scrum » (p.281) : « Le backlog produit est utilisé pour gérer des choses (éléments), tandis que le Sprint Backlog aide l’équipe à se gérer elle-même. […] N’utilisez pas le même outil pour les backlogs de produits et de sprints !”

Des outils différents pour les deux backlogs ? J’ai souvent vu cela dans des équipes travaillant ensemble en un seul endroit : un système de tickets pour le backlog produit, un tableau physique pour le sprint. Dans le cas d’équipes spatialement réparties, je n’ai jamais vu différents outils utilisés pour le Product et le Sprint Backlog. Je suis curieux de savoir si cela fonctionne bien. Si quelqu’un a vécu cela, je serais heureux d’en entendre parler dans un commentaire.

(moi)