Les histoires d’utilisateur sont un outil qui provient de l’Extreme Programming et qui est devenu la façon de facto dont les équipes Agile documentent et recueillent leurs exigences. Il y a beaucoup d’écrits sur les user stories (lien, lien, lien), donc je vais juste parler de ce que je considère comme important pour écrire de bonnes histoires puisque j’en vois BEAUCOUP de vraiment mauvaises aujourd’hui.
Pour ceux qui ne le savent pas, les histoires sont un artefact léger qui nous permet à la fois de capturer les besoins de l’entreprise ET de planifier le travail. Elles sont généralement écrites sur des fiches (oui…des petites fiches 3×5 ou 4×6) dans la langue de l’entreprise ou du client. Avec les user stories, nous n’écrivons que ce qui est nécessaire pour capturer les besoins de l’utilisateur et pas plus. Nous avons tendance à considérer les histoires non pas comme une spécification complète des exigences, mais comme des espaces de placement pour les conversations ultérieures entre les développeurs et le métier.
Lorsqu’elle est utilisée correctement, l’absence de détails d’une histoire d’utilisateur nous offre une grande utilité – nous pouvons utiliser le même document pour parler d’une exigence à un haut niveau, zoomer sur les détails de mise en œuvre et sauter en arrière, le tout en quelques phrases. Puis, une fois que nous avons fini de parler des exigences, nous pouvons envisager les risques, identifier les dépendances et créer un plan de projet sans jamais avoir à poser la carte d’index. Wow ! Je ne connais aucun autre artefact d’exigences existant qui nous permette une telle utilité.
Au fil des années, les personnes qui ont vraiment du succès avec les stories ont établi quelques points communs que l’on retrouve dans toutes les stories :
- Rôle : qui, ou quoi, va utiliser cette fonctionnalité ?
- Fonctionnalité (ou capacité) : qu’est-ce que l’équipe va livrer, ou ajouter, après avoir terminé son travail ?
- Valeur : pourquoi l’entreprise veut-elle même cette fonctionnalité ? Quel impact aura-t-elle sur l’entreprise ?
- Critères d’acceptation : comment saurons-nous si cette fonctionnalité est réalisée ?
- Estimation : combien l’Équipe pense-t-elle que cette fonctionnalité coûtera ?
IMO, pour qu’une story soit considérée comme complète, elle doit avoir TOUTES les caractéristiques décrites ci-dessus. Je constate que lorsque les gens ont du mal à définir toutes les caractéristiques, les stories ne sont pas ce que j’appelle mûres, c’est-à-dire qu’elles n’ont pas été suffisamment réfléchies pour être utilisables par l’Équipe. En plus de ces caractéristiques, les histoires doivent également suivre les critères INVEST (cet excellent article de J.B. Rainsberger parle également d’INVEST).
Mike Cohn a écrit un excellent livre sur les user stories. Malheureusement, pour toute la bonté du livre, les gens semblent s’être concentrés sur le seul morceau de camelote du livre – le modèle d’histoire d’utilisateur. Dans son livre, Mike propose un modèle que certaines équipes ont trouvé utile pour écrire des histoires et à partir de là, ce modèle a été la source de tant de mauvaises histoires que je ne vais pas lui donner plus d’encre (ou de bits). Ce que je reproche au modèle, c’est qu’il incite les gens à ne plus réfléchir en remplissant mécaniquement le rôle, la fonctionnalité et la valeur et en omettant les critères d’acceptation et l’estimation (vraisemblablement parce qu’ils sont absents du modèle). Lorsque je vois des gens lutter avec des histoires, c’est parce qu’ils essaient de coincer leur entreprise dans un modèle qui a aidé une équipe non nommée (qui n’utilise probablement même plus ce modèle) il y a cinq ou six ans et – surprise – il ne correspond pas à l’endroit où ils se trouvent actuellement.
Il y a un processus de réflexion qui doit se produire avant que vous écriviez une seule histoire. Les étapes que j’ai tendance à voir les gens compléter qui réussissent à écrire des histoires sont énumérées ci-dessous. S’il vous plaît garder à l’esprit, alors que ces étapes sont linéaires dans mon post, on peut sauter en arrière, en avant et sauter autour comme il fait sens. L’objectif est d’avoir répondu à ces questions au moment où vous avez terminé l’exploration de votre user story.
- Quels sont les rôles (ou utilisateurs) qui utiliseront votre système ?
- Quels sont leurs besoins ? Comment le produit les aide-t-il à les accomplir ?
- Quelles fonctionnalités (ou capacités) voulez-vous fournir à ces rôles ?
- Pourquoi ces fonctionnalités sont-elles précieuses pour l’entreprise ? Quels types de résultats commerciaux pouvons-nous attendre de ces fonctionnalités ?
- Quelles sont les priorités de ces fonctionnalités ? Avons-nous déjà fait la promesse d’en livrer certaines ?
- Comment sauriez-vous que ces fonctionnalités sont réalisées ?
Enfin, les gens ont tendance à vouloir écrire beaucoup de détails au recto de la story card. J’ai deux suggestions pour ces personnes. Premièrement, utilisez des cartes plus petites – vraiment. Les user stories ne sont PAS des spécifications ou des documents d’exigences. Ce sont juste des fiches qui capturent les besoins de l’utilisateur et qui rappellent que nous devons capturer ces détails de mise en œuvre plus tard. Si vous essayez de faire tenir de plus en plus de choses sur une carte d’index, c’est peut-être un signe que vous avez besoin de spécifications ou d’un certain type de documentation de conception en plus des histoires d’utilisateurs. Deuxièmement, les types de détails que les gens essaient d’écrire sont en fait des critères d’acceptation. En poussant ces détails dans les cas de test, nous gardons l’histoire dans le langage de l’entreprise et conservons l’accent sur la fonctionnalité et la valeur que votre équipe fournit.
.