Phase 5 – Tâches

Empruntées à la méthode Agile SCRUM, les user stories, ou histoires utilisateurs, décrivent ce que le système devrait faire du point de vue d’un utilisateur donné (WELLS 1999). Ce n’est pas un outil issu des processus de design de services, mais c’est certainement un attribut appréciable à intégrer à la méthode SIX pour sa capacité à modéliser le rôle et les attentes de l’utilisateur dans le système.

Les user stories, dans un contexte de développement Agile SCRUM, ne sont pas nécessairement utilisées tel quel dans la méthode SIX, puisque nous avons adapté la méthode sur mesure afin que les tâches issues des histoires utilisateurs puissent être cohérentes avec le reste de l’approche. Mais comme dans la méthode Agile SCRUM, les histoires utilisateurs sont formulées selon la prémisse suivante : « En tant qu’utilisateur X, j’aimerais… ». Chaque utilisateur prend donc la parole et décrit chacune des actions qu’il aimerait pouvoir effectuer avec ou grâce à l’application. Là où la méthode SIX se différencie du processus Agile SCRUM, c’est dans la catégorisation des dites tâches. Au lieu de les classer selon le temps qu’elles mettent à être développées, elles sont classées selon leur priorité, c’est-à-dire selon leur degré d’importance dans leur intégration au sein du système. Les « tâches critiques » représentent les éléments qui seront essentiels au fonctionnement de l’application et à la poursuite de l’objectif. Les « tâches secondaires » sont des tâches qui pourraient assouvir des besoins moins fondamentaux, mais qui pourraient grandement contribuer à la valeur ajoutée de l’application. Finalement, les « tâches wishlist » sont des aspects complémentaires qui seraient souhaitables pour un utilisateur, mais pas du tout essentiels au fonctionnement de l’application. Ces tâches pourraient faire l’objet d’une intégration future, mais à la base, elles servent à assurer une pérennité et une vision plus vaste de l’application.

La description des tâches peut être générée via l’utilisation des méthodes de bodystorming ou de visualisation structurée (chapitre 4). En prenant le rôle d’un persona et en recréant une scène d’utilisation potentielle, nous pourrions faire ressortir des tâches qui ne sont pas évidentes au premier coup d’oeil dans le contexte actuel. Faire soi-même l’expérimentation du service tracé dans le diagramme de service (phase 2) en fonction du parcours utilisateur choisi est un exercice intéressant pour la génération d’idées nouvelles et innovantes. Ainsi, nous nous assurons que les besoins de tous les utilisateurs sont comblés à leur juste mesure.

Figure 23 – Tâches : liste des tâches selon leur importance, pour chaque type d’utilisateur

Figure 24 – Tâches : chaque utilisateur dispose de ses propres besoins

 

 

 

Publicités