Résumé
Ce livre est un algorithme narratif pour le processus de développement, de l'idée à la mise en œuvre, en utilisant des techniques agiles. Le processus est découpé en étapes, chacune indiquant les méthodes appropriées. L'auteur précise que la plupart des méthodes ne sont pas originales, ne prétendant pas à l'originalité. Cependant, le bon style de présentation et une certaine cohérence du processus rendent le livre très utile.
La clé de la technique des cartes des histoires utilisateur est la structuration des idées et des exigences tout au long du parcours de l'utilisateur.
La présentation du processus peut varier. On peut organiser les étapes selon la valeur clé atteinte, ou simplement décrire une journée de travail des utilisateurs telle qu'elle se déroule avec le système. L'auteur insiste sur le fait que les processus doivent être exposés, racontés sous forme d'histoires de l'utilisateur sur la carte du processus, d'où le nom de carte des histoires utilisateur.
À qui cela s'adresse-t-il
Pour les analystes IT et les chefs de projet. À lire absolument. C'est facile et agréable à lire, le livre est de taille moyenne.
Révocation
De la manière la plus simple, comment cela fonctionne.
Le visiteur entre dans un café, choisit des plats, passe une commande, reçoit sa nourriture, mange, et paie.
On peut rédiger des exigences sur ce que nous attendons du système à chaque étape.
Le système doit afficher une liste de plats, chacun ayant une composition, un poids et un prix, et la possibilité de les ajouter au panier. Pourquoi sommes-nous sûrs de ces exigences ? Dans une description 'standard' des exigences, cela n'est pas précisé, ce qui engendre des risques.
Les exécutants qui ne comprennent pas l'utilité de cela font généralement ce qui n'est pas nécessaire. Ceux qui ne sont pas impliqués dans le processus de création de l'idée ne s'investissent pas davantage dans le résultat. Agile dit donc, concentrons-nous d'abord sur les personnes, sur les consommateurs, leurs tâches et leurs objectifs.
Nous construisons des personas, leur donnons des détails pour l'empathie et commençons à raconter des histoires du point de vue des personas.
Zakar, un employé de bureau, est allé déjeuner et souhaite manger rapidement. Que lui faut-il ? L'idée – il veut probablement un plat du jour. Une autre idée – il veut que le système se souvienne de ses préférences, car il suit un régime. Encore une idée – il souhaite qu'on lui apporte directement un café, car il a l'habitude de boire du café avant le déjeuner.
Il existe également un rôle commercial (personnage représentant les intérêts d'une organisation). L'entreprise souhaite augmenter son chiffre d'affaires moyen, accroître la fréquence des achats et maximiser ses profits. L'idée est de proposer des plats originaux d'une cuisine particulière. Une autre idée serait d'introduire des petits-déjeuners.
Les idées doivent être concrétisées, transformées et formulées sous forme de user story. En tant qu'employé du centre d'affaires, Zachar, je veux que le système me reconnaisse afin que je reçoive un menu adapté à mes préférences. En tant que serveur, je veux que le système m'informe quand je dois me rendre à la table pour que le client soit satisfait d'un service rapide. Et ainsi de suite.
Des dizaines d'histoires. Ensuite, la priorisation et le backlog? Jeff souligne les problèmes émergents : l'attention portée aux détails mineurs et la perte de la compréhension conceptuelle, ainsi que la priorisation des fonctionnalités qui crée une image fragmentée dûe à une non-concordance avec les objectifs.
Le chemin de l'auteur : nous priorisons non pas les fonctionnalités, mais le résultat = ce que l'utilisateur obtient finalement.
Un point évident mais souvent négligé : la session de priorisation ne se fait pas avec toute l'équipe, car cela est inefficace, mais avec trois personnes. Le premier s'occupe des affaires, le deuxième de l'expérience utilisateur et le troisième de la mise en œuvre.
Identifions le minimum nécessaire pour résoudre une tâche utilisateur (solution viables minimum).
Détaillons les idées de la première priorité avec des user stories, des esquisses de design, des contraintes et des règles commerciales sur la carte des histoires utilisateurs en racontant et en discutant avec l'équipe de ce dont les personnages et les parties prenantes ont besoin à chaque étape du processus. Les autres idées restent non examinées, dans le backlog des possibilités.
Le processus est écrit sous forme de cartes de gauche à droite, et les idées sur les cartes sous les étapes du processus. Il est essentiel de discuter ensemble du cheminement de toute l'histoire avec les membres de l'équipe pour favoriser une compréhension mutuelle.
Ce mode de travail crée une cohérence par rapport aux processus.
Les idées obtenues doivent être vérifiées. Un membre non-équipé revêt le chapeau du personnage et vit une journée dans l'esprit du personnage en résolvant sa tâche. Il est possible qu'il ne voie pas les travaux déjà réalisés, créant ainsi de nouvelles cartes, tandis que l'équipe découvre des alternatives.
Ensuite, une clarification pour l'évaluation a lieu. Pour cela, trois personnes suffisent. Une responsable de l'expérience utilisateur, un développeur, un testeur avec sa question préférée : “Et si… ?”.
À chaque étape, la discussion se fait selon la carte des processus de l’histoire utilisateur, ce qui permet de garder à l'esprit la tâche de l'utilisateur et de créer une compréhension cohérente.
Est-ce que l'auteur estime nécessaire la documentation ? Oui, c'est nécessaire. Mais comme des notes pour rappeler ce sur quoi nous avons convenu. L'implication d'une personne de l'extérieur requiert à nouveau une discussion.
L'auteur n'approfondit pas le sujet de la suffisance de la documentation, mettant l'accent sur la nécessité des discussions. (Oui, la documentation est nécessaire, peu importe ce que disent ceux qui ne comprennent pas bien l'agilité). De plus, travailler uniquement sur une partie des possibilités peut conduire à la nécessité d'une refonte totale du système. L'auteur souligne le risque d'une sur-analyse si l'idée n'est pas correcte.
Pour réduire les risques, il est essentiel de recevoir rapidement des retours sur le produit en cours de création afin de minimiser les dommages causés par la création d’un produit « inapproprié ». Nous avons fait un croquis d'idée - validé avec l'utilisateur, un croquis de prototypes d'interface - validé avec l'utilisateur, etc. (Il est également brièvement mentionné comment valider des prototypes de logiciels). Les objectifs de création de logiciels, surtout au début, sont d'apprendre par le biais de retours rapides, donc le premier produit créé est un croquis capable de prouver ou de réfuter une hypothèse. (L'auteur s'appuie sur le travail d'Eric Ries, « Lean Startup »).
La carte des histoires aide à établir des communications si la réalisation implique plusieurs équipes. Que doit contenir la carte ? Ce qui est nécessaire pour soutenir la conversation. Non seulement les user stories (qui, quoi, pourquoi), mais aussi des idées, des faits, des croquis d'interfaces, etc.
En divisant les cartes sur la carte des histoires en plusieurs lignes horizontales, il est possible de séparer les travaux par versions - identifier le minimum nécessaire, le niveau d'ajout de fonctionnalités et les détails.
Nous discutons des histoires présentes sur la carte du processus.
Un employé est venu pour le déjeuner.
Que veut-il? De la rapidité de service. Pour que son déjeuner soit déjà prêt sur la table ou au moins sur un plateau. Oups — une étape oubliée : l'employé a décidé de manger. Il se connecte au système et choisit une option de déjeuner d'affaires. Il voit la valeur calorique et la correspondance avec les nutriments, afin de suivre son régime et éviter de prendre du poids. Il voit des images des plats pour décider s'il va manger à cet endroit ou non.
Ensuite, il va aller chercher son déjeuner et manger ? Ou peut-être qu'on lui livrera son déjeuner au bureau ? Dans ce cas, l'étape du processus est le choix du lieu de repas. Il veut voir le délai de livraison et combien cela coûtera, afin de choisir où investir son temps et ses efforts — descendre ou travailler. Il veut connaître l'affluence du café pour éviter d'attendre dans les files.
Ensuite, l'employé arrive au café. Il veut voir son plateau pour le prendre et se mettre à table immédiatement. Le café veut encaisser de l'argent pour gagner de l'argent avec son service. L'employé souhaite passer le moins de temps possible à régler sa commande au café, pour ne pas perdre de temps précieux. Comment faire cela ? Payer à l'avance ou après service à distance. Ou payer sur place via un kiosque. Qu'est-ce qui est le plus nécessaire ? Combien de personnes sont prêtes à payer leur déjeuner par carte bancaire ? Combien de personnes feront confiance à la conservation de leur numéro de carte pour des paiements récurrents dans cette cafétéria ? Sans étude de terrain, c'est flou, des tests sont nécessaires.
À chaque étape du processus, il faut au moins garantir la fonctionnalité, pour cela, il faut prendre une personne type et choisir ce qui est le plus important pour elle (cette fameuse triplette de sélection). L'histoire achevée = une solution viable.
Ensuite, il y a la phase de détails. Le client veut voir l'affluence du café pour éviter les files d'attente. Que veut-il exactement ?
Regarder les prévisions sur combien de personnes seront là dans 15 minutes, quand il s'y rendra.
Regarder le temps moyen de service au café et sa dynamique pour les 30 minutes à venir.
Regarder la situation et la dynamique d'occupation des tables.
Et que faire si le système de prévision donne un résultat incompréhensible ou cesse de fonctionner ?
Regarder à travers le vidéo des files d'attente au café, ainsi que l'occupation des tables. Hmm, pourquoi ne pas faire cela en priorité ?
L'auteur propose un petit exercice pour travailler la pratique : essayez d'imaginer ce que vous faites le matin après votre réveil. Une carte = une action. Agrandissez les cartes (au lieu de moudre le café - buvez une boisson stimulante), pour enlever des détails individuels, en mettant l'accent non pas sur la façon de réaliser, mais sur l'objectif.
Pour qui est ce livre - pour les analystes informatiques et les chefs de projet. Lecture incontournable.
Applications
Les discussions et la prise de décisions sont efficaces en groupes de 3 à 5 personnes.
Écrivez sur la première carte ce qui doit être développé, sur la deuxième - ce qui doit être corrigé de la première, sur la troisième - ce qui doit être corrigé de la première et de la deuxième.
Préparez des histoires comme des gâteaux - sans rédiger la recette de préparation, mais en sachant pour qui, pour quelle occasion, et pour combien de personnes le gâteau est destiné. Si vous décomposez la réalisation, ne le faites pas sur la fabrication des génoises, de la crème, etc., mais sur la création de petits gâteaux prêts.
Le développement de logiciels est similaire à la création d'un film, où il faut soigneusement élaborer et peaufiner le scénario, organiser la scène, les acteurs, etc., avant le début du tournage.
Les ressources seront toujours insuffisantes.
20% des efforts donnent des résultats tangibles, 60% donnent des résultats flous, 20% des efforts nuisent - c'est pourquoi il est important de se concentrer sur l'apprentissage et de ne pas désespérer en cas de résultats négatifs.
Communiquez directement avec l'utilisateur, mettez-vous à sa place. Concentrez-vous sur certains problèmes.
La détaillage et le travail sur l'histoire pour l'évaluation est la partie la plus pénible de Scrum, faites des discussions en mode aquarium (devant le tableau, 3-4 personnes discutent, si quelqu'un veut participer, il remplace quelqu'un).
Source : habr.com
