Arbeiten mit Scrum

Benutzer Geschichte

User Stories sind eine effektive Möglichkeit, Anforderungen an Software in der Entwicklung darzulegen. Solche Geschichten enthalten kurze Ratschläge im Namen des Benutzers der Software.

Da in der Scrum-Methodik das Setzen von Zielen in der Regel das Vorrecht des Kunden oder Softwarebesitzers ist, gelten sie als die wichtigste Möglichkeit, den Entwicklungsprozess zu beeinflussen. Für jede User Story gelten Einschränkungen hinsichtlich der Textmenge und der Komplexität der Präsentation. Geschichte wird meist auf einem kleinen Blatt geschrieben, was den Umfang an sich schon begrenzt.

Dank User Stories können Sie die Wünsche des Kunden dokumentieren und schnell auf Marktanforderungen reagieren.

Die User Story sollte als vereinfachtes Maß für Anforderungen betrachtet werden, da sie kein Abnahmetestverfahren beinhaltet. Die Erstellung der User Story muss dem Zulassungsverfahren entsprechen. Dadurch wird sichergestellt, dass die User Story ihr Ziel erreicht.

Die Story-Struktur sieht so aus: „Als Benutzer <Benutzertyp> möchte ich <Aktion> ausführen, um <Ergebnis> zu erhalten“ (Als Produktbesitzer möchte ich ...). Eine solche Struktur ist nicht nur einfach, sondern auch für jeden verständlich.

Vorteile der Verwendung von User Stories:

• Geschichten sind klein und einfach zu erstellen.
• Helfen Sie allen Beteiligten, die Arbeit am Projekt und seine Unterstützung zu besprechen.
• Erfordern keine ständige Wartung.
• Nur bei Verwendung relevant.
• Verbessern Sie die Interaktion mit dem Kunden.
• Dank ihnen können Sie das Projekt in kleine Phasen unterteilen.
• Erleichtern Sie die Arbeit an Projekten mit unzureichend verstandenen Anforderungen.
• Vereinfachen Sie die Aufgabenbewertung.

Nachteile von User Stories:

• Ohne vorherige Vereinbarung können Verfahren es schwierig machen, sie als Grundlage für eine Vereinbarung zu verwenden.
• Ihr Einsatz erfordert während des gesamten Projekts einen engen Kontakt mit dem Auftraggeber, was den Arbeitsablauf mitunter erschwert.
• Sie haben Nachteile bei der Skalierung auf große Projekte.
• Steht in direktem Zusammenhang mit dem professionellen Niveau der Entwickler.
• Wird zum Starten einer Diskussion verwendet, beendet diese jedoch möglicherweise nicht und wird nicht zur Systemdokumentation verwendet.

Rückstand

Beim Product Backlog handelt es sich um die aktuellen Aufgaben in Form einer Liste, geordnet nach Priorität. Die Liste wird auf Basis der Roadmap (Roadmap) des Projekts und der darin festgelegten Punkte erstellt. Die wichtigsten Aufgaben stehen meist ganz oben auf der Liste. Dies ist notwendig, um zu verstehen, welche Arbeiten zuerst durchgeführt werden sollten.

Das Entwicklungsteam wählt die Geschwindigkeit der Erledigung von Backlog-Aufgaben unabhängig von den Wünschen des Kunden, sondern auf Basis seiner Qualifikationen und Erfahrungen aus vergangenen Sprints. Es ist äußerst unerwünscht, Programmierer „anzupassen“. Das Team selbst wählt Aufgaben aus dem Backlog nach seinen eigenen Überlegungen und Fähigkeiten aus. Die Ausführung erfolgt ohne Unterbrechung (Kanban) oder mehrere Iterationen (Scrum).

Zwei wichtige Rückstandsbedingungen

Der Kern eines Product Backlogs besteht aus einer Roadmap, Vorschlägen und Ausführungsbedingungen. Epics enthalten Bedingungen und User Story. Schauen wir uns ein typisches Roadmap-Beispiel genauer an.

Die Erstellung der Website „Teams in Space“ ist der erste Vorschlag der Roadmap. Es muss in Epics (in der Abbildung sind sie in den Farben Grün, Blau und Türkis dargestellt) und eine User Story für jedes Epic unterteilt werden.

Der Softwarekunde bildet aus mehreren User Stories eine Liste. Bei Bedarf kann er die Reihenfolge ändern, in der die Geschichten ausgeführt werden, sodass sich die Entwickler zunächst mit einem der wichtigsten Epen befassen (links) oder prüfen, wie die vergünstigte Ticketbuchung funktioniert. Dazu müssen Sie Geschichten aus Epen umsetzen (rechts). Beide Optionen sind unten zu sehen.

Welche Faktoren sollte der Kunde priorisieren?

• Relevanz für Benutzer.
• Das Vorhandensein von Feedback.
• Komplexität der Entwicklung.
• Die Beziehung zwischen Aufgaben (um „B“ abzuschließen, müssen Sie zuerst „A“ erledigen).

