Bonjour la communauté,
Alors pour lancer un sujet, j’aimerai savoir ce que veut dire pour vous l’Increment doit être utilisable
Parce que je lis que ce n’est pas forcément de « livrer ».
Sauf que dans ma tête s’est bloquée, comment avoir un résultat (outcome) sans « livrer » une production (output) ? Est-ce un problème de sémantique sur le mot « livrer » ?
Au plaisir de vous lire, avec des exemples si possible 
Y’a aucun problème avec ce qui est écrit en ce qui me concerne.
« L’incrément doit être utilisable » veux dire littéralement ce que ça veux dire, à savoir que le système doit encore marché. Mais derrière se cache aussi la notion d’utilisabilité, d’ergonomie et d’accessibilité, sans lesquels l’incrément n’a aucune valeur. Mais tous ces paramètres n’ont absolument pas besoin d’être « livré en prod » pour être vrai. Ou pour le dire autrement, utilisable =/= utilisé.
Pareil, je vois pas de problème. Parfois, ce n’est pas toujours une bonne chose de livrer « maintenant ».
Peut-être que les utilisateurs ne sont pas disponibles pour la nouvelle fonctionnalité ?
Peut-être que ce n’est pas le bon moment pour le marché, et c’est prêt plus tôt que prévu mais faut attendre encore 1 mois ?
Peut-être qu’il est utilisable pour une partie des utilisateurs, mais pas livré pour tous et toutes ?
Donc ça dépend du contexte, comme d’habituuuuudeeeuh. 
Hello,
Pour fournir un exemple j’ai le cas actuellement, notre sprint se termine dans 9 jours et notre objectif est de réaliser une nouvelle feature comptable. Cette feature doit être opérationnelle en production le 1er octobre, surtout pas avant. Cependant on doit bien la « done » lors de ce sprint (= validé en tests bout en bout sur environnement iso-prod avec des vrais jeux de données et donc déployable en production).
On aura une feature inactive une dizaine/quinzaine de jours en prod. Ce que l’on veut c’est qu’à la fin du sprint elle puisse potentiellement être déployée, mais on se prend une petite marge de sécurité pour être sûr de pas avoir de retard car il y a de gros enjeux derrière.
Merci de vos premiers retours,
Pour moi, c’est livré dans l’environnement demandé par la partie prenante.
Je peux commencer à collecter des informations sur le résultat (bon ou mauvais) via cette approche (satisfaction des utilisateurs, …).
Je livre et l’utilisateur ou les clients n’utilisent pas. C’est utilisable et le résultat est discutable car l’utilisateur en avait la capacité.
Je ne livre pas, comment mesurer le résultat ? Comment je sais que l’utilisateur ou le marché n’était pas prêt ?
Je n’ai pas écrit « en prod », mais juste livré.
Je pense que c’est un problème de sémantique de ma part.
Je devrais réfléchir à un autre terme que « livrer » car il sous-entend production.
Pour être utilisable, elles (toutes choses nécessaires) doivent être livrés disponibles aux parties prenantes pour en mesurer le résultat.
Qu’en pensez-vous ?
OK, y’a quand même un biais qui apparaît dans le raisonnement : il n’est absolument pas nécessaire d’avoir quelque chose de livré et utilisable pour savoir si la solution est la bonne, quoi qu’en disent les pontes de l’agilité. Les designers produits utilisent des trucs magiques depuis des années qui s’appellent des mockups, des prototypes, des maquettes… Si tu attends que ce soit livré pour mesurer tout ça, c’est déjà bien trop tard, surtout à la vue de l’investissement potentiel que ça représente.
Je chipote.
Comment faire pour avoir des retours avec …
???
Dans un sens, il faut bien livrer / mettre à disposition, ces éléments à un utilisateur afin d’avoir un retour.
Cependant, ces éléments ne sont pas utilisables.
Oui tu chipotes. Dans le jargon UX, pour ces artefacts, on parle jamais de « livrer », le langage est pas le même.
Cela confirme mon intuition, et je pense que c’est à moi de changer mon vocabulaire pour m’aligner sur une compréhension plus commune.
Pour moi, un mockup est un livrable, il est livré pour être inspecté. Mais je comprend que livrer peut-être ambigüe, et je serai tenté d’utiliser « mettre à disposition » à l’avenir.
D’un certain côté, il est utilisable dans l’objectif de valider l’ergonomie par exemple car il permet au de collecter du feedback.
Samuel, quel terme me recommanderais-tu d’utiliser à la place de livrer dans ce cas ?
bonjour,
tu peux faire des tests utilisateurs, tu laisses tes mockups / maquettes à dispo de tes parties prenantes et elles peuvent « naviguer » sur un parcours pré-défini avec tes UX (elles doivent réussir à faire l’action demandée sans que tu leur montres quoi faire)
cela te permet de valider ta feature dans son ensemble (pas les détails des règles de gestion) ca te permet aussi de voir si tes parties prenantes réussissent à utiliser ou pas et ca te permet d’avoir des retours sur ta conception.
Nous on fait ca pour les « grosses features » qui vont avoir un gros impact de dev
Ensuite livré ca peut etre aussi « juste » démontrable dans un env de test pour tes parties prenantes sans etre accessible en prod - livré ne veut pas forcément dire poussé en prod justement
Ingrid
Merci pour ton explication Ingrid.
Encore et toujours du vocabulaire.
Je reformule et détail l’idée pour contribuer au sujet.
Dans ce que tu expliques, les parties prenantes sont des utilisateurs, dans le sens de client du produit, qui pourrait faire partie d’un groupe de beta testeurs.
Ce test utilisateur correspond à une validation qualitative de l’UX. C’est une superbe opportunité d’avoir une petite boucle de feedback.
Ces maquettes interactives sont mises à disposition.
Ensuite, quand, c’est livré en production, à ce moment là il y a aussi une boucle feedbacks. Ces feedbacks sont quantitatifs, exemple un taux de conversion, une rétention.
Peut-on considérer une maquette comme un incrément, utilisable temporairement ?
Non. Sauf protocole particulier, elles ne sont pas « mise à disposition » seulement. Elles sont présentées, observées, analysées, …
La différence entre quelque chose qu’on « livre » et quelque chose qu’on utilise pour tester des hypothèses c’est que le premier est actionnable par et pour lui même, alors que le second est un moyen, un outil. « Livrer » une maquette ou un mockup est en soit un non-sens : Je fourni un outil à une utilisatrice… et ensuite ? Si je n’observe pas, si je n’analyse pas, le boulot s’arrête ici, et personne n’a rien accompli. Dans le cas d’un produit livré, quand bien même on observe et analyse rien (ce qui est souvent le cas d’ailleurs), on a tout de même quelque chose d’actionnable d’un côté, et de vendable de l’autre. Peu importe si on itère dessus derrière dans cet exercice de pensée présent.
Pour moi, la partie UI/UX fait partie des étapes qui font qu’un incrément puisse être utilisable mais n’est pas du tout le livrable lui-même, c’est juste une boite qui permet de tester, recueillir des avis des utilisateurs pour peaufiner le produit et livrer justement un incrément cohérent par rapport à ces retours… que cette boite en carton soit le livrable, c’est un peu chaud non ? ça me fait penser à ces boites qu’on livre où il n’y a rien derrière les boutons et quand tu fais une démonstration du produit, le client croit que le produit est déjà créé… attention à ce raccourci ! Sinon, oui une maquette peut être utilisable, être mise à disposition, mais elle ne sera pas une fin mais seulement un moyen d’arriver à un résultat sur le produit livré.
Le moment où un incrément est mis à disposition des utilisateurs en production, c’est le début des emmerdes.
Ceci est une reformulation, adapté à ce sujet, d’une citation de Frédéric Leguédois.
Pour moi, je ne vois pas la différence.
Cela s’applique aussi aux livraisons en production.
Une fonctionnalité qui n’évolue plus, est morte.
Une produit qui n’évolue plus est mort.
Sauf un point que Samuel énonce, que je résume avec la question :
Je vois que le premier dépend du second.
Ho, la boucle de feedback.
Pour parler mercantilement, seulement un des deux est vendable.
Hum, qu’est-ce qui permet de faire une levée de fond ?
C’est un cas spécifique qui n’est pas réellement intéressant dans l’exercice présent de mon point de vue.
Dropbox, juste avec une vidéo, a fait + 60k d’inscrit à sa newsletter.
la maquette n’est pas un incrément selon moi et comme ont dit Samuel et Franck c’est plutot un moyen pour créer ton incrément. Elle peut etre créer par des teams members mais en priorité par les UX (en tout cas dans notre mode de fonctionnement). Elle présente un cas nominal et de la donnée « fake » elle n’est pas intelligente, elle permet uniquement de presenter un déroulement d’écrans ou d’actions répondant à ton besoin.
cela permet de donner de la visibilité sur le fonctionnement envisagé et dans le cas de structures où il n’est pas toujours facile d’accéder aux « vrais » utilisateurs de ton appli (et pas aux admins) par exemple outils B2B, ca permet de faire un Oneshot de feedback qui peut etre impossible à réaliser en fin de chaque sprint
Et là, je reviens avec ma question.
Parce que la maquette, le mokup, … sont des étapes intermédiaires de création de l’incrément.
Elles ne sont pas livrés mais mises à disposition pour en tirer le fruit.
Finalement, on livre ou pas pour avoir un incrément utilisable ? 