Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

Version 1 Nächste Version anzeigen »

 

Zusammenfassung

Die Release-Demonstration (in SCRUM "Sprint-Demo/Sprint Review") ist ein Format zur Vorstellung der umgesetzten Entwicklungspakete. In einem definierten Release Zeitraum können so ein, oder mehrere Entwicklungspakete zu einem Release Paket zusammengefasst werden. Die Projektbeteiligten werden zur Vorführung des funktionsfähigen Softwarestandes ggf. inklusive Hardwarestandes eingeladen.

Diese Demonstration umfasst hauptsächlich die Darstellung der Entwicklung aus der Sicht des Kunden über den verbesserten Nutzen/Wert des Produkts ((User-)Business-Value). Beispielsweise wäre dies die Vorführung von praktischen Anwendungsbeispielen, angelehnt an die umgesetzten User Stories.

 

Struktur / Ablauf

 

Als Veranstaltungsort sollte ein geeigneter Raum im Bezug auf die Größe, Bestuhlung und Präsentationsmöglichkeiten gewählt werden.

Der Product Owner bildet zusammen mit dem SCRUM-Master ein Organisationsteam. Während sich der Product Owner verstärkt auf die Inhalte focusiert bleibt, richtiges der SCRUM-Master seinen Blick auf den Rahmen der Veranstaltung.

Allgemeiner Ablauf:

  • Begrüßung
  • Agenda mit Focus für den Zeitraum seit der letzten Release-Demonstration
  • Einzelvorträge oder Gesamtvortrag ober die neuen Funktionalitäten mit paralleler Vorführung
  • ggf. nachgelagerte Vorführung
  • Abschluss mit Dank an die Beteiligten und besonderenn Dank an spezielle herausragende Leistungen

  • Kleinen Ausblick (Roadmap) über den weiteren Focus mit ggf. kleiner Statisktik über den Entwicklungsprozess (Behobene Bugs, Releseinformationen, Prozessveränderungen etc)

Filmmitschnitt (optional)

Zur Verbesserung der Vortragstechnik und des Formats kann zu Studienzwecken die Demonstration gefilmt werden. Ebenso nützlich können sich die Aufnahmen als Grundlage zu Schulungsunterlagen oder zusätzlichen Dokumentationen herausstellen.

Aus "Compliancegründen" wird es notwendig sein, das Einverständnis der Teilnehmer und des jeweiligen Vortragenden vorab eingeholt werden. 

 

 

Teilnehmer:

 

  • Alle beteiligten am Projektgeschehen und Besucher aus anderen Abteilungen im Unternehmen

 

Sinnvolle Fragestellungen zur Vorbereitung:

 

  • Was ist der Schwerpunkt der Präsentation?
  • Wer kann/möchte welche Themen präsentieren?
  • Wie kann ich die Leistungen der Entwicklung entsprechen präsentieren (z.B.: Statistik)
  • Welche Stake Holder sind für die jeweilige Präsentation besonders wichtig.

 

Ziel / Ergebnis des Meetings:

 

  • Darstellung und Reflektion der erbrachten Leistung
  • Update der beteiligten Projektrollen (Stake Holder, Team, Manager)
  • Präsentation eines fertigen Softwarestandes
  • Synchronisationspunkt mit anderen agilen Projekten

 

Was das Meeting nicht ist:

 

  • Eine Plattform zur ausführlichen Diskussion zwischen Stake Holdern, warum "jetzt" eine Lösung so umgesetzt wurde oder ggf. eben nicht
  • Eine Plattform, um eine Unzufriedenheit, entstehend aus dem Eindruck eines nicht "zufriedenstellenden Entwicklungsfortschritt" öffentlich anzuprangern. Diese Form der Eskalation ist äußerst unprofessionell und dient meist nur egozentrischen Zielen.
  • Eine "Was-wäre-wenn Veranstaltung" -  kurze und prägnante Ideen und Änderungswünsche sind durchaus erwünscht und können für zukünftige Entwicklungen eingebracht werden. Diese werden vom vom Product Owner vermerkt und in einem Folgetreffen (Grooming) ggf. weiter vertieft. NICHT aber im Rahmen der Release-Demonstration.

 

 

 

 

  • Keine Stichwörter