« Design Thinking (SAFe) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (7 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 2 : | Ligne 2 : | ||
[[Catégorie:Portail Product Owner]] | [[Catégorie:Portail Product Owner]] | ||
[[Category: SAFe]] | [[Category: SAFe]] | ||
[[Category: Design Thinking]] | |||
[[Category: Empathie]] | |||
Auteur : © 2010-2022 Scaled Agile, Inc.<br /> | Auteur : © 2010-2022 Scaled Agile, Inc.<br /> | ||
Source : [https://www.scaledagileframework.com/design-thinking/ Design Thinking]<br/> | Source : [https://www.scaledagileframework.com/design-thinking/ Design Thinking]<br/> | ||
| Ligne 93 : | Ligne 95 : | ||
[[Fichier:Design-Thinking F07 WEB.png|border|center|800px|link=]] | [[Fichier:Design-Thinking F07 WEB.png|border|center|800px|link=]] | ||
<div style="text-align: center;">'''Figure 7. Exemple de Story Map.'''</div> | <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== | ==En savoir plus== | ||
| Ligne 100 : | Ligne 124 : | ||
[4] Snyder, Carolyn. ''Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces.'' Morgan Kaufmann, 2003.<br/> | [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. | [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] | |||
