Lean-Agile-Ansatz in der Praxis

Beispiel für einen Studenten-Portal

Eine Community-Hochschule möchte ein Studenten-Portal entwickeln, um den Studierenden Online-Dienstleistungen anzubieten. Sie luden einen Studentenvertreter, Mitarbeiter aus der Abteilung und Mitglieder des Portal-Administrators ein, ein Team zu bilden, um am Projekt zur Entwicklung des Studenten-Portals teilzunehmen. Hier sind die Protokollauszüge aus dem ersten Treffen.

Treffen der Interessenten

Tagesordnung

• Vorschläge für Funktionen des Studenten-Portals
• Diskussion der Umsetzbarkeit der vorgeschlagenen Funktionsliste
• Priorisieren Sie die Funktionen, die als Kernfunktionen, nächste Phase oder wünschenswert umgesetzt werden sollen …

Steve (Entwicklungsteam): Willkommen… Wir möchten die Sitzung produktiver und fruchtbarer gestalten. Wenn wir Funktionen vorschlagen, die Sie wünschen, können wir folgendes Format als Standardform der Darstellung verwenden: Wer (Sie sind), welche Funktion (Sie möchten), und warum (Sie sie möchten)… Diese Funktionen werden als Benutzerstories als Kommunikationsinstrument während dieses Projekts dokumentiert.

Anschließend haben wir eine Liste von Benutzerstories von verschiedenen Interessenten erarbeitet:

Studentenvertreter: Kurse anmelden, Studiengebühren zahlen, Zeitplan einsehen, Zeitplan bearbeiten, Notenübersicht einsehen, Kurse abmelden …

Akademischer Vertreter: Kursinformationen hinzufügen, Kursinformationen bearbeiten, Kursinformationen löschen …

Portal-Administrator: Kursinformationen sichern, Status des Studentenkontos bearbeiten

Jetzt haben wir eine Reihe von Karten, die in Zeilen und Spalten organisiert werden können

Vorgeschlagene Funktionen priorisieren

Vertreter der Entwickler: Wir verfügen über eine Liste prioritisierter Benutzerstories, die in der nächsten Iteration umgesetzt werden sollen. Dazu müssen wir für jede Benutzerstory tiefer in die Details gehen, um weitere Informationen zu erhalten. Lassen Sie uns die erste Kernfunktion „Kurs anmelden“ durchgehen

Wir erhalten folgende zusätzliche Informationen von den Endnutzern für die Sitzung:

• Akademisch: Der Student muss ein Vollzeitstudent sein
• Administrator: Der Student muss korrekte Kontozugangsdaten bereitstellen, um sich anzumelden
• Akademisch: Der Kurs ist nicht voll
• Akademisch: Die Kursvoraussetzungen müssen erfüllt sein
• Administrator: Ein Kurs, der zur Zeitplanung hinzugefügt werden soll, darf keine zeitliche Konflikte mit dem Zeitfenster eines anderen Kurses haben
• Entwickler: Welche anderen Funktionen möchten Sie zusammen mit dieser Funktion in der Zielumgebung als Liste gruppiert haben?
• Student: Kurse abmelden, Zeitplan einsehen, Zeitplan bearbeiten.

Die 3 C’s der Benutzerstory

Gute Benutzerstories sind viel mehr als nur Aussagen. Eine standardmäßige Benutzerstory besteht aus drei Teilen, die allgemein als die drei C’s bezeichnet werden. Der erste „C“ jeder Benutzerstory sollte das standardisierte Format folgen: Als [Rolle], möchte ich [etwas tun], damit [Vorteile] – dies ist der minimale Inhalt einer Benutzerstory, der auf die Karte gesetzt werden soll. Die „Konversationen“ sind der Inhalt des zweiten „C“ einer Benutzerstory, die die Diskussion zwischen den Endnutzern, dem Projektverantwortlichen und dem Entwicklungsteam darstellen. In diesen Gesprächen werden mündliche Diskussionen oder viele andere nützliche Informationen wie E-Mails, Wireframes oder andere relevante Inhalte für das Projekt dokumentiert. Der letzte „C“ einer Benutzerstory ist die Bestätigung, also die Akzeptanzkriterien, die verwendet werden, um zu bestätigen, dass die Benutzerstory korrekt umgesetzt und erfolgreich geliefert wurde.

Lassen Sie mich etwas weiter erläutern, wie man den Bestätigungsabschnitt einer Benutzerstory entwickelt. Hier verwenden wir die bekannteste Vorlage namens Gherkin, die die Formel Given-When-Then anwendet, um die Erstellung von Akzeptanztests für eine Benutzerstory zu leiten:

