Anmerkung
Das Buch ist ein narrierter Algorithmus zur Durchführung des Entwicklungsprozesses von der Idee bis zur Implementierung mithilfe agiler Techniken. Der Prozess ist in Schritten angelegt und bei jedem Schritt werden die Methoden für den Prozessschritt angegeben. Der Autor weist darauf hin, dass die meisten Methoden nicht original sind, ohne zu behaupten, original zu sein. Ein guter Präsentationsstil und eine gewisse Integrität des Prozesses machen das Buch jedoch sehr nützlich.
Die Schlüsseltechnik der User Story Map ist die Strukturierung von Ideen und Aussagen, während der Benutzer den Prozess durchläuft.
Gleichzeitig kann der Prozess auf verschiedene Arten beschrieben werden. Sie können Schritte erstellen, während Sie den Schlüsselwert erreichen, oder Sie können sich einfach vorstellen, wie der Arbeitstag des Benutzers mit dem System funktioniert. Der Autor konzentriert sich auf die Tatsache, dass die Prozesse angegeben werden müssen, ausgesprochen in Form des Benutzerverlaufs auf der Prozesszuordnung, die der Name der User Story Map war.
Wer braucht es?
Für IT-Analysten und Projektmanager. Erforderliche Lektüre. Es liest sich leicht und angenehm, das Buch ist mittelgroß.
Feedback
In seiner einfachsten Form, wie es funktioniert.
Ein Besucher kommt in ein Café, wählt Gerichte aus, bestellt, erhält Essen, isst, bezahlt.
Sie können in jeder Phase die gewünschten Anforderungen an das System schreiben.
Das System sollte eine Liste der Gerichte, jede Zusammensetzung, jedes Gewicht und jeden Preis anzeigen und in den Warenkorb legen können. Warum sind wir von diesen Anforderungen überzeugt? Dies ist in der „Standard“ -Beschreibung der Anforderungen nicht beschrieben und birgt Risiken.
Künstler, die nicht verstehen, warum dies notwendig ist, tun normalerweise nicht das, was benötigt wird. Darsteller, die nicht an der Erstellung einer Idee beteiligt sind, sind nicht am Ergebnis beteiligt. Agile sagt, also konzentrieren wir uns in erster Linie nicht auf das System, sondern auf die Menschen, auf die Verbraucher, ihre Aufgaben und Ziele.
Wir machen Menschen, aus Empathie geben wir ihnen Details und seitens der Menschen beginnen wir, Geschichten zu erzählen.
Büroangestellter Zahar ist zum Mittagessen gegangen und möchte schnell etwas essen. Was braucht er? Die Idee ist, dass er wahrscheinlich ein Geschäftsessen will. Eine andere Idee, an die sich das System erinnern soll, ist seine Präferenz, weil er auf Diät ist. Eine andere Idee. Er möchte sofort Kaffee trinken, weil er es gewohnt ist, vor dem Abendessen Kaffee zu trinken.
Und es gibt immer noch Geschäfte (organisatorischer Charakter ist ein Charakter, der die Interessen einer Organisation vertritt). Das Unternehmen möchte die durchschnittliche Rechnung erhöhen, die Häufigkeit der Einkäufe erhöhen und den Gewinn steigern. Die Idee ist, ungewöhnliche Gerichte einer Art Küche anzubieten. Eine andere Idee - lassen Sie uns das Frühstück vorstellen.
Ideen können und sollten konkretisiert, transformiert und als User Story gestaltet werden. Als Mitarbeiter des Zakhar Business Centers möchte ich, dass das System mich erkennt, damit ich ein Menü erhalte, das auf meinen Vorlieben basiert. Als Kellner möchte ich, dass das System mich benachrichtigt, wenn ich mich dem Tisch nähere, damit der Kunde mit dem schnellen Service zufrieden ist. Usw.
Dutzende von Geschichten. Weitere Priorisierung und Rückstand? Jeff weist auf die auftretenden Probleme hin: Die Verknüpfung kleiner Details und der Verlust des konzeptuellen Verständnisses sowie die Priorisierung der Funktionen führen aufgrund von Inkonsistenzen mit den Zielen zu einem zerrissenen Bild.
Autorenpfad: Wir priorisieren nicht die Funktion, sondern das Ergebnis = was der Benutzer als Ergebnis erhält.
Ein offensichtlicher, nicht offensichtlicher Punkt: Die Prioritätssitzung wird nicht vom gesamten Team abgehalten, da sie unwirksam ist, sondern von drei Personen. Der erste ist für das Geschäft verantwortlich, der zweite für die Benutzererfahrung und der dritte für die Implementierung.
Wir wählen ein Minimum für die Lösung eines Benutzerproblems (die minimal realisierbare Lösung).
Wir beschreiben die Ideen der ersten Priorität mithilfe einer User Story, skizzieren Designs, Einschränkungen und Geschäftsregeln auf der Karte der User Storys, indem wir mit dem Team erklären und diskutieren, was Personen und Stakeholder in jedem Schritt des Prozesses benötigen. Die verbleibenden Ideen bleiben im Rückstand der Möglichkeiten unzusammenhängend.
Der Prozess wird in Form von Karten von links nach rechts und Ideen auf den Karten in den Schritten des Prozesses geschrieben. Notwendigerweise muss der Weg der gesamten Geschichte gemeinsam mit dem Team ausgesprochen werden, damit gegenseitiges Verständnis entsteht.
Die Belichtung auf diese Weise schafft Integrität für den Prozessabgleich.
Die Ideen, die Sie überprüfen müssen. Kein Mitglied des Teams setzt den Hut einer Person auf und lebt im Kopf des Tages der Person, um ihr Problem zu lösen. Eine Variante ist möglich, wenn er die Entwicklungen nicht sieht, Karten neu erstellt und das Team Alternativen entdeckt.
Führen Sie dann einen Drilldown zur Bewertung durch. Dafür reichen drei Personen. Verantwortlich für User Experience, Entwickler, Tester mit einer Lieblingsfrage: "Was wäre wenn ...".
In jeder Phase wird die Diskussion auf einer Karte der Verlaufsprozesse des Benutzers geführt, die es ermöglicht, die Aufgabe des Benutzers im Auge zu behalten, um eine Integrität des Verständnisses zu schaffen.
Benötige ich nach Angaben des Autors Unterlagen? Ja, ich brauche es. Aber als Notizen, damit wir uns daran erinnern können, worauf wir uns geeinigt haben. Die Einbeziehung einer Person von außen erfordert erneut eine Diskussion.
Der Autor befasst sich nicht mit dem Thema der ausreichenden Dokumentation und konzentriert sich auf die Notwendigkeit einer Diskussion. (Ja, Dokumentation ist erforderlich, egal wie Menschen, die nicht tief in Agilität verstehen). Das Studium nur eines Teils der Fähigkeiten kann auch dazu führen, dass das gesamte System vollständig geändert werden muss. Der Autor weist auf das Risiko einer übermäßigen Ausarbeitung hin, wenn er die Idee nicht erraten hat.
Um Risiken auszuschließen, muss schnell ein Feedback zum erstellten Produkt eingeholt werden, um den Schaden bei der Erstellung des „falschen“ Produkts zu minimieren. Sie erstellten eine Skizze der Idee - vom Benutzer validiert, eine Skizze der Schnittstellenprototypen - vom Benutzer validiert usw. (Separat wird ein wenig angegeben, wie Prototypen von Programmen validiert werden können). Die Ziele bei der Erstellung von Software, insbesondere in der Anfangsphase, sind Schulungen durch schnelles Feedback. Dementsprechend ist das erste erstellte Produkt eine Gliederung, die eine Hypothese beweisen oder widerlegen kann. (Der Autor stützt sich auf die Arbeit von Eric Rice, „Startup by Lean Methodology“).
Eine Story Map hilft beim Aufbau der Kommunikation, wenn die Implementierung von mehreren Teams bereitgestellt wird. Was sollte auf der Karte sein? Was Sie brauchen, um das Gespräch zu unterstützen. Nicht nur User Story (wer, was, warum), sondern auch Ideen, Fakten, Umrisse von Schnittstellen usw.
Wenn Sie die Karten auf der Verlaufskarte in mehrere horizontale Linien unterteilen, können Sie die Arbeit in Releases unterteilen - wählen Sie das Minimum, die Ebene des Aufbaus von Funktionen und Bögen aus.
Wir erzählen Geschichten auf der Prozesslandkarte.
Der Angestellte kam zum Mittagessen.
Was will er Servicegeschwindigkeiten. Damit sein Abendessen schon auf dem Tisch oder zumindest auf einem Tablett auf ihn wartet. Opa - ein verpasster Schritt: Der Mitarbeiter wollte essen. Er loggte sich in das System ein und entschied sich für die Option für ein Geschäftsessen. Er sah Kaloriengehalt und Nährwert, um eine Diät zu halten und nicht fett zu werden. Er sah Bilder des Gerichts, um zu entscheiden, ob er an diesem Ort essen würde oder nicht.
Als nächstes wird er Mittag- und Mittagessen bekommen? Oder bekommt er vielleicht ein Mittagessen im Büro? Dann ist der Schritt des Prozesses die Wahl des Ortes der Nahrung. Er möchte sehen, wann er geliefert wird und wie viel es kosten wird, zu entscheiden, wo er Zeit und Mühe aufwenden soll - um unterzugehen oder zu arbeiten. Er möchte, dass das Café voll ist, um nicht in Schlangen zu drängen.
Als nächstes kam der Angestellte ins Café. Er will sein Tablett sehen, es nehmen und sofort zum Abendessen gehen. Das Café möchte Geld annehmen, um Geld für die Instandhaltung zu verdienen. Ein Mitarbeiter möchte in Siedlungen mit einem Café ein Minimum an Zeit verlieren, um keine kostbare Zeit ohne Nutzen zu verschwenden. Wie kann man das machen? Bezahlen Sie im Voraus oder umgekehrt, nachdem Sie aus der Ferne gewartet haben. Oder zahlen Sie im Moment mit einem Kiosk. Welches davon ist das grundlegendste? Wie viele Personen sind bereit, das Mittagessen mit Kreditkarte zu bezahlen? Wie viele Personen vertrauen auf die Speicherung der Kartennummer für wiederholte Zahlungen in diesem Speisesaal? Ohne Feldforschung ist unklar, ob Tests erforderlich sind.
In jedem Schritt des Prozesses müssen Sie zumindest irgendwie Funktionen bereitstellen. Dazu müssen Sie eine Person als Grundlage nehmen und auswählen, was für sie wichtiger ist (dieselben drei Wähler). Die Geschichte bis zum Ende weitergegeben = eine tragfähige Entscheidung getroffen.
Als nächstes kommt das Detail. Der Kunde möchte die Arbeitslast des Cafés sehen, um nicht in den Warteschlangen zu drängen. Was genau will er?
Beobachten Sie die Vorhersage, wie viele Personen in 15 Minuten sein werden, wenn er dorthin geht
Beobachten Sie die durchschnittliche Servicezeit in einem Café und ihre Dynamik eine halbe Stunde im Voraus
Beobachten Sie die Situation und die Dynamik des Einsatzes von Tischen
Was aber, wenn das Prognosesystem ein unverständliches Ergebnis liefert oder nicht mehr funktioniert?
Sehen Sie sich die Videozeilen im Café sowie den Einsatz von Tischen an. Hmm, warum nicht zuerst?
Der Autor weist auf eine kleine Übung zum Üben hin: Versuchen Sie sich vorzustellen, was Sie am Morgen nach dem Aufwachen tun. Eine Karte = eine Aktion. Vergrößern Sie die Karten (anstatt Kaffee zu mahlen - trinken Sie ein erfrischendes Getränk), um einzelne Details zu entfernen, und konzentrieren Sie sich dabei nicht auf die Art der Implementierung, sondern auf das Ziel.
Für wen dieses Buch für IT-Analysten und Projektmanager gedacht ist. Erforderliche Lektüre.
Anwendungen
Diskussion und Entscheidungsfindung sind in Gruppen von 3 bis 5 Personen effektiv.
Schreiben Sie auf die erste Karte, was entwickelt werden muss, auf die zweite - um zu reparieren, was in der ersten, in der dritten getan wurde - um zu reparieren, was in der ersten und zweiten getan wurde.
Bereiten Sie Geschichten wie Kuchen vor - schreiben Sie kein Rezept für die Herstellung auf, sondern finden Sie heraus, an wen, aus welchem Grund, wie viele Menschen einen Kuchen haben. Wenn Sie die Implementierung aufschlüsseln, dann nicht bei der Herstellung von Kuchen, Sahne usw., sondern bei der Herstellung von kleinen fertigen Kuchen.
Die Softwareentwicklung ähnelt dem Erstellen eines Films, wenn Sie ein Drehbuch sorgfältig entwickeln und lecken, eine Szene, Schauspieler usw. organisieren müssen, bevor die Dreharbeiten beginnen.
Ressourcen werden immer knapp sein.
20% der Bemühungen führen zu einem greifbaren Ergebnis, 60% geben an, dass es unklar ist, dass 20% der Bemühungen nachteilig sind - deshalb ist es wichtig, sich auf das Lernen zu konzentrieren und im Falle eines negativen Ergebnisses nicht zu verzweifeln.
Kommunizieren Sie direkt mit dem Benutzer, fühlen Sie sich in seinen Schuhen. Konzentrieren Sie sich auf einige Themen.
Das Detaillieren und Ausarbeiten der Historie für die Bewertung ist der trostloseste Teil von Scrum. Lassen Sie die Diskussionen in einem Aquarium-Modus aufstehen (3-4 Personen diskutieren an der Tafel, wenn jemand teilnehmen möchte, ersetzt er jemanden).