2 of 12

Définitions

Pour se créer un vocabulaire commun, définissons notre lexique de projet.

User story - Histoire utilisateur
Use case - Cas d’utilisation
Storyboard - Scénarimage

Clarification aussi le lexique des outils.

Issue - Ticket
Task - Tâche

3 of 12

En résumé

GITHUB CODE

GITHUB PROJECT

ISSUES

ISSUE #1 - TICKET - PROGRAMMER une LISTE d’étudiants

Tasks - Tâches :

▢ Programmer le DAO

▢ Préparer la vue

▢ Programmer la liste

▢ Tester la liste

KANBAN

À FAIRE	EN COURS	FAIT

USER STORY #1 - PROGRAMMER une LISTE d’étudiants

4 of 12

User story

Le « User story » ou histoire utilisateur est quelque chose qui est utile au client-utilisateur. Une itération agile est définie par une somme de « User story ». Par exemple : être capable de « Lister mes spectacles » est un User story. On dit que chaque itération agile doit produire quelque chose d’utile immédiatement au client même si c’est jamais fini.

On se souvient que c’est une histoire de l’utilisateur et non pas du logiciel. Les « User story » peuvent aussi comprendre des documents qui serviront au client à soulever des fonds chez des anges investisseurs ou ajouter de la qualité à un dossier d’emprunt.

5 of 12

Use case

Cas d’utilisation

Le « Use case » ou cas d’utilisation est un scénario d’utilisation du logiciel par un utilisateur - généralement appelé aussi fonctionnalité.

Par exemple, un logiciel commercial est utilisé par le Chef, le Vendeur et le Comptable. Chacun des trois comptes a des fonctionnalités spécifiques. Le « Diagramme des Use case » permet de clarifier QUI FAIT QUOI avec des liens entre les bonhommes et les bulles de cas d’utilisation.

La vrais documentation du cas d’utilisation c’est la fiche qui décrit de manière formelle tout le scénario du cas d’utilisation, par exemple « Acheter un produit » avec les inputs et outputs.

6 of 12

Différence

La différence entre le « User story » et le « Cas d’utilisation » ou « Cas d’utilisation » c’est que le Cas d’utilisation présente un scénario d’utilisation du logiciel par un des utilisateurs (je clic là, le logiciel affiche ceci) alors que le User story définit le livrable pour le client.

Un livrable peut ne pas avoir à voir avec un cas d’utilisation, par exemple Acheter un serveur.
Différentes étapes de la réalisation d’un cas d’utilisation peuvent être des User Story. Donc on peut avoir plusieurs user story par cas d’utilisation !

Voir l’exemple à la page suivante.

7 of 12

Exemple

Cas d’utilisation - Use case : « Acheter un produit »

User story : avoir un Document fonctionnel décrivant le processus Acheter un produit
User story : pouvoir Acheter un produit (implémentation)
User story : pouvoir utiliser Paypal pour Acheter un produit
User story : pouvoir acheter un produit avec un téléphone.
User story : pouvoir acheter un produit sans compte

Chacun des User story a une valeur commerciale pour le client, mais au niveau scénario, nous travaillons toujours alentour du même Use case.

8 of 12

Storyboard

Le storyboard n’est qu’une vue en bande dessinée d’un Cas d’utilisation. C’est un scénario, mais visuel.

Il ne sert pas vraiment à documenter formellement le processus mais plutôt à déclencher les spécifications dans l’esprit du client. Souvent on le fait AVANT le cas d’utilisation ou en parallèle.

Étape 1

Étape 2

Étape 3

Étape 4

9 of 12

Issue - Ticket

L’ « Issue » c’est le nom qu’a donné Github à ses Tickets. Un ticket dans un système de suivi (Tracker, Bug tracking, etc.) sert à documenter une demande du client et à consigner le suivi de cette demande. Cela peut représenter un nouveau développement ou encore un bug car ces systèmes existaient originalement surtout pour soumettre les bugs.

Dans notre projet, on utilise les « Issue » pour chaque « User story » parce que le Kanban de Github fonctionne comme cela. Il permet de transformer une Issue en User story dans le Kanban. Il ne permet pas de le faire pour les Task.

10 of 12

Issue - Ticket

Dans le développement Agile, on utilise donc les Tickets ou « Issue » pour suivre le développement de chaque nouvelle fonctionnalité ou pour le réglage des bugs. Cela permet :

de ‘linker’ nos commit : il faut inscrire le numéro du ticket dans noter commentaire avec #. Par exemple : “Variante de maquette pour #2” ou “Correction Vue liste etudiant closes #3”
de faire des commentaires datés sur le processus

les liens vers les tutoriels trouvés ou les solutions au problèmes (lien StackOverflow, lien tutoriel, lien doc)
décrire notre réflexion sur un problème
prise de note des nouvelles infos du client (réponse à une question)

savoir qui fait le ticket et si il est actif (on ferme les issues)

11 of 12

Task - Tâche

La « Task » est une unité de travail plus petite que le User Story. La plupart des logiciels permettent de définir les Tâches dans un User Story.

Dans Github project les tâches sont dans la description du Issue correspondant au User story.

12 of 12