Annotation
Le livre est un algorithme narré pour conduire le processus de développement de l'idée à la mise en œuvre en utilisant des techniques agiles. Le processus est présenté en étapes et à chaque étape, les méthodes de l'étape de processus sont indiquées. L'auteur souligne que la plupart des méthodes ne sont pas originales, sans prétendre être originales. Mais un bon style de présentation et une certaine intégrité du processus rendent le livre très utile.
La technique clé de la carte de l'utilisateur est la structuration des idées et des déclarations au fur et à mesure que l'utilisateur parcourt le processus.
Dans le même temps, le processus peut être décrit de différentes manières. Vous pouvez créer des étapes au fur et à mesure que vous atteignez la valeur clé, ou vous pouvez simplement prendre et imaginer les utilisateurs travaillant la journée, comment cela fonctionne en utilisant le système. L'auteur se concentre sur le fait que les processus doivent être énoncés, prononcés sous la forme d'un historique des utilisateurs sur la carte des processus, qui était le nom de la carte des utilisateurs.
Qui en a besoin
Pour les analystes informatiques et les chefs de projet. Lecture obligatoire. Il se lit facilement et agréablement, le livre est de taille moyenne.
Rétroaction
Dans sa forme la plus simple, comment cela fonctionne.
Un visiteur vient dans un café, choisit des plats, passe une commande, reçoit de la nourriture, mange, paie.
Vous pouvez écrire les exigences que nous voulons du système à chaque étape.
Le système doit afficher une liste de plats, chaque composition de plat, son poids et son prix et pouvoir être ajouté au panier. Pourquoi sommes-nous confiants dans ces exigences? Cela 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 ne le font généralement pas. 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, alors concentrons-nous principalement non pas sur le système, mais sur les personnes, les consommateurs, leurs tâches et leurs objectifs.
Nous faisons des gens, pour l'empathie nous leur donnons des détails et de la part des gens nous commençons à raconter des histoires.
L'employé de bureau Zahar est allé déjeuner et veut manger un morceau. De quoi a-t-il besoin? L'idée est qu'il veut probablement un déjeuner d'affaires. Une autre idée dont il veut que le système se souvienne est sa préférence, car il suit un régime. Une autre idée. Il veut prendre du café tout de suite, car il a l'habitude de boire du café avant le dîner.
Et il y a encore des affaires (le caractère organisationnel est un personnage représentant les intérêts d'une organisation). L'entreprise veut augmenter la facture moyenne, augmenter la fréquence des achats, augmenter les bénéfices. L'idée est de proposer des plats insolites d'une sorte de cuisine. Une autre idée - introduisons le petit déjeuner.
Les idées peuvent et doivent être concrétisées, transformées et conçues comme une histoire d'utilisateur. En tant qu'employé du centre d'affaires de Zakhar, je souhaite que le système me reconnaisse, afin que je reçoive un menu en fonction de mes préférences. En tant que serveur, je veux que le système m'informe quand approcher de la table afin que le client soit satisfait du service rapide. Et ainsi de suite.
Des dizaines d'histoires. Une priorisation et un arriéré supplémentaires? Jeff souligne les problèmes qui se posent: le lien dans les petits détails et la perte de compréhension conceptuelle ainsi que la priorisation du fonctionnel crée une image déchirée en raison de l'incohérence avec les objectifs.
Chemin de l'auteur: Nous priorisons non pas la fonctionnalité, mais le résultat = ce que l'utilisateur obtient en conséquence.
Un point évident non évident: la session prioritaire n'est pas tenue par toute l'équipe, car elle est inefficace, mais par trois personnes. Le premier est responsable des affaires, le second de l'expérience utilisateur et le troisième de la mise en œuvre.
Nous sélectionnons un minimum pour résoudre un problème utilisateur (la solution viable minimum).
Nous détaillons les idées de la première priorité à l'aide d'une user story, décrivons les conceptions, les restrictions et les règles métier sur la carte des user stories en racontant et en discutant avec l'équipe de ce dont les personnes et les parties prenantes ont besoin à chaque étape du processus. Les idées restantes ne sont pas assemblées, dans l'arriéré des opportunités.
Le processus est écrit sous forme de cartes de gauche à droite, et des idées sur les cartes sous les étapes du processus. Nécessairement, le chemin de toute l'histoire doit être énoncé avec l'équipe pour l'apparition d'une compréhension mutuelle.
L'exposition de cette manière crée l'intégrité pour la mise en correspondance des processus.
Les idées que vous devez vérifier. Aucun membre de l'équipe ne porte le chapeau d'une personne et vit dans la tête de la journée de la personne, résolvant son problème. Une variante est possible quand il ne voit pas les développements, créant à nouveau des cartes et que l'équipe découvre des alternatives.
Ensuite, descendez pour évaluation. Trois personnes suffisent pour cela. Responsable de l'expérience utilisateur, développeur, testeur avec une question préférée: "Et si ...".
À chaque étape, la discussion se déroule sur une carte des processus historiques de l'utilisateur, ce qui permet de garder à l'esprit la tâche de l'utilisateur pour créer une intégrité de compréhension.
Ai-je besoin de documentation selon l'auteur? Oui, j'en ai besoin. Mais comme notes, nous permettant de nous souvenir de ce sur quoi nous nous sommes mis d'accord. L'implication d'une personne de l'extérieur nécessite à nouveau une discussion.
L'auteur ne se penche pas sur 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 gens qui ne sont pas profondément en mesure de comprendre agile). De plus, l'étude d'une partie seulement des capacités peut entraîner la nécessité d'une modification complète de l'ensemble du système. L'auteur souligne le risque d'une élaboration excessive dans le cas où ils n'ont pas deviné l'idée.
Pour éliminer les risques, il est nécessaire de recevoir rapidement des commentaires sur le produit créé afin de minimiser les dommages à la création du «mauvais» produit. Ils ont réalisé une esquisse de l'idée - validée par l'utilisateur, une esquisse des prototypes d'interface - validée par l'utilisateur, etc. (Séparément, un peu est indiqué comment valider les prototypes de programmes). Les objectifs de la création de logiciels, en particulier au stade initial, sont la formation par rétroaction rapide; en conséquence, le premier produit créé est un schéma qui peut prouver ou infirmer une hypothèse. (L'auteur s'appuie sur le travail d'Eric Rice, «Startup by Lean Methodology»).
Une Story Map aide à établir la communication si la mise en œuvre est assurée par plusieurs équipes. Que devrait être sur la carte? Ce dont vous avez besoin pour soutenir la conversation. Pas seulement une histoire d'utilisateur (qui, quoi, pourquoi), mais des idées, des faits, un aperçu des interfaces, etc.
En divisant les cartes de la carte historique en plusieurs lignes horizontales, vous pouvez diviser le travail en versions - sélectionnez le minimum, la couche de construction fonctionnelle et de construction d'arc.
Nous racontons des histoires sur la carte du processus.
L'employé est venu déjeuner.
Que veut-il? Vitesses de service. Alors que son dîner l'attend déjà sur la table ou du moins sur un plateau. Opa - une étape manquée: l'employé voulait manger. Il s'est connecté au système et a choisi l'option déjeuner d'affaires. Il a vu la teneur en calories et la valeur nutritive afin de maintenir un régime alimentaire et de ne pas grossir. Il a vu des photos du plat pour décider s'il mangerait dans cet endroit ou non.
Ensuite, il ira déjeuner et déjeuner? Ou peut-être qu'il déjeunera au bureau? Ensuite, l'étape du processus est le choix du lieu de la nourriture. Il veut voir le moment où il sera livré et combien cela coûtera de choisir où passer du temps et des efforts - pour descendre ou pour travailler. Il veut voir le café occupé pour ne pas se bousculer.
Ensuite, l'employé est venu au café. Il veut voir son plateau, le prendre et immédiatement aller dîner. Le café veut accepter de l'argent pour gagner de l'argent sur l'entretien. Un employé veut perdre un minimum de temps dans les établissements avec un café, afin de ne pas perdre un temps précieux sans bénéfice. Comment faire Payez à l'avance ou vice versa après un entretien à distance. Ou payez en ce moment en utilisant un kiosque. Lequel est le plus basique? Combien de personnes sont prêtes à payer par carte de crédit pour le déjeuner? Combien de personnes font confiance au stockage du numéro de carte pour les paiements répétés de cette salle à manger? Sans recherche sur le terrain, il n'est pas clair si des tests sont nécessaires.
À chaque étape du processus, vous devez au moins fournir des fonctionnalités, pour cela, vous devez prendre comme base une sorte de personne et choisir ce qui est le plus important pour lui (les trois mêmes électeurs). Passé l'histoire à la fin = pris une décision viable.
Vient ensuite le détail. Le client veut voir la charge de travail du café pour ne pas se bousculer dans les files d'attente. Que veut-il exactement?
Regardez les prévisions du nombre de personnes dans 15 minutes, quand il y ira
Regardez le temps de service moyen dans un café et sa dynamique pendant une demi-heure à l'avance
Surveillez la situation et la dynamique de l'emploi des tables
Mais que se passe-t-il si le système de prévision donne un résultat incompréhensible ou cesse de fonctionner?
Regardez à travers les lignes vidéo du café, ainsi que l'emploi des tables. Hmm, pourquoi ne pas le faire en premier?
L'auteur souligne un petit exercice pour pratiquer la pratique: essayez d'imaginer ce que vous faites le matin après le réveil. Une carte = une action. Agrandissez les cartes (au lieu de moudre du café - buvez une boisson rafraîchissante) pour supprimer les détails individuels, en tenant compte non pas du mode de mise en œuvre, mais de l'objectif.
Pour qui ce livre est destiné aux analystes informatiques et chefs de projets. Lecture obligatoire.
Les applications
La discussion et la prise de décision sont efficaces en groupes de 3 à 5 personnes.
Écrivez sur la première carte ce qui doit être développé, sur la seconde - pour corriger ce qui a été fait dans la première, dans la troisième - pour fixer ce qui a été fait dans la première et la seconde.
Préparez des histoires comme des gâteaux - pas en écrivant une recette à faire, mais en cherchant à qui, pour quelle raison, combien de personnes ont un gâteau. Si vous décomposez la mise en œuvre, alors pas sur la fabrication de gâteaux, de crème, etc., mais sur la fabrication de petits gâteaux finis.
Le développement de logiciels est similaire à la réalisation d'un film lorsque vous devez soigneusement développer et lécher un script, organiser une scène, des acteurs, etc., avant le début du tournage.
Les ressources seront toujours rares.
20% des efforts donnent un résultat tangible, 60% indiquent qu'il n'est pas clair que, 20% des efforts sont préjudiciables - 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 certaines questions.
Détailler et élaborer l'historique de l'évaluation est la partie la plus morne de la mêlée, faites en sorte que les discussions se tiennent debout en mode aquarium (3-4 personnes discutent au conseil d'administration, si quelqu'un veut participer, il remplace quelqu'un).