« Design Thinking (SAFe) » : différence entre les versions

(27 versions intermédiaires par le même utilisateur non affichées)

Ligne 2 :

[[Catégorie:Portail Product Owner]]

[[Category: SAFe]]

[[Category: Design Thinking]]

[[Category: Empathie]]

Source : [https://www.scaledagileframework.com/design-thinking/ Design Thinking]<br/>

Ligne 52 :

Ligne 54 :

<br/>

En revanche, dans un marché de clients indirects, ce qui est courant dans les solutions B2C, les équipes produits doivent trouver un moyen de maintenir un lien avec leur client cible. Elles développent donc des "personas", des consommateurs et/ou utilisateurs fictifs issus d'études de marché [2]. Ces personas décrivent les différentes personnes susceptibles d'utiliser un produit ou une solution de manière similaire, ce qui permet de comprendre comment les utilisateurs réels se comporteraient avec une solution. Les user personas étayent également la stratégie de segmentation du marché en offrant un outil de conception concret pour renforcer le fait que les produits et les solutions sont créés pour des personnes. Les personas sont le moteur du développement de produits et de plusieurs pratiques SAFe, comme le montre la figure 3.<br/>

[[Fichier:Design Thinking F03 WEB.png|border|center|link=]]

[[Fichier:Design Thinking F03 WEB.png|border|650px|center|link=]]

<div style="text-align: center;">'''Figure 3. Les Personas dirigent les activités clés de SAFe.'''</div>

En plus des user personas, les ''buyer'' personas étendent le design thinking pour inclure les personnes et les organisations qui décident des achats. Elles permettent de s'assurer que la conception englobe l'ensemble de l'expérience d'achat du produit, y compris le service après-vente, le support et les opérations.

===Développer l'empathie grâce aux cartes d'empathie===

Les entreprises orientées client font preuve d'empathie tout au long du processus de conception. De manière générale, la conception empathique ignore les idées préconçues et s'appuie sur le point de vue du client pour élaborer des solutions.<br/>

<br/>

Les cartes d'empathie [1] sont un outil de design thinking qui favorise l'identification du client en aidant les équipes à développer une compréhension profonde et partagée des autres (figure 4). Elles aident les équipes à imaginer ce qu'un persona spécifique pense, ressent, entend et voit lorsqu'il utilise le produit. Plus le degré d'empathie d'une équipe pour son client est élevé, plus l'équipe sera en mesure de concevoir une solution souhaitable.<br/>

[[Fichier:Word-image-35.png|border|center|link=]]

[[Fichier:Word-image-35.png|border|center|800px|link=]]

<div style="text-align: center;">'''Figure 4. Canevas de Carte d'Empathie.'''</div>

===Concevoir l'expérience client grâce aux cartes de parcours===

Une ''carte du parcours client'' illustre l'expérience d'un utilisateur qui s'engage dans le [https://www.scaledagileframework.com/operational-value-streams/ flux de valeur opérationnel], les produits et les services d'une entreprise. Comme le montre la figure 5, les cartes de parcours sont de puissants outils de conception pour les flux de valeur opérationnels. Elles permettent aux équipes d'identifier les moyens d'améliorer les livrables spécifiques d'un ou plusieurs [https://www.scaledagileframework.com/development-value-streams/ flux de valeur de développement] afin de créer une meilleure expérience de bout en bout.<br/>

[[Fichier:Operational Value Streams F07 WEB.png|border|center|800px|link=]]

<div style="text-align: center;">'''Figure 5. Flux de valeur opérationnels et cartes du parcours du client.'''</div>

===Offrir des avantages grâce aux fonctionnalités===

Alors qu'une carte du parcours capture l'expérience à haut niveau du client à travers le flux de valeur opérationnel, les fonctionnalités du produit gèrent les livrables spécifiques qui répondent aux besoins d'une partie prenante. Les fonctionnalités sont généralement décrites par le biais d'une matrice des fonctionnalités et des avantages, à l'aide de phrases courtes qui fournissent un contexte et une hypothèse sur les avantages dont bénéficie l'utilisateur.<br/>

<br/>

Les pratiques de design thinking favorisent le changement de l'ordre dans lequel nous considérons les éléments de l'hypothèse fonctionnalités-avantages. Elles aident les équipes Agile à explorer de meilleures façons, plus rapides, d'offrir les avantages souhaités (figure 6).<br/>

[[Fichier:Design-Thinking F06 WEB-4.png|border|center|800px|link=]]

<div style="text-align: center;">'''Figure 6. La matrice traditionnelle "fonctionnalités et avantages " devient une matrice "avantages et fonctionnalités ".'''</div>

===Concevoir des workflows pour les utilisateurs grâce aux Story Maps===

Les fonctionnalités sont mises en œuvre par le biais d'une ou plusieurs Stories. Il existe deux types de stories dans SAFe :

* Les '''User Stories''' sont le principal moyen d'exprimer les fonctionnalités nécessaires. Elles peuvent être écrites dans un format de rôle ou de persona :

** '''Rôle''' : En tant <rôle utilisateur> Je veux <activité/but> Afin de <une raison telle que. créer de la valeur métier ou de la valeur pour l'utilisateur>.

** '''Persona''' : Frank veut <activité/but> afin que Franck obtienne <valeur>

* Les '''Enabler Stories''' recueillent les exigences en matière de système, d'architecture ou d'infrastructure, telles que les améliorations à apporter pour prendre en charge le pipeline de livraison continue.

Le Team Backlog contient des User et des Enabler Stories qui proviennent du Program Backlog, ainsi que des stories qui sont issues du contexte local de l'équipe. Comme tous les backlogs, le Team Backlog est priorisé, et les stories sont implémentées par ordre de priorité.<br/>

<br/>

Les fonctionnalités qui mettent en évidence un workflow constituent un défi unique pour les équipes Agile : un workflow est une séquence d'étapes qui doivent être réalisées pour accomplir un objectif utilisateur de plus haut niveau. L'ordre linéaire d'un backlog peut empêcher les équipes Agile de comprendre les relations entre les étapes. Souvent, une étape donnée peut être améliorée, et les équipes doivent également trouver un équilibre entre la complétude (toutes les étapes doivent être prises en charge) avant d'améliorer un ensemble spécifique d'étapes. Des conflits potentiels apparaissent lorsque la phase divergente de développement d'une solution prévoit des possibilités d'amélioration, tandis que la phase convergente de design thinking se concentre sur ce qui est essentiel pour la prochaine version.<br/>

<br/>

Les solutions contiennent à la fois de grands et de petits workflows. Considérons le modeste workflow d'un homme d'affaires qui importe un relevé de carte de crédit dans un système de déclaration de frais pour qu'il soit traité. L'utilisateur doit :

* Télécharger le relevé de carte de crédit depuis la banque

* Télécharger le relevé de carte de crédit dans le système de gestion des frais.

* Faire correspondre les transactions du relevé de carte de crédit avec les reçus de dépenses stockés dans le système de gestion des frais.

* Supprimer toute transaction non remboursable

Comme décrit précédemment, chacune de ces stories peut être appréhendée dans un workflow. De plus, chacune peut être améliorée au fil du temps : nous pourrions, par exemple, imaginer une connexion directe entre la banque et le système de gestion des frais, ou un agent d'IA automatisé qui gère la tâche de rapprochement des transactions.<br/>

<br/>

Les fonctionnalités qui représentent un workflow sont recueillies par le biais de story maps [3], qui organisent une séquence de stories en fonction des tâches dont un utilisateur a besoin pour atteindre son objectif (Figure 7).<br/>

<br/>

[[Fichier:Design-Thinking F07 WEB.png|border|center|800px|link=]]

<div style="text-align: center;">'''Figure 7. Exemple de Story Map.'''</div>

<br/>

Les story maps permettent aux équipes de comprendre comment les stories du backlog de l'équipe soutiennent les objectifs des utilisateurs (Figure 8).<br/>

[[Fichier:Design-Thinking F08 WEB.png|border|center|800px|link=]]

<div style="text-align: center;">'''Figure 8. Relation entre les Story Maps et les Team Backlogs.'''</div>

<br/>

Les Story Maps clarifient également les relations entre la qualité et la valeur :

* '''Qualité''' - Chaque Story dans le backlog doit être terminée avec qualité.

* '''Valeur''' - Toutes les stories sélectionnées dans la Story Map doivent être terminées pour créer de la valeur, car si une story est négligée, l'utilisateur ne peut pas terminer son travail.

===Augmenter le retour d'information sur le design grâce aux prototypes===

Un prototype est un modèle fonctionnel de la Fonctionnalité ou du Produit que l'on souhaite construire. Il aide l'équipe de conception à clarifier sa compréhension du problème et réduit les risques liés à l'élaboration d'une solution. Les prototypes offrent une myriade d'avantages aux équipes chargées des produits :

* '''Retour d'information rapide.''' Par définition, un prototype est moins cher et plus rapide à produire qu'une solution complète. Cela permet un retour d'information plus rapide de la part des utilisateurs et des clients, une meilleure compréhension des exigences de la solution et une plus grande confiance dans les conceptions finales.

* '''Réduction des risques.''' Les prototypes peuvent réduire le risque technique en permettant aux équipes Agile de porter leurs efforts initiaux sur les aspects de la solution qui présentent le plus de risques.

* '''Propriété intellectuelle / dépôt de brevet.''' Les prototypes peuvent être utilisés pour satisfaire aux exigences stratégiques de gestion de la propriété intellectuelle le plus tôt possible dans le processus de développement.

* '''Modèles pour les exigences.''' Les prototypes peuvent fournir plus de clarté dans les exigences de la fonctionnalité ou de la solution souhaitée que des pages de documentation.

<br/>

Il existe de nombreux types de prototypes, chacun étant destiné à fournir différents types d'informations :

* '''Les prototypes bas niveau (lo-fi) papier''' sont généralement des esquisses dessinées à la main de la solution envisagée. Ils peuvent être automatisés pour illustrer les workflows en tant que compléments aux user story maps.

* '''Les prototypes moyen niveau (mi-fi)''' sont des représentations visuellement complètes de solutions centrées sur le logiciel mais ne sont généralement pas intégrés fonctionnellement.

* '''Les prototypes haut niveau (hi-fi)''' sont des modèles visuellement achevés et interactifs que les utilisateurs et les clients peuvent explorer en direct.

* '''Les prototypes matériels''' fournissent un retour d'information critique à l'équipe Agile sur des éléments tels que les facteurs de forme, les tailles et les exigences opérationnelles. Par exemple, lors de l'exploration des facteurs de forme pour voir comment une nouvelle tablette pourrait s'intégrer dans les sacs à dos, les porte-documents et les voitures actuels, une entreprise de la Silicon Valley a simplement découpé une multitude de modèles en plastique dans une seule feuille de plastique. Plus tard dans le processus de conception, cette même équipe a constaté qu'elle devait revoir la conception de l'alimentation électrique afin qu'elle n'interfère pas trop avec le signal WIFI. <br/>

<br/>

Pour obtenir un retour d'information concret, les équipes produits doivent s'efforcer de recourir à la forme de prototypage la plus rapide et la moins coûteuse. Souvent, le prototypage sur papier est le meilleur choix. [4][5]

==En savoir plus==

Ligne 68 :

Ligne 124 :

[4] Snyder, Carolyn. ''Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces.'' Morgan Kaufmann, 2003.<br/>

[5] Gothelf, Jeff, and Josh Seiden. ''Lean UX: Designing Great Products with Agile Teams.'' O’Reilly Media, 2016.

==Autres ressources==

[https://www.scaledagileframework.com/posters/ Télécharger les posters]

Anonyme

Rechercher

« Design Thinking (SAFe) » : différence entre les versions

Espaces de noms

Plus

Actions de la page

Navigation

Navigation

Contact

Outils wiki

Outils wiki

@@ Ligne 2 : / Ligne 2 : @@
 [[Catégorie:Portail Product Owner]]
 [[Category: SAFe]]
+[[Category: Design Thinking]]
+[[Category: Empathie]]
 Auteur : &copy; 2010-2022 Scaled Agile, Inc.<br />
 Source : [https://www.scaledagileframework.com/design-thinking/ Design Thinking]<br/>
@@ Ligne 52 : / Ligne 54 : @@
 <br/>
 En revanche, dans un marché de clients indirects, ce qui est courant dans les solutions B2C, les équipes produits doivent trouver un moyen de maintenir un lien avec leur client cible. Elles développent donc des "personas", des consommateurs et/ou utilisateurs fictifs issus d'études de marché [2]. Ces personas décrivent les différentes personnes susceptibles d'utiliser un produit ou une solution de manière similaire, ce qui permet de comprendre comment les utilisateurs réels se comporteraient avec une solution. Les user personas étayent également la stratégie de segmentation du marché en offrant un outil de conception concret pour renforcer le fait que les produits et les solutions sont créés pour des personnes. Les personas sont le moteur du développement de produits et de plusieurs pratiques SAFe, comme le montre la figure 3.<br/>
-[[Fichier:Design Thinking F03 WEB.png|border|center|link=]]
+[[Fichier:Design Thinking F03 WEB.png|border|650px|center|link=]]
 <div style="text-align: center;">'''Figure 3. Les Personas dirigent les activités clés de SAFe.'''</div>
 En plus des user personas, les ''buyer'' personas étendent le design thinking pour inclure les personnes et les organisations qui décident des achats. Elles permettent de s'assurer que la conception englobe l'ensemble de l'expérience d'achat du produit, y compris le service après-vente, le support et les opérations.
 ===Développer l'empathie grâce aux cartes d'empathie===
 Les entreprises orientées client font preuve d'empathie tout au long du processus de conception. De manière générale, la conception empathique ignore les idées préconçues et s'appuie sur le point de vue du client pour élaborer des solutions.<br/>
 <br/>
 Les cartes d'empathie [1] sont un outil de design thinking qui favorise l'identification du client en aidant les équipes à développer une compréhension profonde et partagée des autres (figure 4). Elles aident les équipes à imaginer ce qu'un persona spécifique pense, ressent, entend et voit lorsqu'il utilise le produit. Plus le degré d'empathie d'une équipe pour son client est élevé, plus l'équipe sera en mesure de concevoir une solution souhaitable.<br/>
-[[Fichier:Word-image-35.png|border|center|link=]]
+[[Fichier:Word-image-35.png|border|center|800px|link=]]
 <div style="text-align: center;">'''Figure 4. Canevas de Carte d'Empathie.'''</div>
+===Concevoir l'expérience client grâce aux cartes de parcours===
+Une ''carte du parcours client'' illustre l'expérience d'un utilisateur qui s'engage dans le [https://www.scaledagileframework.com/operational-value-streams/ flux de valeur opérationnel], les produits et les services d'une entreprise. Comme le montre la figure 5, les cartes de parcours sont de puissants outils de conception pour les flux de valeur opérationnels. Elles permettent aux équipes d'identifier les moyens d'améliorer les livrables spécifiques d'un ou plusieurs [https://www.scaledagileframework.com/development-value-streams/ flux de valeur de développement] afin de créer une meilleure expérience de bout en bout.<br/>
+[[Fichier:Operational Value Streams F07 WEB.png|border|center|800px|link=]]
+<div style="text-align: center;">'''Figure 5. Flux de valeur opérationnels et cartes du parcours du client.'''</div>
+===Offrir des avantages grâce aux fonctionnalités===
+Alors qu'une carte du parcours capture l'expérience à haut niveau du client à travers le flux de valeur opérationnel, les fonctionnalités du produit gèrent les livrables spécifiques qui répondent aux besoins d'une partie prenante. Les fonctionnalités sont généralement décrites par le biais d'une matrice des fonctionnalités et des avantages, à l'aide de phrases courtes qui fournissent un contexte et une hypothèse sur les avantages dont bénéficie l'utilisateur.<br/>
+<br/>
+Les pratiques de design thinking favorisent le changement de l'ordre dans lequel nous considérons les éléments de l'hypothèse fonctionnalités-avantages. Elles aident les équipes Agile à explorer de meilleures façons, plus rapides, d'offrir les avantages souhaités (figure 6).<br/>
+[[Fichier:Design-Thinking F06 WEB-4.png|border|center|800px|link=]]
+<div style="text-align: center;">'''Figure 6. La matrice traditionnelle "fonctionnalités et avantages " devient une matrice "avantages et fonctionnalités ".'''</div>
+===Concevoir des workflows pour les utilisateurs grâce aux Story Maps===
+Les fonctionnalités sont mises en œuvre par le biais d'une ou plusieurs Stories. Il existe deux types de stories dans SAFe :
+* Les '''User Stories''' sont le principal moyen d'exprimer les fonctionnalités nécessaires. Elles peuvent être écrites dans un format de rôle ou de persona :
+** '''Rôle''' : En tant <rôle utilisateur> Je veux <activité/but> Afin de <une raison telle que. créer de la valeur métier ou de la valeur pour l'utilisateur>.
+** '''Persona''' : Frank veut <activité/but> afin que Franck obtienne <valeur>
+* Les '''Enabler Stories''' recueillent les exigences en matière de système, d'architecture ou d'infrastructure, telles que les améliorations à apporter pour prendre en charge le pipeline de livraison continue.
+Le Team Backlog contient des User et des Enabler Stories qui proviennent du Program Backlog, ainsi que des stories qui sont issues du contexte local de l'équipe. Comme tous les backlogs, le Team Backlog est priorisé, et les stories sont implémentées par ordre de priorité.<br/>
+<br/>
+Les fonctionnalités qui mettent en évidence un workflow constituent un défi unique pour les équipes Agile : un workflow est une séquence d'étapes qui doivent être réalisées pour accomplir un objectif utilisateur de plus haut niveau. L'ordre linéaire d'un backlog peut empêcher les équipes Agile de comprendre les relations entre les étapes. Souvent, une étape donnée peut être améliorée, et les équipes doivent également trouver un équilibre entre la complétude (toutes les étapes doivent être prises en charge) avant d'améliorer un ensemble spécifique d'étapes. Des conflits potentiels apparaissent lorsque la phase divergente de développement d'une solution prévoit des possibilités d'amélioration, tandis que la phase convergente de design thinking se concentre sur ce qui est essentiel pour la prochaine version.<br/>
+<br/>
+Les solutions contiennent à la fois de grands et de petits workflows. Considérons le modeste workflow d'un homme d'affaires qui importe un relevé de carte de crédit dans un système de déclaration de frais pour qu'il soit traité. L'utilisateur doit :
+* Télécharger le relevé de carte de crédit depuis la banque
+* Télécharger le relevé de carte de crédit dans le système de gestion des frais.
+* Faire correspondre les transactions du relevé de carte de crédit avec les reçus de dépenses stockés dans le système de gestion des frais.
+* Supprimer toute transaction non remboursable
+Comme décrit précédemment, chacune de ces stories peut être appréhendée dans un workflow. De plus, chacune peut être améliorée au fil du temps : nous pourrions, par exemple, imaginer une connexion directe entre la banque et le système de gestion des frais, ou un agent d'IA automatisé qui gère la tâche de rapprochement des transactions.<br/>
+<br/>
+Les fonctionnalités qui représentent un workflow sont recueillies par le biais de story maps [3], qui organisent une séquence de stories en fonction des tâches dont un utilisateur a besoin pour atteindre son objectif (Figure 7).<br/>
+<br/>
+[[Fichier:Design-Thinking F07 WEB.png|border|center|800px|link=]]
+<div style="text-align: center;">'''Figure 7. Exemple de Story Map.'''</div>
+<br/>
+Les story maps permettent aux équipes de comprendre comment les stories du backlog de l'équipe soutiennent les objectifs des utilisateurs (Figure 8).<br/>
+[[Fichier:Design-Thinking F08 WEB.png|border|center|800px|link=]]
+<div style="text-align: center;">'''Figure 8. Relation entre les Story Maps et les Team Backlogs.'''</div>
+<br/>
+Les Story Maps clarifient également les relations entre la qualité et la valeur :
+* '''Qualité''' - Chaque Story dans le backlog doit être terminée avec qualité.
+* '''Valeur''' - Toutes les stories sélectionnées dans la Story Map doivent être terminées pour créer de la valeur, car si une story est négligée, l'utilisateur ne peut pas terminer son travail.
+===Augmenter le retour d'information sur le design grâce aux prototypes===
+Un prototype est un modèle fonctionnel de la Fonctionnalité ou du Produit que l'on souhaite construire. Il aide l'équipe de conception à clarifier sa compréhension du problème et réduit les risques liés à l'élaboration d'une solution. Les prototypes offrent une myriade d'avantages aux équipes chargées des produits :
+* '''Retour d'information rapide.''' Par définition, un prototype est moins cher et plus rapide à produire qu'une solution complète. Cela permet un retour d'information plus rapide de la part des utilisateurs et des clients, une meilleure compréhension des exigences de la solution et une plus grande confiance dans les conceptions finales.
+* '''Réduction des risques.''' Les prototypes peuvent réduire le risque technique en permettant aux équipes Agile de porter leurs efforts initiaux sur les aspects de la solution qui présentent le plus de risques.
+* '''Propriété intellectuelle / dépôt de brevet.''' Les prototypes peuvent être utilisés pour satisfaire aux exigences stratégiques de gestion de la propriété intellectuelle le plus tôt possible dans le processus de développement.
+* '''Modèles pour les exigences.''' Les prototypes peuvent fournir plus de clarté dans les exigences de la fonctionnalité ou de la solution souhaitée que des pages de documentation.
+<br/>
+Il existe de nombreux types de prototypes, chacun étant destiné à fournir différents types d'informations :
+* '''Les prototypes bas niveau (lo-fi) papier''' sont généralement des esquisses dessinées à la main de la solution envisagée. Ils peuvent être automatisés pour illustrer les workflows en tant que compléments aux user story maps.
+* '''Les prototypes moyen niveau (mi-fi)''' sont des représentations visuellement complètes de solutions centrées sur le logiciel mais ne sont généralement pas intégrés fonctionnellement.
+* '''Les prototypes haut niveau (hi-fi)''' sont des modèles visuellement achevés et interactifs que les utilisateurs et les clients peuvent explorer en direct.
+* '''Les prototypes matériels''' fournissent un retour d'information critique à l'équipe Agile sur des éléments tels que les facteurs de forme, les tailles et les exigences opérationnelles. Par exemple, lors de l'exploration des facteurs de forme pour voir comment une nouvelle tablette pourrait s'intégrer dans les sacs à dos, les porte-documents et les voitures actuels, une entreprise de la Silicon Valley a simplement découpé une multitude de modèles en plastique dans une seule feuille de plastique. Plus tard dans le processus de conception, cette même équipe a constaté qu'elle devait revoir la conception de l'alimentation électrique afin qu'elle n'interfère pas trop avec le signal WIFI. <br/>
+<br/>
+Pour obtenir un retour d'information concret, les équipes produits doivent s'efforcer de recourir à la forme de prototypage la plus rapide et la moins coûteuse. Souvent, le prototypage sur papier est le meilleur choix. [4][5]
 ==En savoir plus==
@@ Ligne 68 : / Ligne 124 : @@
 [4] Snyder, Carolyn. ''Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces.'' Morgan Kaufmann, 2003.<br/>
 [5] Gothelf, Jeff, and Josh Seiden. ''Lean UX: Designing Great Products with Agile Teams.'' O’Reilly Media, 2016.
+==Autres ressources==
+[https://www.scaledagileframework.com/posters/ Télécharger les posters]

Anonyme

Rechercher

« Design Thinking (SAFe) » : différence entre les versions

Navigation

Outils wiki

Outils de la page

« Design Thinking (SAFe) » : différence entre les versions