Outils Utiles
Twig 4 : ce que l’on pourrait attendre.
Qu'est-ce qu'on pourrait attendre de Twig 4 ? Découvrez dans cet article les améliorations tant attendues par la communauté !
“Persona + Need + Purpose” voilà les trois piliers du concept d’une User Story. Mais quel est donc ce secret essentiel pour répondre aux besoins du client, tout en restant flexible et en s’adaptant aux attentes de celui-ci.
Lorsque l’on utilise la méthode Agile, comme au sein de l’équipe Efficience IT, le terme User Story, ou en français “histoire utilisateur”, est régulièrement utilisé. Il permet de décrire une fonctionnalité ou un besoin du point de vue de l’utilisateur.
À partir de celle-ci, on vient définir les exigences d’un projet d’une manière simple et compréhensible, sous la forme d’une courte phrase, qui précise qui est l’utilisateur, ce qu’il souhaite exécuter et pourquoi.
Cela doit être très précis, si l’on prend un exemple de formulation : “En tant qu’acheteur, je veux me connecter à mon compte, pour accéder à mes informations.” Nous avons le “qui”, qui est en l’occurrence l’utilisateur, le “quoi”, la connexion au compte, et le “pourquoi”, accéder à ces informations.
C’est cette phrase qui est donnée aux développeurs pour détailler une tâche. Les user stories sont généralement groupées dans un “backlog”, ou en français un “carnet de produit”. Elles sont utilisées comme base par l’équipe afin de planifier les sprints de développement.
Elles permettent ainsi que tous les efforts fournis soient orientés sur les besoins réels des utilisateurs, et qu’une collaboration entre le client et le chargé de projet ait lieu.
Souvent utilisées dans le cadre des méthodes de développement agile, comme Scrum ou Kanban (entre autres), les user stories sont là pour guider le développement collaboratif de n’importe quel type de projet, et pas seulement de logiciel. Ces dernières se concentrent sur la création de valeur pour l’utilisateur final.
Ces histoires sont la plus petite unité de travail dans les projets Agile. Leur utilisation dépend cependant du framework utilisé, qui est, lui, choisi en fonction de la taille du projet. Par exemple, Scrum est adopté pour une équipe plus ou moins large, dans laquelle un projet est réparti entre plusieurs développeurs.
Le cadre de gestion de projet agile Scrum est largement utilisé dans le développement web. Nous en utilisons des brides au sein d’Efficience IT. Dans ce framework, un projet est divisé en itérations, appelées “sprints”. Les user stories sont ici ajoutées aux sprints et sont “brûlées” tout au long du projet. Chez EfficienceIT, nous utilisons Click Up comme outil pour donner des deadlines à ces sprints et leur état d’avancement, mais il en existe plein d’autres. Vous trouverez ici un article sur les outils de suivi de projet. Ce système d’histoire aide les parties prenantes du projet à organiser les sprints et à faire des prévisions agiles grâce à une vision commune de l’objectif à atteindre. Tout cela permet de créer de la valeur ajoutée à chaque sprint.
Kanban est, quant à elle, une technique originaire du Japon qui signifie étiquette ou carton, et fonctionne sous un système en 3 étapes : à faire, en cours et terminé. Les user stories avancent dans les colonnes établies avec le temps. Les histoires sont extraites de leur backlog et permettent aux développeurs de gérer les travaux en cours afin d’affiner leur workflow. Ici, les user stories sont représentées sous forme de notes adhésives et permettent de respecter les échéances.
Tout d’abord, reprenons notre dicton vu au début de l’article : Persona, Need et Purpose. En français, ces 3 aspects sont traduits par :
Il faut noter que l’utilisateur final ne sera pas forcément le client, c’est le destinataire de l’application web. Donc, demandez-vous : qui est concerné par cette fonctionnalité logicielle ? Quelle est l’utilité finale du produit et surtout pour qui ? Quelles sont les caractéristiques psycho-démographiques de l’utilisateur final ? Cela comprend évidemment son âge, son sexe, son statut familial, son emploi, et notamment, son comportement en ligne, qui, en l’occurrence, nous intéresse particulièrement dans le monde du développement web.
L’idéal est de penser à la façon dont l’utilisateur final emploiera la fonctionnalité logicielle. Cette étape permet à l’équipe des développeurs de comprendre en profondeur comment le public utilisera leur travail. Quelles sont les intentions et exigences de l’utilisateur final ?
On vient définir la valeur ajoutée de la fonctionnalité proposée en fonction des objectifs généraux. Quels sont les avantages de celle-ci ? Quel est son rôle ?
Tout cela peut sembler un peu flou, voici donc quelques exemples de user stories, pour mieux visualiser ce qui a été dit précédemment.
Exemple 1 : En tant qu’utilisatrice du site e-commerce, je souhaite ajouter des produits à mon panier d’achat, afin de pouvoir passer une commande.
Dans cette user story, l'utilisateur est identifié comme une consommatrice du site e-commerce. L’objectif est d’ajouter des produits à son panier d'achat, pour lui permettre de passer une commande. Cette histoire met en évidence l'action spécifique que l'utilisatrice souhaite effectuer et l'objectif qu'elle souhaite atteindre.
Exemple 2 : En tant qu’administrateur de système, je souhaite gérer les comptes utilisateurs, afin de modifier ou supprimer des utilisateurs dans le système.
Dans cet exemple, l'utilisateur est identifié comme un administrateur du système. Le but pour lui est de pouvoir gérer les comptes utilisateurs en modifiant ou supprimant des utilisateurs au sein du système.
Exemple 3 : En tant qu’utilisateur d’une application mobile de livraison de nourriture, je souhaite pouvoir suivre en temps réel ma commande, afin d’avoir une visibilité sur l’avancement de celle-ci et d’en estimer le délai de livraison.
Il ne faut pas oublier que les user stories varient en fonction du projet, d’où les exemples variés. Le contexte et les besoins des utilisateurs ne seront jamais les mêmes. Ces exemples sont là pour vous donner une idée de la forme que peut prendre une user story. Bien sûr, les histoires peuvent être plus longues et plus précises, mais le but est d’aller au principal.
Vous savez maintenant pourquoi ces scénarios sont essentiels pour le bon déroulement d’un projet Agile, de type Scrum ou Kanban. Les détails sont capitaux pour une bonne collaboration entre le client et les développeurs, qui sont présents pour répondre aux besoins et attentes de celui-ci précisément. L’utilisateur final est la cible, il faut le comprendre et l’analyser pour pouvoir réaliser le projet correctement.
