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

(17 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 70 :

Ligne 72 :

<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 77 :

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 70 : / Ligne 72 : @@
 <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 77 : / 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