Abstrakt
Das Buch ist ein erzählter Algorithmus zur Durchführung des Entwicklungsprozesses von der Idee bis zur Umsetzung mithilfe agiler Techniken. Der Prozess ist in Schritten aufgebaut und bei jedem Schritt werden die Methoden für den Prozessschritt angegeben. Der Autor weist darauf hin, dass die meisten Methoden nicht originell sind, ohne Anspruch auf Originalität zu erheben. Aber der gute Schreibstil und eine gewisse Integrität des Prozesses machen das Buch sehr nützlich.
Eine Schlüsseltechnik des User Story Mapping besteht darin, Ideen und Leistungen zu strukturieren, während sich der Benutzer durch den Prozess bewegt.
Dabei kann der Prozess auf unterschiedliche Weise beschrieben werden. Sie können Schritte aufbauen, während Sie einen Schlüsselwert erreichen, oder Sie können sich einfach den Arbeitstag der Benutzer vorstellen, während sie das System nutzen. Der Autor konzentriert sich auf die Tatsache, dass Prozesse skizziert werden müssen, gesprochen in Form einer User Story auf einer Prozesslandkarte, was uns den Namen User Story Map eingebracht hat.
Wer braucht es
Für IT-Analysten und Projektmanager. Muss gelesen werden. Das Buch ist mittelgroß und leicht und angenehm zu lesen.
Rückruf
In seiner einfachsten Form funktioniert es so.
Ein Besucher kommt in ein Café, wählt Gerichte aus, gibt eine Bestellung auf, erhält Essen, isst und bezahlt.
Wir können in jeder Phase Anforderungen für das schreiben, was wir vom System erwarten.
Das System sollte eine Liste der Gerichte anzeigen, jedes Gericht sollte eine Zusammensetzung, ein Gewicht und einen Preis haben und in den Warenkorb gelegt werden können. Warum vertrauen wir auf diese Anforderungen? Dies ist in der „Standard“-Anforderungsbeschreibung nicht beschrieben und birgt Risiken.
Künstler, die nicht verstehen, warum das notwendig ist, machen meist das Falsche. Darsteller, die nicht am Entstehungsprozess einer Idee beteiligt sind, sind am Ergebnis nicht beteiligt. Agile sagt: Konzentrieren wir uns in erster Linie nicht auf das System, sondern auf die Menschen, auf die Verbraucher, ihre Aufgaben und Ziele.
Wir erstellen Personas, geben ihnen Details für Empathie und beginnen, Geschichten aus der Sicht der Persona zu erzählen.
Büroangestellter Zakhar ist zum Mittagessen gegangen und möchte einen schnellen Snack zu sich nehmen. Was braucht er? Die Idee ist, dass er wahrscheinlich ein Geschäftsessen möchte. Eine andere Idee ist, dass er möchte, dass sich das System seine Vorlieben merkt, weil er auf Diät ist. Eine andere Idee. Er möchte sofort Kaffee bekommen, weil er es gewohnt ist, vor dem Mittagessen Kaffee zu trinken.
Und es gibt auch ein Unternehmen (ein Organisationscharakter ist ein Charakter, der die Interessen einer Organisation vertritt). Unternehmen möchten den durchschnittlichen Scheck erhöhen, die Kaufhäufigkeit erhöhen und den Gewinn steigern. Die Idee ist – bieten wir ungewöhnliche Gerichte einer bestimmten Küche an. Noch eine Idee: Lassen Sie uns das Frühstück vorstellen.
Ideen können und sollen in Form einer User Story konkretisiert, transformiert und präsentiert werden. Als Mitarbeiter des Zakhar Business Centers möchte ich, dass das System mich erkennt, damit ich ein Menü basierend auf meinen Vorlieben erhalten kann. Als Kellner möchte ich, dass das System mich benachrichtigt, wenn ich mich dem Tisch nähere, damit der Kunde mit schnellem Service zufrieden ist. Usw.
Dutzende Geschichten. Als nächstes kommt die Priorisierung und der Rückstand? Jeff weist auf die dabei auftretenden Probleme hin: Sich in kleinen Details zu verzetteln und das konzeptionelle Verständnis zu verlieren sowie die Funktionalität zu priorisieren, führt aufgrund der Inkonsistenz zu den Zielen zu einem uneinheitlichen Bild.
Der Weg des Autors: Wir priorisieren nicht die Funktionalität, sondern das Ergebnis = was der Benutzer am Ende bekommt.
Ein offensichtlicher, nicht offensichtlicher Punkt: Die Priorisierungssitzung wird nicht vom gesamten Team durchgeführt, weil sie ineffektiv ist, sondern von drei Personen. Der erste ist für das Business zuständig, der zweite für die User Experience und der dritte für die Umsetzung.
Wählen wir das Minimum zur Lösung eines Benutzerproblems (minimum realisierbare Lösung).
Wir beschreiben die Ideen mit der ersten Priorität mithilfe von User Stories, Designskizzen, Einschränkungen und Geschäftsregeln auf der User Story Map, indem wir dem Team mitteilen und besprechen, was Menschen und Stakeholder in jedem Schritt des Prozesses benötigen. Die verbleibenden Ideen belassen wir ungeprüft im Backlog der Opportunities.
Der Prozess wird von links nach rechts auf Karten geschrieben, mit Ideen auf Karten unterhalb der Prozessschritte. Der Weg durch die gesamte Geschichte muss unbedingt gemeinsam mit den Teammitgliedern besprochen werden, um ein gegenseitiges Verständnis zu gewährleisten.
Eine solche Ausarbeitung schafft Integrität in Übereinstimmung mit den Prozessen.
Die eingegangenen Ideen müssen getestet werden. Ein Nicht-Teammitglied setzt den Hut der Person auf und lebt den Tag der Person in seinem Kopf durch, um ihr Problem zu lösen. Es ist möglich, dass er die Entwicklungen nicht sieht, Karten neu erstellt und das Team Alternativen für sich entdeckt.
Anschließend erfolgt die Detaillierung zur Auswertung. Dafür reichen drei Personen. Verantwortlich für User Experience, Entwickler, Tester mit einer Lieblingsfrage: „Was wäre, wenn…“.
In jeder Phase folgt die Diskussion einer Prozesslandkarte der Benutzerhistorie, die es ermöglicht, die Aufgabe des Benutzers im Auge zu behalten und ein kohärentes Verständnis zu schaffen.
Ist nach Meinung des Autors eine Dokumentation notwendig? Ja ich brauche es. Sondern als Notizen, die es Ihnen ermöglichen, sich daran zu erinnern, worüber Sie sich geeinigt haben. Die erneute Einbeziehung eines Außenstehenden erfordert Diskussion.
Der Autor geht nicht auf das Thema der ausreichenden Dokumentation ein, sondern konzentriert sich auf den Diskussionsbedarf. (Ja, Dokumentation ist erforderlich, egal wie Leute, die kein tiefes Verständnis für Agilität haben, dies behaupten.) Auch die Ausarbeitung nur eines Teils der Funktionen kann dazu führen, dass eine vollständige Überarbeitung des gesamten Systems erforderlich wird. Der Autor weist auf die Gefahr übermäßiger Ausarbeitung hin, wenn die Idee falsch ist.
Um Risiken auszuschließen, ist es notwendig, schnell Feedback zum erstellten Produkt zu erhalten, um den Schaden durch die Erstellung des „falschen“ Produkts zu minimieren. Wir haben eine Skizze der Idee erstellt – sie mit dem Benutzer validiert, Schnittstellenprototypen skizziert – sie mit dem Benutzer validiert usw. (Getrennt davon gibt es ein paar Informationen zur Validierung von Programmprototypen). Die Ziele bei der Erstellung von Software, insbesondere in der Anfangsphase, sind Lernen durch schnelles Feedback; dementsprechend werden als erstes Produkt Skizzen erstellt, die eine Hypothese beweisen oder widerlegen können. (Der Autor stützt sich auf die Arbeit von Eric Ries „Startup using Lean methodology“).
Eine Story Map trägt zur Verbesserung der Kommunikation bei, wenn die Umsetzung über mehrere Teams hinweg erfolgt. Was sollte auf der Karte sein? Was Sie brauchen, um das Gespräch am Laufen zu halten. Nicht nur eine User Story (wer, was, warum), sondern Ideen, Fakten, Schnittstellenskizzen usw.
Indem Sie die Karten auf der Verlaufskarte in mehrere horizontale Linien unterteilen, können Sie die Arbeit in Veröffentlichungen unterteilen – das Nötigste hervorheben, eine Ebene mit zunehmender Funktionalität und Bögen.
Wir erzählen Geschichten auf der Prozesslandkarte.
Ein Mitarbeiter kam zum Mittagessen.
Was will er? Servicegeschwindigkeiten. Damit sein Mittagessen bereits auf dem Tisch oder zumindest auf einem Tablett auf ihn wartet. Hoppla – ein verpasster Schritt: Der Mitarbeiter wollte essen. Er loggte sich ein und wählte die Option „Geschäftsessen“. Er erkannte, dass der Kaloriengehalt und der Nährstoffgehalt ihm dabei halfen, eine Diät einzuhalten und nicht an Gewicht zuzunehmen. Er sah sich Bilder des Gerichts an, um zu entscheiden, ob er dort essen würde oder nicht.
Wird er als nächstes Mittag- und Abendessen holen? Oder wird vielleicht das Mittagessen in sein Büro geliefert? Dann ist der Schritt des Prozesses die Auswahl eines Ortes zum Essen. Er möchte sehen, wann es geliefert wird und wie viel es kosten wird, damit er entscheiden kann, wo er seine Zeit und Energie verbringen möchte – nach unten gehen oder zur Arbeit gehen. Er möchte sehen, wie voll das Café ist, um nicht in Warteschlangen zu drängeln.
Dann kam der Angestellte ins Café. Er möchte sein Tablett sehen, damit er es nehmen und direkt zum Abendessen gehen kann. Das Café möchte Geld annehmen, um mit dem Service Geld zu verdienen. Der Mitarbeiter möchte bei der Abrechnung mit dem Café möglichst wenig Zeit verlieren, um wertvolle Zeit nicht nutzlos zu verschwenden. Wie kann man das machen? Bezahlen Sie im Voraus oder umgekehrt nach dem Service aus der Ferne. Oder bezahlen Sie vor Ort am Kiosk. Was ist dabei das Wichtigste? Wie viele Menschen sind bereit, das Mittagessen mit einer Bankkarte zu bezahlen? Wie viele Menschen würden dieser Kantine vertrauen, dass sie ihre Kartennummer für wiederholte Zahlungen speichert? Ohne Feldforschung ist unklar, ob Tests erforderlich sind.
Bei jedem Schritt des Prozesses müssen Sie irgendwie Funktionalität bereitstellen; dazu müssen Sie eine Person als Grundlage nehmen und auswählen, was für sie wichtiger ist (dieselben drei Selektoren). Habe die Geschichte bis zum Ende verfolgt = eine praktikable Lösung gefunden.
Als nächstes kommt die Detaillierung. Der Kunde möchte sehen, wie voll das Café ist, um sich nicht in Warteschlangen zu drängeln. Was genau will er?
Sehen Sie sich die Prognose an, wie viele Personen in 15 Minuten dort sein werden, wenn er dort ankommt
Sehen Sie sich die durchschnittliche Servicezeit in einem Café und ihre Dynamik eine halbe Stunde im Voraus an
Sehen Sie sich die Situation und die Dynamik der Tischbelegung an
Was passiert, wenn das Prognosesystem ein unklares Ergebnis liefert oder nicht mehr funktioniert?
Beobachten Sie per Video die Warteschlangen im Café sowie die Belegung der Tische. Hmm, warum nicht zuerst das machen?!
Der Autor weist auf eine kleine Übung zum Üben hin: Versuchen Sie sich vorzustellen, was Sie morgens nach dem Aufwachen tun. Eine Karte = eine Aktion. Vergrößern Sie die Karten (anstatt Kaffee zu mahlen, trinken Sie ein belebendes Getränk), um einzelne Details zu entfernen, und konzentrieren Sie sich dabei nicht auf die Art der Umsetzung, sondern auf das Ziel.
Für wen ist dieses Buch gedacht: IT-Analysten und Projektmanager. Muss gelesen werden.
Apps
Diskussionen und Entscheidungsfindung sind in Gruppen von 3 bis 5 Personen effektiv.
Schreiben Sie auf die erste Karte, was entwickelt werden muss, auf die zweite – korrigieren Sie, was Sie in der ersten gemacht haben, auf die dritte – korrigieren Sie, was in der ersten und zweiten Karte gemacht wurde.
Bereiten Sie Geschichten wie Kuchen vor – nicht indem Sie ein Rezept aufschreiben, sondern indem Sie herausfinden, für wen, für welchen Anlass und für wie viele Personen der Kuchen bestimmt ist. Wenn wir die Umsätze aufschlüsseln, dann würde es sich nicht um die Herstellung von Kuchen, Sahne usw. handeln, sondern um die Herstellung von kleinen Fertigkuchen.
Die Softwareentwicklung ähnelt dem Erstellen eines Films, bei dem Sie das Drehbuch sorgfältig entwickeln und verfeinern, die Szene, die Schauspieler usw. organisieren müssen, bevor die Dreharbeiten beginnen.
Es wird immer einen Mangel an Ressourcen geben.
20 % der Bemühungen führen zu greifbaren Ergebnissen, 60 % führen zu unverständlichen Ergebnissen, 20 % der Bemühungen sind schädlich – deshalb ist es wichtig, sich auf das Lernen zu konzentrieren und nicht im Falle eines negativen Ergebnisses zu verzweifeln.
Kommunizieren Sie direkt mit dem Benutzer und fühlen Sie sich in seine Lage versetzt. Konzentrieren Sie sich auf einige Probleme.
Die Detaillierung und Entwicklung der Geschichte zur Auswertung ist der langweiligste Teil von Scrum. Führen Sie die Diskussionen im Stehen im Aquarium-Modus durch (3-4 Personen diskutieren an der Tafel, wenn jemand teilnehmen möchte, ersetzt er jemanden).
Source: habr.com