Patton Jeff. Benutzergeschichten. Die Kunst der agilen Softwareentwicklung

Zusammenfassung

Das Buch beschreibt einen algorithmischen Ansatz zur Durchführung des Entwicklungsprozesses von der Idee bis zur Implementierung unter Verwendung agiler Techniken. Der Prozess wird in Schritte gegliedert, und für jeden Schritt werden Methoden angegeben. Der Autor weist darauf hin, dass die meisten Methoden nicht originell sind und keinen Anspruch auf Originalität erheben. Doch der gute Schreibstil und die gewisse Kohärenz des Prozesses machen das Buch sehr hilfreich.

Die Schlüsseltechnik der User Story Map ist die Strukturierung von Ideen und Anforderungen, während der Nutzer den Prozess durchläuft.

Es gibt verschiedene Möglichkeiten, den Prozess zu beschreiben. Man kann die Schritte nach dem Erreichen des Schlüsselwertes ordnen oder einfach den Arbeitstag der Nutzer darstellen, während sie das System verwenden. Der Autor betont, dass Prozesse in Form von Geschichten erzählt werden müssen, was der User Story Map ihren Namen gibt.

Für wen ist das relevant

Für IT-Analysten und Projektleiter. Unbedingt lesenswert. Lässt sich leicht und angenehm lesen, das Buch hat eine durchschnittliche Länge.

Bewertung

Im einfachsten Sinne funktioniert es so.

Der Besucher kommt ins Café, wählt die Gerichte aus, bestellt, erhält das Essen, isst und bezahlt.

Man kann die Anforderungen formulieren, die wir an das System in jeder Phase haben.

Das System sollte eine Liste von Gerichten anzeigen, mit den Zutaten, dem Gewicht und dem Preis jedes Gerichts, sowie der Möglichkeit, diese in den Warenkorb zu legen. Warum sind wir uns bei diesen Anforderungen sicher? In einer ‚Standard‘-Beschreibung der Anforderungen ist dies nicht angegeben, was Risiken birgt.

Akteure, die nicht verstehen, warum dies notwendig ist, tun in der Regel nicht das, was nötig ist. Akteure, die nicht in den Prozess der Ideenentwicklung eingebunden sind, sind auch nicht am Ergebnis beteiligt. Agile sagt, lasst uns also zunächst nicht auf das System, sondern auf die Menschen, die Verbraucher, ihre Aufgaben und Ziele konzentrieren.

Wir erstellen Personas, um Empathie zu entwickeln, verleihen ihnen Details und beginnen von der Perspektive dieser Personas aus, Geschichten zu erzählen.

Der Büromitarbeiter Zachar ist zum Mittagessen gegangen und möchte schnell etwas essen. Was braucht er? Die Idee - wahrscheinlich möchte er ein Business-Lunch. Eine weitere Idee ist, dass er möchte, dass das System sich seine Vorlieben merkt, weil er auf Diät ist. Noch eine Idee: Er möchte, dass ihm sofort Kaffee gebracht wird, weil er es gewohnt ist, vor dem Mittagessen Kaffee zu trinken.

Es gibt auch Geschäftsinteressen (Organzahl — ein Charakter, der die Interessen einer Organisation vertritt). Das Unternehmen möchte den durchschnittlichen Umsatz steigern, die Kaufhäufigkeit erhöhen und den Gewinn maximieren. Die Idee ist: Lassen Sie uns außergewöhnliche Gerichte einer bestimmten Küche anbieten. Eine weitere Idee: Lassen Sie uns Frühstücke einführen.

Ideen können und sollten konkretisiert, umgewandelt und in Form von User Stories formuliert werden. Als Mitarbeiter des Business Centers Zahkar möchte ich, dass das System mich erkennt, damit ich ein Menü gemäß meinen Vorlieben erhalte. Als Kellner möchte ich, dass mich das System benachrichtigt, wann ich an den Tisch gehen soll, damit der Kunde mit dem schnellen Service zufrieden ist. Und so weiter.

Zehntausende von Geschichten. Was ist mit der Priorisierung und dem Backlog? Jeff weist auf die auftretenden Probleme hin: Das Festhängen in kleinen Details und der Verlust des konzeptionellen Verständnisses, plus die Priorisierung von Funktionen, verleihen ein zerrissenes Bild aufgrund von Inkohärenz zu den Zielen.

Der Weg des Autors: Wir priorisieren nicht die Funktionalität, sondern das Ergebnis = das, was der Benutzer am Ende erhält.

Offensichtlich unauffälliger Punkt: Die Priorisierungssitzung wird nicht im gesamten Team, da es ineffizient wäre, sondern mit drei Personen durchgeführt. Der erste ist für das Geschäft zuständig, der zweite für die Benutzererfahrung und der dritte für die Umsetzung.

