Expliquer la différence entre un élément de backlog de produit et une tâche
J'ai rencontré ce défi plusieurs fois et j'espère que quelqu'un pourra fournir des références, une formation ou des conseils sur la façon d'expliquer la différence entre un élément de backlog de produit et une tâche dans TFS.
Je comprends et ai expliqué qu'un élément de backlog de produit est le "quoi" et la tâche est le "comment". J'ai également expliqué que l'IBP est l'exigence et la tâche est de savoir comment l'exigence est satisfaite.
Je reçois à plusieurs reprises des regards vides et des grattements de tête lorsque j'explique cela. Il semble que les ingénieurs logiciels à qui j'explique cela ne peuvent pas faire la distinction. C'est pareil pour eux.
Je crois que mon autre défi est que je ne suis pas en mesure d'illustrer efficacement pourquoi il est important de faire la distinction.
L '"élément de backlog de produit" est en effet le Quoi, la fonctionnalité qui doit être construite. La tâche décrit les étapes à suivre pour y parvenir.
De nombreuses équipes ne sont pas habituées à se décomposer en tâches, elles construisent simplement ce que dit la spécification. Pour ces personnes, il est difficile de les voir comme deux choses distinctes.
Peut-être qu'une simple anecdote aiderait:
Voir les articles du carnet de produit comme les articles de leur liste de courses pour leurs vacances. Peut-être une "tente", une "canne à pêche", une "voiture préparée pour le voyage".
Les tâches de l'élément "tente" seraient "Décrire les exigences de la tente", "Comparer les tentes en ligne", "Obtenir des conseils d'amis ayant une expérience en plein air", "Aller à la boutique en plein air", "Acheter une tente", "installer la tente dans l'arrière-cour pour vérifier l'exhaustivité "," emballer la tente pour voyager "
Les tâches pour la canne à pêche seront très similaires, mais les tâches pour "préparer la voiture pour le voyage" sont probablement très différentes: "Vérifier les exigences des États/pays sur l'itinéraire souhaité", "acheter un gilet de sécurité", "remplacer le contenu expiré des premiers soins kit "," inspecter la roue de secours "," planifier un rendez-vous avec un garage pour faire vérifier le moteur "," aller au garage pour faire vérifier le moteur "," aller à l'agence d'État pour acheter un laissez-passer d'autoroute "," vérifier l'assurance automobile "
Cela sépare clairement la question de ce que le propriétaire du produit veut de ce qu'il doit faire. À moins bien sûr que le propriétaire du produit se soit déjà décomposé en éléments exploitables dans le Product Backlog, auquel cas vous devez également lui parler.
Comme je l'ai dit, pour de nombreux développeurs, ils pensent qu'ils ont déjà suffisamment d'informations et savent quoi faire, ils ne veulent pas décomposer les étapes What into How, ils y arriveront lorsqu'ils y arriveront. Lorsque vous commencez à leur parler du suivi de la progression du sprint, de l'amélioration des estimations, du suivi du travail oublié pendant la planification du sprint et d'autres éléments liés aux améliorations professionnelles, demandez-leur comment eux et leur équipe sauront où ils peuvent s'améliorer et comment ils sais qu'ils sont vraiment faits. Quand ils peuvent trouver un système qui fonctionne sans créer de tâches et cela fonctionne, alors c'est très bien, mais les chances sont très faibles qu'ils le peuvent réellement.
Avant d'essayer de travailler avec TFS et les outils agiles, votre équipe devra comprendre comment tout cela fonctionne. La meilleure façon est de les faire travailler avec un carton, visible de tous sur le lieu de travail. Plus tard, lorsque le processus sera mieux compris, le passage aux outils sera utile. Sans compréhension, les outils ne seront pas très utiles et rencontreront beaucoup de résistance.
Je pense que Jesse a fourni une excellente réponse. Je vais simplement essayer de le faire, eh bien, plus simple (si possible) :) L'élément Backlog du produit (ou User Story, si vous préférez) est généralement écrit comme ceci:
En tant que nouveau client, je souhaite enregistrer mes coordonnées afin d'être informé des nouveautés produits
Dans une tête de développeur, cela peut se traduire par:
- Créer un formulaire d'inscription
- Écrire les données d'enregistrement dans la base de données
- Envoyer un e-mail au nouveau client pour confirmer son inscription
Ces trois éléments sont les tâches.
J'espère que cela pourra aider.
- Rendez-le aussi simple que possible mais pas plus simple (Einstein)
Voici comment nous roulons:
Le PBI:
- est le exigence aka "le quoi"
- est ce dont vous parlez avec un client.
- C'est ce qui apparaît sur la mise à jour quotidienne du projet (DPU) pour le sprint ..... encore une fois parce que le DPU est face au client.
- C'est ce dont le client parlera et se référera en termes d'estimations et de budget.
- Peut comprendre une ou plusieurs tâches.
- Est orienté métier et décrit dans un langage de style métier/domaine que le client comprend.
- Est-ce ce qui est testé et accepté dans les tests d'acceptation des utilisateurs (UAT)
La tâche:
- Un travail est-il nécessaire pour matérialiser l'IBP (exigence)
- Pas quelque chose dont vous parlez avec un client
- Ne s'affiche pas sur le DPU parce que vous n'en parlez pas avec les clients
- Est estimé, mais ses estimations sont-elles regroupées dans l'IBP
- Est un enfant à une et une seule exigence.
- Peut être décrit (et l'est souvent) à l'aide d'un jargon technique
- Testé en interne et signé par test
- Non accepté ou testé isolément par le client (il ne sait pas qu'il existe)