Une user story peut être définie dans une phrase comme:
As a <type of user> I want <some goal> so that <some reason>
Juste Google pour la «formule de la user story» et les premiers liens proposent tous cette formule.
Ma question est, quel est le but de cette clause? Est-ce là pour les managers? Est-il là pour que les chefs de projet et les parties prenantes puissent mieux comprendre la priorité de l'élément? Pourquoi est-il là?
Remarque: j'ai travaillé avec la as a <type of user> I want <some goal>formule, et cela fonctionne très bien. Je n'ai remarqué aucun problème dans mon travail en implémentant ce format qui est plus bref.
user-story
Saeed Neamati
la source
la source
Réponses:
Le but est d'éviter un travail inutile en forçant l'utilisateur / client à fournir un avantage commercial solide et tangible comme raison de l'existence de cette fonctionnalité.
Il n'est pas rare que des fonctionnalités soient ajoutées simplement parce que quelqu'un pensait qu'elles avaient l'air cool, ou parce que d'autres logiciels l'ont, donc le nôtre doit également l'avoir. Plus souvent qu'autrement, ceux-ci sont au moins complètement inutiles, sinon activement nocifs.
Cependant, il est généralement facile de repérer ces fonctionnalités, car les personnes qui les proposent généralement auront du mal à fournir une raison commerciale convaincante.
Il y a une technique appelée Popping The Why Stack , où vous prenez la partie "afin que", et demandez "Pourquoi?", Puis vous prenez cette réponse, et demandez "Pourquoi?" à nouveau, récursivement. Si, après (disons) de trois à cinq « Pourquoi » s, vous n'êtes pas arrivé à soit « parce que ça va nous faire de l' argent » ou « parce que ça va nous économiser de l' argent » ( de préférence avec une description précise exactement comment cette va se produire), alors la fonctionnalité ne vaut pas la peine d'être implémentée.
Certaines personnes croient que cela est si important qu'elles l'ont mis en premier dans le modèle d'histoire:
Il y a un excellent exemple tiré d'une conférence de certaines personnes de Thoughtworks: l'un de leurs clients voulait que les rapports imprimés soient formatés de manière très particulière. Lorsque le consultant a demandé "Pourquoi", ils ont dit que de cette façon, ils étaient plus faciles à taper. Ainsi, au lieu d'implémenter la fonction de formatage des rapports, ils ont simplement transféré les rapports sur le réseau. Sans la clause «so that», ils continueraient d' imprimer leurs documents dans un département, de les envoyer par la poste à l'autre département et de les recopier.
la source
Le «pour que» donne une raison à l'objectif.
Par exemple, l'objectif pourrait être d'afficher les chiffres des ventes du mois dernier. Vous pouvez travailler avec cela, mais l'une des raisons pour lesquelles vous devez savoir pourquoi vous souhaitez les afficher afin de pouvoir répondre aux exigences les plus profondes. Que veulent-ils faire avec les chiffres de vente ou les perspectives? La connaissance de ces informations vous donnera plus d'informations sur l'application et plus de chances de concevoir une interface utilisateur permettant au client de faire ce qu'il veut.
Une autre utilisation pour la raison est de prioriser les histoires. Si vous avez deux histoires:
mais ne dispose que des ressources pour en faire un - lequel faites-vous? Sans raison, vous devineriez simplement et vous pourriez ne pas livrer le bon à temps. Bien que cela soit moins important, le client devrait vous dire quoi faire en premier, mais ce n'est parfois pas le cas.
la source
En plus de ce qui a été dit, fournir une raison pour les exigences vous permet de juger de la validité de l'exigence. L'utilisateur peut vouloir des choses pour la mauvaise raison. Avoir le «pour que» clarifie la raison permet donc à l'analyste de valider que la demande est ainsi mieux satisfaite.
Exemple:
AI veut pouvoir sélectionner des employés dans une liste de tous les employés de l'entreprise
BI veut pouvoir sélectionner des employés dans une liste de tous les employés de l'entreprise afin que je puisse supprimer ceux qui ont quitté l'entreprise il y a 5 ans.
(B) n'a pas de sens même dans une organisation moyenne, mais vous pouvez valider l'exigence de l'utilisateur et proposer une autre façon pour le client de répondre à l'exigence.
la source