L'UX design dans un projet agile

Le processus Agile à deux boucles permet d'associer le meilleur de l'agilité dans le développement avec l'approche centrée utilisateurs.

Lors de la gestion des produits logiciels et des équipes de développement agiles qui les créent, deux problèmes communs semblent presque toujours émerger :

  1. L'équipe de développement a l'impression de s'impliquer trop tard dans le processus de planification.

  2. L'équipe est frustrée par les histoires incomplètes entrant dans la planification du sprint.

Les équipes de développement déplorent de ne pas être intégrées suffisamment tôt dans le processus, mais ne souhaitent ps entamer les développements avant la finalisation du process de conception, ce qui peut paraître comme contradictoire.

Quelle est la solution à cette apparente contradiction ? Il s'agit de créer 2 "boucles" de décision, l'une centrée sur la conception et l'autre sur la production.

La double boucle de l'agilité

Étape 1 : La boucle de rétroaction

Le travail de l'équipe de production consiste à fournir une solution au client qui résout son problème. L'équipe de livraison se compose d'un responsable technique, d'un scrum master et de développeurs.

Chaque augmentation de valeur que l'équipe de livraison fournit au client est généralement réalisée sous la forme d'une nouvelle fonctionnalité logicielle ou d'une modification d'une fonctionnalité existante.

Une fois que le client utilise le logiciel et réalise une tâche, il répond à l'équipe de livraison avec des retours sous forme d'idées : rapports de bugs et demandes de fonctionnalités. Ces idées sont ensuite traitées par l'équipe de livraison, qui crée un nouvel incrément de valeur (quelques modifications logicielles) en réponse à celles-ci.

Cette boucle de rétroaction est au cœur de la fourniture de logiciels que les clients utiliseront. Et plus vite nous pouvons offrir de la valeur au client, plus vite nous recevons leurs commentaires, ce qui augmente la valeur du logiciel pour le client.

Étape 2 : la réalité rencontre la boucle de rétroaction

Premièrement, certaines idées sont impossibles à mettre en œuvre (en d'autres termes, elles ne sont pas réalisables ), donc l'équipe de livraison jette l'idée et elle n'est jamais communiquée au client.

Deuxièmement, il est inévitable qu'il y ait toujours plus d'idées à venir que l'équipe de livraison n'a le temps de mettre en œuvre, donc les idées s'accumuleront au fil du temps et deviendront un retard .

Au fil du temps, cet arriéré deviendra bien sûr de plus en plus long, jusqu'à ce que l'équipe de livraison soit complètement débordée et incapable de répondre rapidement aux clients.

Comment gérer cet arriéré sans cesse croissant ? La solution est le propriétaire du produit .

Étape 3 : Le rôle du Product Owner

Afin de maîtriser ce backlog, nous ajoutons le rôle du Product Owner . La product owner n'est pas membre de l'équipe de livraison, car elle ne construit pas la solution proprement dite. Au lieu de cela, elle forme une «équipe» distincte qui fonctionne à l'unisson avec l'équipe de livraison. Ensemble, l'équipe de livraison et le propriétaire du produit forment une seule super-équipe chargée d'apporter de la valeur aux clients.

Le propriétaire du produit est chargé d'examiner chaque idée entrante et de poser la question « Est-ce que cela a de la valeur ? »

  • Si la réponse « non », l'idée est rejetée.

  • Si la réponse est « oui », le propriétaire du produit prend l'idée et crée une histoire d'utilisateur - un énoncé clair du problème qui doit être résolu - et le hiérarchise dans un backlog de produit . Chaque fois que l'équipe de livraison est prête pour plus de travail, elle peut retirer l'histoire prioritaire du backlog de produit et travailler à la transformer en valeur.

Le plus gros problème avec notre modèle jusqu'à présent est qu'il suppose que nous créons des logiciels de manière purement réactionnaire. Si tout ce que nous faisions était de mettre en œuvre ce que les clients nous ont dit, nous nous retrouverions avec un logiciel pléthorique qui fait des centaines de choses différentes - et aucune d'entre elles bien.

Étape 4 : mieux gérer les idées

Nous devons nous assurer que nous travaillons vers un objectif plus important pour ce que le produit devrait être. Cet objectif est décrit par la vision et les objectifs du produit .

La vision et les objectifs deviennent des sources d'idées en eux-mêmes, mais ils nous aident également à juger les idées venant des clients. Si l'idée d'un client ne correspond pas à notre vision et à nos objectifs, nous pouvons la rejeter.

Avec toutes ces idées qui arrivent, le propriétaire du produit a besoin d'un endroit pour les conserver. Ces idées sont organisées en un backlog d'idées , parfois aussi appelé backlog d'opportunités .

Si nous nous arrêtions à l'étape 4, nous aurions une assez bonne description de la façon dont les équipes agiles travaillent traditionnellement dans un environnement Scrum ou Kanban. Mais avec le double boucle, nous allons beaucoup plus loin.

Étape 5 : Le rôle du responsable technique

Si nous prenons un développeur de l'équipe de livraison, le responsable technique , et la faisons travailler plus étroitement avec le propriétaire du produit, elle peut aider le propriétaire du produit à identifier et à rejeter les idées qui ne sont pas réalisables.

Nous avons donc le responsable technique qui rejoint le propriétaire du produit dans l' équipe de découverte . Maintenant, avec le propriétaire du produit identifiant les idées qui ont de la valeur et le responsable technique identifiant les idées réalisables, nous pouvons nous assurer qu'au moment où l'équipe de livraison retire une histoire du backlog du produit, elle peut être sûre que c'est à la fois possible et utile pour se transformer en un incrément logiciel.

La vie est définitivement améliorée pour l'équipe de livraison avec ce changement, mais qu'en est-il du client ?

Comme je l'ai souligné au tout début, l'aspect le plus important de l'ensemble du processus est d'obtenir des commentaires plus rapidement.

Étape 6 : Comment pouvons-nous obtenir des commentaires plus rapidement ?

Dans la boucle de rétroaction comme celle dont nous avons parlé jusqu'à présent, la vitesse de la rétroaction est aussi rapide que la partie la plus lente de la boucle, donc afin d'obtenir la rétroaction la plus rapide, nous devons identifier quelle partie prend le plus de temps.

Quelle est la partie la plus lente de la boucle ?

Il est presque certain que la création du logiciel réel est plus lente que toutes les autres parties du processus.

Pouvons-nous accélérer cette partie du processus? De toute évidence, nous ne pouvons pas obtenir de commentaires sur notre logiciel de la part d'un client tant que nous n'avons pas réellement montré ce logiciel au client, n'est-ce pas ?

« la création du logiciel réel est plus lente que toutes les autres parties du processus »

Mais que se passerait-il si nous pouvions obtenir les commentaires du client avant d'écrire une seule ligne de code ? (Voir le grand point d'interrogation jaune ci-dessus.) Heureusement, il existe un moyen de le faire !

