2. Comment nous faisons les backlogs de produit▲
Le Backlog de produit est le coeur de Scrum. C'est là où tout commence. Le Backlog de produit est en gros une liste priorisée d'exigences, d'histoires, de caractéristiques ou autre. Des choses que le client veut, décrites selon la terminologie du client.
Nous appelons ça des histoires, ou parfois simplement des éléments du backlog.
Nos histoires incluent les champs suivants :
- ID - un identifiant unique, juste un nombre auto-incrémenté. Cela évite de perdre la trace des histoires quand on les renomme.
- Nom - Un nom, une description courte de l'histoire. Par exemple « Voir l'historique de ses transactions ». Suffisamment claire pour que les développeurs et le directeur de produit comprennent approximativement de quoi ils parlent, et suffisamment claire pour la distinguer des autres histoires. Normalement 2 à 10 mots.
- Importance - l'importance attribuée par le directeur de produit à cette histoire. Par exemple 10. Ou 150. Élevée = plus important.
- Je fais attention d'éviter le terme « priorité » parce que la priorité 1 est typiquement considérée comme la plus « haute » priorité, ce qui est dommage si plus tard vous décidez que quelque chose d'autre est encore plus important. Quelle priorité devrait-on lui attribuer ? Priorité 0 ? Priorité -1 ? - Estimation initiale - l'évaluation initiale de l'équipe sur la quantité de travail qui est nécessaire pour implémenter cette histoire par rapport aux autres histoires. L'unité est les points d'histoire et correspond habituellement à peu près à des « jours-hommes idéaux ».
- Demandez à l'équipe « si vous pouvez prendre le nombre optimal de personnes pour cette histoire (ni trop peu ni trop nombreux, typiquement 2), et que vous vous enfermez dans une salle avec plein de nourriture et que vous travaillez sans jamais être dérangé, après combien de jours sortiriez-vous avec une implémentation finie, démontrable, testée, et livrable ? ». Si la réponse est « avec 3 gars enfermés dans une salle ça prendrait approximativement 4 jours » alors l'estimation initiale est de 12 points d'histoire.
- Le point important n'est pas d'obtenir des estimations absolues correctes (c'est-à-dire que 2 points d'histoire devraient prendre 2 jours), le point important est d'avoir des estimations relatives correctes (c'est-à-dire que 2 points d'histoire devraient nécessiter à peu près la moitié du travail de 4 points d'histoire). - Comment le démontrer - une description succincte de comment cette histoire sera démontrée à la démo de fin d'itération. C'est essentiellement la spécification d'un test simple. « Fais ci, ensuite fais ça, puis ceci devrait arriver ».
- Si vous pratiquez le DDT (Développement Dirigé par les Tests) cette description peut être utilisée comme du pseudo-code pour vos tests d'acceptance.
- Notes - n'importe quelle autre info, des clarifications, des références aux autres sources d'info, etc. Normalement très bref.
BACKLOG DE PRODUIT (exemple)
| ID | Nom | Imp | Est | Démo. | Notes |
|---|---|---|---|---|---|
| 1 | Dépôt | 30 | 5 | Authentification, ouvrir la page de dépôt, déposer 10 euros, aller sur la page du solde et vérifier que ça a bien augmenté de 10. | Nécessite un diagramme de séquences UML. Ne pas se soucier du cryptage pour l'instant. |
| 2 | Voir l'historique de ses transactions | 10 | 8 | Authentification, cliquez sur « transactions ». Faire un dépôt. Revenir aux transactions, vérifier que le nouveau dépôt apparaît. | Utiliser la pagination pour éviter des requêtes volumineuses. Conception semblable à la page des utilisateurs. |
Nous avons expérimenté beaucoup d'autres champs, mais à la fin, les six champs ci-dessus étaient les seuls que nous utilisions sprint après sprint. Nous faisons habituellement un document Excel avec le partage activé (c'est-à-dire que plusieurs utilisateurs peuvent modifier le fichier en même temps). Officiellement le directeur de produit possède ce document, mais nous ne voulons pas verrouiller l'accès aux autres utilisateurs. Régulièrement un développeur veut ouvrir le document pour clarifier quelque chose ou changer une estimation.
Pour la même raison, nous ne plaçons pas le document dans le dépôt de contrôle de version ; nous le plaçons dans un répertoire partagé plutôt. Ceci semble la manière la plus simple d'autoriser les modifications simultanées sans causer des verrous ou des conflits de réconciliation.
Cependant, presque tous les autres artefacts sont placés dans le système de contrôle de version.
2-1. Champs d'histoire supplémentaires▲
Parfois nous utilisons des champs supplémentaires dans le product backlog, surtout par commodité pour le directeur de produit pour l'aider à trier ses priorités.
- Catégorie - un classement approximatif de cette histoire, par exemple « back office » ou « optimisation ». De cette façon le directeur de produit peut facilement filtrer tous les éléments « optimisation » et leur affecter une priorité basse, etc.
- Composants - Habituellement représentés par des « cases à cocher » dans un tableau Excel, par exemple « base de données, serveur, client ». Ici l'équipe ou le directeur de produit peut identifier quels composants techniques vont être impliqués dans l'implémentation de cette histoire. Ceci est utile quand vous avez plusieurs équipes Scrum, par exemple une équipe back office et une équipe client, et que vous souhaitez rendre plus facile pour chaque équipe de décider quelles histoires prendre.
- Demandeur - le directeur de produit peut vouloir garder une trace de quel client ou quelle partie prenante avait demandé cet élément à l'origine, dans le but de les informer sur l'avancement.
- ID de suivi de bug - si vous avez un système de suivi des bogues séparé, comme nous faisons avec Jira, il est utile de garder une trace de toute correspondance directe entre une histoire et un ou plusieurs bogues.
2-2. Comment nous gardons le backlog de produit à un niveau métier▲
Si le directeur de produit a un passé technique il peut vouloir ajouter des histoires comme « ajouter des indexes sur les table d'événements ». Pourquoi veut-il faire ça ? Le but réel sous-jacent est probablement quelque chose du genre « augmenter la rapidité de la recherche des évènements sur le back office ».
Quand je vois des histoires orientées technique comme celle-ci, je pose normalement au directeur de produit une série de questions « mais pourquoi » jusqu'à ce qu'on trouve le but sous-jacent.
Ensuite on reformule l'histoire dans les termes de ce but sous-jacent (« augmenter la rapidité de la recherche des évènements sur le back office »). La description technique d'origine finit en tant que note (« indexer la table des évènements peut peut-être résoudre le problème »).