• (Gegeben.. und) ein Kontext
• (Wenn.. und) eine Aktion durchgeführt wird
• (Dann.. und) Führen Sie einige Aktionen aus

Werkzeuge wie Cucumber und Jbehave-Testframeworks fördern die Verwendung der Given/Then/Then-Vorlage zur Durchführung automatisierter Tests, obwohl sie auch rein als Heuristik verwendet werden kann, unabhängig davon, ob ein Werkzeug eingesetzt wird.

Lassen Sie uns alle Informationen für die Benutzerstory „Kurs anmelden“ sammeln und in das 3Cs-Format bringen:

Nun bringen wir die Informationen in UeXceler, das die zuvor entwickelte Umwandlung und Bestätigung enthält.

Aufteilung eines Epics in Benutzerstories

Wenn wir die Benutzerstory „Kurs anmelden“ weiter detailliert untersuchen, könnten wir feststellen, dass sie als Benutzerstory zu groß ist, um in einem Sprint umgesetzt zu werden. Wir können sie als Epic (größere Benutzerstory) betrachten, die in eine Gruppe verwandter kleinerer Benutzerstories aufgeteilt werden kann. Wir können ein Epic in Aufgaben aufteilen, das würde ich Horizontaufteilung nennen, oder alternativ können wir das Epic in Szenarien aufteilen und das vertikale Aufteilen nennen.

Horizontales Aufteilen

Der traditionelle Ansatz zum Aufbau einer großen Funktion bestand darin, sie in die Arbeit auf den architektonischen Ebenen zu zerlegen. Zum Beispiel Modell-View-Controller (MVC) oder Client-Server-Architektur, damit wir eine Trennung der Anliegen für die Systemarchitektur erreichen und sie anschließend feinjustieren, um eine n-Schichten-Architektur wie GUI, Steuerlogik, Objektmodell, Objekt-Relationen-Mapping, Datenbankebenen usw. zu erhalten. Es gibt viele Aspekte der n-Schichten-Architektur, und ich möchte hier nur einige auflisten:

• Ermöglicht uns, hohe Fachkenntnisse in einer der architektonischen Schichten zu entwickeln
• Andere Anwendungen können die von Ihren Schichten bereitgestellte Funktionalität wiederverwenden.
• Sie können Ihre Schichten über mehrere physische Ebenen verteilen. Dies kann sich sehr positiv auf Ihre Anwendung auswirken, indem Leistung (manchmal), Skalierbarkeit und Ausfallsicherheit verbessert werden.
• Die Wartung Ihrer Anwendung ist einfacher, da die Kopplung zwischen den Schichten gering ist.
• Das Hinzufügen weiterer Funktionalität zu Ihrer Anwendung wird erleichtert.
• Schichten machen Ihre Anwendung testbarer.

Es gibt eine große Anzahl erfolgreicher Implementierungen auf Basis der n-Schichten-Architektur, wie beispielsweise Ruby on Rails und webdienstbasierte Architektur.

Benutzerstories und horizontales Aufteilen

Obwohl die n-Schichten-Architektur für unser System Vorteile bietet, hat sie einige Nachteile, wenn sie mit dem Benutzerstory-Ansatz verwendet wird. Sie neigt dazu, einen sehr langen Feedback-Zyklus zu haben, abhängig von der Größe der Funktion, da wir darauf warten, dass alle mit ihrem jeweiligen Teil fertig sind, um sie zu integrieren und sicherzustellen, dass sie funktioniert. Der Begriff „horizontales Slicing“ bezieht sich auf die Verwendung dieses architektonischen Schichtenansatzes als primäre Methode zur Aufteilung großer Funktionen.

Vertikales Aufteilen

Um den Feedback-Zyklus zu beschleunigen, können wir ein Epic nehmen und in mehrere Benutzerszenarien aufteilen, die durch jede architektonische Ebene verlaufen. Fast jede Funktion kann in solche Slices aufgeteilt werden, sodass alle Teile in höchstens ein paar Tagen gebaut, integriert und getestet werden können. Jeder Slice besteht aus allen Arbeiten, die in einer architektonischen Ebene erledigt werden müssen, sowie jeglichem Testen und Integrieren, das erforderlich ist, um ihn für die Freigabe bereitzustellen.

