de_DE

Scrum-Prozess: Von Product-Backlog-Einträgen zum lieferbaren Produktinkrement

Table of Contents hide
1 Entwicklung
2 Überprüfung
3 Automatisiertes Testen
4 Zusammenfassung

Ziel der täglichen Arbeit eines Sprints ist es, ein versandfähiges Produktinkrement für das Produkt in einer Form zu erstellen, die an einen Kunden oder Benutzer geliefert werden kann.

Im Kontext eines einzelnen Sprints bedeutet ein Produktinkrement oder auslieferbares Inkrement, dass ein Arbeitsprodukt gemäß der Projektdefinition entwickelt, integriert, getestet und dokumentiert wurde und als bereit für die Veröffentlichung gilt.

Das Entwicklungsteam kann dieses Produkt am Ende des Sprints veröffentlichen oder nicht – der Zeitpunkt der Veröffentlichung hängt vom Veröffentlichungsplan ab. Das Projekt kann mehrere Sprints erfordern, bevor das Produkt den Satz an marktfähigen Mindestprodukten (MMP) enthält, der erforderlich ist, um eine Marktfreigabe zu rechtfertigen.

Um versandfähige Funktionen zu erstellen, sind das Entwicklungsteam und der Product Owner an drei Hauptaktivitäten beteiligt:

Ausarbeiten

In einem agilen Projekt ist Elaboration der Prozess, bei dem die Details einer Produktfunktion festgelegt werden. Immer wenn das Entwicklungsteam eine neue User Story in Angriff nimmt, stellt die Ausarbeitung sicher, dass alle unbeantworteten Fragen zu einer User Story beantwortet werden, damit der Entwicklungsprozess fortgesetzt werden kann.

Der Product Owner arbeitet mit dem Entwicklungsteam zusammen, um User Stories auszuarbeiten, aber das Entwicklungsteam sollte das letzte Wort bei Designentscheidungen haben. Der Product Owner sollte im Laufe des Tages für Rückfragen zur Verfügung stehen, wenn das Entwicklungsteam weitere Klärungen zu den Anforderungen benötigt.

Entwicklung

Während der Produktentwicklung fällt die meiste Aktivität natürlich dem Entwicklungsteam zu. Der Product Owner arbeitet bei Bedarf weiterhin mit dem Entwicklungsteam zusammen, um Klarheit zu schaffen und die entwickelte Funktionalität zu genehmigen. Während des Sprints:

  • Koppeln Sie Mitglieder des Entwicklungsteams, um Aufgaben zu erledigen. Dies verbessert die Qualität der Arbeit und fördert den Austausch von Fähigkeiten.
  • Befolgen Sie die vereinbarten Designstandards des Entwicklungsteams. Wenn Sie sie aus irgendeinem Grund nicht befolgen können, überprüfen Sie diese Standards erneut und verbessern Sie sie.
  • Beginnen Sie mit der Entwicklung, indem Sie automatisierte Tests einrichten. Mehr über automatisiertes Testen finden Sie im folgenden Abschnitt und in Kapitel 15. Wenn während der Entwicklung neue, nette Funktionen auftauchen, fügen Sie sie dem Produkt-Backlog hinzu. Vermeiden Sie es, neue Funktionen zu programmieren, die außerhalb des Sprintziels liegen.
  • Integrieren Sie Änderungen, die während des Tages codiert wurden, einen Satz nach dem anderen. Test auf 100-prozentige Korrektheit. Integrieren Sie Änderungen mindestens einmal täglich; Manche Teams integrieren sich mehrmals am Tag. Führen Sie Codeüberprüfungen durch, um sicherzustellen, dass der Code den Entwicklungsstandards entspricht. Identifizieren Sie Bereiche, die überarbeitet werden müssen. Fügen Sie die Überarbeitungen als Aufgaben im Sprint-Backlog hinzu.
  • Erstellen Sie während der Arbeit technische Dokumentationen. Warten Sie mit einem Release nicht bis zum Ende des Sprints oder schlimmer noch bis zum Ende des Sprints.

Überprüfung

Die Überprüfung der in einem Sprint geleisteten Arbeit besteht aus drei Teilen: automatisiertes Testen, Peer-Review und Product-Owner-Review. Das Team kann Folgendes durchführen:

Automatisiertes Testen

Automatisiertes Testen bedeutet, dass ein Computerprogramm den Großteil Ihrer Codetests für Sie durchführt. Mit automatisierten Tests kann das Entwicklungsteam schnell Code entwickeln und testen, was ein großer Vorteil für agile Projekte ist. Häufig programmieren agile Projektteams tagsüber und lassen die Tests über Nacht laufen. Am Morgen kann das Projektteam den vom Testprogramm generierten Fehlerbericht überprüfen, während des täglichen Scrums über Probleme berichten und diese Probleme sofort im Laufe des Tages beheben.

  • Automatisiertes Testen kann Folgendes umfassen: Unit-Tests: Testen des Quellcodes in seinen kleinsten Teilen – der Komponentenebene
  • Systemtest: Testen des Codes mit dem Rest des Systems
  • Statisches Testen: Überprüfen, ob der Code des Produkts den Standards entspricht, basierend auf Regeln und Best Practices, auf die sich das Entwicklungsteam geeinigt hat

Peer-Review

Peer-Review bedeutet einfach, dass die Mitglieder des Entwicklungsteams den Code der anderen überprüfen.

Product Owner Bewertung

Wenn eine User Story entwickelt und getestet wurde, verschiebt das Entwicklungsteam die Storys in die Spalte Akzeptieren auf dem Taskboard. Der Product Owner überprüft dann die Funktionalität und stellt sicher, dass sie die Ziele der User Story gemäß den Akzeptanzkriterien der User Story erfüllt. Der Product Owner überprüft jeden Tag User Stories.

Zusammenfassung

Das Entwicklungsteam berichtet über den Aufgabenfortschritt, indem es das Sprint-Backlog aktualisiert, mit dem Aufgaben abgeschlossen wurden und wie viel Arbeit in Stunden für neu gestartete Aufgaben noch zu erledigen ist. Abhängig von der Software, die das Scrum-Team verwendet, aktualisieren die Sprint-Backlog-Daten möglicherweise auch automatisch das Sprint-Burndown-Diagramm.

Andere Scrum-Artikel

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht.