[XP] Question sur la scécification d'un logiciel en agile/TDD [Résolu]

[balteo]

Bonjour,

Je souhaiterais avoir des conseils de praticiens des méthodes agiles (XP ou Scrum) sur la manière de spécifier les fonctionnalités d'un logiciel.

J'ai lu quelques passages d'ouvrages sur Scrum et XP mais je ne comprends pas comment la spécification doit être faite.

Comment dois-je procéder sachant que je souhaiterais m'appuyer sur une pratique de développement TDD?

La story de XP (phrase très courte qui sert de base de départ aux utilisateurs afin que ceux-ci décrivent les besoins avec le développeur) me parait insuffisante dans le sens qu'elle n'offre pas de trace écrite des besoins décris par les utilisateurs. L'ai-je mal compris?

Pour ce qui est des user stories de Scrum, y-a-t-il plusieurs storytests pour un user story? Quelqu'un peut-il me donner un exemple de feature et de ses stories associées?

Quand choisir la méthodologie de spécification XP et quand choisir la méthodologie de Scrum?

Tous vos commentaires ou réponses sont les bienvenus.

Julien.

[Drawingrom]

Dans scrum par exemple, on stocke les stories dans un product backlog qui nous indique en gros ce que contiendra le produit. Les stories commencent par une phrase courte (par exemple avec le formalisme "en tant que ... je veux ... pour"). L'embryon du backlog est décrit avant le début de la réalisation du projet (le début de la première itération).

L'équipe et le product owner échangent ensuite lors des sprint plannings pour ajouter des informations sur la story, de façon à se mettre d'accord sur le résultat attendu. C'est à ce moment qu'il est possible de définir les tests d'acceptation.

Ce type de document est un peu un résumé de spécifications fonctionnelles, c'est un minimum pour commencer à travailler. Cela peut ne pas suffire aux parties ; contractuellement par exemple il peut être demandé d'avoir des spécifications pour se protéger en tant que fournisseur... Ce n'est pas interdit.

Scrum comme XP définissent un cadre de travail minimal pour réaliser un projet agile mais rien ne t’empêche de rajouter ce dont tu as besoin.

[souviron34]

Envoyé par balteo

Je souhaiterais avoir des conseils de praticiens des méthodes agiles (XP ou Scrum) sur la manière de spécifier les fonctionnalités d'un logiciel.

les spécificatons d'un logiciel ne dépendent pas de la méthodolgie de développement utilisées...

Le comment les obtenir éventuellement..

[balteo]

Merci pour vos réponses.

@souviron:
Qu'entends tu par:

Le comment les obtenir éventuellement..

[souviron34]

Envoyé par balteo

@souviron:
Qu'entends tu par:

Les méthodes agiles définissent plus ou moins précisément des processus en interaction avec l'utilisateur et/ou le client...

Les méthodes classiques (V) en général ne disent pas comment dialoguer..

Certains documents de ces méthodes cependant (une grande boîte d'électronique française avait par exemple fait le travail de mixer normes AFNOR et DoD) , peuvent présenter qui doit faire quoi, et qu'est-ce qui doit ressortir à chaque étape..

En ce qui concerne les méthodes style Agile c'est plus courant, car le dialogue fait (ou devrait faire) partie du cycle à relativement court terme, donc les rôles et manières de faire peuvent éventuellement être plus détaillées..

Mais l'ergonomie et la "user-centered attitude" peuvent prendre tout un tas d'aspects différents.. : interviews, vidéos, story-board, use cases, etc etc...


Maintenant, normalement que l'on utilise une méthode Agile ou un cycle en V bien classique, la spécification du logiciel, c'est à dire l'arborescence des fonctionalités, les listes de paramètres à fournir, etc, devraient être les mêmes dans les 2 cas..

[Luckyluke34]

Envoyé par balteo

Pour ce qui est des user stories de Scrum, y-a-t-il plusieurs storytests pour un user story? Quelqu'un peut-il me donner un exemple de feature et de ses stories associées?

Il est bon de noter que les user stories en tant que telles ne font pas partie du framework Scrum, elles sont issues de XP. Dans Scrum on parle de product backlog items dont la forme n'est pas spécifiée, même si évidemment les user stories restent la forme la plus répandue de spécification agile.

On peut tout à fait avoir plusieurs story tests par user story et cela peut être considéré comme des critères d'acceptance suffisants pour valider la story.

Exemple :

[[Feature]] Comptes utilisateurs

[User story] En tant que visiteur du site, je veux pouvoir créer un compte utilisateur afin d'avoir accès aux fonctionnalités réservées aux membres.

[Story test] (formalisme given/when/then)
Etant donné que je n'ai pas saisi toutes les données obligatoires du formulaire de création de compte
Lorsque j'essaie de créer un compte
Je suis bloqué et un message d'erreur m'avertit des saisies manquantes

[Story test]
Etant donné que le compte utilisateur X existe
Lorsque j'essaie de créer un compte ayant pour nom d'utilisateur X
Je suis bloqué et un message m'indique que ce compte existe déjà

[Story test]
Etant donné que j'ai saisi un mot de passe d'une longueur inférieure à 5
Lorsque j'essaie de créer un compe utilisateur
Je suis bloqué et un message m'indique que la longueur du mot de passe doit être > 5

...

[User story] En tant qu'utilisateur enregistré, je peux me connecter afin d'avoir accès à mes fonctionnalités membre.

[User story] En tant qu'utilisateur enregistré, je peux récupérer mon mot de passe perdu afin d'avoir à nouveau accès au site.

...

Pour plus de précisions sur les spécifications agiles, je te recommande le livre de Mike Cohn http://www.amazon.fr/User-Stories-Applied-Software-Development/dp/0321205685/ref=sr_1_1?ie=UTF8&qid=1312209308&sr=8-1
Sinon comme dit souviron34, rien n'interdit d'avoir des documents d'analyse ou de spécification plus poussés du moment que l'équipe de dev en a besoin. C'est juste que dans les méthodes agiles, avoir un logiciel qui marche sera toujours considéré comme ayant plus de valeur métier pour le client que disposer de 4000 pages de documentation.