http://letrainde13h37.fr/29/ux-et-agile-duo-gagnant-pour-livrer-des-produits-efficaces/
Cet approche est intéressante, mais elle me donne le sentiment que Scrum n'est toujours pas bien compris par ces auteurs.
Ci-dessous mes commentaires en vrac:
· Le Fond
- Les projets (IT en particulier) ont évolués
dans le sens où le produit développé doit répondre aux attentes d'un
utilisateur et non aux attentes de la technologie. L'Agilité en
particulier expose le postulat qu’un bon produit est celui qui est utilisé
car répondant aux attentes du marché (les utilisateurs). A l'opposé, les
démarches prônées par le marketing de Kottler, le produit ne crée plus les
attentes.
- dans les projets Scrum évolués, le produit
devient une histoire que l'on raconte à un groupe d'utilisateur. Dans un
premier temps nous répondons directement à leurs attentes, mais le
développement du produit induit un nouveau facteur la participation active
du client et des utilisateurs. Scrum dispose dans son ADN ce type de
démarche. La maturité aidant, les Product Owner (Resp. du produit)
deviennent des acteurs de l'équipe projet (pas le représentant du client)
focalisé sur "l'histoire-produit" à leur raconter de sorte
qu'une relation étroite et permanente entre Product Owner et Utilisateurs
s'installe favorisant la livraison du bon produit au bon moment et, comme
le dit Roman Pichler, un produit que les utilisateurs aiment.
- les apports de l'agilité (rectification):
l'agilité apporte un process permettant de créer un environnement
favorisant la collaboration étroite entre le développement et les
utilisateurs en libérant les blocages de part et d'autre: les itérations
livrent une "histoire-produit" pour avoir à chaque fois le
retour d'information des utilisateurs. La notion de valeur est un point à
valider dès le début de la relation: est-ce que la valeur est pour le
client ou pour les utilisateurs? L'approche itérative crée cet environnement
de communication où un compromis limité dans le temps permet d'avancer pas
à pas vers la solution. En fait, l'Agilité (Scrum en particulier) gère
l'équilibre entre "Doing" et "Talking".
- Réduire l’écart entre “Cycle d’évolution d’un produit” et “Processus
d’une organisation” est
un faux ami. Le cycle de vie du produit reste au cœur de la discussion
cependant celui-ci est calé aux attentes réelles du marché (utilisateur).
Le Processus d'organisation est un effet collatéral important de
l'approche centrée utilisateur ou centrée produit. Les organisations
mutent en systèmes où l'ensemble des participants sont au front (plus de
back office!): voir modèle Beyond Budgeting (Agile Governance &
Finance).
- N’oubliez pas qu’Agilité signifie livrer au plus vite
de la valeur. Ceci
est faux. L'Agilité c'est créer une relation de confiance entre
l'organisation, le client, les utilisateurs et l'équipe de développement.
La livraison de la valeur n'est qu'un vecteur pour arriver à cette fin:
pendant les itérations la relation avec les utilisateurs reste permanente
sans qu'il n'y ait livraison de valeur. Cette livraison ne parvient qu'à
la fin de l'itération. Ne pas confondre vitesse avec précipitation.
- Intégration de l’UX dans le Backlog du
produit
Cela fait plus de 7 ans déjà que Scrum intègre les
préceptes de l'UX dans la mission du Product Owner. En France où la culture
projet est à ses balbutiements, nous découvrons que les vertus proposées. Le
Product Owner est un peu le parent pauvre de Scrum car cette méthode,
principalement portée par les développeurs, expliquait il y a vingt ans
que le Product Owner est un ersatz de Business Analyste. En 1988, cette erreur
a été relevée et corrigée et les UX Designers ont été intégrés dans les équipes
de développement. Depuis 2001, nous considérons que le Product Owner est un UX
Designer avec des compétences en gestion de produit et il travaille au sein de
l'équipe Scrum au même titre que le Scrum Master. Cette démarche est perçue
avec difficulté par les SSI car cela change leur relation avec le client. Avec
Scrum, maximiser les résultats signifie également de fournir une équipe
complète (PO compris) et s'engager sur un résultat (obligation de résultat) a
contrario des contrats en régie donnant le leadership de l'agilité au client
(qui a rarement été formé à cela!).
En conclusion, cet article présente l'UX
Designer comme un doublon au rôle du Product Owner qui couvre déjà tout le
spectre décrit. La réponse, de mon point de vue, serait de dire que le Product
Owner est un UX Designer fait plus de sens.
L'Agilité se veut pragmatique et évite les
surcharges. Fusionner les deux fonctions telles que la nature de mes formations
PO depuis 5 ans déjà.
· La Forme
- l'approche est un peu "junior" et
les références françaises Claude et Jean-Claude ne peuvent pas réellement
répondre à cette question:
- Claude analyse intelligemment Scrum du
point de vue développeur IT
- Jean-Claude du point de vue UX
- il manque une dimension réduisant la
surcharge apportée par une fonction supplémentaire ayant été clairement
exprimée par Roman Pichler, Jeff Sutherland, Ken
Schwaber, Mike Cohn, Johanna Rothman, Jochen Krebs,
