Parcours partie prenante

Que fait Parcours partie prenante ?

Les exigences que personne n'a écrites émergent lorsque quelqu'un qui n'est pas l'auteur essaie de faire la chose : l'opérateur qui installe le service, le scientifique qui cherche ses données, le collègue qui configure un dépôt, le mainteneur qui lit un journal à trois heures du matin. Un parcours fait cela sur le papier, avec une personne nommée et un processus concret, avant que la modification ne soit spécifiée. Son résultat n'est pas une conception : ce sont des questions pour le propriétaire, des lacunes et des exemples d'acceptation que les spécifications et les tests peuvent utiliser.

Deux habitudes empruntées, avec remerciements : l'entretien à deux chapeaux, le chapeau produit (valeur utilisateur, objectifs, succès) et le chapeau développeur (faisabilité, sécurité, cas limites), comme le fait la compétence Feature Forge (licence MIT) par jeffallan ; et marquer ce qu'une partie prenante simulée a « dit » comme étant de moindre confiance que ce qu'une vraie partie prenante a dit, comme le font les compétences d'elicitation d'exigences de melodic-software.

Entrées

À établir avec l'utilisateur avant de commencer le parcours, et à écrire en haut du résultat :

1. La personne. Qui elle est, ce qu'elle veut de ce processus, ce qu'elle sait et ne sait pas, ce qu'elle a sur sa machine, et ce qu'elle ne lirait jamais. Privilégier le rôle d'une vraie personne à l'institut plutôt qu'un archétype ; privilégier les réponses d'une vraie personne à vos suppositions lorsque vous pouvez demander.
2. Le processus. La chose qu'elle essaie de faire, de sa première étape jusqu'au moment où elle considère que c'est fait. Exemples : installer le crawler sur un serveur ; trouver la mesure de la semaine dernière dans l'index ; ajouter un nouveau format de fichier en tant que collection externe ; démarrer un nouveau dépôt pour le développement avec des agents ; lire le journal de crawl après une exécution nocturne.
3. Ce qui existe. Les documents, le code, les commandes et les pages que la personne rencontrerait, afin que le parcours teste la réalité et non un plan. Les lire comme la personne le ferait : dans l'ordre où elle les trouverait, en sautant ce qu'elle sauterait.

Le parcours

Parcourir le processus une étape à la fois, dans la peau de la personne. Pour chaque étape, écrire :

• Ce qu'elle fait, concrètement : la commande tapée, la page ouverte, le fichier lu, la personne sollicitée.
• Ce qu'elle doit savoir à ce moment-là, et si ce qui existe le lui dit.
• Ce qui se passe mal ici en pratique : l'échec silencieux, le message trompeur, le choix sans valeur par défaut, l'étape qui nécessite des droits qu'elle n'a pas, l'attente sans retour d'information.
• La question qu'elle poserait au propriétaire si elle le pouvait, dans ses mots.

Ensuite, changer de chapeau deux fois sur l'ensemble du parcours : avec le chapeau produit, demander ce que la personne voulait et si le processus le lui fournit, à quoi ressemble « fait » pour elle, de quoi elle se plaindrait ; avec le chapeau développeur, demander ce qui est infaisable, non sécurisé, lent à l'échelle ou fragile dans l'ordre des étapes.

Lorsque le parcours atteint un point que les documents ne couvrent pas, ne pas inventer la réponse : l'enregistrer comme une question, et si vous avez dû supposer quelque chose pour continuer, le dire et marquer le reste du parcours comme reposant sur cette hypothèse.

Monter d'un niveau lorsqu'une étape révèle quelque chose de général (cinq pourquoi) : un message confus est une étape ; « l'outil ne dit jamais ce qu'il va faire avant de le faire » est une exigence.

Résultat

Écrire le parcours dans les notes de conception du projet si elles existent (par exemple design/walkthroughs/<personne>-<processus>.md), sinon docs/walkthroughs/, et donner un bref résumé dans la réponse. Modèle :

# Parcours : <personne> <fait processus>

Personne : <qui, objectif, connaissances, environnement>. Confiance : <simulé | basé sur des entretiens avec ...>.
Ce qui existe : <documents, code, commandes lus>.

## Étapes
1. **<étape>.** Fait : <...>. Doit savoir : <...>. Se passe mal : <...>. Demanderait : "<...>".

## Chapeau produit
<ce qu'elle voulait, ce qu'est "fait" pour elle, de quoi elle se plaindrait>

## Chapeau développeur
<infaisable, non sécurisé, lent, fragile>

## Questions pour le propriétaire
- <question, dans les mots de la personne, avec l'étape dont elle provient>

## Lacunes
- <exigence, comportement ou document qui n'existe pas ; l'étape qui en a besoin>

## Exemples d'acceptation
- Quand <situation concrète>, alors <résultat observable>.   (prêt pour un scénario de spécification ou un test)

Règles

• Dire quelles parties sont simulées. Un parcours par un agent trouve les lacunes qu'un collègue attentif trouverait ; il ne sait pas ce que la vraie personne valorise. Transmettre les questions à une vraie partie prenante là où elle existe, et mettre à jour la ligne de confiance.
• Rester dans la peau de la personne. Si vous savez comment le système fonctionne, la personne ne le sait pas ; écrire ce qu'elle voit, pas ce que vous savez.
• Concret plutôt que général. « L'opérateur exécute modama-crawler crawl et ne voit rien pendant deux heures » est une constatation ; « les retours pourraient être améliorés » n'en est pas une.
• Les questions, les lacunes et les exemples sont la livraison. Ne pas concevoir la correction ici ; le propriétaire décide ce qui devient une exigence.
• Envisager un œil neuf : pour un outil qui existe, un sous-agent à qui l'on ne donne que la personne, le processus et les documents destinés à l'utilisateur, avec pour instruction d'exécuter l'outil, trouve ce que l'auteur ne peut pas désapprendre. C'est la compétence hallway-test de ce plugin ; l'utiliser lorsque le parcours se transforme en « essayons-le ».