SCRUM & Webtown

Wir vertrauen auf SCRUM.

SCRUM

Wir bei Webtown verwenden die SCRUM-Methode nach folgenden Regeln:

Prinzipien & Regeln

Die Regeln von Scrum definieren die Beziehungen und Interaktionen zwischen den Ereignissen, Rollen und dem Arbeitsmaterial. Scrum Teams entwickeln ihre eigenen Regeln, Werkzeuge und das Arbeitsmaterial entsprechend der Prinzipien und Werte von Scrum.

Die Scrum-Prinzipien:

  • wertegesteuerte Priorisierung (im Backlog)
  • Kooperation (im Scrum-Team und mit den Stakeholdern)
  • Selbstorganisation
  • Empirisches Prozess Monitoring (Review in Retrospektive, ständige Fortschrittskontrolle )
  • Iterative Entwicklung (potentiell veröffentlichbare Produktinkremente in jedem Sprint)
  • Im Zeitrahmen (Ereignisse im Zeitfenster)​​​​​​

 

Die Vorteile von SCRUM

Warum sind wir überzeugt, dass Scrum für alle Projektparteien Vorteile bringt:

Schaffen von Werten

Mit Scrum werden durch Kommunikation zwischen Produkt Owner und dem Entwicklungsteam Lösungen basierend auf Businesswerten geschaffen, anstatt strikt einen vorgegebenen Anforderungskatalog abzuarbeiten.

Diese direkte Kommunikation trägt wesentlich zur Qualität der Lösung bei.

Produktplanung in Hinblick auf eine funktionierende Lösung

Im Rahmen unserer Projekte sind wir - soweit möglich - bestrebt, alle Aktivitäten durchzuführen, die für die Produktivsetzung der Software erforderlich sind. Dafür definieren wir gemeinsam spezifische Abnahmekriterien.

In Zusammenhang damit empfehlen wir den kontinuierlichen Upload von Content, um eine Verzögerung durch Anhäufung dieser Aufgaben zu vermeiden.

Als Ergebnis davon besteht bereits nach dem ersten Sprint die Möglichkeit, dass der Produkt Owner einen ersten Eindruck einer möglichen Lösung erhält. Feedback daraus kann zeitnah in den weiteren Entwicklungsprozess eingearbeitet werden, wodurch der Wert der zu schaffenden Lösung weiter steigt.

Einer der größten Vorteile von agilen Projekten ist, dass nach jedem Sprint ein potentielles Produktinkrement live gehen kann.

Schnelle Anpassung an Veränderung

Durch regelmäßigen Feedback können die Anforderungen zeitnah an nachjustierte Ziele und Erwartungen angepasst werden.

Die so erstellte Funktionalität stellt am Ende des Projektes entspricht tatsächlich den Erwartungen der Anwender und stellt einen echten Wert dar.

Mit Scrum sind die Änderungskosten beträchtlich geringer als bei traditionellen Methoden, bei der alle Änderungung zusätzliche Kosten zu den initialen Umsetzungskosten darstellen.

Hohe Qualität

In Scrum wird Qualität dadurch definiert, daß eine Lösung eine Fertigstellungsdefinition erfüllt (Definition of Done, DoD), und so der vom Kunden gewünschte Wert erreicht wird.

  • Diese Definition wird gemeinsam von allen Mitgliedern des Scrum Teams erstellt, beständig überprüft und, falls notwendig, angepasst.
  • Um hohe Qualität zu gewährleisten, ist es essentiell, „technische Schuld“ so gering als möglich zu halten. Dafür überprüfen wir die Codequalität und unterziehen sie eine Qualitätsanalyse mit der der Analyselösung SonarQube. Zusätzlich führen wir manuelle und automatisierte Tests durch.
  • Für die Überprüfung des erwarteten Unternehmenswertes haben sich Tests mit den tatsächlichen Anwendern als die effizienteste Lösung erwiesen.

