Grundlagen von Agile Development

Freigeben Version: Yokohama

Aktualisiert 30. Januar 2025

5 Minuten Lesedauer

Scrum ist eine der beliebtesten Methoden von Agile Development, Der einen festen Sprint-Zeitplan und regelmäßige Anforderungstests umfasst. Diese Aktivitäten werden von allgemeinen Rollen wie Produktbesitzer, Scrum-Master und Gruppenmitglieder ausgeführt. Erfahren Sie mehr über die Grundlagen von Agile DevelopmentProzess.

Scrum-Framework

Machen Sie sich mit der Terminologie und den Artefakten vertraut, die in verwendet werden Agile Development.

Zuweisungsgruppe oder agiles Team

Gruppe von Anwendern, die an der Arbeit und dem Abschluss der Entwicklung für ein agiles Produkt beteiligt sind. In Agile Development 2.0, Dieses Team wird als Zuweisungsgruppe bezeichnet.

In einer Zuweisungsgruppe wird ein Anwender als Scrum-Master festgelegt, der dafür verantwortlich ist, sicherzustellen, dass alle Scrum-Aktivitäten für ein Release ordnungsgemäß ausgeführt werden. Weitere Informationen finden Sie unter Zuweisungsgruppen in Agile Development 2.0.

Epic

Allgemeine Definition einer Anforderung, die dem Unternehmen einen Mehrwert bietet, z. B. eine neue Funktion oder eine wesentliche Erweiterung. Epics sind in Agile Stories unterteilt und können von einem oder mehreren Teams bearbeitet werden.

Story

Kurze, verwaltbare Arbeiten, die sich auf ein Epic beziehen. Stories erfassen auf einfache und präzise Weise, wer, was und warum einer Anforderung ist. Mithilfe der Beschreibung und der Kriterien, die in den Stories erwähnt werden, können Teams den Aufwand genau schätzen, der für die Implementierung der Arbeit in der IT erforderlich ist.

Scrum-Aufgabe

Eindeutige Aufgaben, die zum Abschließen einer Story erforderlich sind. Eine Aufgabe erfordert möglicherweise 4 bis 12 Stunden.

Backlog

Liste der Arbeiten, die implementiert werden müssen, um bestimmte Ergebnisse zu erzielen. Backlog enthält Arbeiten im Zusammenhang mit neuen Funktionen, Erweiterungen vorhandener Funktionen und anderen Aktivitäten der Produktentwicklung.

Backlog wird als einzelne Arbeitsquelle für ein Produkt oder Team betrachtet. Alles, was nicht im Backlog enthalten ist, wird für die Entwicklung nicht priorisiert.

Persönlicher Backlog

Produktbesitzer definieren eine personalisierte Arbeits-Pipeline, die als persönlicher Backlog bezeichnet wird, indem sie relevante Filterkriterien anwenden. In Agile Development 2.0, Produktbesitzer können beliebig viele personalisierte Backlogs definieren. Die zum Erstellen des personalisierten Backlogs verwendeten Kriterien sind flexibel und können jederzeit geändert werden.

Sprints

Kurze, feste Zeiträume, in denen Teammitglieder eine bestimmte Anzahl von Stories auswählen und abschließen. Diese kurzen, zeitlich vorgegebenen Zyklen bieten den Teams die Flexibilität, sich an sich ändernde Prioritäten anzupassen.

Die Häufigkeit der Wiederholung für einen Sprint wird von den Entwicklungsteams und den Produktbesitzern festgelegt. Beispiel: Ein 10-tägiger Sprint oder ein 1-wöchiger Sprint.

Sprint-Backlog

Arbeitsumfang für einen Sprint. Produktbesitzer und ihre Entwicklungsteams verwenden die Sprint-Planungsaktivität, um ihren Backlog zu überprüfen und zu entscheiden, welche Stories für einen Sprint erfasst werden sollen.

Design

Fokusbereich mit zugehörigem Geschäftsnutzen. Ein Design bezieht sich auf mindestens eines der Ziele des Unternehmens. Designs helfen Ihnen, Ihre Arbeit auf hoher Ebene zu priorisieren und können mehreren Epics zugeordnet werden.

Produkt

Entität zum Organisieren von Designs, Epics und Stories mit ähnlichen Funktionen in einem einzelnen Kontext. Ein Produkt stellt ein Element oder eine Funktion dar, die entwickelt und auf den Markt gebracht werden soll.

Freigeben

