![](https://api-ux.wikihero.org/storage/user-avatar/d736bb10/S9d3TtbzTeYZ5i7e.jpg)
Bien intégrer le processus UX avec SAFe (et autres cadres de travail agiles)
“L’UX et SAFe” est un sujet intéressant à maitriser. Lorsqu’on travaille avec les grandes entreprises, il y a de fortes chances qu'elles fonctionnent sur ce modèle.
Je ne pense pas avoir la solution parfaite, mais à force d’avoir travaillé dans ce mode et avec les retours de mon équipe chez Whitespace, je commence à trouver des astuces qui nous permettent de mieux fonctionner ensemble.
SAFe (Scaled Agile Framework), pour la parenthèse, est un cadre de travail qui permet de mettre en place une méthode de développement Agile à grande échelle dans une entreprise. Il fournit une structure pour coordonner et synchroniser les équipes travaillant sur des projets complexes et de grande envergure en utilisant des pratiques agiles telles que Scrum et Kanban.
C’est toute une orchestration de cadences, avec de grands rassemblements (PI planning), différents “streams”, un “release train” pour faire du “continuous delivery”, etc.
Ça part sur de bonnes bases. Le souci, comme d'habitude, et comme avec la méthode Agile en général, c'est que le rôle de l'UX n'est pas prévu à la base comme élément intégré.
Donc à chaque fois, c'est la même question:
- Comment est-ce qu'on vous intègre dans tout ça?
- Et vous faites quoi au juste?
Donc nous sommes obligés de définir notre rôle : on explique qu'on va faire de la recherche, créer des wireframes et prototypes, les tester avec les utilisateurs, et collaborer étroitement avec les équipes durant le développement..
Cela demande beaucoup de travail d'éducation de notre côté pour obtenir l'acceptation, voir le respect, des autres membres du projet (ou programme).
Quels sont les défis et comment peut-on les gérer?
1.UN STREAM TRANSVERSE POUR LE DESIGN
Dans un projet récent, il nous a fallu beaucoup de discussions pour faire comprendre qu’il faut définir les éléments transverses avant de se lancer dans la conception et le développement des diffèrents produits (qui font partie d’une même famille). Donc :
- un concept de navigation globale,
- un Design System avec les éléments de base, les composants et templates, et
- des règles de contenu et d’interaction
sont essentiels pour ne pas se retrouver dans un chaos total.
Typiquement dans SAFe, cette idée existe pour l’architecture technique mais pas pour le design. Une solution est donc de se rapprocher du Solution Architect et s’intégrer dans le “Architectural Runway”.
2.LA MAITRISE DU VOCABULAIRE
Pour se faire comprendre, il est important d’utiliser le “language” SAFe et Agile, qui sont par ailleurs bien documentés.
Dans le contexte d’un large programme, nous avons pu rajouter le “usability testing” pour la “DoR” (Definition of Ready) d’une feature, et d’avoir un “UX QA” comme “DoD” (Definition of Done) pour une story - donc, en d’autres termes, injecter une approche UX dans un monde Agile.
3.TRAVAILLER 2-3 SPRINTS EN AMONT
Préparer les features et stories en amont nous permet de faire des mini tests agiles si nécessaire avec les utilisateurs et de faciliter la vie des développeurs, en leur donnant un cadre bien structuré. Cet argument est en général assez convaincant, il faut juste utiliser des mots clés comme “efficacité” et “qualité.”
![](/_nuxt/img/866cb67.png)