Patton Jeff. Benutzergeschichten. Die Kunst der agilen Softwareentwicklung

Zusammenfassung

Dieses Buch erzählt den Algorithmus des Entwicklungsprozesses von der Idee bis zur Implementierung unter Verwendung agiler Techniken. Der Prozess wird schrittweise dargelegt, wobei für jeden Schritt die Methoden für den Schritt des Prozesses angegeben werden. Der Autor weist darauf hin, dass viele der Methoden nicht originell sind und auch nicht den Anspruch auf Originalität erheben. Aber der gute Schreibstil und die gewisse Kohärenz des Prozesses machen das Buch sehr nützlich.

Die Schlüsseltechnik der Benutzerstory-Karte ist die Strukturierung von Ideen und Anforderungen, während der Benutzer den Prozess durchläuft.

Dabei kann der Prozess auf verschiedene Weise beschrieben werden. Man kann die Schritte um die Erreichung des Schlüsselwerts herum anordnen oder einfach den Arbeitstag der Benutzer darstellen, wie er mit dem System abläuft. Der Autor betont, dass Prozesse in Form einer Benutzerstory auf der Prozesskarte beschrieben werden müssen, was auch zur Bezeichnung Benutzerstory-Karte führte.

Wem nützt das?

Für IT-Analysten und Projektleiter. Unbedingt lesenswert. Es lässt sich leicht und angenehm lesen, das Buch hat eine mittlere Größe.

Widerruf

In einfachster Form, wie es funktioniert.

Ein Besucher kommt ins Café, wählt Gerichte aus, gibt eine Bestellung auf, erhält das Essen, isst und bezahlt.

Man kann Anforderungen festlegen, was wir von dem System in jedem Schritt erwarten.

Das System muss eine Liste von Gerichten anzeigen, die Zusammensetzung, Gewicht und Preis jedes Gerichts enthalten und die Möglichkeit bieten, in den Warenkorb zu legen. Warum sind wir uns dieser Anforderungen sicher? In der "Standard"-Beschreibung der Anforderungen wird dies nicht erwähnt, was Risiken hervorruft.

Ausführende, die nicht verstehen, warum dies notwendig ist, tun normalerweise nicht das, was nötig ist. Ausführende, die nicht in den Prozess der Ideenfindung einbezogen sind, sind auch nicht am Ergebnis interessiert. Agile sagt, lassen Sie uns zuerst nicht auf das System, sondern auf die Menschen, ihre Aufgaben und Ziele konzentrieren.

Wir erstellen Personas, um Empathie zu gewinnen, geben ihnen Details und beginnen, Geschichten aus der Sicht dieser Personas zu erzählen.

Der Büromitarbeiter Sachar ist zum Mittagessen gegangen und möchte schnell einen Snack haben. Was braucht er? Die Idee – vielleicht möchte er ein Business-Lunch. Eine weitere Idee ist, dass er möchte, dass das System sich seine Vorlieben merkt, da er sich in einer Diät befindet. Noch eine Idee: Er möchte, dass ihm sofort ein Kaffee gebracht wird, weil er es gewohnt ist, vor dem Mittagessen Kaffee zu trinken.

Es gibt auch ein Geschäft (Org-Charakter – eine Figur, die die Interessen einer Organisation vertritt). Das Geschäft möchte den durchschnittlichen Warenkorb erhöhen, die Kaufhäufigkeit steigern und den Gewinn erhöhen. Die Idee – lassen Sie uns ungewöhnliche Gerichte aus einer bestimmten Küche anbieten. Eine weitere Idee – lassen Sie uns Frühstück einführen.

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

Zehntausende von Geschichten. Dann Priorisierung und Backlog? Jeff weist auf aufkommende Probleme hin: Das Verharren in Kleinigkeiten und der Verlust des konzeptionellen Verständnisses plus die Priorisierung der Funktionen schaffen ein zerrissenes Bild aufgrund der Inkohärenz mit den Zielen.

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

Offensichtlicher nicht offensichtlicher Punkt: Die Sitzung zur Priorisierung erfolgt nicht mit dem gesamten Team, da dies ineffizient ist, sondern mit drei Personen. Der Erste zuständig für das Geschäft, 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 (Minimum Viable Solution).

Wir detaillieren die Ideen der ersten Priorität mithilfe von User Stories, Designskizzen, Einschränkungen und Geschäftsregeln auf der Karte der Benutzerhistorien, indem wir mit dem Team darüber sprechen und diskutieren, was den Personas und Stakeholdern in jedem Schritt des Prozesses benötigt wird. Die anderen Ideen lassen wir unentschlossen im Backlog der Möglichkeiten.