Lassen Sie uns das Minimum für die Lösung einer Benutzeraufgabe festlegen (minimal funktionsfähige Lösung).

Wir detaillieren die Ideen der obersten Priorität mithilfe von User Stories, Entwurfsskizzen, Einschränkungen und Geschäftsregeln auf der Karte der Benutzerhistorien durch Erzählung und Diskussion mit dem Team, was für die Personas und Stakeholder in jedem Schritt des Prozesses erforderlich ist. Die anderen Ideen bleiben unberücksichtigt im Backlog der Möglichkeiten.

Der Prozess wird in Form von Karten von links nach rechts geschrieben, und die Ideen auf den Karten stehen unter den Schritten des Prozesses. Es ist wichtig, den gesamten Verlauf der Geschichte gemeinsam mit den Teammitgliedern zu besprechen, um ein gegenseitiges Verständnis zu fördern.

Die Ausarbeitung auf diese Weise schafft eine integrative Übereinstimmung mit den Prozessen.

Die erhaltenen Ideen müssen überprüft werden. Kein Teammitglied schlüpft in die Rolle der Persona und lebt einen Tag im Kopf der Persona, um deren Problem zu lösen. Es kann vorkommen, dass er die bisherigen Ergebnisse nicht sieht und die Karten von Grund auf neu erstellt, während das Team alternative Lösungen entdeckt.

Anschließend erfolgt die Detaillierung zur Bewertung. Dafür sind drei Personen ausreichend. Verantwortlicher für die Benutzererfahrung, Entwickler, Tester mit der bevorzugten Frage: „Was wäre wenn…“.

In jeder Phase wird über die Prozesskarte der User Journey diskutiert, was es ermöglicht, die Nutzeraufgabe im Gedächtnis zu behalten und ein ganzheitliches Verständnis zu schaffen.

Ist Dokumentation laut Meinung des Autors notwendig? Ja, sie ist nötig. Aber als Notizen, die helfen, sich an die getroffenen Vereinbarungen zu erinnern. Die Einbindung einer externen Person erfordert erneut eine Diskussion.

Der Autor vertieft sich nicht in die Frage der ausreichenden Dokumentation, sondern legt den Fokus auf die Notwendigkeit von Diskussionen. (Ja, Dokumentation ist wichtig, auch wenn einige Menschen, die nicht tief im Verständnis von Agile sind, das Gegenteil behaupten.) Außerdem kann die Behandlung nur eines Teils der Möglichkeiten dazu führen, dass das gesamte System neu gestaltet werden muss. Der Autor weist auf das Risiko einer Überarbeitung hin, wenn die Idee nicht richtig getroffen wurde.

Um Risiken zu minimieren, ist es wichtig, schnell Feedback zu dem entwickelten Produkt zu erhalten, um den Schaden durch die Schaffung eines „falschen“ Produkts zu minimieren. Haben Sie eine grobe Idee skizziert – validieren Sie diese beim Nutzer, haben Sie erste Prototypen des Interfaces skizziert – validieren Sie diese beim Nutzer usw. (In einem separaten Abschnitt wird kurz erwähnt, wie man Prototypen validiert.) Die Ziele bei der Softwareentwicklung, insbesondere in der Anfangsphase, bestehen darin, durch schnelles Feedback zu lernen; dementsprechend sind die ersten entwickelten Produkte Entwürfe, die in der Lage sind, Hypothesen zu bestätigen oder zu widerlegen. (Der Autor stützt sich auf die Arbeit von Eric Ries "Lean Startup").

Eine Story-Karte hilft, die Kommunikation zu fördern, wenn mehrere Teams an der Implementierung arbeiten. Was sollte auf der Karte stehen? Alles, was benötigt wird, um das Gespräch zu unterstützen. Nicht nur die User Story (wer, was, warum), sondern auch Ideen, Fakten, Interface-Skizzen und mehr…

Durch das Unterteilen der Karten auf der Story-Karte in mehrere horizontale Linien kann die Arbeit in Releases unterteilt werden – das Minimalste hervorheben, eine Schicht zum Ausbau der Funktionalität und die Feinheiten.

Wir besprechen die Geschichten auf der Prozesskarte.

Ein Mitarbeiter kommt zur Mittagspause.

Was möchte er? Schnelligkeit beim Service. Damit sein Mittagessen bereits auf dem Tisch oder mindestens auf dem Tablett auf ihn wartet. Oh, Moment – ein übersprungener Schritt: Der Mitarbeiter möchte etwas essen. Er hat das System betreten und die Option für das Business-Lunch ausgewählt. Er hat die Kalorienzahl und die Nährwertkonformität gesehen, um seine Diät einzuhalten und nicht zuzunehmen. Er hat die Bilder des Gerichts gesehen, um zu entscheiden, ob er an diesem Ort essen wird oder nicht.