Typischerweise teilt das horizontale Aufteilen Funktionen in Benutzerstories oder Aufgaben auf Ebene der architektonischen Komponenten. Beispiel: Frontend-UI, Datenbanken oder Backend-Dienste. Während ein vertikaler Slice funktionierende, demonstrierbare Software ergibt, die geschäftlichen Wert hinzufügt. Daher verbessert das vertikale Aufteilen die Fähigkeit des Teams, in jedem Sprint ein potenziell lieferbares Produktinkrement zu liefern. Stellen Sie sich vor, einen Kuchen mit Schichten aus Sahne, Schokolade, Obst und Kuchen zu schneiden. Wenn Sie den Kuchen horizontal schneiden, erhält Ihr Freund nur ein Stück Kuchen, Schokolade, Sahne oder Obst. Ich bin sicher, dass Ihre Freunde lieber ein Stück mit etwas von jeder Schicht gewollt hätten. Nur eine einzelne Schicht des Kuchens zu erhalten, ermöglicht ihnen nicht den echten Geschmack des gesamten Kuchens. Ein Ansatz, der Ihren Freunden eher zusagt, ist das Erstellen von vertikalen Scheiben (den gewünschten Wert).

Horizontales Aufteilen eines Epics mit Ziel

Erinnern Sie sich daran, dass die Umwandlung der Benutzerstory „Kurs anmelden“ in der Stakeholder-Sitzung vorgestellt wurde, wobei die Funktion zuerst von den Studierenden (Hauptrolle) vorgeschlagen und von anderen Stakeholdern unterstützt wurde. Wenn wir die Details der Benutzerstory genauer untersuchen, stellen wir fest, dass einige Informationen von den anderen Stakeholdern zurückgehalten wurden, die als unterstützende Rolle in der Benutzerstory beteiligt sind.

In der Realität mögen einige Studierende die Einschränkungen, die von den „unterstützenden Rollen“ gesetzt werden, nicht oder wollen sie gar nicht. Zum Beispiel möchte ein Studierender, der ein Passwort vergessen hat und es dreimal falsch eingegeben hat, möglicherweise nicht den Prozess zur Passwortzurücksetzung durchlaufen, aber dennoch das Vertrauen haben, mehrmals erneut zu versuchen, oder Studierende möchten keine Beschränkung für Bibliotheksbücher oder Ausleihzeiträume haben, und so weiter. Wer Geschäftsregeln und Einschränkungen für die vorgeschlagenen Funktionen als sein Benutzerziel festlegen möchte, sind genau diejenigen, die als unterstützende Rollen in der Benutzerstory beteiligt sind. Die Funktion sollte gar nicht funktionieren, wenn die Geschäftsregeln und das zweite Ziel nicht auf die vorgeschlagene Funktion angewendet werden. Wenn wir das Epic horizontal nach den Zielen der sekundären Akteure in eine Gruppe von Benutzerstories aufteilen, können wir sowohl die Ziele der sekundären Akteure erfüllen, die Benutzerstory testbar machen und direkt von der richtigen Person Feedback erhalten.

Lassen Sie uns die Informationen aus den Abschnitten Umwandlung und Bestätigung untersuchen, um zu sehen, wie wir die größere Geschichte „Kurs anmelden“ in eine Gruppe verwandter Benutzerstories aufteilen können.

1. Der Student muss ein registrierter Student sein. Wenn nicht, erhält er/sie nicht das von der Benachrichtigung für neue Studierende bereitgestellte Zugangsrecht. Wenn er die Benachrichtigung erhalten hat, aber das Konto noch nicht aktiviert wurde, muss er/sie das neue Konto online registrieren (als rot umkreist 1 markiert)
2. Wenn wir den Anmeldevorgang etwas tiefer untersuchen, wissen wir, dass ein Student, der die Zugangsdaten dreimal falsch eingegeben hat, in den „Passwortzurücksetzungsprozess“ eintreten muss (als rot umkreist 2 & 3 markiert)

Allgemeiner Bereich für Benutzerstories

Lassen Sie uns diese Benutzerstories in UeXceler erstellen:

Die Benutzerstory „Anmelden“ wird im allgemeinen Bereich für Benutzerstories erstellt. Zusätzlich zu den Anmelbebenen-Userstories werden zwei weitere verwandte Benutzerstories ebenfalls im allgemeinen Bereich für Benutzerstories erstellt, nämlich die Benutzerstories „Passwort zurücksetzen“ und „Neues Studentenkonto erstellen“ aus folgenden Gründen:

• Falls der Student die Kontozugangsdaten dreimal falsch eingibt, wird die Benutzerstory „Passwort zurücksetzen“ ausgelöst;
• Und falls ein neuer Student noch kein Studentenkonto angelegt hat, könnte er/sie die Benutzerstory „Neues Studentenkonto erstellen“ innerhalb des Anmeldebildschirms auslösen.

