Abstrait
Le livre est un algorithme commenté permettant de mener à bien le processus de développement, de l'idée à la mise en œuvre, à l'aide de techniques agiles. Le processus est divisé en étapes et à chaque étape, les méthodes pour l'étape du processus sont indiquées. L’auteur souligne que la plupart des méthodes ne sont pas originales, sans prétendre l’être. Mais le bon style d’écriture et une certaine intégrité du processus rendent le livre très utile.
Une technique clé de la cartographie des user story consiste à structurer les idées et les performances au fur et à mesure que l’utilisateur avance dans le processus.
Parallèlement, le processus peut être décrit de différentes manières. Vous pouvez créer des étapes à mesure que vous atteignez une valeur clé, ou vous pouvez simplement prendre et imaginer la journée de travail des utilisateurs au fur et à mesure de leur utilisation du système. L'auteur se concentre sur le fait que les processus doivent être décrits, exprimés sous la forme d'une user story sur une carte de processus, ce qui nous a donné le nom de user story map.
Qui en a besoin
Pour les analystes informatiques et les chefs de projet. À lire absolument. Facile et agréable à lire, le livre est de taille moyenne.
rappel
Dans sa forme la plus simple, voici comment cela fonctionne.
Un visiteur vient dans un café, sélectionne des plats, passe une commande, reçoit de la nourriture, mange et paie.
Nous pouvons rédiger des exigences concernant ce que nous attendons du système à chaque étape.
Le système doit afficher une liste de plats, chaque plat a une composition, un poids et un prix et pouvoir l'ajouter au panier. Pourquoi avons-nous confiance dans ces exigences ? Ceci n’est pas décrit dans la description « standard » des exigences et cela crée des risques.
Les artistes qui ne comprennent pas pourquoi cela est nécessaire font généralement la mauvaise chose. Les artistes qui ne sont pas impliqués dans le processus de création d'une idée ne sont pas impliqués dans le résultat. Agile dit : concentrons-nous principalement non pas sur le système, mais sur les personnes, sur les consommateurs, leurs tâches et leurs objectifs.
Nous créons des personnages, leur donnons des détails pour faire preuve d'empathie et commençons à raconter des histoires du côté du personnage.
Zakhar, employé de bureau, est allé déjeuner et souhaite prendre une collation rapide. De quoi a-t-il besoin? L’idée est qu’il veut probablement un déjeuner d’affaires. Une autre idée est qu’il souhaite que le système mémorise ses préférences, car il suit un régime. Une autre idée. Il veut qu'on lui apporte du café immédiatement car il a l'habitude d'en boire avant le déjeuner.
Et il y a aussi une entreprise (un personnage organisationnel est un personnage représentant les intérêts d'une organisation). Les entreprises souhaitent augmenter le chèque moyen, augmenter la fréquence des achats et augmenter leurs bénéfices. L'idée est la suivante : proposons des plats inhabituels d'une certaine cuisine. Une autre idée : introduisons le petit-déjeuner.
Les idées peuvent et doivent être concrétisées, transformées et présentées sous la forme d’une user story. En tant qu'employé du Zakhar Business Center, je souhaite que le système me reconnaisse afin que je puisse recevoir un menu basé sur mes préférences. En tant que serveur, je souhaite que le système me prévienne quand m'approcher de la table afin que le client soit satisfait d'un service rapide. Et ainsi de suite.
Des dizaines d'histoires. Viennent ensuite la priorisation et le retard ? Jeff souligne les problèmes qui surviennent : s'enliser dans de petits détails et perdre la compréhension conceptuelle, et donner la priorité aux fonctionnalités crée une image irrégulière en raison d'une incohérence avec les objectifs.
Le chemin de l’auteur : nous ne donnons pas la priorité à la fonctionnalité, mais au résultat = ce que l’utilisateur obtient au final.
Un point évident non évident : la séance de priorisation n'est pas réalisée par toute l'équipe, car inefficace, mais par trois personnes. Le premier est responsable du business, le second de l’expérience utilisateur et le troisième de la mise en œuvre.
Sélectionnons le minimum pour résoudre un problème utilisateur (solution minimale viable).
Nous détaillons les premières idées prioritaires à l'aide de user stories, de croquis de conception, de contraintes et de règles métier sur la user story map en racontant et en discutant avec l'équipe ce dont les personnes et les parties prenantes ont besoin à chaque étape du processus. Nous laissons les idées restantes sans examen dans l’arriéré d’opportunités.
Le processus est écrit sur des cartes de gauche à droite, avec des idées sur des cartes sous les étapes du processus. Il est impératif que le cheminement à travers toute l’histoire soit discuté avec les membres de l’équipe pour garantir une compréhension mutuelle.
Cette élaboration crée une intégrité dans le respect des processus.
Les idées reçues doivent être testées. Un non-membre de l'équipe met le chapeau de la personne et vit la journée de la personne dans sa tête, résolvant son problème. Il est possible qu'il ne voie pas les développements, créant à nouveau des cartes, et que l'équipe découvre des alternatives par elle-même.
Ensuite, il y a les détails pour l’évaluation. Trois personnes suffisent pour cela. Responsable de l'expérience utilisateur, développeur, testeur avec une question favorite : « Et si... ».
À chaque étape, la discussion suit une cartographie des processus de l'historique de l'utilisateur, ce qui permet de garder à l'esprit la tâche de l'utilisateur pour créer une compréhension cohérente.
La documentation est-elle nécessaire de l’avis de l’auteur ? Oui j'en ai besoin. Mais comme des notes qui vous permettent de vous souvenir de ce sur quoi vous vous êtes mis d'accord. Impliquer un étranger nécessite à nouveau une discussion.
L'auteur n'aborde pas le sujet de la suffisance de la documentation, se concentrant sur la nécessité d'une discussion. (Oui, la documentation est nécessaire, peu importe la façon dont les personnes qui n'ont pas une compréhension approfondie de l'agile la prétendent). En outre, l’élaboration d’une partie seulement des capacités peut nécessiter une refonte complète de l’ensemble du système. L'auteur souligne le risque d'une élaboration excessive dans le cas où l'idée est fausse.
Pour éliminer les risques, il est nécessaire de recevoir rapidement des commentaires sur le produit en cours de création afin de minimiser les dommages liés à la création du « mauvais » produit. Nous avons fait un croquis de l'idée - l'avons validé avec l'utilisateur, esquissé des prototypes d'interface - l'avons validé avec l'utilisateur, etc. (Séparément, il y a quelques informations sur la façon de valider les prototypes de programmes). Les objectifs de la création de logiciels, en particulier au stade initial, sont l'apprentissage en recevant des commentaires rapides ; par conséquent, le premier produit créé est constitué de croquis capables de prouver ou de réfuter une hypothèse. (L'auteur s'appuie sur les travaux d'Eric Ries « Startup using Lean méthodologie »).
Une story map contribue à améliorer la communication lorsque la mise en œuvre est effectuée dans plusieurs équipes. Que doit-il y avoir sur la carte ? Ce dont vous avez besoin pour poursuivre la conversation. Pas seulement une user story (qui, quoi, pourquoi), mais des idées, des faits, des croquis d'interface, etc...
En divisant les cartes sur la carte historique en plusieurs lignes horizontales, vous pouvez diviser le travail en versions - mettre en évidence le strict minimum, une couche de fonctionnalités croissantes et des arcs.
Nous racontons des histoires sur la carte du processus.
Un employé est venu déjeuner.
Que veut-il? Vitesses de service. Alors que son déjeuner l'attend déjà sur la table ou du moins sur un plateau. Oups, une étape manquée : l'employé voulait manger. Il s'est connecté et a sélectionné l'option déjeuner d'affaires. Il a vu la teneur en calories et le contenu nutritionnel pour l'aider à suivre un régime et à ne pas prendre de poids. Il a vu des photos du plat pour décider s'il mangerait à cet endroit ou non.
Ensuite, ira-t-il déjeuner et dîner ? Ou peut-être que le déjeuner sera livré à son bureau ? Ensuite, l’étape du processus consiste à choisir un endroit où manger. Il veut savoir quand il lui sera livré et combien cela coûtera, afin de pouvoir choisir où consacrer son temps et son énergie : descendre ou aller travailler. Il veut voir à quel point le café est occupé pour ne pas faire la queue.
Puis l'employé est venu au café. Il veut voir son plateau pour pouvoir le prendre et aller directement dîner. Le café veut accepter de l'argent pour gagner de l'argent sur le service. Le salarié souhaite perdre un minimum de temps sur les règlements avec le café, afin de ne pas perdre inutilement un temps précieux. Comment faire? Payez à l'avance ou vice versa après le service à distance. Ou payez sur place à l'aide d'un kiosque. Quelle est la chose la plus importante à ce sujet ? Combien de personnes sont prêtes à payer leur déjeuner avec une carte bancaire ? Combien de personnes feraient confiance à cette cantine pour stocker leur numéro de carte en cas de paiements répétés ? Sans recherche sur le terrain, il n’est pas clair que des tests sont nécessaires.
À chaque étape du processus, vous devez d'une manière ou d'une autre fournir des fonctionnalités, pour cela vous devez vous baser sur une personne et choisir ce qui est le plus important pour elle (les trois mêmes sélecteurs). J'ai suivi l'histoire jusqu'à la fin = j'ai trouvé une solution viable.
Vient ensuite les détails. Le client veut voir à quel point le café est occupé, afin de ne pas faire la queue. Que veut-il exactement ?
Voir les prévisions du nombre de personnes qu'il y aura dans 15 minutes quand il arrivera
Visualisez le temps de service moyen dans un café et sa dynamique une demi-heure à l'avance
Voir la situation et la dynamique d'occupation des tables
Que se passe-t-il si le système de prévision donne un résultat peu clair ou cesse de fonctionner ?
Regardez en vidéo les files d'attente dans le café, ainsi que l'occupation des tables. Hmm, pourquoi ne pas faire ça d'abord ?!
L'auteur suggère un petit exercice à pratiquer : 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 du café, buvez une boisson revigorante) pour supprimer des détails individuels, en vous concentrant non pas sur la méthode de mise en œuvre, mais sur l'objectif.
À qui s'adresse ce livre : les analystes informatiques et les chefs de projet. À lire absolument.
Applications
La discussion et la prise de décision sont efficaces en groupe de 3 à 5 personnes.
Écrivez sur la première carte ce qui doit être développé, sur la seconde - corrigez ce que vous avez fait dans la première, sur la troisième - corrigez ce qui a été fait dans la première et la deuxième.
Préparez des histoires comme des gâteaux - non pas en écrivant une recette, mais en découvrant à qui, pour quelle occasion et à combien de personnes le gâteau est destiné. Si l'on décompose les ventes, il ne s'agirait pas de la production de gâteaux, de crèmes, etc., mais de la production de petits gâteaux prêts à l'emploi.
Le développement de logiciels est similaire à la réalisation d'un film, où vous devez soigneusement développer et peaufiner le scénario, organiser la scène, les acteurs, etc. avant le début du tournage.
Il y aura toujours un manque de ressources.
20 % des efforts produisent des résultats tangibles, 60 % donnent des résultats incompréhensibles, 20 % des efforts sont nuisibles - c'est pourquoi il est important de se concentrer sur l'apprentissage et de ne pas désespérer en cas de résultat négatif.
Communiquez directement avec l'utilisateur, sentez-vous à sa place. Concentrez-vous sur certains problèmes.
Détailler et développer l'histoire pour l'évaluation est la partie la plus morne de Scrum, faites en sorte que les discussions se déroulent en mode aquarium (3-4 personnes discutent au tableau, si quelqu'un veut participer, il remplace quelqu'un).
Source: habr.com