Anschließend wird er sich sein Mittagessen holen und essen? Oder bekommt er vielleicht sein Essen ins Büro geliefert? Der nächste Schritt im Prozess ist die Auswahl des Essensortes. Er möchte die Zeit sehen, wann das Essen geliefert wird und wie viel es kosten wird, um zu entscheiden, ob er Zeit und Energie auf den Weg nach unten oder zur Arbeit verwenden möchte. Er möchte die Auslastung des Cafés sehen, um nicht in Warteschlangen stehen zu müssen.

Dann kommt der Mitarbeiter ins Café. Er möchte sein Tablett sehen, um es zu nehmen und sofort essen zu gehen. Das Café möchte Geld annehmen, um durch den Service Einnahmen zu erzielen. Der Mitarbeiter möchte möglichst wenig Zeit mit dem Bezahlen im Café verlieren, um keine wertvolle Zeit unproduktiv zu verbringen. Wie kann man das erreichen? Vorauszahlung oder im Nachhinein remote bezahlen? Oder im Moment über einen Kiosk bezahlen? Was ist das Wichtigste dabei? Wie viele Menschen sind bereit, ihr Mittagessen mit Kreditkarte zu bezahlen? Wie viele Menschen vertrauen darauf, ihre Kartennummer für zukünftige Zahlungen bei dieser Kantine zu speichern? Ohne Marktforschung ist das unklar, daher sind Tests notwendig.

In jedem Schritt des Prozesses muss irgendwie die Funktionalität gewährleistet werden. Dazu sollte man eine Persona als Basis nehmen und auswählen, was für sie am wichtigsten ist (dieses Trio von Entscheidern). Wenn die Geschichte bis zum Ende durchlaufen ist, wurde eine tragfähige Lösung geschaffen.

Als nächstes folgt die Detaillierung. Der Kunde möchte die Auslastung des Cafés kennen, um nicht in Warteschlangen stehen zu müssen. Was möchte er konkret?

Die Prognose ansehen, wie viele Leute in 15 Minuten dort sein werden, wenn er ankommt.

Die durchschnittliche Servicezeit im Café und deren Entwicklung für die nächsten 30 Minuten einsehen.

Die Situation und die Dynamik der Tischbelegung beobachten.

Was ist, wenn das Prognosesystem unklare Ergebnisse liefert oder nicht mehr funktioniert?

Über die Videoüberwachung Warteschlangen im Café sowie die Belegung der Tische beobachten. Hmm, warum nicht das als Erstes umsetzen?!

Der Autor weist auf eine kleine Übung hin, um die Praxis zu festigen: Stellen Sie sich vor, was Sie morgens nach dem Aufwachen tun. Eine Karte = eine Handlung. Verdichten Sie die Karten (statt 'Kaffee mahlen' schreiben Sie 'energydrink trinken'), um individuelle Details zu entfernen und den Fokus auf das Ziel, nicht auf die Umsetzung zu lenken.

Diese Buch richtet sich an IT-Analysten und Projektleiter. Pflichtlektüre.

Anwendungen

Diskussionen und Entscheidungsfindungen sind in Gruppen von 3 bis 5 Personen am effektivsten.

Schreibe auf die erste Karte, was entwickelt werden muss, auf die zweite, was in der ersten verbessert werden muss, und auf die dritte, was in der ersten und zweiten Karte korrigiert werden muss.

Bereite Geschichten wie Torten vor – nicht das Rezept aufschreiben, sondern herausfinden, für wen, zu welchem Anlass und für wie viele Personen die Torte ist. Wenn du die Umsetzung aufteilen musst, dann nicht in die Herstellung von Böden, Creme usw., sondern in die Herstellung kleiner fertiger Törtchen.

Softwareentwicklung ähnelt der Filmproduktion, bei der das Drehbuch sorgfältig ausgearbeitet und poliert, die Szene, die Schauspieler usw. vor den Dreharbeiten organisiert werden müssen.

Ressourcen werden immer knapp sein.

20% der Anstrengungen führen zu spürbaren Ergebnissen, 60% ergeben unklare Resultate, und 20% der Anstrengungen schaden – deshalb ist es wichtig, sich auf das Lernen zu konzentrieren und nicht zu verzweifeln, wenn das Ergebnis negativ ist.

Kommuniziere direkt mit dem Benutzer und versetze dich in seine Lage. Konzentriere dich auf bestimmte Probleme.

Die Detailierung und Ausarbeitung von Geschichten zur Bewertung ist der anstrengendste Teil von Scrum. Halten Sie die Diskussionen im Aquarium-Modus (an der Tafel diskutieren 3-4 Personen; wenn jemand teilnehmen möchte, ersetzt er eine Person).

Quelle: habr.com