1. Als Student möchte ich mich im Studentenportal anmelden, damit…
2. Als Portal-Administrator möchte ich überprüfen, dass die Person, die sich anmeldet, ein registrierter Student ist, damit…
3. Als Kursleiter möchte ich die Eignung überprüfen, bevor ich den ausgewählten Kurs in den Studentenzeitplan aufnehmen lasse, damit…

Wir können diese drei Benutzerstories als horizontale Aufteilung aus dem Epik „Kurs anmelden“ betrachten, doch diese Benutzerstories erfüllen das Ziel einiger unterstützender Akteure, von denen Sie Rückmeldungen erhalten und bestätigen können. Würden die Voraussetzungen nicht erfüllt sein, wäre die Hauptbenutzerstory überhaupt nicht mehr sinnvoll.

Sie sehen, dass wir alle diese Benutzerstories im allgemeinen Bereich für Benutzerstories untergebracht haben, und der Grund dafür ist, dass sie wahrscheinlich die gleichen Voraussetzungen mit anderen verwandten Funktionen (Benutzerstories) auf derselben Aufrufseite teilen, wie beispielsweise „Zeitplan anzeigen“, „Zeitplan bearbeiten“, „Kurse abmelden“ usw.

Use-Case-Abteilungen

In der obenstehenden Abbildung sind drei verbleibende rot umrandete Markierungen mit den Nummern 4, 5 und 6 zu sehen. Sie stellen die alternativen Szenarien des Epics „Kurs anmelden“ dar. Falls eine dieser drei Bedingungen nicht erfüllt ist, tritt ein alternatives Szenario auf und kann als aufgeteilte Benutzerstory dargestellt werden. Vielleicht könnten wir sie entweder horizontal oder vertikal aufteilen, aber ist es nicht immer vorzuziehen, vertikal zu teilen? Nicht unbedingt – es hängt wirklich von der Situation ab. Es gibt keine universell passende Lösung in der Welt, wir müssen prüfen, welche Herangehensweise für Ihren Fall besser geeignet ist. Lassen Sie mich dies etwas weiter ausführen.

Zum Beispiel, wenn Sie die Hauptbenutzerstory einem Entwickler zuweisen und die drei Benutzerstories „Anmelden“, „Neues Konto erstellen“ und „Passwort zurücksetzen“ einem anderen Entwickler zuweisen. Sie könnten bevorzugen, dass der Entwickler, der für die Hauptbenutzerstory verantwortlich ist, zuerst das glückliche Szenario im aktuellen Sprint entwickelt und die alternativen Szenarien schrittweise in den folgenden Sprints durch denselben Entwickler weiterentwickelt (falls der Zeitrahmen dies zulässt). Doch wenn der Zeitrahmen kurz ist und gleichzeitig der Eindruck entsteht, dass es für denselben Entwickler zu viel ist, die gesamte Epik zu bewältigen, können Sie sie horizontal in Aufgaben aufteilen, um sie gleichzeitig an mehrere Entwickler zu verteilen.

Aufteilung des Epics in Szenarien

Wenn wir die Details des in der Bestätigungsschnitt des Epics beschriebenen Szenarios betrachten, können wir leicht die vertikalen Slices für eine Gruppe verwandter Benutzerstories finden.

1. Als Kursleiter möchte ich die Voraussetzungen überprüfen, bevor ich den ausgewählten Kurs in den Studentenzeitplan aufnehmen lasse, damit…
2. Als Kursleiter möchte ich die Kursverfügbarkeit überprüfen, bevor ich den Kurs in den Studentenzeitplan aufnehmen lasse, damit…
3. Als Kursleiter möchte ich die Zeitfensterverfügbarkeit des Studenten überprüfen, bevor ich den ausgewählten Kurs in den Studentenzeitplan aufnehmen lasse, damit…

Aufteilung des Epics in Aufgaben

Wenn wir das Epik in kleinere Aufgaben aufteilen möchten, um parallel in derselben Sprint-Phase zu entwickeln, wie folgt:

1. Überprüfung des Kurs-Kontingent-Status
2. Überprüfung der Kursvoraussetzungen
3. Überprüfung des Zeitfensters

Jetzt liegt es ganz bei Ihnen, wie Sie das Epik in Benutzerstories für den agilen Entwicklungsprozess aufteilen möchten. Sie sehen, dass die Benutzerstory „Kurs anmelden“ und ihre verwandten Benutzerstories in einer Use-Case-Abteilung (Ihr Epik) untergebracht sind, die ebenfalls „Kurs anmelden“ genannt wird und als Platzhalter dient, um alle Hauptbenutzerstories und die aus der Hauptbenutzerstory abgeleiteten Benutzerstories aufzunehmen.