Der Prozess wird in Form von Karten von links nach rechts geschrieben, während die Ideen auf den Karten unter den Schritten des Prozesses stehen. Der gesamte Verlauf der Geschichte muss unbedingt zusammen mit den Teammitgliedern besprochen werden, um gegenseitiges Verständnis zu schaffen.

Diese Vorgehensweise schafft eine Ganzheitlichkeit der Übereinstimmung mit den Prozessen.

Die erhaltenen Ideen müssen überprüft werden. Kein Teammitglied setzt den Hut einer Persona auf und verbringt einen Tag im Kopf der Persona, um deren Aufgabe zu lösen. Es ist möglich, dass er die bereits erarbeiteten Ergebnisse nicht sieht und die Karten neu erstellt, während das Team Alternativen entdeckt.

Dann erfolgt eine Detaillierung zur Bewertung. Dazu reichen drei Personen aus: der Verantwortliche für die Benutzererfahrung, ein Entwickler und ein Tester mit der Lieblingsfrage: „Was wäre, wenn...“

In jeder Phase erfolgt eine Diskussion basierend auf der Prozesskarte der Benutzerhistorie, was es ermöglicht, die Aufgabe des Benutzers im Kopf zu behalten und ein ganzheitliches Verständnis zu schaffen.

Braucht der Autor Dokumentation? Ja, sie ist notwendig. Aber sie sollte als Notizen dienen, die daran erinnern, worüber man sich verständigt hat. Die Einbindung einer externen Person erfordert wiederum Diskussionen.

Der Autor vertieft sich nicht in das Thema der Angemessenheit der Dokumentation, sondern legt den Hauptfokus auf die Notwendigkeit von Diskussionen. (Ja, Dokumentation ist erforderlich, egal was Menschen sagen, die sich nicht tief mit Agile auskennen). Außerdem kann die Bearbeitung nur eines Teils der Möglichkeiten dazu führen, dass das gesamte System neu gestaltet werden muss. Der Autor weist auf das Risiko einer übermäßigen Bearbeitung hin, wenn die Idee nicht zutreffend ist.

Um Risiken zu minimieren, ist es notwendig, schnell Feedback zu dem erstellten Produkt zu erhalten, um den Schaden durch die Schaffung eines „falschen“ Produkts zu minimieren. Wir haben eine Idee skizziert — validiert beim Benutzer, ein Entwurf für das Benutzeroberflächenprototyp — validiert beim Benutzer usw. (Es wird separat erläutert, wie Prototypen validiert werden). Die Ziele der Softwareerstellung, insbesondere in der Anfangsphase, bestehen darin, durch schnelles Feedback zu lernen. Somit sind die ersten erstellten Produkte Skizzen, die in der Lage sind, Hypothesen zu beweisen oder zu widerlegen. (Der Autor stützt sich auf die Arbeit von Eric Ries „Lean Startup“).

Die User-Story-Karte hilft, die Kommunikation zu etablieren, insbesondere wenn die Umsetzung von mehreren Teams getragen wird. Was sollte auf der Karte stehen? Das, was für die Unterstützung des Gesprächs benötigt wird. Nicht nur User Stories (wer, was, warum), sondern auch Ideen, Fakten, Entwürfe von Benutzeroberflächen usw.

Durch das Unterteilen der Karten in der Geschichte in mehrere horizontale Linien können die Arbeiten in Releases aufgeteilt werden — das absolute Minimum, die Schicht zur Erweiterung der Funktionalität und die sogenannten „Schleifen“.

Wir besprechen die Geschichten auf der Prozesskarte.

Der Mitarbeiter kam zum Mittagessen.

Was möchte er? Geschwindigkeit des Service. Damit sein Mittagessen bereits auf dem Tisch oder zumindest auf dem Tablett wartet. Oh, ein verpasster Schritt: Der Mitarbeiter möchte essen. Er loggte sich ins System ein und wählte die Option für das Business-Lunch. Er sah die Kalorienzahl und die Übereinstimmung mit den Nährwertangaben, um seine Diät einzuhalten und nicht zuzunehmen. Er sah Bilder des Gerichts, um zu entscheiden, ob er an diesem Ort essen möchte oder nicht.