Die Prioritäten bei der Arbeit werden vom Kunden festgelegt, andere Parteien können jedoch ihre Meinung dazu äußern. Der Erfolg des Backlogs hängt unter anderem von den Meinungen von Kunden und Programmierern ab. Gemeinsam können sie bessere Ergebnisse erzielen und eine pünktliche Lieferung des fertigen Produkts sicherstellen.

Wie man einen Rückstand behält

Wenn der Rückstand bereits erstellt wurde, müssen Sie ihn danach im Laufe der weiteren Arbeit regelmäßig ändern. Der Softwarekunde sollte vor jeder neuen Iterationsplanung sicherstellen, dass das Backlog ordnungsgemäß zusammengestellt wird. Dies wird dazu beitragen, Prioritäten zu klären oder nach der Analyse der letzten Iteration etwas zu ändern. Das Anpassen des Backlogs in Agile wird manchmal als „Grooming“, „Refinement“ oder „Backlog Maintenance“ bezeichnet.

Wenn der Rückstand bereits relativ groß ist, muss der Kunde Aufgaben nach kurzfristiger und langfristiger Ausführung gruppieren. Kurzfristige Einsätze sollten geprüft werden, bevor ihnen dieser Status verliehen wird. Sie müssen eine User Story verfassen und alle Nuancen innerhalb des Teams herausfinden.

Bei langfristigen Aufgaben ist es äußerst wünschenswert, dass die Entwickler ihre Einschätzung abgeben. Dies erleichtert die Priorisierung. Vielleicht ändert sich etwas, aber das Team wird sein Verständnis für die Aufgaben verbessern und die Arbeit schneller erledigen.

Der Backlog ist ein wichtiger Bestandteil zwischen dem Kunden und dem Programmierteam. Der Kunde kann die Prioritäten jederzeit ändern, basierend auf Kundenfeedback, Prognosen oder neuen Anforderungen.

Es wird empfohlen, Änderungen direkt im laufenden Betrieb zu vermeiden. Dies wirkt sich negativ auf den Arbeitsablauf und die emotionale Verfassung der Programmierer aus.

Sprint

Ein Sprint ist ein kurzer Zeitraum, in dem ein vorher vereinbarter Arbeitsumfang erledigt werden muss. Sprints basieren auf Scrum- und Agile-Methoden. Die Auswahl der richtigen Sprints hilft einem agilen Team bei der Entwicklung hochwertiger Software.

„Mit Scrum kann man ein Produkt in mehreren Iterationen mit klarer Dauer entwickeln – Sprints. Es hilft dabei, große Projekte in kleinere Aufgaben zu zerlegen“, sagt Megan Cook, Jira Lead bei Atlassian.

Wie plant und führt Scrum Sprints durch?

Laut den Autoren der Scrum-Methodik müssen sich alle zu einem separaten Meeting treffen, um den zukünftigen Sprint zu planen. Bei dieser Veranstaltung müssen die Teammitglieder Antworten auf zwei Hauptfragen finden: Was muss in diesem Sprint getan werden und wie geht das am besten?

An der Festlegung der Liste der Arbeitsaufgaben sind der Softwarekunde, der Scrum-Master und die Programmierer beteiligt. Der Kunde erklärt das Ziel des Sprints und Aufgaben aus dem Backlog.

Anschließend entwickelt das Team einen Plan, nach dem die Aufgaben im Sprint erledigt werden. Dieser Plan wird zusammen mit den ausgewählten Arbeitselementen als Sprint-Backlog bezeichnet. Nach der Planungsbesprechung macht sich das Team an die Arbeit. Entwickler wählen Aufgaben aus dem Backlog aus. Sobald die Arbeit abgeschlossen ist, ändert sich der Status jeder Aufgabe von „In Bearbeitung“ zu „Fertig“.

Während des Sprints hält das Team tägliche Scrum-Meetings (Stand-Ups) ab, um aktuelle Themen und Fortschritte zu besprechen. Solche Treffen sind erforderlich, um Schwierigkeiten zu identifizieren, die sich auf den Abschluss des Sprints auswirken können.

Ist der Sprint abgeschlossen, zeigt das Team die Ergebnisse seiner Arbeit auf der Ergebnisübersicht (Demo). Jeder Teilnehmer des Projekts kann sich mit den Ergebnissen vertraut machen. Bevor der fertige Code in die Produktionsumgebung eingebunden wird, sollte eine Einarbeitung erfolgen.

Die Retrospektive schließt den Zyklus der Sprints ab. Darauf identifiziert das Team Bereiche, die in einem zukünftigen Sprint verbessert werden müssen.

Worauf man achten sollte und was man nicht tun sollte

Den meisten jungen Teams fällt es schwer, Sprints zum ersten Mal in ihren Workflow einzuführen. Um Probleme zu vermeiden, empfehlen wir Ihnen, die Liste der Aktionen zu überprüfen, die vorrangige Aufmerksamkeit erfordern.

Was müssen wir machen:

