Recueillir efficacement les besoins
CHAPITRE 3
101
L’inconvénient en est que la démarche par user stories fonctionne bien si le client est à
proximité et disponible.
Rassemblées dans un référentiel unique, elles constituent le product backlog.
Quelle technique choisir : user story ou use case ?
Le tableau 3-3 1 présente les différences majeures entre les deux techniques.
Le choix de la technique (user story ou use case) dépend fortement du contexte et de la
méthodologie adoptée.
On insistera davantage sur la formalisation dans le cadre de projets où l’équipe est
dispersée géographiquement ; au contraire, si le client est disponible et le nombre
d’interlocuteurs réduit, la user story est parfaitement adaptée.
– V pour Vertical : un bon scénario décrit une fonctionnalité complète de l’application, dont le
client peut en soi apprécier l’intérêt. Lorsqu’il concerne une seule « couche » de l’application,
on parle de scénario horizontal, il faut alors chercher un meilleur découpage. Mauvais exemples : « Créer le modèle d’objets métier correspondant à la facturation » ; « Créer l’interface
graphique pour les fonctions de facturation » ; « Créer le schéma de base de données pour la
facturation ». Bon exemple : un découpage qui fait apparaître comme scénarios distincts les
différents services rendus par le module de facturation.
– E pour Estimé : pour que les scénarios client puissent servir de base à la planification, on
doit connaître leurs coûts d’implémentation, ou au moins une estimation. S’il est difficile de
donner une estimation, c’est que le scénario est trop vague. Bon exemple : « Implémenter les
règles métier R1, R2 et R3 ». Mauvais exemple : « Garantir le respect des règles de gestion
selon la législation en vigueur. »
– S pour Suffisamment petit : toujours pour faciliter la planification, les scénarios doivent être
réalisables en assez peu de temps pour que l’équipe de développement puisse en planifier
plusieurs dans la même itération. Si les développeurs estiment le temps nécessaire pour la
réalisation d’un scénario à une itération entière, il faut découper le scénario. Mauvais exemple :
« Réaliser le module de facturation ».
– T pour Testable : un excellent moyen pour s’assurer que tout le monde, client et développeurs,
comprend ce que recouvre un scénario consiste à se demander comment on va le tester. Une
question qu’il est utile de poser : « Le développeur nous dit qu’il vient de réaliser le scénario en
moins de cinq minutes ; on pense qu’il se fiche de nous. Comment le prendre en défaut ? »
Cet aide mémoire, de même que d’autres outils, bons réflexes ou démarches de questionnement,
font partie des compétences qui peuvent rendre plus efficaces le travail sur les scénarios client.
On peut s’interroger sur leur durée de péremption et le manque de traçabilité les caractérisant,
mais l’objectif est précisément de détruire ces fiches ; seuls la fonctionnalité réelle et le code
commenté documentent le produit.
1. Voir http://www.qualitystreet.fr/
GestProjInform Livre Page 101 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 3
101
L’inconvénient en est que la démarche par user stories fonctionne bien si le client est à
proximité et disponible.
Rassemblées dans un référentiel unique, elles constituent le product backlog.
Quelle technique choisir : user story ou use case ?
Le tableau 3-3 1 présente les différences majeures entre les deux techniques.
Le choix de la technique (user story ou use case) dépend fortement du contexte et de la
méthodologie adoptée.
On insistera davantage sur la formalisation dans le cadre de projets où l’équipe est
dispersée géographiquement ; au contraire, si le client est disponible et le nombre
d’interlocuteurs réduit, la user story est parfaitement adaptée.
– V pour Vertical : un bon scénario décrit une fonctionnalité complète de l’application, dont le
client peut en soi apprécier l’intérêt. Lorsqu’il concerne une seule « couche » de l’application,
on parle de scénario horizontal, il faut alors chercher un meilleur découpage. Mauvais exemples : « Créer le modèle d’objets métier correspondant à la facturation » ; « Créer l’interface
graphique pour les fonctions de facturation » ; « Créer le schéma de base de données pour la
facturation ». Bon exemple : un découpage qui fait apparaître comme scénarios distincts les
différents services rendus par le module de facturation.
– E pour Estimé : pour que les scénarios client puissent servir de base à la planification, on
doit connaître leurs coûts d’implémentation, ou au moins une estimation. S’il est difficile de
donner une estimation, c’est que le scénario est trop vague. Bon exemple : « Implémenter les
règles métier R1, R2 et R3 ». Mauvais exemple : « Garantir le respect des règles de gestion
selon la législation en vigueur. »
– S pour Suffisamment petit : toujours pour faciliter la planification, les scénarios doivent être
réalisables en assez peu de temps pour que l’équipe de développement puisse en planifier
plusieurs dans la même itération. Si les développeurs estiment le temps nécessaire pour la
réalisation d’un scénario à une itération entière, il faut découper le scénario. Mauvais exemple :
« Réaliser le module de facturation ».
– T pour Testable : un excellent moyen pour s’assurer que tout le monde, client et développeurs,
comprend ce que recouvre un scénario consiste à se demander comment on va le tester. Une
question qu’il est utile de poser : « Le développeur nous dit qu’il vient de réaliser le scénario en
moins de cinq minutes ; on pense qu’il se fiche de nous. Comment le prendre en défaut ? »
Cet aide mémoire, de même que d’autres outils, bons réflexes ou démarches de questionnement,
font partie des compétences qui peuvent rendre plus efficaces le travail sur les scénarios client.
On peut s’interroger sur leur durée de péremption et le manque de traçabilité les caractérisant,
mais l’objectif est précisément de détruire ces fiches ; seuls la fonctionnalité réelle et le code
commenté documentent le produit.
1. Voir http://www.qualitystreet.fr/
GestProjInform Livre Page 101 Vendredi, 3. avril 2009 12:07 12