Au lieu d'attendre d'avoir écrit un logiciel avant d'avoir des retours de nos clients, nous pouvons leur montrer des prototypes . En ce qui concerne notre diagramme, au lieu de fournir la valeur réelle aux clients, nous pouvons leur montrer des remplaçants de valeur, puis ils peuvent nous faire part de leurs commentaires sur ces prototypes.

Étape 7 : Une rétroaction plus rapide grâce au prototypage

Alors maintenant, le travail de l' équipe de découverte est de créer des prototypes de la valeur que nous pourrions fournir aux clients. Selon notre produit, les prototypes peuvent être des wireframes de pages Web, des spécifications d'API, des prototypes de documents écrits à la main ou tout autre élément pouvant remplacer le produit réel.

Le propriétaire du produit a également pour tâche supplémentaire de montrer ces prototypes aux clients et de trouver la réponse à la question : « Si nous devions construire cela, le client l'utiliserait-il (et pourrait-il) ? »

Souvent, un concepteur de produits se joint à l'équipe de découverte pour aider à créer les prototypes. Son travail consiste à s'assurer que les prototypes sont utilisables .

Si les retours du prototype montrent que l'idée est valable et utilisable, nous pouvons attacher le prototype à la user story et l'ajouter au backlog du produit, donnant à l'équipe de livraison encore plus de conseils sur la façon de le construire. Si les commentaires montrent que l'idée n'a pas de valeur, l'idée est rejetée.

Maintenant, nous pouvons voir que nous avons deux cycles de rétroaction, pas un seul.

Étape 8 : Les deux cycles

Le cycle de découverte valide la valeur et la faisabilité d'une idée, en créant des prototypes en cours de route.

Le cycle de livraison délivre la valeur d'une idée déjà validée.

Bien que je décrive ici deux équipes distinctes, l'équipe de livraison et l'équipe de découverte , en réalité, ces deux équipes devraient travailler ensemble pour former un groupe cohérent, et elles devraient réussir ou échouer en tant que groupe. Et comme toutes les équipes qui travaillent en étroite collaboration, elles sont plus efficaces lorsqu'elles s'assoient ensemble dans le même espace autant que possible.

Le cycle de découverte peut être beaucoup plus court que le cycle de livraison, car les prototypes sont plus faciles à créer que les logiciels entièrement fonctionnels, ce qui nous permet d'obtenir les commentaires de nos clients le plus rapidement possible.