Discussion :

[ytrewq]

Salut les chums,

Alors la questions concernent l'interview des customers du product que l'on est charge de mettre en place.
Trop souvent les users reviennet a la fin du projets pour se plaindre et dire qu'on a oublie certine de leur preoccupation...
Alors le ne parle pas encore de validation de cahier de charge/fonctionnalite...
Mais supposons que le probleme soit au niveau du concepteur... Supposons que celui ci s y soit mal prit lors de la discussion avec les futurs utilisateurs du produit... Ma question est : quelle sont les questions a poser au users pendant les interview pour tirer les info les plus pertinantes pour modeliser le systemes (MCD, MLT, MOD, MCT, MPD etc...) ?

[escartefigue]

Salut les chums,
Alors la questions concernent l'interview des customers du product que l'on est charge de mettre en place.
[. . .]
Mais supposons que le probleme soit au niveau du concepteur... Supposons que celui ci s y soit mal prit lors de la discussion avec les futurs utilisateurs du produit...

Effectivement, il arrive souvent que le concepteur ne s'y prenne pas comme il faut, par exemple, vous êtes vous assurés de la qualité de votre exposé ?
Un langage clair et concis est la base d'une compréhension aisée.
Pour commencer, choisissez votre langue, si vous vous adressez à un public francophone, c'est le cas pour ce forum, utilisez la langue française et non un mélange de termes que chacun interprètera à sa façon et plus ou moins aisément.
Et aussi, un peu d'attention concernant la grammaire et l'orthographe ne nuit pas

Ma question est : quelle sont les questions a poser au users pendant les interview pour tirer les info les plus pertinantes pour modeliser le systemes (MCD, MLT, MOD, MCT, MPD etc...) ?

Toutes les questions qui permettent de lever le doute sont à poser :
- chassez tous les "non dits" sources d'interprétations
- chassez les synonymes sources de confusion
- vérifiez ce qui est toujours vrai et ce qui ne l'est pas
- reformulez les règles pour vérifier que ce que vous avez compris est le reflet exact de ce qu'on a exprimé
- illustrez par des exemples
- et surtout : faites valider vos travaux à chaque étape pour éviter l'effet tunnel

[ok.Idriss]

Bonjour.

Alors pour moi cette question ne concerne pas forcemment la méthode ou le langage de modélisation utilisé (UML, Merise, etc).

Pour ma part j'ai toujours eu affaire à trois situations :

1) Le projet est en cycle en V ou équivalent : donc on investit beaucoup sur la rédaction de SFD (spécifications fonctionnelles détaillées) qui le plus souvent ont la forme de RFC. Les SFD sont validées par le client avec signature d'un PV. Un ajustement des SFD constitue un avenant au contrat initial qui prendra en compte le coût des changements à tout les niveaux dans le cycle.

Dans les SFD, on a pas encore la modélisation des données mais on peut avoir des diagrammes de séquences ou d'activité UML, du BPMN ou encore des MCT/MCTA Merise ou autres.
La modélisation des données rentre déjà dans la rédaction des spécifications techniques détaillées.

2) Le projet est en Scrum : donc c'est le jeu, le client demande des ajustements après chaque itérations (il y a une démo à la fin de chaque itérations et une phase de recette client). Les spécifications sont remplacées par des "user stories" sous la forme de tiquets avec le formet "En tant que, je veux que, afin de" avec des tests d'acceptances rédigées sur le tiquet. Une itération constitue une liste de users stories priorisées par le "product owner".

Et donc on a plus trop ces problèmes d'oublis vu que le client est beaucoup plus impliqué dans les priorisations des fonctionnalités/stories et donc des ajustements sont fait toutes les 2/3 semaines si nécéssaire.

3) Le projet est en Kanban : la du coup y-a plus d'itérations, on passe notre temps à refaire l'ordre des prio des tâches (plus de distinguo entre évolution/user storie et anomalies).

Pour les 2 et 3 au final, on reviens souvent sur ce qui vient d'être développé, ça fait plus de travail pour les concepteurs/devs mais ça coute généralement beaucoup moins cher pour le client de travailler avec ce type de méthodologies et pour ma part je pense qu'il y a beaucoup moins de tensions contractuelles. J'ai rarement vu un cycle en V qui se termine par une totale satisfaction des deux côtés :p (malgré le rodage des SFG, SFD, SFT y-a toujours au moins un groupe de personnes qui s'est sentit mis de côté même en interne chez le client).

Donc pour répondre à la question dans tout les cas :

1) Le client doit valider soit les SFG/SFD dans le cas du cyle en V, soit le sprint backlog (contenu de l'itération) et les users stories (évolutions) dans le cas de Scrum, soit la priorisation des tâches à court moyen et long terme dans le cadre de Kanban. C'est une une histoire de cadrage et de définition des responsabilités en cas de litige et être capable de faire avancer les choses dans le bon sens pour toutes les parties prenantes (changer les prio pour Kanban, changer le contenu de l'itération suivante pour Scrum ou négocier un avenant de contrat pour le cycle en V).

2) Si la modélisation de tes données ou traitements ne correspond pas aux besoins du client => soit les specs (SFG/SFD) sont pas bonnes malgré validation du client (et donc évolution ou nouvelle user storie ou on repriorise une tache), soit les specs n'ont pas été comprises correctement par l'équipe technique et donc c'est une anomalie qui doit être détectée pendant les phases de recettes contractuellement définie et à corriger dans les délais d'engagements (SLA) définis par le contrat. Et même si les phases de recettes sont terminées et qu'une anomalie est constatée plus tard en production, on a aussi des périodes de TMA définies dans un contrat pour corriger les anomalies de production (pareil avec des délais d'engagement de réponse et de corrections).

3) Dans le cas d'un problème de compréhension d'une spec : si le cadre contractuel le permet (surtout sur les projets en agile) ne pas hésiter à "harceler" le PO (product owner) de questions pendant la réalisation technique (modélisation ou codage), il est en partie la pour ça :p . Et synthétiser les réponses de celui-ci sur le ticket de la user storie dans l'outil utilisé (jira, mantis, redmin, etc) et lui demandant de valider la synthèse. Si le cadre contractuel ne le permet pas (cycle en V), se référer au chef de projet pour demander des explications, c'est à lui de savoir si ça déborde du cadre contractuel ou pas et de négocier avec le client ou pas.

Idriss