Personnellement, j'en étais arrivé à la conclusion que le style
déclaratif était plus approprié dans des environnements de type startup
où le détail d'une feature est ammené à changer souvent, quand le style
impératif est plus approprié pour les agences et clients directs, pour
les faire réellement visualiser ce que tu leur proposes.
Au final, j'ai fini par ne plus utiliser cucumber en startup parce que
le style déclaratif a peu de valeur ajoutée comparé à du rspec pur.
Je vois deux problèmes dans le cas de ton client :
1. il ne comprend pas ce que tu vas faire
2. il exprime un désir d'implémentation, plutôt qu'un besoin
Le premier est probablement lié au style déclaratif. J'imagine assez
bien ton client lire ça et se dire "ben oui, je veux qu'on ajoute un
artiste, MAIS il faut que ... et que ... et que ...". Lui proposer
quelque chose de détaillé lui aurait permis de saisir ta vision de la
feature.
Le second point est courant chez les clients directs, et il faut
l'éviter absolument. Ils ont toujours du mal à exprimer leur besoin, ils
préfèrent penser une solution qui est la plupart du temps bancale (parce
qu'ils ne sont pas, justement, des professionnels du développement).
C'est à toi de leur tirer les vers du nez, par exemple en disant, ici :
"Donc si je comprend bien, votre besoin et de laisser vos utilisateurs
faire des suggestions pour vous aider à compléter votre catalogue ? Il
faut se méfier de la validation a priori parce que cela implique
beaucoup de travail, à terme, et risque de laisser penser à vos
utilisateurs que vous les méprisez s'ils attendent trop longtemps. De
plus, il serait désagréable pour un membre ayant faire l'effort de
soumettre une proposition de recevoir un mail lui disant qu'il manque
des informations. Voici ce que je vous propose :
Feature: Suggestion d'artistes
Afin de fournir un volume d'artistes permettant à tous d'y trouver son
compte
Un membre de notre site doit pouvoir suggérer des artistes
Scénario: Suggérer un artiste
Étant donné que je suis un membre connecté
Lorsque je vais sur la page de création d'artiste
Et que je remplis "Prénom" avec "John"
Et que j'appuie sur "Soumettre ma proposition"
Alors je dois voir "Vous devez renseigner le nom de l'artiste"
Et je dois voir "En cas de difficulté, vous pouvez nous contacter à
<mail>"
Lorsque je remplis "Nom" avec "Doe"
Et que j'appuie sur "Soumettre ma proposition"
Alors je dois voir "Merci ! Nous traitons au plus vite votre demande"
Et l'administrateur doit recevoir un mail avec détails et lien de
confirmation
Scénario: Confirmer une demande d'ajout
Étant donné qu'un utilisateur a fait une demande d'ajout concernant
"John Doe"
Lorsque je click sur le lien "Ajouter"
Et que je vais sur la page des artistes
Alors je dois voir "John Doe"
Et l'utilisateur doit recevoir un mail l'informant de l'ajout
Scénario: Rappel de demande d'ajout
Étant donné qu'un utilisateur a fait une demande d'ajout il y a semaine
Et qu'il n'est pas confirmé
Alors je dois recevoir un mail de rappel
Fournir le plus d'information dans le mail et permettre de valider en un
click sur un lien permettra de simplifier le processus de validation et
éviter la surcharge.
Si plus tard nous nous rendons compte que vous n'arrivez pas à suivre
les demandes, il faudra surement envisager une validation automatique.
"
On Tuesday, July 9, 2013 6:53:48 PM UTC+2, Guirec Corbel wrote:
>
> 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] <javascript:>
> > 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] <javascript:>
>> Pour résilier votre abonnement envoyez un e-mail à l'adresse
>> [email protected] <javascript:>
>> ---
>> 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]<javascript:>
>> .
>> 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 .
