Olivier, j'ai essayé ça mais avec le style déclaratif. Je suis tout à fait
d'accord que c'est super utile pour déterminer l'architecture de
l'application mais je pense que je préfère garder ça comme documentation
technique.
Voici que j'avais comme scénario :
Étant donné que je suis un utilisateur connecté
Et que je suis sur la page de création d'un artiste
Quand je remplis le formulaire
Et que je le valide
Alors je dois voir « L'artiste a été ajouté »
Et voici sa correction (avec la correction en couleur) :
Étant donné que je suis un utilisateur connecté
Je veux compléter le formulaire d’enregistrement d’une œuvre pour la
vente.
Or, l’artiste dont je souhaite enregistrer une œuvre n’apparaît pas à
la liste des artistes à sélectionner.
Je dois pouvoir basculer sur un formulaire me permettant de suggérer un
artiste à la liste commune.
Une fois le formulaire complété, je l’expédie à l’administrateur du
site.
Je reçois un message m’avisant que mon message a été envoyé et qu’une
réponse me sera transmise dans les plus brefs délais.
L’administrateur prend ma demande en considération.
Si la réponse à ma demande est positive, le message que je recevrai
alors est le suivant : « Prénom Nom a été ajouté à la liste des artistes
considérés »
Si la réponse est négative, le message que je recevrai alors est le
suivant : « Information insuffisante permettant d’ajouter Prénom, Nom à la
liste . Prière de contacter directement l’administrateur du site ».
On renvoi l’usager au formulaire général de contact.
Peut-être que c'est moi qui n'a pas assez fait de scénario, que j'aurais dû
utilisé le style impératif ou que j'aurai dû mieux expliquer mais on
s'entend qu'on est assez loin du scénario standard. J'ai peur qu'avec un
style impératif, il aurait également ajouter l'envoi des courriels, etc. Je
commence à connaitre mon client et je ne crois pas qu'un scénario soit une
bonne solution pour lui. Il a le profile de l'utilisateur qui s'y connait
suffisamment en informatique pour qu'il pense savoir comment ça marche. Il
est un peu bidouilleur aussi.
Je dis ça mais j'aime bien mon client. C'est vraiment pas négatif envers
lui. C'est juste que je ne crois pas que ça marche dans ce cas là. Je crois
que de très cours libellés sont mieux avec lui.
Le 9 juillet 2013 12:36, Olivier El Mekki <[email protected]> a écrit :
> Je n'ai jamais eu de problème à présenter des user stories, c'était même
> généralement très bien reçu, mais c'est vrai que je bossais plus avec
> des agences.
>
> Si tu as peur que ton client ne comprenne pas, tu peux accompagner tes
> users stories de wireframes. Aucun cahier des charges ou application de
> management ne peut battre ça (et au passage, tu commences déjà à faire
> l'architecture de ton application et écrire tes tests).
>
> Mais bon, attention à ne pas prendre ton client pour un imbécile, non
> plus :)
>
> Scénario: Créer un article
> Lorsque je vais sur la page des articles
> Et que je suis le lien "Nouvel article"
> Et que je remplis "Titre" avec "Mon article"
> Et que je remplis "Contenu" avec "Le texte de mon article"
> Et que j'appuie sur "Créer l'article"
> Alors je dois voir "Mon article" en titre de page
> Et je dois voir "Le texte de mon article" dans le corps de la page
> Et je dois voir la date de publication
>
> Je pense que n'importe qui ayant un jour utilisé internet comprendra ça.
>
>
> On Tuesday, July 9, 2013 6:29:15 PM UTC+2, Guirec Corbel wrote:
>
>> Olivier, au niveau des users stories je suis assez d'accord. Je ne suis
>> pas très d'accord avec le fait d'écrire des scénarios complet. J'ai essayé
>> avec mon client actuel et je pense qu'il ne comprend pas trop ce qu'est un
>> scénario. Je lui ai expliqué brièvement mais je ne veux pas passer trop de
>> temps la dessus. Je pencherais pour des histoires très courtes comme
>> "L'utilisateur doit pouvoir ajouter un artiste", "Un email doit être
>> envoyer à l'administrateur à l'ajout d'un artiste", "Le nom de l'artiste
>> doit être auto-complété quand on commence à taper son nom".
>>
>> Je pense faire ceci :
>>
>> 1. découper le projet en pleins de stories;
>> 2. déterminer la vélocité de chacune d'entre elle;
>> 3. noter mon nombre d'heures tout les jours;
>> 4. diviser nom nombre d'heures dans la semaine par la vélocité et
>> déterminer un ratio Heure (ou prix)/Point de vélocité;
>>
>> Une fois que le ratio est déterminé, c'est assez facile de prévoir
>> combien une liste de tâche peu durer. Bien sur, le ratio peut évoluer au
>> fil du temps.
>>
>> Qu'en pensez-vous?
>>
>>
>> Le 9 juillet 2013 11:42, Guillaume Betous <[email protected]> a
>> écrit :
>>
>>> > Guillaume, imagine la même situation où le client demande un
>>> formulaire pour
>>> > l'ajout d'un artiste sans notification à l'admin et sans javascript.
>>> Cette
>>> > demande fait parti d'une liste de plusieurs autres. Tu demandes quand
>>> même
>>> > une demi journée uniquement pour le formulaire?
>>>
>>> J'ai jamais eu de cas aussi extrême (je ne bosse pas dans le dev web,
>>> ce sont des missions bcp plus longues en général), mais ça ne me
>>> choquerais pas de lui estimer à 1/2 journée, quitte à lui expliquer :
>>> je ne peux pas facturer moins. Ensuite, si réellement tu n'y mets
>>> qu'une heure, t'es toujours à temps de lui annoncer une bonne
>>> nouvelle, il ne t'en voudra pas :)
>>>
>>> gUI
>>>
>>> --
>>> Pour la santé de votre ordinateur, préférez les logiciels libres.
>>> Lire son mail :
>>> http://www.mozilla-europe.org/**fr/products/thunderbird/<http://www.mozilla-europe.org/fr/products/thunderbird/>
>>> Browser le web :
>>> http://www.mozilla-europe.org/**fr/products/firefox/<http://www.mozilla-europe.org/fr/products/firefox/>
>>> Suite bureautique :
>>> http://www.libreoffice.org/**download/<http://www.libreoffice.org/download/>
>>>
>>> --
>>> --
>>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance"
>>> de Google Groups.
>>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
>>> [email protected]
>>> Pour résilier votre abonnement envoyez un e-mail à l'adresse
>>> railsfrance...@**googlegroups.com
>>>
>>> ---
>>> Vous recevez ce message, car vous êtes abonné au groupe Google
>>> Groupes Railsfrance.
>>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
>>> concernant, envoyez un e-mail à l'adresse railsfrance...@**
>>> googlegroups.com.
>>>
>>> Pour plus d'options, visitez le site https://groups.google.com/**
>>> groups/opt_out <https://groups.google.com/groups/opt_out> .
>>>
>>>
>>>
>> --
> --
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
> [email protected]
> Pour résilier votre abonnement envoyez un e-mail à l'adresse
> [email protected]
> ---
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes Railsfrance.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> [email protected].
> Pour plus d'options, visitez le site
> https://groups.google.com/groups/opt_out .
>
>
>
--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse
[email protected]
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant,
envoyez un e-mail à l'adresse [email protected].
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
