Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Agile Pays Basque 2017 - Ne créez plus un produit inutile! Concentrez vous sur la valeur

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
Lean Startup
Lean Startup
Chargement dans…3
×

Consultez-les par la suite

1 sur 44 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Agile Pays Basque 2017 - Ne créez plus un produit inutile! Concentrez vous sur la valeur (20)

Publicité

Plus récents (20)

Publicité

Agile Pays Basque 2017 - Ne créez plus un produit inutile! Concentrez vous sur la valeur

  1. 1. « Il n’y a rien de plus inutile que de faire avec efficacité quelque chose qui ne doit pas du tout être fait. » - Peter Drucker Ne créez plus un produit inutile! Concentrez vous sur la valeur.
  2. 2. Merci ! Milesker !
  3. 3. Un utilisateur…
  4. 4.  Gratis !  Trop bien !  18 Paquets de BN pour le prix de 19 et le 19eme offert ! Metro – Boulot - Con sot !
  5. 5. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. – principe du Manifeste Agile Crédits photos Antoine Repessé : http://www.antoinerepesse.com/ #ZeroWaste  Fouillis !  Déchets !  Pollution !  Satisfait ?  Plus de moyens financiers  Planète à bout de souffle  Changement de mentalités  En quête de sens
  6. 6. Qu’est ce que la valeur ? Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides. – Henri Ford  Valeur subjectif (un exemple)  Financière ?  Gain de temps ?  Bonheur ?  Valeur financière VS valeur de la VIE
  7. 7. Organisation / La vision
  8. 8. Créez une vision partagée ! Si tu veux construire un bateau, ne rassemble pas tes hommes et femmes pour leur donner des ordres, pour expliquer chaque détail, pour leur dire où trouver chaque chose. Si tu veux construire un bateau, fais naître dans le cœur de tes hommes et femmes le désir de la mer. --St Exupéry  Organisme complexe composé de personnes qui partagent 1 objectif commun  Cassez les silos ! – pas de Taylorisme  Connectez-vous à une vision d’ensemble
  9. 9. 14 points de Deming illustrés : http://qualite--entreprise.blogspot.fr/2011/08/les-14-points-de-deming-illustres.html Alignez-vous sur des valeurs communes!  Culture Lean / TPS  Produit de haute qualité  Collaboration  Amélioration continue
  10. 10.  Quantité /Temps  Culture non soutenable du Héro  Culture de la mesure VS Culture de la valeur  Utilisation maximisée (métier/dev) Culture projet Changez de culture !
  11. 11. Evitez le Water-scrum fall / cycle en Vrum !  Département Planning & budgeting  Go -> process (outsourcing!)  Confiance totale dans la chaine de production (déni du changement)  Couteux et complexe  Crise logiciel 1968 - ONU
  12. 12. Vous obtenez ce que vous mesurez ! Output = résultat Outcome = valeur
  13. 13. Prenez une approche expérimentale !
  14. 14. Prediction is difficult, especially about the future. --Niels Bohr
  15. 15. Identifiez la valeur et améliorez le flux! - A quel moment dans le flux découvre t’on les problèmes ? - Est-ce qu’on est capable de savoir si les fonctionnalités livrées correspondent réellement à la demande client?  Trop de travail (planifié et non planifié)  Peu de valeur client  Empêche d’atteindre ses objectifs personnels  Flux de Valeur (VSM)
  16. 16. Limitez l’en cours !  + tâches parallèles + temps livraison long  Visualiser la VSM et créer un Kanban  Représentation visuelle (en cours et goulot)  Multiprojets > changements de contexte Arrêtez de commencer – commencez par terminer !
  17. 17. Priorisez l’en cours !  Tout en même temps !  Premier arrivé premier servi !  Le plus rapide  Le plus de valeur  Cost of Delay le plus élevé
  18. 18. Laissez vos équipes s’auto-organiser !  Pas de liste de fonctionnalités détaillées  Pas de challenge de tickets  Mais valeurs business et objectifs  Equipes trouvent comment les atteindre  Intelligence collective  Manager = jardinier
  19. 19. Minimisez la distance entre «celui qui fait » et « celui qui utilise »
  20. 20. Donnez-vous du temps pour vous améliorer et pour innover !  Personnes toujours « occupées »  Manque de disponibilité pour l’essentiel  Syndrome du crayon Bic
  21. 21. Votre but est de changer la vie de vos utilisateurs ! Vous êtes leur Le produit
  22. 22. Mettez un visage à vos clients et utilisateurs ! Chaque grande idée que vous transformez en une solution pour un produit change le monde à plus ou moins grande échelle pour les gens qui l’utilisent. Et si ce n’est pas le cas, c’est que vous avez échoué. --Jeff Patton  Persona (problèmes / besoins / comportement)  Infos collectées & vérifiées  Compréhension partagée  Point de départ du job-to-be-done
  23. 23. Allez sur le terrain rencontrer vos utilisateurs ! Le point le plus important à se rappeler au sujet de l’entreprise est qu’il n’y a pas de résultats à l’intérieur de ses murs. Le résultat du business est la satisfaction client. --Peter Drucker  Méthode Lean Startup  Hypothèse et Incertitude  Process itératif & incrémental  Innovation
  24. 24. Concentrez-vous sur les feedbacks ! Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s’adaptent le mieux aux changements. -- Darwin Nous croyons au [développement de cette fonctionnalité] [pour ces personnes] [cette valeur ajoutée] Nous saurons quand nous aurons réussi Quand nous verrons [ce signal émis par le marché] Développement piloté par une hypothèse
  25. 25. Utilisez les Impact Mapping pour valider vos hypothèses ! The difficulty in defining quality is to translate future needs of the user into measurable characteristics, so that a product can be designed and turned out to give satisfaction at a price the user will pay. -- Walter Shewhart
  26. 26. « Est-ce qu’on devrait le faire ? » PLUTOT que : « Est-ce qu’on sait le faire ? » Questionnez-vous ?  YAGNI - You Are Not Gonna Need it  Concentre sur clients pas sur chiffres  Pas de solution « toute cuite » mais un système tiré
  27. 27. Construisez un parcours de questions et non pas une liste de fonctionnalités !
  28. 28. Construisez un parcours de questions et non pas une liste de fonctionnalités !
  29. 29. Créez une Story Map pour raconter l’histoire et le déroulement de votre Vision  Visualisation dans son ensemble  Comprendre les objectifs  Communication narrative
  30. 30. Racontez votre histoire du produit !
  31. 31. Racontez votre histoire du produit !
  32. 32. Ne négociez pas la qualité ! Build the right thing – build it right  MVP : valide hypothèse  Non négociable !  Ingénierie logicielle  Dette technique Le vrai codeur ne teste pas. A la rigueur, ce sont les utilisateurs qui testent. Ou les autres, ceux qui doutent. Mais pas lui. – Commitstrip.com
  33. 33. Déployez en continu !  Organisation hiérarchiques (archaiques)  Col blancs / bleus  Build / run  IT : charges / coût  Organisation performantes  Responsabilise les personnes  Validation rapide des hypothèses  Intégration continue  Déploiement continue  Amélioration continue Les équipes ne deviennent pas agile en adoptant une nouvelle méthodologie, elle sont agile par la volonté de s’améliorer en continue.
  34. 34. Less is more… more or less La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. – Antoine de St Exupéry
  35. 35. Restez frugal ! Il y a toujours plus à créer que nous avons de temps et de ressource à y consacrer. – Jeff Patton  Rythme soutenable  Ne peut avoir une croissance infinie dans un monde fini… https://www.youtube.com/watch?v=3CM_KkDuzGQ
  36. 36. Et n’oubliez pas… Ne créez plus un produit inutile! Concentrez vous sur la Votre travail vise à changer le monde !... … celui de vos utilisateurs  A grand pouvoir… grandes responsabilités !
  37. 37. Quelques questions à se poser… • Savez-vous combien de temps vos équipes passent sur des activités sans valeur ajoutée et à corriger des « anomalies » plutôt qu’à livrer de la valeur? • Connaissez-vous les principales causes de gaspillages (les muda lean)? • Est-ce que vos équipes de développement doivent demander la permission d’investir du temps dans des activités de travail qui réduisent les gaspillages et les activités chronophages à travers le flux de valeur (exemple : build, test, deploiement automatiques, refactoring)? • Est-ce que leur requêtes sont rejetées pour des raisons telles que : « on a pas les budgets » ou « on a pas le temps »? • Combien de temps cela prend-il pour déployer un changement qui implique 1 seule ligne de code ?
  38. 38. Lean Product Manifesto Le Manifeste du Lean Product Management Nous découvrons comment mieux créer des produits de plus grande valeur pour nos clients par la pratique et en aidant les autres à le faire. Ces expériences nous ont amené à valoriser : Les besoins et les problèmes des clients plus que les besoins internes Les expériences basées sur les données plus que des solutions préconçues Les feuilles des route des problèmes des clients plus que les feuilles de route des fonctionnalités La génération d'idées et la collaboration plus que des ordres de fabrication sur le produit Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. http://wiki.ayeba.fr/Le+Manifeste+du+Lean+Product+Management
  39. 39. Nom Objectif Lien Value Stream Map Impact Map Planning stratégique https://gojko.net/2014/11/17/how-to-get-the- most-out-of-impact-mapping/ Story Map Cartographie des jobs-to-be-done http://jpattonassociates.com/user-story- mapping/ Matrice Valeur -Complexité Prioriser les fonctionnalités d’un produit http://wiki.ayeba.fr/La+Matrice+Valeur- Complexit%C3%A9 Lean Canvas Poser l’hypothèse que le produit/marché rentre dans l’hypothèse qui doit être traitée http://leancanvas.com Opportunity Canva Se concentre sur ce qui devrait être fait et pourquoi, aide à comprendre comment satisfaire des clietns spécifiques et des utilisateurs plutôt que la stratégie de l’organisation Http://comakewith.us/tag/opportunity-canvas Value proposition canvas Décrit comment les produits et services créernt des gains clients et comment ils créent des bénéfices face aux attentes des utilisateurs, à leur désir, à leur intérêt d’utilisation http://bit.ly/1v6Z5Ae Trucs et astuces
  40. 40. De la lecture… 5e édition

