La Livraison Agile Disciplinée (Disciplined Agile Delivery – DAD) : le cycle de vie Exploratoire

Le Cycle de vie Exploratoire de DAD

• Le cycle de vie Exploratoire de DAD est basé sur les principes du Lean Startup prônés par Eric Ries.
  • Voir figures pages 94 et 95
• La philosophie du Lean Startup est de minimiser les investissements initiaux dans le développement de nouveaux produits/services (offres) sur le marché en faveur de petites expériences.
  • L’idée est de mener des expériences avec des clients potentiels pour identifier ce qu’ils veulent en fonction de l’utilisation réelle, augmentant ainsi nos chances de produire quelque chose qui les intéresse réellement.
  • Cette approche consistant à exécuter des expériences en contact direct avec les clients pour explorer les besoins des utilisateurs est une stratégie de réflexion conceptuelle importante pour explorer les « problèmes épineux » dans votre domaine.

Aspects

• Il s’agit d’une méthode scientifique simplifiée.
• La notion de MVP
  • Nous élaborons une hypothèse sur ce que veulent nos clients, nous développons un ou plusieurs produits minimum viables (Minimum Viable Product – MVP) qui sont déployés auprès d’un sous-ensemble de clients potentiels, puis nous observons et mesurons leur fonctionnement avec le ou les MVP.
    • Voir figure 6.11 Exploration de la terminologie autour des MVP page 96
    • Sur la base des données que nous collectons, nous décidons comment nous allons avancer.
      • Faisons-nous pivoter et repenser notre hypothèse ?
      • Retravaillons-nous un ou plusieurs MVP pour exécuter de nouvelles expériences basées sur notre meilleure compréhension des besoins des clients ?
    • Écartons-nous une ou plusieurs idées ?
    • Allons-nous de l’avant avec une ou plusieurs idées et les « transformons-nous » en véritables offres clients ?
  • Les MVP sont des investissements dans l’apprentissage.
    • Les MVP que nous créons sont construits à la hâte, souvent “smoke and mirrors” ou code de qualité prototype, dont le seul but est de tester une hypothèse.
    • Ce n’est pas la “vraie chose”, et ce n’est pas censé l’être.
    • C’est une fonctionnalité ou une offre de service que nous présentons à nos clients potentiels pour voir comment ils y réagissent.
• Exécutez plusieurs expériences en parallèle.
  • Idéalement, ce cycle de vie implique de mener plusieurs expériences en parallèle pour explorer notre hypothèse.
  • Il s’agit d’une amélioration par rapport au Lean Startup, qui se concentre sur une seule expérience à la fois – bien qu’il soit plus facile d’exécuter une seule expérience à la fois, il faut plus de temps pour arriver à une bonne idée et, pire encore, il risque d’identifier une stratégie avant que d’autres options aient été envisagées.
• Les expériences ratées sont toujours des réussites.
  • Certaines organisations hésitent à mener des expériences parce qu’elles craignent d’échouer, ce qui est regrettable car une approche exploratoire comme celle-ci réduit en fait le risque d’échec du produit (qui a tendance à être important, coûteux et embarrassant).
  • Notre conseil est de rendre « sûr d’échouer », de reconnaître que lorsqu’une expérience a un résultat négatif, c’est un succès parce que vous avez appris à peu de frais ce qui ne fonctionnera pas, ce qui vous permettra de vous recentrer sur la recherche de quelque chose qui fonctionnera.
• Suivez un autre cycle de vie pour créer le produit réel.
  • Une fois que nous avons découvert une ou plusieurs idées qui, semble-t-il, réussiront sur le marché, nous devons maintenant construire la « vraie solution ».
  • Nous le faisons en suivant l’un des autres cycles de vie DAD.

Adaptation

• Exploration d’une nouvelle offre.
  • La raison la plus convaincante, du moins pour nous, est d’appliquer ce cycle de vie pour explorer une idée que votre organisation a pour un nouveau produit.
• Exploration d’une nouvelle fonctionnalité.
  • À plus petite échelle, le cycle de vie exploratoire est en fait la stratégie pour exécuter un test A/B ou un test fractionné où vous implémentez plusieurs versions d’une nouvelle fonctionnalité et les exécutez en parallèle pour déterminer celle qui est la plus efficace.
• Preuves de concept (Proof of Concept – PoC) parallèles.
  • Avec un PoC, vous installez puis évaluez un package, parfois appelé une solution commerciale prête à l’emploi (COTS), dans votre environnement.
  • Un moyen efficace de réduire le risque d’acquisition de logiciels consiste à exécuter plusieurs preuves de concept en parallèle, une pour chaque progiciel potentiel que vous envisagez, puis à comparer les résultats pour identifier la meilleure option disponible.
    • C’est ce qu’on appelle souvent un “bake-off (concours de pâtisserie)”.
• Comparaisons de stratégie.
  • Certaines organisations, en particulier celles qui évoluent dans des environnements très concurrentiels, vont démarrer plusieurs équipes dans un premier temps pour travailler sur un produit.
  • Chaque équipe travaille essentiellement sur la phase démarrage (Inception), et peut-être même un peu sur la phase construction (Construction), le but étant d’identifier une vision du produit et de prouver sa stratégie architecturale.
    • Dans ce cas, leur travail est plus avancé qu’un MVP mais moins avancé qu’un (Minimum Business Increment – MBI).
  • Puis, après un certain temps, ils comparent le travail des équipes et choisissent la meilleure approche : « l’équipe gagnante » peut avancer et devenir l’équipe produit.

Créé le 27/12/2022.