• Überprüfen Sie, ob das Team den Zweck des Sprints versteht und weiß, wie er erfolgreich sein wird. Dies ist notwendig, damit alle gemeinsam ein erfolgreiches Ergebnis erzielen können.
• Sie sollten einen klaren und verständlichen Rückstand haben. Wenn der Rückstand nicht korrekt gepflegt wurde, kann dies zu einem Problem werden, das den Arbeitsablauf beeinträchtigen kann.
• Stellen Sie sicher, dass Ihre Schätzung des Arbeitstempos korrekt ist und berücksichtigen Sie dabei Sommerferien und andere Faktoren.
• Beteiligen Sie sich aktiv an der Sprintplanung. Ermutigen Sie die Teammitglieder, den Plan für Storys, Bugs und Aufgaben zu erweitern.
• Lehnen Sie Aufgaben ab, bei denen Entwickler keine Abhängigkeitsprobleme lösen können.
• Nachdem der Plan genehmigt wurde, ernennen Sie einen Mitarbeiter, der für die Eingabe von Daten in das Projektmanagementprogramm (Jira-Karten usw.) verantwortlich ist.

Was man vermeiden sollte:

• Übertreiben Sie es nicht mit einer großen Anzahl von Storys, schätzen Sie das Arbeitstempo nüchtern ein und weisen Sie keine Aufgaben zu, die in einem Sprint nur schwer zu erledigen sind.
• Achten Sie auf die Qualität Ihrer Arbeit. Prüfen Sie, ob Sie genügend Zeit für die Qualitätskontrolle und die Behebung von Fehlern im Code haben.
• Stellen Sie sicher, dass alle Teammitglieder den Inhalt des Sprints klar verstehen. Jagen Sie nicht der Geschwindigkeit hinterher. Das gesamte Team muss an einem Strang ziehen.
• Überfordern Sie Entwickler nicht mit zusätzlicher Arbeit. Ein weiterer Sprint folgt bald.
• Äußert das Team Bedenken hinsichtlich der Arbeitsbelastung oder der Frist, sollten Sie deren Meinung berücksichtigen. Behandeln Sie Probleme und beheben Sie sie gegebenenfalls.

Scrum-Board

Das Scrum Board ist ein Tool, das zeigt, wie die Arbeit des Scrum-Teams erledigt wird. Auf einer solchen Tafel können Sie Informationen auf Papier, an der Wand oder in elektronischer Form (JIRA, Trello) anzeigen.

Ein Scrum-Board hat mindestens drei Spalten: „Zu erledigen“, „In Bearbeitung“ und „Fertig“. Hier ist ein Beispielboard:

Das Scrum-Board enthält alle Informationen aus dem Backlog, die zuvor zur Planung freigegeben wurden. Geschäftsaufgabenkarten werden in der Regel nach Priorität von oben nach unten an die Tafel gepinnt. Sie können sie in bestimmte Arten von Arbeiten unterteilen (Arbeiten an Code, Design und anderen).

Nachdem ein Teil der Arbeit erledigt ist, wird die Karte über die Tafel in die nächste Spalte verschoben. Um den Fortschritt der Teamarbeit sichtbar zu machen, hilft die „verbleibende Arbeit“ pro Tag im Burndown-Diagramm.

Sie können auch eine Flipchart-Tafel verwenden. Darauf werden die Namen der Werke auf Papieraufkleber geschrieben und an der Tafel befestigt. Sobald die Arbeit abgeschlossen ist, werden die Aufkleber in eine andere Spalte verschoben.

Burndown-Diagramm

Das Burndown-Diagramm zeigt den Umfang der geleisteten Arbeit und den Umfang der verbleibenden Arbeit. Es wird täglich aktualisiert und steht allen Interessierten zur Verfügung. Die Grafik wird benötigt, um den Fortschritt der Arbeit am Sprint darzustellen.

Es gibt zwei Arten von Diagrammen:

• Burndown-Diagramm, das den Arbeitsfortschritt in einem Sprint zeigt.
• Burndown-Diagramm, das den Fortschritt der Arbeit bis zur Veröffentlichung des Produkts zeigt (Daten werden aus mehreren Sprints zusammengefasst).

Diagrammbeispiel:

Dieses Beispiel nutzt die Psychologie: Das Diagramm zeigt nicht die Anzahl der erledigten Aufgaben, sondern die Anzahl der verbleibenden (nicht erledigten) Aufgaben.

Das heißt, wenn das Team 90 von 100 Aufgaben erledigt hat, entsteht möglicherweise das falsche Gefühl, dass alles bereit ist. Schließlich ändert der Fortschritt von 90 auf 100 Aufgaben nicht wirklich etwas.

Wenn Sie die Anzahl der verbleibenden Aufgaben anzeigen, werden Sie feststellen, dass diese von Mal zu Mal kleiner werden. Dies spornt die Projektbeteiligten unbewusst an, schneller ans Ziel zu kommen – es sollten keine unerledigten Aufgaben auf der Tafel verbleiben.