Ein Release hat ein Start- und Enddatum, an dem mehrere Entwicklungsiterationen abgeschlossen werden. Releases werden von einem Produktbesitzer erstellt und enthalten Anwenderstorys, manchmal aus mehreren Produkten und können auch mehrere Teams umfassen. Die einem Release zugeordneten Stories bilden ihren Release-Backlog.

Hinweis:

In Agile Development 2.0Stellen Sie sicher, dass Sie ein Produkt erstellen, bevor Sie Designs, Epics oder Stories erstellen. Sie können diese Datensätze nicht übermitteln, ohne sie an ein Produkt anzuhängen.

Nachdem Sie Stories und Scrum-Aufgaben für Ihre Produkte erstellt haben, können Sie einen personalisierten Backlog erstellen, der die Stories aus einem oder mehreren dieser Produkte enthält.

Fehler

Fehler können verwendet werden, um die Lösung von Problemen zu melden und nachzuverfolgen, die während der Entwicklung einer neuen Funktion festgestellt werden, oder als Feedback für vorhandene Funktionen. Produktbesitzer überprüfen dann diese Fehler und entscheiden, Stories für sie zu erstellen, die den relevanten Zuweisungsgruppen zugewiesen werden.

Mit Agile Development – Unified Backlog, Sie können eine Selektierungstafel einrichten, um einen zentralisierten Backlog für Datensätze verschiedener Aufgabentypen zu verwalten, z. B. Fehler, Stories und Erweiterungen. Weitere Informationen finden Sie unter Agile Development – Unified Backlog.

Erweiterungen

Erweiterungsanforderungen können verwendet werden, um Funktionserweiterungen für ein Produkt zu protokollieren. Diese Anforderungen können sich aus internen Anforderungen oder Kundenfeedback ergeben. Produktbesitzer überprüfen diese protokollierten Anforderungen und entscheiden anhand der Priorität, Stories für sie zu erstellen. Diese Stories werden dann den relevanten Zuweisungsgruppen für die Entwicklung zugewiesen.

Scrum-Aktivitäten

Der Scrum-Prozess besteht normalerweise aus den folgenden Aktivitäten.

Sprint-Planung

Mitglieder der Zuweisungsgruppe treffen sich, um über die Stories zu entscheiden, die sie im Sprint bereitstellen können. Normalerweise werden zuerst die Stories mit den besten Rangfolgen festgelegt. Die Gruppe entscheidet, welche Scrum-Aufgaben für jede Story erforderlich sind. Der Produktbesitzer muss anwesend sein, um Fragen zu beantworten.

Täglicher Stand-up

Mitglieder der Zuweisungsgruppe treffen sich, um den Fortschritt ihrer Arbeit vom vorherigen Tag, die für den aktuellen Tag geplante Arbeit und alle Blocker zu besprechen. Der tägliche Standup sorgt dafür, dass sich die Gruppenmitglieder darauf konzentrieren, die Stories für den aktuellen Sprint abzuschließen, und informiert den Scrum-Master über alle Blocker.

Am Ende des Sprints sollten alle Stories abgeschlossen sein. Alle unvollständigen Stories werden zurück in den Backlog oder in einen zukünftigen Sprint verschoben.

Sprint-Überprüfungen

Sprint-Überprüfungssitzungen finden am Ende jedes Sprints statt. In diesen Besprechungen überprüft die Zuweisungsgruppe die abgeschlossene Arbeit und demonstriert ihrem Produktbesitzer die neu entwickelten Funktionen.

Sprint-Retrospektiven

Am Ende jedes Sprints wird ein Retrospektivmeeting durchgeführt, um die Diskussion zwischen den Gruppenmitgliedern darüber zu erleichtern, was gut gelaufen ist und was nicht. Das Ziel einer Sprint-Retrospektive besteht darin, Möglichkeiten zur Verbesserung der Ausführung zukünftiger Sprints zu besprechen.

Für Details zur Vorgehensweise Agile Development 2.0Kann Ihnen helfen, Ihre Bemühungen bei der Produktentwicklung zu verwalten, siehe Agile Development Prozess-Flow.

Scrum-Berichte

Scrum-Berichte helfen Ihnen, die Leistung und den Fortschritt Ihres agilen Teams zu analysieren. Diese Berichte können sich auf ein Epic, einen Sprint oder ein Release beziehen und Verlaufsdaten zur Arbeitsgeschwindigkeit Ihres Teams bereitstellen. Performance Analytics Das Inhaltspaket für Agile 2,0 bietet vorkonfigurierte Dashboards mit Datenvisualisierungen, um Sie bei der Verbesserung Ihrer agilen Praktiken zu unterstützen.

Weitere Informationen finden Sie unter Performance Analytics Inhaltspaket für Agile 2,0.