Quelles sont vos bonnes idées pour inciter à communiquer le POURQUOI devant le COMMENT?
Rémy Sanlaville
C'est un sujet dont nous avons abordé lors de notre journée et cela pourrait être intéressant d'échanger nos idées sur ce point.
En ce qui me concerne, voilà quelques réflexions :
- Par expérience, on peut constater qu'effectivement ce n'est pas une chose facile pour la plupart d'entre nous.
Les deux niveaux (pourquoi et comment) sont souvent mélanger, et les personnes ont du mal à bien faire l’abstraction
entre le pourquoi et le comment.
Est-ce culturel ? Est-ce que dans d'autres pays c'est différent ?
Pourquoi est-ce si difficile ?
...
Il serait intéressant de mieux comprendre cela via des études spécifiques (par exemple sociologique ou autres).
Cela nous donnerait des pistes de réflexions pour trouver des idées.
- Sinon, voilà quelques idées pour aider à faire ressortir le pourquoi :
+ Utiliser la technique des 5 Whys
Refs
CITCON 2009 User Acceptance Test, Nicolas Martignole, 20 septembre 2009 (cf. exemple de la fabrication du F-15 par l’armée américaine)
Cinq pourquoi, wikipédia
Le pouvoir du Pourquoi : les 5 whys (exemple du « Washington Monument »)
+ Pour pouvoir s'améliorer/s'exercer, le mieux est de rajouter des contraintes fortes.
C'est ce que font par exemple les musiciens quand ils s'entraînent (cf. Strategy #2: To Master a Skill, Master Something Harder)
Par exemple :
* Simplifier au maximum l'explication de ce que vous voulez décrire
- Essayer de décrire votre besoin via twitter (140 caractères max)
- Un enfant doit pouvoir vous comprendre : “If you can't explain it to a six year old, you don't understand it yourself.” ― Albert Einstein
* Rajoutez-vous des contraintes
- Expliquer votre besoin à une personne qui a une déficience : sourd, aveugle...
* Demander à de non spécialistes (qui ne sont pas en dans votre domaine/métier) de vous expliquer ce qu'ils ont compris ou non
+ Vérifier que votre description ne décrit que le comportement et n'est donc pas dépendante de la technique/implantation
Si vous changez la manière de faire (le comment/l'implantation) alors votre description doit toujours est valide.
Et vous ? Que diriez-vous ?
Rémy
LESEIGNEUR Laurent
Bonjour à tous,
Le cas m’est arrivé ce matin : une user story bien technique et très précise : un ticket avec un gros COMMENT, avec un tout petit pourquoi. Au 3° des 5 why on a trouvé ce qui clochait, en l’occurrence un problème de téléphone arabe qui a dilué le sens à chaque interlocuteur.
Je vois souvent un effet de masquage/rigidité fonctionnelle quand on commence par le comment.
Cf. :
http://theses.univ-lyon2.fr/documents/getpart.php?id=lyon2.2002.noir_m&part=64573
http://psychologie-cognitive.blogspot.com/2011_01_01_archive.html
Arriver avec une demande et une ébauche de solution pour en augmenter sa valeur masque souvent un manque de recul du demandeur.
Cordialement,
L.
--
De :
cara-ase...@googlegroups.com [mailto:cara-ase...@googlegroups.com] De
la part de Rémy Sanlaville
Envoyé : dimanche 19 février 2012 23:41
À : cara-ase...@googlegroups.com
Objet : Quelles sont vos bonnes idées pour inciter à communiquer le
POURQUOI devant le COMMENT?
Click here to report this email as spam.
Bruno Orsier
Bonjour,
C’est le thème d’un des « key process patterns » dont nous avons parlé en intro de l’atelier : « Deriving Scope from goals ». Je viens de prendre quelques notes ci-dessous.
Le chapitre commence par l’exemple souvent cité (je crois que c’est Rémy qui m’en avait parlé la première fois) de l’avion de chasse F16, qui a beaucoup de succès car les concepteurs ont su s’intéresser au pourquoi alors que le client avait initialement fourni le comment.
Comment : 1 avion qui atteigne Mach 2.5
Pourquoi : 1 avion qui puisse s’échapper facilement d’un combat aérien. Résultat : un avion beaucoup moins cher, répondant parfaitement au vrai besoin.
Gojko Adzic distingue deux situations :
I) Equipes qui ont un contrôle à haut niveau du périmètre leur projet. Il donne quelques pistes :
a. Understand the why and who. Le format “as … I want … in order to …” ou ses variantes est crucial. Comprendre QUI va utiliser l’application (à quelle fréquence, etc.) peut changer complètement la donne.
b. Understand where the value is coming from. Essayer de prioritiser au plus haut niveau possible (plutôt qu’au niveau de tâches ou stories bas niveau).
c. Understand what outputs the business users expect. C’est en fait plus simple que d’essayer de comprendre les entrées de l’application, et cela implique plus facilement les utilisateurs.
d. Have developers provide the « I want » part of the user stories. C’est l’idée d’impliquer au plus tôt développeurs et testeurs.
II) Equipes qui n’ont pas le contrôle (mais rien ne les empêche d’influencer le périmètre). Pistes :
a. Ask how something would be useful. Demander un example haut niveau de comment une feature serait utile. Cela indiquera le vrai problème.
b. Ask for an alternative solution. Découvrir des options supplémentaires.
c. Don’t only look at the lowest level. Risque de perte de la vision globale à cause du besoin de découpage en choses qui tiennent dans une itération.
d. Make sure teams deliver complete features (when : large multi-site projects). Problème classique des équipes qui livrent des composants… et qui donc ne peuvent pas discuter des features complètes avec des clients/utilisateurs.
C’est un domaine en pleine évolution, Gojko ne parle que des recettes qu’il a vu réellement dans des équipes. Il signale des techniques innovantes qu’il faudrait regarder plus en détail :
- Feature injection
- Effect mapping
- User story mapping
A+
Bruno
DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
Johan Martinsson
DUPUIS JEAN
Salut
Je prends le train en route après une grippe / gastro… désolé pour la non réactivivté
En ce qui me concerne, voilà ma pratique :
j’ai la chance d’avoir passé 17 ans en assistance MOA et d’avoir une formation de gestion / marketing, je ne connais de la programmation que des bribes de turboPascal vues en DEUG d’économie appliquée en 1989… Du coup, je n’ai aucune tentation de m’intéresser au COMMENT… même si aujourd’hui j’essaye d’acquérir un vernis techno
1/ Je rebondis sur ce que dit @Rémy : « Un enfant doit pouvoir vous comprendre : “If you can't explain it to a six year old, you don't understand it yourself.” ― Albert Einstein »
Depuis toujours, j’utilise cette technique : je dis « un gamin ou votre grand-mère doivent comprendre ce dont vous parlez »
Je vais un cran plus loin : pour ceux qui ont des petits enfants, ça vous parlera : autour de 3 ans, un enfant est hyper curieux. La preuve, il demande « POURQUOI » à peu près sur tout… « POURQUOI il fait tout noir ? POURQUOI tu vas au travail etc… Sa curiosité n’a comme limite que vous absence de réponse. Il fait les 5 POURQUOI naturellement… Les enfants de 3 ans sont certainement les meilleurs consultants en assistance maîtrise d’ouvrage que je connaisse. Et je m’aperçois que de 5 à 25 ans, on s’évertue par nos études à nous enfoncer dans le COMMENT et nous éloigner du POURQUOI originel
2/ Egalement à partir de l’apport de @Rémy + Vérifier que votre description ne décrit que le comportement et n'est donc pas dépendante de la technique/implantation
Si vous changez la manière de faire (le comment/l'implantation) alors votre description doit toujours est valide.
On a également ce point aujourd’hui sur mon périmètre : on va changer d’architecture et on doit pouvoir :
- Passer les tests fonctionnels et les tests de perf de la même manière sur l’archi existante et sur l’archi cible… les API et adresses IP sont inchangées… mais on change la boite noire au milieu.
Voici un petit layus d’un de mes collègues sur cette fameuse problématique de boites noire (ne pas dépendre dans l’implémentation des tests de la technologie testée)…
La mesure boite noire consiste à considérer la PSCS (l’objet de la mesure) comme un bloc monolithique et de faire les mesures en périphérie.
Les principaux avantages sont :
· Méthode de test simple
· Pas d’impact sur l’objet observé
· Utilisable tant pour mesurer les performances de l’existant que de la cible car indépendante de ce qui est développé et à tester
· Pas de perte des performances
Les principaux inconvénients sont :
· Inutilisables en phase de production
· Niveau d’information faible
La mesure boite blanche consiste à insérer des points de mesure dans l’objet observé. A partir de ce moment, il est possible d’avoir un vue précise sur la performance des modules ou des fonctions.
Les principaux avantages sont :
· Utilisable de phase de production
· Information très riche
· Possibilité de faire des statistiques
Les principaux inconvénients sont :
· Méthode de test complexe
· Impact sur l’objet observé
· Spécifique à l’architecture cible
· Perte des performances
Les tests en boites blanches sont plus complexes et donc plus couteux à mettre en œuvre, toutefois ils apportent beaucoup plus d’informations, y compris des informations statistiques.
A+
Jean Dupuis
Directeur de Projets
Ingénierie Applicative
LD : + 33 476 61 36 60
Mobile : + 33 6 82 70 83 12
10, rue Lavoisier – 38330 Montbonnot
ATTENTION : Ce message et toutes les pièces jointes (ci-après le "message") sont confidentiels et strictement réservés aux destinataires qui procèderont aux vérifications appropriées en matière de virus. Toute utilisation ou diffusion non autorisée est interdite.
Tout message électronique est susceptible d'altération. L'auteur de ce message et le Groupe OPEN déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou indûment utilisé par des tiers, ou encore s'il a causé tout dommage ou perte de toute nature.
Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
***********************************
WARNING : This message and any attachments (the "message") are confidential and strictly intended for their addressees, who will conduct appropriate virus checks. Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. The author of this message or OPEN Group shall not be liable for the message if altered, changed, falsified or unduly used by third parties, or for any damage or loss.
If you are not receiver of this message, please cancel it immediately and inform the sender.
De : cara-ase...@googlegroups.com [mailto:cara-ase...@googlegroups.com] De la part de Rémy Sanlaville
Envoyé : dimanche 19 février 2012 23:41
À : cara-ase...@googlegroups.com
Objet : Quelles sont vos bonnes idées pour inciter à communiquer le POURQUOI devant le COMMENT?
Frederic JANET
Hi Folks,
Dans la série retour d’expérience (tardif) sur ce sujet…
Dans le cadre d’un projet au forfait pour un client dans le domaine de la gestion des assurances locatives, nous avons été confronté à l’obligation de passer du Cas II (équipe n’ayant pas le contrôle du scope : nous) au Cas I (équipe qui ont le contrôle du scope : encore nous).
Ce projet ne marchait pas car nous n’arrivions pas à dialoguer avec notre client, et ce pour des raisons simples :
· Nous étions informaticiens et ne comprenions pas le langage du monde de l’assurance, ce qui nous mettais dans la situation inconfortable de démarrer un projet sans maitriser le scope et nous a fait rater la phase d’avant-vente.
· Le client n’était pas du tout informaticien de métier mais exprimait systématiquement ses besoins avec une solution toute faite.
Les conséquences directes ont été :
· Dérive en charge et en délai
· Architecture inadaptée
· Risque d’escalade permanent
La seule solution à consistée à revenir aux besoins en mode boite blanche par la biais de workshops à 90% fonctionnels et 10% techniques.
Dans ces workshops, nous avons du ré apprendre à communiquer ensemble en appliquant les axes suivants:
· En général même qd je comprends une réponse, je joue au candide (j’y arrive très rapidement de façon naturelle J) pour obliger mon interlocuteur à reformuler son exigence. Je ne suis pas persuadé du bien fondé qu’un enfant puisse comprendre les joies des assurances locatives par contre je considère toujours que ma spécification doit être compréhensible par une personne externe au projet (donc ni métier, ni technique).
· Application des 5 whys (pas toujours nécessaire d’aller jusqu’à 5) mais permet de revenir au vrais besoins primaires.
· Toujours impliquer le client pour argumenter son explication avec des exemples abstraits puis concrets.
· Apporter au plus tôt du quantitatif : combien de personnes connectées en même temps, combien de message transmis par jour … dans le but de faciliter le travail d’architecture. Autre aspect intéressant, qd un client a du mal à répondre aux questions de volumétrie c’est que lui aussi est un peu trop éloigné des vrais besoins.
· Toujours savoir QUI va utiliser telle ou telle fonctionnalité. Cela parait bête mais cette question n’est pas systématiquement posée.
· Les aspects techniques abordés pendant ces réunions étaient volontairement haut niveau de façon à aiguiller notre client vers une solution viable (en termes de faisabilité ou de performances ou de coûts), c’est le seul moment ou la notion de solution a été abordée.
Au final et même si nous n’avons pas mis en place une approche BDD, les bénéfices ont été divers
· Reprise de confiance client
· Meilleure implication au final de l’équipe de dev (… qui ne veut pas qu’on fasse son travail à sa place).
· Définition formalisées des exigences client > fonctionnalités applicatives > solution technique.
· Mise en place d’une matrice fonctionnelle pour faire le lien entre les exigences client et les fonctionnalités applicatives, donc lisible par le client et par l’équipe tout au long du projet.
· Architecture redimensionnée pour les besoins réels.
· Nous comprenons parfaitement le langage métier de notre client.
Donc pas facile à faire mais faisable (sous réserve que le client soit moteur luis aussi dans la démarche).
A+
Fred.
De : cara-ase...@googlegroups.com [mailto:cara-ase...@googlegroups.com] De la part de Bruno Orsier
Envoyé : lundi 20 février 2012 16:20
À : cara-ase...@googlegroups.com
Objet : RE: Quelles sont vos bonnes idées pour inciter à communiquer le POURQUOI devant le COMMENT?
Rémy Sanlaville
Merci pour ton retour.
Je voulais réagir sur ton dernier point concernant les tests en boîte noire ou blanche.
J'ai un peu de mal à bien comprendre et voir comment les stratégies de tests (boîte noire ou blanche...) permettent de mieux spécifier son besoin.
J'ai l'impression que les aspects spécification et tests abordent des problématiques différentes et avec des visions différentes :
- la spécification décrit le besoin (et si possible pourquoi) ;
- le test vérifie que le besoin a été implanté correctement.
Les avantages et inconvénients que tu listes me semble plus orienté test que spécification.
Peut-être voulais-tu souligné un point que je n'ai pas bien compris ?
Rémy
Rémy Sanlaville
Merci pour ton retour d'expérience très intéressante et enrichissante d'enseignement.
Il me semble que ta démarche entre bien dans celle du BDD, notamment sur l'aspect de la transmission
de ce qui faut faire entre votre client et vous. Cela correspond à l'étape 1 discussion du cycle ATDD.
On peut noter par exemple, le travail du langage omniprésent qui correspond au métier de votre client.
J'ai noté aussi le travail sur les exigences non-fonctionnelles, thème qui est rarement abordé dans les articles sur le BDD.
Je ne sais pas si dans le livre de Gojko Adzic, il parle de cela ou non.
Quand tu indiques
Sinon comme tu le soulignes, pas facile à faire...
Rémy
DUPUIS JEAN
Bonjour Remy
C’est amusant car j’aurai défini à peu près le contraire sur tests et specs… ;-)
Dans ma connaissance de la pratique traditionnelle merise, les specs détaillées sont écrites par la maîtrise d’œuvre IT (développeur) sur le comment (ex. SFD : comment concrètement on répond au besoin, avec quels écrans avec quelles règles de contrôle… c’est très concret, on est loin de la philosophie, du pourquoi…). La Specification est formulée en partant de la définition de besoins ou de la spec générale exprimée par un client au travers d’un cahier des charges ou d’un premier niveau de doc (cela a l’avatnage d’obliger le client à structurer sa pensée et à essayer de clarifier le périmètre de ce qu’il attend) ou d’un échange oral (non recommandé dans les méthodes classiques car le client reste brouillon dans sa tête).
En ce qui concerne les tests, pour moi ils ont deux buts :
- D’une part si on les conçoit a posteriori (ce qui a mon avis est une erreur), ils servent à valider que la solution fonctionne comme on l’attend : il travaille donc sur le quoi. C’est dommage de se contenter d’une telle approche a posteriori car cela prive le développeur d’une visibilité sur l’attendu CONCRET et ça crée une espèce d’ambiance JURY / ELEVE ou le client va pouvoir mettre une mauvaise note au mauvais développeur… ce qui est stupide comme attitude, convenons en
- D’autre part, si on est en approche test driven ce qui est plus constructif, le test aide à donner des cas concrets sur le POURQUOI. En fait, comme le souligne Fred Janet, le client parle un langage souvent métier a tendance à vouloir avancer un peu vite sur le COMMENT au lieu de se concentrer sur sa vraie VA : le POURQUOI. Et les informaticiens se délectent du COMMENT où ils sont très forts… et on en perd le POURQUOI.
Globalement, je crois qu’il faut s’intéresser à la typologie des clients et à leur capacité à passer de l’abstrait au concret et l’inverse. Créer des cas de tests avec les données en entrée et en sortie sans entrer dans le détail de comment ça se déroule, permet de se centrer sur le QUOI et d’éclairer le POURQUOI ?
- Ex. Le client DUPUIS retire 100 € du distributeur et dispose à la fin du retrait de 1x50, 2x20 et 1x10, soit de 5x20 => on est sur le POURQUOI de l’application borne DAB-GAB et sur le QUOI (résultat attendu) de la transaction en boite noire.
Inversement, si on entre dans le détail du déroulé de la transaction, on est sur le COMMENT
- Autre cas : Si on définit un test plus fin, on est sur le COMMENT : Le client DUPUIS souhaite retirer de l’argent de manière sécurisée. Pour cela, il introduit sa carte, saisit son code PIN, sélectionne « retirer de l’argent » puis la Somme à retirer parmi une liste de 10 valeurs les plus demandées à ce DAB, puis le type de coupures souhaitées ; enfin il souhaite demander un ticket de relevé d’opération. On voit qu’il aurait pu faire autrement : insérer sa carte, choisir un retrait, le montant, le type de coupures puis saisir son code PIN et finir par le ticket… On est toujours sur le COMMENT.
A+
Jean Dupuis
Directeur de Projets
Ingénierie Applicative
LD : + 33 476 61 36 60
Mobile : + 33 6 82 70 83 12
10, rue Lavoisier – 38330 Montbonnot
ATTENTION : Ce message et toutes les pièces jointes (ci-après le "message") sont confidentiels et strictement réservés aux destinataires qui procèderont aux vérifications appropriées en matière de virus. Toute utilisation ou diffusion non autorisée est interdite.
Tout message électronique est susceptible d'altération. L'auteur de ce message et le Groupe OPEN déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou indûment utilisé par des tiers, ou encore s'il a causé tout dommage ou perte de toute nature.
Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
***********************************
WARNING : This message and any attachments (the "message") are confidential and strictly intended for their addressees, who will conduct appropriate virus checks. Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. The author of this message or OPEN Group shall not be liable for the message if altered, changed, falsified or unduly used by third parties, or for any damage or loss.
If you are not receiver of this message, please cancel it immediately and inform the sender.
De : cara-ase...@googlegroups.com [mailto:cara-ase...@googlegroups.com] De la part de Rémy Sanlaville
Envoyé : lundi 5 mars 2012 21:52
À : cara-ase...@googlegroups.com
Objet : Re: Quelles sont vos bonnes idées pour inciter à communiquer le POURQUOI devant le COMMENT?
Frederic JANET
Hello,
Pour le QUI, il y a 2 exploitations
· La première fonctionnelle, le qui peut faire partie des 5Why et permet d’affiner les exigences voir changer l’exigence (on peut s’apercevoir à ce moment là que l’exigence est mal exprimée). Cela rejoint ce que tu nous avais montré dans tes slides sur la proportion de fonctions réellement utilisées par rapport à celles spécifiées.
· La deuxième technique pure pour localiser le module de traitement associé (batch, IHM, autres) et pour faire un travail préparatoire sur les IHMs en termes d’utilisation et d’ergonomie.
Frederic.
De : cara-ase...@googlegroups.com [mailto:cara-ase...@googlegroups.com] De la part de Rémy Sanlaville
Envoyé : lundi 5 mars 2012 22:12
À : cara-ase...@googlegroups.com
Objet : Re: Quelles sont vos bonnes idées pour inciter à communiquer le POURQUOI devant le COMMENT?
Rémy Sanlaville
C’est amusant car j’aurai défini à peu près le contraire sur tests et specs… ;-)
Ce qui est intéressant de creuser, c'est de voir si on dit la même chose avec des mots différents ou s'il y a divergence de point de vue et du coup pourquoi.
Dans ma connaissance de la pratique traditionnelle merise, les specs détaillées sont écrites par la maîtrise d’œuvre IT (développeur) sur le comment (ex. SFD : comment concrètement on répond au besoin, avec quels écrans avec quelles règles de contrôle… c’est très concret, on est loin de la philosophie, du pourquoi…). La Specification est formulée en partant de la définition de besoins ou de la spec générale exprimée par un client au travers d’un cahier des charges ou d’un premier niveau de doc (cela a l’avatnage d’obliger le client à structurer sa pensée et à essayer de clarifier le périmètre de ce qu’il attend) ou d’un échange oral (non recommandé dans les méthodes classiques car le client reste brouillon dans sa tête).
Je ne connais pas merise (juste de nom).
Comme tu le soulignes, de ce que tu décris, on est ici dans une spécification (technique) détaillée.
On est du côté du Doing the Software Right et ce n'est pas l'objet du BDD.
Mais avant de décrire des spécifications détaillées, il faut avoir des spécifications qui décrivent le besoin (en s'abstrayant au maximum de l'implantation).
C'est le côté du Doing the Right Software et c'est l'objet du BDD.
En ce qui concerne les tests, pour moi ils ont deux buts :
- D’une part si on les conçoit a posteriori (ce qui a mon avis est une erreur), ils servent à valider que la solution fonctionne comme on l’attend : il travaille donc sur le quoi. C’est dommage de se contenter d’une telle approche a posteriori car cela prive le développeur d’une visibilité sur l’attendu CONCRET et ça crée une espèce d’ambiance JURY / ELEVE ou le client va pouvoir mettre une mauvaise note au mauvais développeur… ce qui est stupide comme attitude, convenons en
- D’autre part, si on est en approche test driven ce qui est plus constructif, le test aide à donner des cas concrets sur le POURQUOI. En fait, comme le souligne Fred Janet, le client parle un langage souvent métier a tendance à vouloir avancer un peu vite sur le COMMENT au lieu de se concentrer sur sa vraie VA : le POURQUOI. Et les informaticiens se délectent du COMMENT où ils sont très forts… et on en perd le POURQUOI.
Globalement, je crois qu’il faut s’intéresser à la typologie des clients et à leur capacité à passer de l’abstrait au concret et l’inverse. Créer des cas de tests avec les données en entrée et en sortie sans entrer dans le détail de comment ça se déroule, permet de se centrer sur le QUOI et d’éclairer le POURQUOI ?
- Ex. Le client DUPUIS retire 100 € du distributeur et dispose à la fin du retrait de 1x50, 2x20 et 1x10, soit de 5x20 => on est sur le POURQUOI de l’application borne DAB-GAB et sur le QUOI (résultat attendu) de la transaction en boite noire.
Il me semble que le Cycle en V cherchait à faite la même chose en décrivant les tests en même temps que la phase de spécification du besoin avant d'arriver à l'implantation.
Néanmoins, j'ai l'impression que dans l'approche BDD il y a quelques différences :
- Le BDD se focalise sur le business et l'utilité pour l'utilisateur. On essaye de se poser les questions de pourquoi on a besoin de cela et qu'est-ce que cela apporte. Est-ce vraiment utile et est-ce que je ne ferai pas mieux de commencer par autre chose.
- Les exemples servent pour la compréhension de ce qui est attendu par l'ensemble des parties prenantes. Par contre, dans les outils, on ne reprendra que le minimum pour piloter le développement et on évitera de gérer tous les cas pour vérifier l'ensemble des combinaisons possibles.
Ce n'est pas forcément le cas de tout le monde comme tu le soulignes, mais c'est souvent la majorité des cas (du moins de ce que j'ai pu voir).
Je n'ai toujours pas bien compris ce qu'apporte la stratégie boîte noire/blanche dans le fait de pouvoir mieux décrire son besoin.
Rémy
Rémy Sanlaville
Pour le QUI, il y a 2 exploitations
· La première fonctionnelle, le qui peut faire partie des 5Why et permet d’affiner les exigences voir changer l’exigence (on peut s’apercevoir à ce moment là que l’exigence est mal exprimée). Cela rejoint ce que tu nous avais montré dans tes slides sur la proportion de fonctions réellement utilisées par rapport à celles spécifiées.
· La deuxième technique pure pour localiser le module de traitement associé (batch, IHM, autres) et pour faire un travail préparatoire sur les IHMs en termes d’utilisation et d’ergonomie.
Cela rejoint le pattern de description d'un besoin : In order to... As a... I want...
Cela ramène aussi aux Personas.
On peut ainsi voir les différents profiles qui vont utiliser l'application avec leurs propres contraintes, langages, règles métiers...
Cela aidera aussi à définir leur parcours utilisateur et de leur offrir une interface ergonomique qui répond à leur besoin.
Rémy
DUPUIS JEAN
Bonjour Rémy
Quelques réponses dans ton mail
De : cara-ase...@googlegroups.com [mailto:cara-ase...@googlegroups.com] De la part de Rémy Sanlaville
Envoyé : mardi 6 mars 2012 22:01
À : cara-ase...@googlegroups.com
Objet : Re: Quelles sont vos bonnes idées pour inciter à communiquer le POURQUOI devant le COMMENT?
Bonjour Jean,
Dans ma connaissance de la pratique traditionnelle merise, les specs détaillées sont écrites par la maîtrise d’œuvre IT (développeur) sur le comment (ex. SFD : comment concrètement on répond au besoin, avec quels écrans avec quelles règles de contrôle… c’est très concret, on est loin de la philosophie, du pourquoi…). La Specification est formulée en partant de la définition de besoins ou de la spec générale exprimée par un client au travers d’un cahier des charges ou d’un premier niveau de doc (cela a l’avatnage d’obliger le client à structurer sa pensée et à essayer de clarifier le périmètre de ce qu’il attend) ou d’un échange oral (non recommandé dans les méthodes classiques car le client reste brouillon dans sa tête).
Je ne connais pas merise (juste de nom). Tu appelles ça cycle en V, c’est la mm chose
Comme tu le soulignes, de ce que tu décris, on est ici dans une spécification (technique) détaillée. Pour moi c’est une specification Fonctionnelle détaillée, cela n’a rien de technique sinon je serai incapable de l’écrire ;-)
On est du côté du Doing the Software Right et ce n'est pas l'objet du BDD. Exact
Mais avant de décrire des spécifications détaillées, il faut avoir des spécifications qui décrivent le besoin (en s'abstrayant au maximum de l'implémantation).
C'est le côté du Doing the Right Software et c'est l'objet du BDD. OK
En ce qui concerne les tests, pour moi ils ont deux buts :
- D’une part si on les conçoit a posteriori (ce qui a mon avis est une erreur), ils servent à valider que la solution fonctionne comme on l’attend : il travaille donc sur le quoi. C’est dommage de se contenter d’une telle approche a posteriori car cela prive le développeur d’une visibilité sur l’attendu CONCRET et ça crée une espèce d’ambiance JURY / ELEVE ou le client va pouvoir mettre une mauvaise note au mauvais développeur… ce qui est stupide comme attitude, convenons en
- D’autre part, si on est en approche test driven ce qui est plus constructif, le test aide à donner des cas concrets sur le POURQUOI. En fait, comme le souligne Fred Janet, le client parle un langage souvent métier a tendance à vouloir avancer un peu vite sur le COMMENT au lieu de se concentrer sur sa vraie VA : le POURQUOI. Et les informaticiens se délectent du COMMENT où ils sont très forts… et on en perd le POURQUOI.
On est bien d'accord avec cela, et c'est pour cela que je suis séduit par l'approche TDD qui est plutôt Spécification Driven Development et non des tests. OK
Globalement, je crois qu’il faut s’intéresser à la typologie des clients et à leur capacité à passer de l’abstrait au concret et l’inverse. Créer des cas de tests avec les données en entrée et en sortie sans entrer dans le détail de comment ça se déroule, permet de se centrer sur le QUOI et d’éclairer le POURQUOI ?
- Ex. Le client DUPUIS retire 100 € du distributeur et dispose à la fin du retrait de 1x50, 2x20 et 1x10, soit de 5x20 => on est sur le POURQUOI de l’application borne DAB-GAB et sur le QUOI (résultat attendu) de la transaction en boite noire.
Pour moi cela rejoint l'approche spécification par l'exemple qui a pour l'avantage de pouvoir reprendre ensuite ces exemples tout au long du développement.
Il me semble que le Cycle en V cherchait à faite la même chose en décrivant les tests en même temps que la phase de spécification du besoin avant d'arriver à l'implantation.
Oui c’est la théorie en effet mais la pratique en est très loin à ma connaissance. Souvent les tests sont préparés par les développeurs après avoir développé…
Néanmoins, j'ai l'impression que dans l'approche BDD il y a quelques différences :
- Le BDD se focalise sur le business et l'utilité pour l'utilisateur. On essaye de se poser les questions de pourquoi on a besoin de cela et qu'est-ce que cela apporte. Est-ce vraiment utile et est-ce que je ne ferai pas mieux de commencer par autre chose.
En théorie, ca existe aussi dans les approches traditionnelles. On parle d’analyse de la valeur. Dans le secteur public, ils ont la méthode MAREVA qui porte là-dessus, sur des projets tout ce qu’il y a de plus tradi (cycle en V). Mais du modèle à la pratique réelle il y a un grand pas. En particulier parce que dans un cycle en V, on fait un contrat « immuable » (sauf avenants) sur la base d’un cahier des charges fonctionnel (cahier des clauses techniques particulières dans le public) : un cahier des cahrges, un contrat pour un projet qui va durer 12 à 24 mois… Donc la MOA sait que l’opportunité de demander qqchose de significatif passe tous les 12, 24, 36 48 mois… pas question d’en oublier sinon on aura changé de job avant ou été racheté… ;-) Donc on charge à mort le cahier des charges avec des demandes fonctionnelles loufoques, potentielles, on demande des fonctions qu’a le copain du Ministère d’a coté sans savoir si ce serait utile chez nous, et surtout sans recours à aucune analyse de la valeur ni priorisation (MoSCoW…)
- Les exemples servent pour la compréhension de ce qui est attendu par l'ensemble des parties prenantes. Par contre, dans les outils, on ne reprendra que le minimum pour piloter le développement et on évitera de gérer tous les cas pour vérifier l'ensemble des combinaisons possibles. OUI
Ce qui me gêne aussi lorsqu'on emploie le terme test, c'est que cela est plutôt vu comme une activité de validation après le développement avec tous les travers que tu as pu mentionner.
Ce n'est pas forcément le cas de tout le monde comme tu le soulignes, mais c'est souvent la majorité des cas (du moins de ce que j'ai pu voir). Je suis d’accord, il y a un gros problème de terminologie. Je vois en permanence des projets sur lesquels il y a de joyeux mélanges de concepts :
- Certains appellent « tests usine » la visite de la MOA qui vient voir dans l’usine avant la livraison pour recette si ce qu’on prépare est bien dans la ligne de la demande. Donc regard totalement fonctionnel. Pour moi, le test usine n’a rien à voir avec du test fonctionnel. C’est purement technique.
- D’autres parlent de « recette MOE »… ça n’existe pas. On parle de Qualif. Le terme « recette » signifiant réception, acceptation est uniquement utilisable pour l’activité de MOA
- Idem sur les environnements : on croit qu’on parle de la mm chose mais pas du tout. Chez un client, ils ont un environnement « d’intégration » sur lequel il n’y a que l’appli livrée et pas tout l’environnement…, un environnement de « pré-prod » qui n’est pas du tout l’image de la prod et qui est modifiée à la main dans sa config pour faire de la recette… Le problème du concept flou est partout. D’où la nécessité de reformuler en permanence, de jouer le candide, de creuse pour « nettoyer les concepts fourre-tout »
Je n'ai toujours pas bien compris ce qu'apporte la stratégie boîte noire/blanche dans le fait de pouvoir mieux décrire son besoin.
Boite noire : cela t’aide à te restreindre à une description IN / OUT. Je rentre ça, il sort ça, qu’importe la magie dans la boite. => c’est ce qui nous faut pour le BDD
A+
Rémy