Vermeidung einer Fehlerhäufung zu Ende des Projekten durch kontinuierliches Testen

Die manuellen Tests während eines Sprints werden durch automatisierte Tests ergänzt, so wird eine hohe Testabdeckung erreicht. Dadurch, und durch die Einbeziehung aller Stakeholder, können Planungsfehler frühzeitig erkannt und die Kosten der Fehlerbehebung niedrig gehalten werden.

Dokumentation ist aktuell

Durch die Wartung der User Stories spiegeln diese stets die aktuellen Anforderungen wieder, und sämtliche User Stories sind vorhanden, um die Geschwindigkeit des Developmentteams zu gewährleisten.

Die Übereinstimmung zwischen Systembeschreibung und der entwickelten Lösung wird durch Update der Dokumentation in jedem Sprint gewährleistet.

 

Projekt Struktur

Aus unserer Sicht kann die Abstimmung der verwendeten Enterprise Umgebung und er SCRUM Methode wie folgt aussehen:
 

 

 

 

Pre-Sprint Phase (Vorbereitungs Phase)

  • Zu Beginn des Projekts sammelt der Produkt Owner in der Projekt Vision die Informationen zum Ziel des Projekts und die entscheidenen Informationen die für die Umsetzung benötigt werden.
  • Wie sich das Produkt im Laufe der geplanten Releases zu dem in der Vision skizzierten Produkt entwickelt, wird von ihnen in der Produkt Roadmap vorgestellt: Sie erfassen die Unternehmensziele und legen die Merkmale und Anforderungen fest, die erfüllt werden müssen, damit diese Ziele erreicht werden können.
  • Das resultierende Ergebnis der Pre-Sprint Phase ist der anfängliche Produkt Backlog.
    • Die Vorgaben und Anforderungen der Anwender werden im Produkt Backlog in Form eines Epics oder einer User Story erfasst.
    • Alle Änderungen, die in Form von Features, Funktionen, Anforderungen, Verbesserungen und Korrekturen auftreten, die in zukünftigen Releases des Produkts durchgeführt werden sollen, werden in den Produkt Backlog aufgenommen.
    • Die Backlog Items werden vom Product Owner priorisiert und den geplanten Releases zugewiesen.
    • Der Product Backlog ändert sich bis zum Abschluss des Projekts kontinuierlich.
  • Um ein Produkt von angemessener Qualität herzustellen, ist es notwendig, Anforderungen festzulegen, die die Erwartungen an das Produkt klar darstellen und überprüfbare Ergebnisse beinhalten. Diesem Zweck dienen die sogenannten "Done"-Kriterien (Definition Of Done).
    • Die "Ready-Kriterien" (Definition Of Ready) enthalten typischerweise die formalen und wesentlichen Anforderungen an die Backlog-Positionen. Durch deren Einhaltung kann sichergestellt werden, dass das ausführende Team die Lösung auf der Grundlage hochwertiger Anforderungen plant und liefert, so dass auch die zu erstellende Software den Zielen genau entspricht.
    • Durchdachte "Done"-Kriterien" stellen sicher, dass der Produkt-Fortschritt den Anforderungen für das gesamte Produkt entsprechen. Damit können Situationen vermieden werden, in denen eine zu spät identifizierte Anforderung für das gesamte Produkt auf das gesamte Projekt mit hohem Kostenniveau angewendet werden muss.

In der Vorbereitungsphase wird das Scrum-Team gebildet und die Verhandlungen zwischen dem Entwicklungsteam und dem Product Owner beginnen.

