Scrum Rituale: Sprint Demo

Scrum Sprint Demo: Eine umfassende Anleitung

Key Takeaways: Die Sprint -Demo zeigt abgeschlossene Sprint -Arbeiten und ermöglicht es dem Produktbesitzer, gegen Akzeptanzkriterien zu validieren. Es klärt die abgeschlossene Arbeit, verbessert die Schätzung und informiert die Geschwindigkeit des Teams. Der Fokus liegt auf nachweisbarem Wert, nicht auf technischen Details oder Problemen (die in die Retrospektive gehören). Angenommene Funktionen werden dann gemäß einem nachhaltigen Zeitplan integriert (freigegeben).

(Dieser Abschnitt basiert auf Scrum: Anfänger zu Ninja von M. David Green. In Stores und als eBook verfügbar.)

Die Sprint -Demo, die zum Schluss des Sprint stattfindet, ist ein entscheidendes Ritual. Das Entwicklungsteam demonstriert abgeschlossene Arbeiten, während der Produktbesitzer die Fertigstellung gegen Akzeptanzkriterien bewertet und jede Geschichte akzeptiert oder ablehnt. Dies liefert ein klares Bild des Sprint -Fortschritts und verfeinert die zukünftige Schätzung.

Sprint -Demo -Ziele:

Das Hauptziel ist es, die Ausgabe des Sprints und den aktualisierten Zustand des Produkts nach der Integration zu verstehen. Akzeptierte Geschichten bestimmen die Geschwindigkeit des Teams und verbessern zukünftige Sprint -Rückstände.

Gäste bei der Sprint -Demo:

Während Gäste willkommene Beobachter sind, sollte ihre Anwesenheit die Ziele oder den Zeitraum der Demo nicht stören. Sie sind Beobachter, keine Teilnehmer, es sei denn, das Feedback wird aktiv eingestuft.

Zeitbox der Sprint -Demo:

Zeitzuweisung hängt von der Anzahl und Komplexität der abgeschlossenen Geschichten ab. Ein halber Tag ist für zweiwöchige Sprints üblich. Der Scrum Master sorgt dafür, dass die zugewiesene Zeit festhält.

kombiniert die Demo und Retrospektive:

Oft planen die Teams die Retrospektive am selben Tag, um die Produktivitätsstörung zu minimieren. Dies priorisiert jedoch Scrum-Artefakte vor der konkreten Produktentwicklung-ein Kompromiss, der sorgfältig berücksichtigt wird.

Vorbereitung auf die Sprint -Demo:

Die Demo zeigt alle "Done" -Stories, unabhängig vom Release -Status. Jedes Teammitglied sollte bereit sein, seine Arbeit zu erklären. Ein Treffen vor dem Demonstranten mit dem Produktbesitzer sorgt für die Übereinstimmung mit den Annahmekriterien und bereitet sich auf Demonstrationen vor. Die Scrum Master koordiniert die Vorbereitung und stellt sicher, dass die Demo in das Timebox passt.

produktbesitzergetriebene Demos:

Während die Ingenieure vorhanden sind, ist der Produktbesitzer Live -Tests von Vorteil. Ingenieure kennen den "glücklichen Weg", aber der Produktbesitzer identifiziert Kantenfälle und priorisiert die Akzeptanzkriterien, um umfassende Tests und Stakeholder -Engagement zu gewährleisten.

eine Geschichte demonstrieren:

Der Scrum -Master leitet den Prozess und überprüft systematisch jede Geschichte. Der Produktbesitzer liest die Geschichte und die Akzeptanzkriterien, während die Demo eingerichtet ist, um sicherzustellen, dass jeder die Erwartungen versteht. Die Demo konzentriert sich auf die funktionale Ergänzung des Produkts und demonstriert die Erfüllung jedes Akzeptanzkriteriums. Unzureichende Akzeptanzkriterien, die während der Demo identifiziert wurden, führen zu neuen Geschichten für zukünftige Sprints.

Vermeiden Sie eine detaillierte Diskussion über Probleme:

zwar wertvoll, detaillierte Diskussionen über Entwicklungsherausforderungen sollten in die Retrospektive verschoben werden. Die Konzentration auf das Produkt verhindert, dass die Demo in technischen Details festgefahren wird.

Tallying -Punkte und Geschwindigkeit:

Der Scrum Master berechnet die Geschwindigkeit des Sprints basierend auf Punkten, die den akzeptierten Geschichten zugewiesen sind. Abgelehnte oder unvollständige Geschichten werden verfolgt und ihr Status aktualisiert. Berichte, die den Fortschritt des Sprints zusammenfassen, werden häufig erzeugt.

die Geschichten veröffentlichen:

Veröffentlichung integriert abgeschlossene Funktionen in das Live -Produkt. Release -Methoden variieren; Einige Teams veröffentlichen sofort, während andere Geschichten für größere Veröffentlichungen gruppieren. Die kontinuierliche Integration unterstützt die sofortige Veröffentlichung und beseitigt die Veröffentlichungsschritte nach dem Demo.

kontinuierliche Integration:

Mit kontinuierlicher Integration sollten die Ingenieure eine Geschichte erst aufgeben, wenn sie veröffentlicht und getestet wird. Dies erfordert möglicherweise Zeit für Wartung und Verbesserung.

Veröffentlichungsplanung:

Veröffentlichungspläne sollten sich mit dem nachhaltigen Tempo des Teams und den Zielen des Produktbesitzers, nicht den willkürlichen Fristen des Teams anpassen. Vermeiden Sie es, die Fristen auf Kosten der Qualität einzuhalten. Priorisieren Sie bei Bedarf kritische Merkmale.

häufig gestellte Fragen (FAQs)

(Der FAQS -Abschnitt wurde für die Kürze weggelassen, da er die bereits im Haupttext bereits behandelten Informationen wiederholt.)

Das obige ist der detaillierte Inhalt vonScrum Rituale: Sprint Demo. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!