Get best of the week

5 règles pour intégrer UX dans Agile et Scrum

Une traduction de l'article a été préparée avant le lancement du cours Agile Project Manager in IT .



Au début de ma carrière, le logiciel est venu dans des boîtes. Si cela vous semble étrange, sachez que lorsque j'étais enfant, mon père a ramené à la maison des cartes perforées sur lesquelles des programmes ont été enregistrés dans les années 1970. Un tel logiciel avait un état final. Après 20 ans à partir de ce moment, cela semblait déjà ridicule. Aujourd'hui, nous créons des systèmes qui peuvent être améliorés à l'infini. Cela pose la question: «Quand le travail se termine-t-il?» - et cette question est difficile à répondre. Nous cherchons la réponse à cette question, car elle nous aidera à répondre à d'autres questions encore plus importantes. L'équipe recevra-t-elle son prix ou le rapportera-t-elle? L'équipe fera-t-elle quelque chose de nouveau? L'intéressé en bénéficiera-t-il?

Les équipes de développement qui utilisent Scrum (ou toute autre variante de la méthodologie Agile) ont une idée claire de la fin du développement. Souvent, cela signifie "un ensemble de critères minimums qu'un produit / service doit avoir pour répondre aux besoins de l'entreprise." En conséquence, il se résume à une liste de fonctions, qui est approuvée par la partie prenante (ou le propriétaire du produit) et au moment de l'achèvement du projet doit être pleinement mise en œuvre. Les développeurs l'appellent «fonctionne comme prévu».

Mais «travailler comme prévu» signifie seulement que le logiciel fait ce qu'il veut. Malheureusement, cela ne suffit parfois pas. En fait, ce n'est que le début d'une conversation que nous avons en permanence avec nos utilisateurs et clients. C'est l'amélioration continue de nos systèmes pour offrir une meilleure expérience qui leur donne une réelle valeur.

Alors, comment définir le «shutdown» d'une équipe? Quand une équipe démarre-t-elle un nouveau projet? Le manque de retour sur investissement est un bon point de départ, mais comment savoir qu'il n'y a pas de retour sur investissement? La réponse sera donnée par les clients. Nous regardons leur comportement. Nous écoutons leurs besoins, évaluons si nos systèmes répondent à ces besoins et réfléchissons à ce que nous pouvons faire pour répondre à ces besoins en constante évolution. Nous appelons ces mesures les résultats.

Et ces résultats ne sont pas prévisibles, tout comme il est impossible de prédire le comportement humain. Pour obtenir de bons résultats, les membres de l'équipe doivent s'engager activement avec les clients afin de détecter les changements dans leur comportement, les raisons de leur occurrence et les opportunités de mieux répondre aux besoins des clients à l'avenir. La bonne nouvelle est que votre entreprise emploie probablement déjà des personnes particulièrement douées dans ces domaines - des concepteurs. Malgré le fait qu'aujourd'hui les designers soient présents dans presque toutes les entreprises, la plupart d'entre eux n'occupent pas des postes suffisamment élevés pour influencer l'adoption de décisions importantes. En fait, beaucoup d'entre eux sont laissés à l'écart des processus de développement Agile, adaptés aux programmeurs et aux chefs de produit.

L'intégration des concepteurs dans le processus de développement Agile est un problème constant pour de nombreuses organisations. Grâce à près de 20 ans d'expérience dans la conception, la gestion et la consultation d'équipes de produits, j'ai identifié les 5 règles suivantes qu'une équipe doit suivre si elle veut s'assurer que l'expérience utilisateur (UX) soit intégrée avec succès dans leur processus Agile:

1. Un concepteur distinct pour chaque équipes

Il ne peut y avoir de compromis. Sans le «propre» concepteur de l'équipe Scrum, vous disposez simplement d'une équipe de développement qui, sans concepteur, ne peut pas fournir le niveau approprié de qualité d'expérience utilisateur.

2. Heures de travail en équipe avec les clients

Cette règle que j'ai apprise de Jared Spoolqui a mené une étude prouvant que les équipes qui passent au moins 2 heures de travail toutes les 6 semaines communiquent avec les clients (par exemple, recevoir des appels d'assistance, parler avec les utilisateurs, regarder les gens, etc.) se développent plus efficacement des produits.

3. Le travail du concepteur est le premier point de l'

arriéré En bref: garder un seul arriéré. Développement, contrôle qualité, conception, travaux de recherche - tout cela doit résider dans un seul backlog, priorisé par toute l'équipe qui effectue ce travail. Dès que le travail est divisé en deux backlogs, l'équipe en choisira un et décidera de le traiter comme le «principal», et le second le mettra simplement dans la boite arrière.

4. Les résultats comme filtres de priorisation pour le backlog

J'ai beaucoup écritsur les résultats (et Josh Seyden a écrit un livre entier à ce sujet ), mais la seule chose que je veux noter dans le contexte du sujet d'aujourd'hui est que chaque élément du backlog doit passer le filtre des objectifs finaux de l'équipe. Demandez-vous: «Ce travail aidera-t-il à atteindre l'objectif?» Si la réponse est non, supprimez cet élément.

5. Formation interfonctionnelle

L'expérience utilisateur et la conception comportent de nombreuses choses intéressantes qui méritent d'être explorées. Ces événements peuvent être menés par des concepteurs (ou des analystes), mais ils doivent être pratiqués et suivis par toute l'équipe. Plus une équipe peut apprendre ensemble, moins il faut de temps pour partager les connaissances acquises et plus pour décider où les appliquer (ce qui est un sujet de conversation plus productif pour l'équipe).

La nature rétrospective itérative de Scrum est bien adaptée aux activités UX et de conception. L'intégration des informations clients dans le processus de travail provient directement du Manifeste Agile (travail avec les clients, etc.). L'expérience utilisateur et le design nous rapprochent de l'objectif Agile de concentration sur le client et de meilleure satisfaction client. Suivez ces 5 règles pour combiner design et développement agile.


.

More articles:


All Articles