Et pour aller juste un tout petit peu plus loin, voilà aussi illustré ce que j’évoquais pendant le live sur la différence entre l’approche point-based et l’approche set-based:
Point-based (la majorité des implémentations de scrum):
Ca manque de feedback ce diagramme !
Pour info, il a été mis à jour par le London Design Council, qui sont le créateur a priori du double diamant, assez anciennement connu pour… Du design très waterfall. Ils essaient de changer leur image, heureusement.
Ca m’inspire un peu plus ce schéma, qui prend en compte mieux la complexité du design.
J’aime bien tes schémas sur le set based et le point based @Samuel_Abiassi … Tu as des articles qui en parlent pour que je comprenne mieux le concept ? Merci !
Merci, je me le suis bouffé tranquillement. Excellente conf !
En fait le set based design c’est exactement ce que j’explique dans des formations sur les multiples possibilités de design, et c’est ce que la Pensée Design (la vraie) amène.
Très fan du concept !
Le problème, c’est que je pense pas que beaucoup de personnes vont voir cette vidéo alors que comme d’hab avec Cope, c’est un must-watch, et ça m’attriste pas mal.
Set-Based design est intéressant (je ne le connaissais pas), mais je le vois étant utile uniquement sur des petites variations, sinon le coûts seront exorbitants.
Je me rappelle notamment la discussion du live de mardi sur le choix de base de données. Je ne vois pas comment cette technique peut être utilisée dans ce cas, car les conséquences de ce choix vont pas se voir simplement à la fin d’un sprint. Et je pense que c’est trop coûteaux de garder une implémentation multiple de BDD pendant plusieurs Sprints.
Quand à moi, je favorise plutôt l’approche point-based, car pour la plupart des produits on est pas en train de révolutionner le moyen d’interaction de l’utilisateur. On connait pour la plupart notre client final, ce n’est pas un extraterrestre qui peut avoir 20 doigts, un seul œil, et réfléchi de manière totalement différente.
Donc l’approche set-based, je la vois plutôt efficace pour les produits qui sont « bleeding edge », avec des concepts totalement differents.
Cela dit, ce n’est pas exclu de l’utiliser pour des produits classiques sur une fonctionnalité spéciale.
Je t’invite à regarder la vidéo que j’ai posté juste au dessus si ce n’est pas déjà fait.
tldr: Oui, Set-based n’est pas forcément indiqué si tu « sais déjà ce qu’il faut faire » (quoi que cela puisse vouloir dire… )
D’une part, de quelle durée de sprint parle-t-on ici ? D’autre part, tu « penses » que c’est trop couteux ? Pourquoi pas. Mais par rapport à quoi ? Montre moi les données qui prouvent que c’est moins couteux de réécrire tout un pan de code et redéfinir toute une archi parce que la BDD choisie ne correspondait pas au final à ce dont on avait besoin.
C’est bien un de mes reproches. Où est l’innovation ? Où est la recherche scientifique dans le processus ? Si le but est de répondre de façon « juste assez bonne » à un problème, la barre n’est pas bien haute.
Oui, et oui. Mais du coup la question derrière serait: si ta zone de travail n’est pas le « bleeding edge », comme pas mal d’entreprise sur le marché, pourquoi autant de produits sont ils de qualité aussi médiocre ?
DESIGN Thinking:round_pushpin: L’approche du diamant double — La Nouvelle École de Créativité
)