Geht er als Nächstes zum Lunch holen und essen? Oder wird ihm vielleicht das Lunch ins Büro geliefert? Dann ist der Schritt im Prozess die Auswahl des Essensortes. Er möchte sehen, wann es geliefert wird und was es kosten wird, um zu entscheiden, wo er Zeit und Mühe investieren will – ob nach unten zu gehen oder zur Arbeit. Er möchte die Auslastung des Cafés sehen, um nicht in Warteschlangen zu stehen.

Anschließend kam der Mitarbeiter ins Café. Er möchte sein Tablett sehen, um es zu nehmen und gleich essen zu gehen. Das Café möchte Geld annehmen, um am Service zu verdienen. Der Mitarbeiter möchte möglichst wenig Zeit mit den Abrechnungen im Café verlieren, um keine wertvolle Zeit ungenutzt verstreichen zu lassen. Wie geht das? Vorauszahlen oder nach dem Service remote bezahlen. Oder im Moment über einen Kiosk bezahlen. Was ist das Wichtigste daran? Wie viele Leute sind bereit, das Mittagessen mit einer Kreditkarte zu bezahlen? Wie viele Leute vertrauen darauf, ihre Kartennummer für zukünftige Zahlungen in dieser Mensa zu speichern? Ohne eine Felduntersuchung ist es unklar, es bedarf Tests.

In jedem Schritt des Prozesses muss auf irgendeine Weise Funktionalität sichergestellt werden. Dafür sollte eine Persona als Grundlage genommen werden, um zu wählen, was für ihn am wichtigsten ist (die besagte Gruppe von Entscheidungsträgern). Die Geschichte bis zum Ende durchlaufen = eine tragfähige Lösung geschaffen.

Als Nächstes kommt die Detaillierung. Der Kunde möchte die Auslastung des Cafés sehen, damit er nicht in Warteschlangen stehen muss. Was genau möchte er?

Den Prognose sehen, wie viele Menschen in 15 Minuten dort sein werden, wenn er ankommt.

Die durchschnittliche Bedienzeit im Café und deren Dynamik für die nächsten eine halbe Stunde betrachten.

Die Situation und die Dynamik der Belegung der Tische beobachten.

Was ist, wenn das Prognosesystem ein unverständliches Ergebnis liefert oder aufhört zu arbeiten?

Durch die Videoüberwachung der Warteschlangen im Café sowie der Belegung der Tische schauen. Hm, warum nicht damit zuerst anfangen?!

Der Autor schlägt eine kleine Übung zur Praxisentwicklung vor: Versuchen Sie sich vorzustellen, was Sie morgens nach dem Aufwachen tun. Eine Karte = eine Handlung. Verdichten Sie die Karten (statt Kaffee mahlen - ein belebendes Getränk trinken), um individuelle Details zu entfernen und sich auf das Ziel, nicht die Umsetzung zu konzentrieren.

Für wen ist dieses Buch - für IT-Analysten und Projektleiter. Unbedingt lesenswert.

Anwendungen

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

Schreiben Sie auf die erste Karte, was entwickelt werden muss, auf die zweite - was an der ersten zu verbessern ist, und auf die dritte - was an der ersten und der zweiten zu korrigieren ist.

Bereiten Sie Geschichten wie Kuchen vor - ohne das Rezept zunotieren, sondern herauszufinden, für wen, zu welchem Anlass und für wie viele Personen der Kuchen gedacht ist. Wenn Sie die Umsetzung aufschlüsseln, dann nicht in die Herstellung von Böden, Sahne usw., sondern in die Herstellung kleiner fertig gebackener Kuchen.

Softwareentwicklung ähnelt der Erstellung eines Films, bei dem das Drehbuch sorgfältig ausgearbeitet und perfektioniert, die Szene, die Schauspieler und Co. organisiert werden müssen, bevor die Dreharbeiten beginnen.

Ressourcen werden immer knapp sein.

20% der Anstrengungen bringen spürbare Ergebnisse, 60% bringen unklare Ergebnisse, und 20% der Anstrengungen schaden – deshalb ist es wichtig, sich auf die Ausbildung zu konzentrieren und sich nicht von negativen Ergebnissen entmutigen zu lassen.

Kommunizieren Sie direkt mit den Nutzern, fühlen Sie sich in ihre Lage versetzt. Konzentrieren Sie sich auf bestimmte Probleme.

Die Detaillierung und Ausarbeitung der Geschichte zur Bewertung ist der mühsamste Teil des Scrum, machen Sie Diskussionen stehend im Aquarium-Modus (an der Tafel diskutieren 3-4 Personen, wenn jemand teilnehmen möchte, ersetzt er jemanden).

Quelle: habr.com