Ziel ist es, bis zum Ende der Vorbereitungsphase die folgenden Bedingungen für die Sprinteinleitung zur Verfügung zu stellen:

  • Erstellung der Produktvision
  • Erstellung der Produkt-Roadmap
  • Identifizierung von Interessengruppen (intern und extern)
  • Vorbereitung des ersten Product Backlogs (Identifizierung der Teilnehmer, Aufnahme von Epics), Verteilung des Rahmens für Story Points auf Epic oder Feature-Ebene.
  • Vorbereitung von sprintbereiten User Stories für die ersten 3 Sprints
  • Festlegung der Kriterien für READY und DONE
  • Bildung des Scrum-Teams
  • Hardware- und Software-Infrastruktur

Der erste Sprint kann nach Abschluss der mit der Vorbereitungsphase verbundenen Aufgaben eingeleitet werden.

Scrum Zyklus

  • Der Scrum-Zyklus beginnt mit der ersten Sprint-Planung.
    • Bei der Sprint-Planung wird das Ziel des Sprints gemeinsam vom Product Owner und dem Entwicklungsteam festgelegt. Der Input für die Arbeit des Entwicklungsteams erfolgt über die sprintbereiten Product Backlog Elemente. Jede User Story, die für den Sprint geplant ist, wird vom Entwicklungsteam mit einem Story Point versehen und von diesem bezüglich des Umfangs des Sprints verpflichtet (Sprint Backlog).
    • In der zweiten Hälfte der Sprintplanung wird vom Entwicklungsteam ein Plan zur Umsetzung des Sprintziels und zur effizienten Durchführung der internen Arbeit erarbeitet. Um ein Produktinkrement vorzubereiten, das am Ende eines jeden Sprints möglicherweise live gehen kann, werden alle Aufgaben im Zusammenhang mit dem Produktinkrement vom Team innerhalb des Sprints durchgeführt.
    • Als Ergebnis der Planung werden die User Stories vom Entwicklungsteam in kleinere Elemente, Teilaufgaben, zerlegt.
  • Während der Zeit des Sprints werden die für die Implementierung erforderlichen Aktivitäten und die Erreichung des Sprintziels synchronisiert, die vom Scrum Team jeden Tag beim Daily Scrum abgestimmt werden.
  • Gleichzeitig zu der Implementierung arbeitet der Product Owner an den User Stories der nachfolgenden Sprints. Beim  Backlog Refinement (oder Backlog Grooming) verhandeln der Product Owner und das Entwicklungsteam über die vom Product Owner geschriebenen User Stories. Basierend auf dem Feedback aktualisiert der Product Owner die Backlog-Positionen und deren Priorität.
  • Am Ende des Sprints, beim Sprint Review (oder Sprint Demo), wird das fertige Produktinkrement dem Product Owner vom Entwicklungsteam präsentiert.
    • Wenn das Produktinkrement die Akzeptanzkriterien erfüllt und den "Done"-Kriterien entspricht, akzeptiert der Product Owner die abgeschlossenen User Stories.
    • Die User Stories, die diese Kriterien nicht erfüllen, werden wieder in den Product Backlog aufgenommen.
  • Am Ende eines jeden Sprints überprüft das Scrum-Team die Tätigkeiten in der Sprint Retrospektive. Diese Prüfung umfasst die angewandten Methoden, die Zusammenarbeit der Teammitglieder und die Qualität des hergestellten Produkts. Für jede festgestellte Abweichung erstellen die Teams einen Plan zur Lösung des Problems, der kontinuierlich überwacht wird.
  • Die empfohlene Dauer eines Sprints beträgt 1 bis 2 Wochen, wobei Anfang und Ende während des gesamten Projekts auf den gleichen Tag der Woche fallen.
     

Releases und Produktfreigaben

  • Die Produktfreigabe/-aktivierung erfolgt zu den in der Produkt-Roadmap festgelegten Zeiten.
  • Der Freigabe geht eine detaillierte Planung voraus, wodurch der Release-Plan erstellt wird. Die Release-Planung unterstützt die Kunden bei der Vorbereitung auf eingespielte Änderungen und die Aufnahme der für die Organisation bzw. das Unternehmen erforderlichen Aktivitäten (Änderung von Workflows, Schulungen).