Notes de l'éditeur

  • J’aimerai commencer cette présentation par une citation de Peter Drucker qui a été le point de départ de ma réflexion. –
    « Pape du management » moderne et qui a fondé le management par objectifs.
    - Son idée c’est de donner libre cours à l’énergie et à la responsabilité individuelle.

    J’ai choisi de garder la citation en guise de titre, et le titre en guise de sous-titre, ce qui est le plus pertinent à mon sens.
  • Artisan agiliste
    Même pensée que les craftman - notion d’artisanant, de cas à cas.
    Non reproductibel – pas de copier coller ds les accompagnement
    On grandit grace à l’experience, on apprend de ses erreurs
    Prez me reflète un peu : apprendre sketchnote, prends des risque car pas parfait , moins joli que si tout est numérisé mais vivant– soyez bienveillants et indulgents

    A vous de deviner si les 2 persos qui sotn là sont la représentation de mes enfants ou des personnes que j’accompagne
  • On rencontre tous les jours des produits qu’on a pas demandé mais qu’on nous livre quand même, des fonctionnalités qui nous sont pas utiles, qu’on nous offre (à grand coup d’agressions publicitaires special offer – discount), qui ne servent « à rien » (dans ce cas, occupe de la place sur la table), génère du gaspillage (ne sera pas consommé).
     
    Exemple : les paquets de BN vendus pas lots de 5 alors qu’on a 2 enfants
    Les promos achetez 3 jeans pour le prix de 2 > génère du gaspillage, prennent de la place, remplissent les placards.
  • Au final on se retrouve dans un fouillis de fonctionnalités et de produits inutiles, de « déchets » qui polluent les fonctionnalités qui servent réellement.
     
    Aujourd’hui on a besoin de l’Agilité et du Lean car les entreprises n’ont plus les moyens de développer un produit qui ne sert plus à rien ni à personne. Dans un contexte de 30 glorieuses tout se vendait à n’importe qui. C’était l’époque florissante de l’industrie et l’informatique. Aujourd’hui même l’Etat vit au-dessus de ses moyens, c’est pour ça que l’agilité a autant le vent en poupe.

    Ce n’est pas une question de mode, c’est une question de génération qui change. Tant au niveau du top-down, côté management qu’au niveau du bottom-up (nouvelle génération) qui ne veulent plus exécuter des ordres sans trop savoir pourquoi et se faire lourder ensuite par des des actionnaires pour des raisons de profit. Qui recherchent une certaine liberté, une confiance et un engagement.

    Photos Antoine Repessé : http://www.antoinerepesse.com/
  • « Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides »
  • C’est l’anti pattern des silos ou il y a ceux qui vendent le produit, ceux qui rédigent les specs, ceux qui codent (souvent au bangalore, car là-bas la « maçonnerie » est moins cher, ceux qui testent, etc. Du coup les personnes s’occupent de leur ticket, id dans un tableur excel et sont complètement déconnectés de la vision globale ou de l’ensemble du projet. Ils ne savent pas comment leur travail sera utilisé ni s’il le sera un jour (perte de motivation).

    P.14 Une entreprise est un système complexe dont le comportement ne peut être réduit à une approche Tayloriste qui découpe chaque composante pour l’analyser
    Quelle est la raison d’être d’une entreprise ? C’est un organisme complexe composé de personnes qui partagent un objectif commun.

    CF AMAZON - REnault
  •  La raison d’être d’un manager est d’aider les employés à avoir le pouvoir de « stopper la ligne de production » (principe des entreprises Toyota ou n’importe qui peut arrêter la chaine.

    Comment la culture Lean, la culture Toyota à l’origine fonctionne ?

    En créant une culture ou chacun est aligné sur l’objectif de construire un produit de très haute qualité et ou les travailleurs et managers collaborent ensemble pour s’améliorer de façon continue. C’est le principe du Kaizen qui fonctionne sur l’alignement et l’autonomie à tous les niveaux.

    Et oui une entreprise Lean est essentiellement un système humain et non pas cette notion « moderne » et déformée qui considère les salariés comme une « charge » et un coût.

    Partagez une culture et des valeurs !
  • Malheureusement à ce jour la culture projet juge les gens en fonction de si leur travail est réalisé dans les temps et dans les budgets et non sur la valeur livrée aux clients. La productivité est mesurée sur l’output (la quantité) et non le outcome (anecdote Jira Canada et Pascal).
     
    Les gens du métier sont donc jugés sur leur capacité à rédiger des documents (spécifications), des business cases et non sur la valeur livrée aux utilisateurs finaux; les développers sont jugés sur les lignes de codes poussées dans leur gestionnaire de code source et non sur l’intégration d’une fonctionnalité robuste et son usage sur du long terme.
     
    On créée une culture non soutenable du hero qui est félicité si son utilisation est maximisée (heures supp) plutôt que de s’assurer qu’en en faisant moins on va livrer plus de valeur On s’assure de maintenir les gens « occupés à leur tâche « 150 mails par jour », dépilage de tickets trello, etc.
     
    Dans les organisations malades et bureaucratiques c’est la culture de la mesure qui est utilisée comme forme de contrôle.
     
    Y’a pleins de gens sceptique quand on les forme ou on les déforme (car après tout cela fait souvent 10 ans qu’ils font du management) qui pensent que le Lean et l’Agilité ne peut pas s’appliquer chez eux à cause de cette culture.
    https://www.amazon.com/p/feature/p34qgjcv93n37yd
     
    Comment ce type de culture s’exprime ? Théorie du crayon bic
  • Dans un contexte entreprise, le travail planifié est généralement priorisé un travaers un departement centralisé type « planning and budgeting ». Les projets ayant obtenu le « go » (le saint graal) filent à travaers un certains nombre de process de développement avant d’être livré. Même dans les organisations qui ont adopté des pratiques agiles de développement la value stream (le flux de valeur) ressemble souvent à du water-fall ou à du Vrum (dixit Claude Aubry). Dans le cas ou certaines phase de la vie du produit sont outsourcé, d’autres process s’ajoutent.

    Le probleme de ses process est tellement couteux et complexe qu’il a été posé dans un paradigme exposé en 1968 à l’ONU lors de la crise du logiciel. Le paradygme de l’époque reposait sur des cycles qui faisaient que le produit ne pouvait pas livrer de la valeur avant sa livraison, à la fin de sa vie dans le cycle industriel. On avait une confiance total en amont de la chaine de production que rien ne changerait ds les spécifications initiales.

    Aucune de ces pratiques ne peuvent survivre à ce jour à développement logiciel dont la force repose sur le prototypage rapide et peu cher et sur les changements fréquents qu’on peut y apporter. En particulier dans le fait qu’on est si souvent dans le faux en ce qui concerne l’utilisation du produit
  • Les recherches ont montré que le paradoxe de la recherche absolue de profit diminue le ROI contrairement aux entreprises qi ont du succès en développant sur du long terme leur capacité d’innover, de s’adapter et de se concentrer sur leurs employés, leurs clients et leurs produits.
  • Aucun plan ne survit au premier contact avec l’ennemi
  • noyées sous le travail,
    peu de valeur au clients.
    tâches plannifiées et non plannifié
    chacun
    empecher d’atteindre leur objectif personnel.

    Vous pouvez pallier cela en cartografiant le flux de valeur : Value Steam Map (exemple du supermarché). L’idée est de cartographier de la demande client, jusqu’à la livraison tout le flux de valeur


    La value stream s’accompagne d’un certain nombre de questions:
    A quel moment dans le flux découvre t’on les problèmes ?
    Est-ce que’on est capable de savoir si les focntionnaltiés livrées correspondent réellement à la demande client,

  • Plus on a des projets/tâches en parrallèles, plus cela prendra du temps sur la livraison.
    Je vous encourage à visualizer les dynamiques de la value stream en créant un Kanban board qui représente pour chaque étape l’encours, les goultos d’étranglement.
    A quoi sert à la limite ? A s’imposer de terminer : « stop starting – start finishing »
    Dans les entreprises, un indicateur de multitache (too much WIP) est le nombre de personne assignées à plus d’un projet. Cette pratique pernicieuse mène inévitablement à des lead-time qui sotn plus long et baisse la qualité en raison du « context swwitching ».


  • Partons du postulat qu’on a 2 fonctionnalités hyper prioritaires à développer (oui car totu est prioritaire). La queestion à se poser est : quel est le cout que nous devrons assumer si on ne développe pas cette focntionnalité. Exemple perte sèche de 10 000€ par semaine (lié à des pénalités, manque à gagner, etc).
    Si n fait comme on a l’habitude de faire c’est à dire commencer les 2 focntionnalités simultanément (parce que totu est prioritaire) alors on va prendre du retard dans les 2 cas (liés au multitasking)
    Schéma P. 149
    Le cost of delay est une métrique intéressante qui aide à prioriser. Au lieu de prioriser par valeur, on s’interroge sur le coût que va couter la livraison en retard de la focntionnalité.
  • On vient de parler de comment améliorer la boucle de feedback et accélérer la livraison de valeur, on va se concentrer maintenant sur l’alignement. Comment s’assurer qu’on a réalisé le bon produit pour les bon utilisateurs et pour l’organisation.

    L’innovatin s’oppose à l’idée de venir avec une liste de requirements/focntionnalités, de les stocker dans un backlog et de demander à l’équipe de les dépiler.Au contraire, on s’attache à décrire en terme de valeur business l’objectif à atteindre pour chaque itération. C’est aux équipes de trouer des idées sur comment achever ces objectifs, construire, tester, builder, etc.

    De cette façon, on exploite toute l’inttelligence de chacun à trouver une façon ingénueuse et géniale de résoudre le problème avec le moins de gaspillage possible. Les équipes se concentrent sur la valeur à livrer plutot que sur des mesures (nb de stories traitées, véolcité, lignes de code produites, heures travaillées, etc;)

    L’objectif est de minimiser l’OUTPUT et de maximiser l’OUTCOME. Le moins de ligne de code on produit, le plus rapidement on livre de la valeur, le mieux c’est si on atteint les objectif fixés.

    Les centrales à gaz, les systèmes complexes, le personnel en burn-out sont des symptomes de focalisations sur l’output plutot que sur l’outcome.
  • L’optimisation du temps des collaborateurs et le fait de maintenir toujours les gens occupés côute que coûte implique que la collaboration prends plus de temps.
    Et oui, les gens ont la tête sous l’eau et ne sont pas disponibles! Donc du coup ils n’ont pas le temps de se concentrer sur l’essentiel. C’est souvent le cas pour les approches XP, de bonnes pratiques d’ingénierie logiciel (avec les Test et l’intégration continue).
    C’est bien connu que Le vrai codeur ne teste pas. A la rigueur, ce sont les utilisateurs qui testent. Ou les autres, ceux qui doutent. Mais pas lui.

    TODO . P.34 voir si on eut le proposer
  • Expliquer la différence entre cleints et utilisateurss
    Un persona est la représentation de leur pb, besoins, comportements d’un gourpe hypothétique d’utilisateurs. Les persona sotn basés sur des infos collectées et vérifiées. C’est le point de départ d’une alignement et d’une compréhension partagée de la cible pour totue l’équipe. Ce sont des personages ficitfs mais représentatifs qui permettent de créer de l’empathie envers le groupe cible et ses problèmes à résoudre et de déplacer la conversion du pojnt initial : quelles seraient mes préférences personnelles à la question : quelle valeur va t’on livrer à ce persona, le job-to-be-done

    TODO : outil : empathy map
    P.76 : the pb statement canvas

    Chaque grande idée que vous transformez en une solution pour un produit change le monde à plus ou moins grande échelle pour les gens qui l’utilisent. Et si ce n’est pas le cas, c’est que vous avez échoué. Jeff Patton

  • P.15 schema
    Dans la méthode Lean Startup, on utiilise une approche systémique pour travailler dans un process iteratif.
    Principe d’hypothèse. On pense que et on va aller la valider sur le terrain pour voir si on a raison ou pas…
    Le paradoxe du leean development est qu’il requiert de la variation et de l’incertitude mais il repose sur des méthodes de travail standardisées pour formuler les hypothèses de l’innovationet les expérimenter de façon répétable afin de minimiser le gaspillage et la perte de temps alors qu’il maximise la valeur et la créativité.
    P.71 proposer des outis : lean canvas / opportunity canvas value proposition canvas / business model canvas


    Outil : carte des impact et comment on l’utilise
    P.90 : vanity metric / P92 Pirate metric
  • Gojko Adzic nous présente la technique d’impact mapping poour tester des hypothèses
    http://wiki.ayeba.fr/Dessiner+des+cartes+d%27impacts


    But Le centre d'une carte d'impacts répond à la plus importante des questions : Pourquoi faisons-nous cela ? C'est le but que nous souhaitons atteindre. Acteurs La première branche d'une carte d'impacts fournit des réponses aux questions suivantes : Qui peut générer l'effet désiré ? Qui peut l'empêcher ? Qui sont les consommateurs et utilisateurs de notre produit ? Qui sera impacté par le produit ? Ce sont les acteurs qui peuvent influencer le résultat. Impacts La branche de second niveau d'une carte d'impacts positionne les acteurs en fonction du but métier. Elle répond aux questions suivantes : Comment les comportements de nos acteurs pourraient-ils changer ? Comment peuvent-ils nous aider à atteindre le but ? Comment peuvent-ils nous empêcher d'atteindre le but ? Ce sont les impacts que nous cherchons à créer. Livrables Une fois que nous avons répondu à ces trois questions, nous pouvons discuter du périmètre. La branche de troisième niveau de la carte d'impacts répond à la question suivante : Que pouvons-nous faire, en tant qu'organisation ou équipe de production, pour encourager les impacts désirés ? Ce sont les livrables, les fonctionnalités logicielles et les activités organisationnelles.
  • Une des question à se poser est est-ce qu’on DEVRAIT le faire et non pas est-ce qu’on peut/sait le faire. En effet le but du développement de produits n’est pas de fabriquer des produits!
    Principe YAGNI en XP
    Ce qui se passe souvent ds les organisations c’est qu’on tendance à collecter des « vanity metrics » qui ont pr seul objectif de nous conforter dans nos opinions mais qui n’offrent pas de guidance claire sur les actions à prendre. Exemple de « vality metrics » : nb de visite sur un site web est ce que c’est une seule personne qui a visité le site 100 fois ou 100 personnes qui ont visité une seule fois? Il faut au contratire tracker l’usage et le cycle de vie du site. Number of downloads versus utilisation du download.
    Le problème est qu’on a tendance à mesurer ce qui est facielemtn mesurable (en fait ce qu’one st capable de mesurer) mais pas ce qui importe le plus (cf. pirate metrics)
    L’idée est de construire une/des solutions robustes pour répondre aux demandes à la volée. Les objectifs doivent être vus comme un « pull system » pour des clients qui veulent le service/outils/produit que l’on propose et non pas un system de push mandaté, plannifié et une solution « toute cuite » que des gens doivent vendre ou leur imposer. (cic shéma des cours kanban pull/push system)

    En se concentrant sur les client et non plus en chassant des chiffres (« vanity numbers ») on se force à faire du KISS et à maintenir un contact de proximité avec les clients. Rappelez vous attendre des gros chiffres n’est pas une fin en soi; par contre répondre aux attentes et enchanter les clients en est une.
    P.79
  • Qd on commence un produit, d’instincs les équipes commencent à construire une liste de spécifications pour un produit scalable (qui grossisse très vite – soyons ambitioneux!) avec la liste exhaustive de toutes les fonctionnalités et des dates de livraisons. Le danger avec cette approche est de se priver de l’évolution et ajustement possible grâce aux feedback des utilisateurs. Dans les premières phases du lancement, on apprend on ne gagne pas d’argent. C’est donc important de limiter l’engagement des personnes, du temps et de l’argent à ne pas faire de fonctionnalités inutiles ou qui ne produirait pas la valeur attendue. On doit accepter que tout est hypothèse à tester, valider dans un monde inertain oou il faut apprendre constamment.
    Notre priorité est donc une liste d’hypothèses à tester plutot qu’une liste de requirements à construire.
    Il est malheureusement trop fréquent de s’éloigner de cette pensée et d’envoyer bcp de features (le tri se fera totu seul, plus y’en a mieux c’est), ce qui amène à un profond niveau de complexité, des couts de développemetns et de maintenance, et des difficultés à changer de scope, à pivoter. Rappelez vous le nombre de featrues livrées ne sont aps des mesures de succès, les valeurs livrées le sont!
  • Qd on commence un produit, d’instincs les équipes commencent à construire une liste de spécifications pour un produit scalable (qui grossisse très vite – soyons ambitioneux!) avec la liste exhaustive de toutes les fonctionnalités et des dates de livraisons. Le danger avec cette approche est de se priver de l’évolution et ajustement possible grâce aux feedback des utilisateurs. Dans les premières phases du lancement, on apprend on ne gagne pas d’argent. C’est donc important de limiter l’engagement des personnes, du temps et de l’argent à ne pas faire de fonctionnalités inutiles ou qui ne produirait pas la valeur attendue. On doit accepter que tout est hypothèse à tester, valider dans un monde inertain oou il faut apprendre constamment.
    Notre priorité est donc une liste d’hypothèses à tester plutot qu’une liste de requirements à construire.
    Il est malheureusement trop fréquent de s’éloigner de cette pensée et d’envoyer bcp de features (le tri se fera totu seul, plus y’en a mieux c’est), ce qui amène à un profond niveau de complexité, des couts de développemetns et de maintenance, et des difficultés à changer de scope, à pivoter. Rappelez vous le nombre de featrues livrées ne sont aps des mesures de succès, les valeurs livrées le sont!
  • Le story Mapping est un outil développé par Jeff Patton (aniamtion cube and go) et expliqué dans un livre.
    L’idé est que votre produit a un squelette et une colonne vertebrale (sketchnote : suqelette) et la carte le montre .

    La story map aide à planifier et prioriser les focntionnalité en visualisant al solution dans son ensemble. Attention le story mapping n’a pas pour objet de générer des storyes ou de créer n release plan. Son but est de bien comprendre les objectifs des clients et les jobs-to-be-done. C’est une outil de communication anrrative de la solution qui permet d’engager les équipes et les parties prenantes (stakeholders) et d’obtenir leur feedback.
    En parcourant la carte des stories et en racontant l’histoire de la solution, on s’assure qu’on a aps manqué d’éléments importants. Parrallèlement on maximize l’apprentissage en identifiant les prochains risques et hypothèses à valider en minimisant le gaspillage et l’overengineering de la solution qui ne correspondraient pas aux besoins utilisateurs et au MVP. Rappelez vous on doit avoir de l’empathie pour nos utilisateurs , ressentir leurs besoins, leurs douleurs.

    Comment ça se construit ? C’est très simple, je décris l’histoire d’un produit en listant (avec des post-its) chaque grande étape que les utilisateurs identifient dans le flux. Ensuite on revient sur les détails de chaque étape et on en discute.
  • Pourquoi on parle de Story Mapping (de carto d’histoire) ? D’US (histoires utilisateur) ?
    Par exemple si je vous montre cette photo, que voyez vous?
    Moi je vois…
    Bien entendu si vous regardez seulement la photo vous ne saurez pas totu ça car vous n’étiez pas là. Je me souviens de tout ça car j’étais présente. C’est la manière dont les documetns focntionnent en réalité. Si vous relisez un CR de réunion et que vous y étiez, vous allez vous rappeler la discussion mouvementée entre 2 personne, les échanges qu’il y a eu etc. La compréhension mutuelle et le face à face sont bourrés de détails qui ne figurent pas ds la meilleure spec de la création. Les docs aident à se souvenir, mais Pour partagez une spécification, réunissez-vous et discutez!
  • Pourquoi on parle de Story Mapping (de carto d’histoire) ? D’US (histoires utilisateur) ?
    Par exemple si je vous montre cette photo, que voyez vous?
    Moi je vois…
    Bien entendu si vous regardez seulement la photo vous ne saurez pas totu ça car vous n’étiez pas là. Je me souviens de tout ça car j’étais présente. C’est la manière dont les documetns focntionnent en réalité. Si vous relisez un CR de réunion et que vous y étiez, vous allez vous rappeler la discussion mouvementée entre 2 personne, les échanges qu’il y a eu etc. La compréhension mutuelle et le face à face sont bourrés de détails qui ne figurent pas ds la meilleure spec de la création. Les docs aident à se souvenir, mais Pour partagez une spécification, réunissez-vous et discutez!
  • Jusqu’alors l’idée est de créer rapidement des MVP et de valider l’hypothèse. Est-ce que cela est compatible avec la notion de qualité ? OUI en lean et agile la qualité est non négociable !l Des pratiques d’ingénierie logicielle agile sont plus que recommandées (quadrant de test de Martin Fowler)
    On parle de dette technique. La dette technique est une métaphore empruntee au système bancaire. On peut la contracter volontairement mais après il faut la maîtriser. Ce qui veut dire avec de bonnes pratiques de test (TDD obligatories, avoir une bonne architecture, avec du code modulable). Le code bouge, il est vivant comme le produit. Il faut donc limiter les effets de bords, les dommages collatéraux quand on ajuste le cycle de vie du produit.

    Quadrant de test de Martin Fowler + commit strip tester c’est douter
  • Ds bcp d’entreprises, on distingue ceux qui build et ceux qui run les logiciels (l’IT) et ceux qui décident ce que le logiciel doit faire et qui fotn les décisions d’investissement (le Métier). Ce sont les reliques d’une époque ou l’IT était considéré comme uncout ou des charges qui servait à réaliserles demandes métier et non pas des personnes qui crééent de la valeur pour des clients finaux.

    Cet héritage colle aux organisations et est associés avec la hiérarchie, le mindset et le relationnel. Dans les organisation performantes, on supprime ces distinctions et on retrouve des gens sui design, build et run l’intégratité du produitet en acceptent la restponsabilité à l’égard des clients et utilisateurs. « You build it, you run it »; autrement dit « you eat your own dog food ».
    Cela demande des pratiques d’ingénierie telles que l’intégration continue, et l’investissement dans des tests automatisés. Autrement il est impossible de poser des hypothèses et de les valider rapidement.
    C’est l’ADN de l’agilité. Les équipes ne deviennet pas agile en adoptant une nouvelle méthodologie, elle sont agile par la volonté de s’améliorer en continue.
  • Rythme soutenable
    On en peut avoir une croissance infinie dans un monde fini…

  • P.71 à mettre en annexe ?

×