Grundgedanke von Scrum
Grundgedanke hierbei ist, stets nach jedem Entwicklungszyklus (die in der Regel zwischen einer Woche und einem Monat, meist jedoch zwei Wochen andauern) ein funktionierendes Produkt geschaffen zu haben, das den grundlegenden Bedürfnissen der Zielklientel gerecht wird. Durch diese kurzen sogenannten Sprints ist es dem entwickelnden Team möglich, sich jedes Mal auf wenige, jedoch präzise definierte Funktionen und Features zu fokussieren und diese lauffähig umzusetzen.
Werde jetzt in 6-12 Monaten Software-Tester!
Durch diese Vorgehensweise entwickelt sich das Produkt iterativ (= in sich wiederholenden Durchgängen) und inkrementell (= schrittweise aufeinander aufbauend) weiter. Dies hat den Vorteil, dass Änderungswünsche meist kurzfristig und ohne größere Probleme umgesetzt werden können. Da außerdem seit dem ersten Entwicklungsdurchgang ein funktionierendes Produkt existiert, kann dieses bereits unter realen Bedingungen genutzt werden.
Ziele von Scrum
Ziel bei Scrum ist ausdrücklich nicht, ein komplettes Produkt mit allen zu Anfang gewünschten Anforderungen und Features auf einmal fertigzustellen und zu liefern. Die Gefahr, anschließend aufgrund von geänderten Anforderungen in Teilen oder in Gänze aufwändig Anpassungen vornehmen zu müssen, ist zu groß.
Scrum-Rollen
Innerhalb des Scrum-Frameworks ist eine Reihe von personellen Rollen vorgesehen, jede mit ihren eigenen spezifischen Aufgaben und Funktionen, um sicherzustellen, dass der angestrebte iterative inkrementelle Entwicklungsprozess so reibungslos und effizient wie möglich verläuft.
Diese Rollen sind:
- Developer
- Product Owner
- Scrum Master
Sie bilden zusammen ein Scrum-Team, meist bestehend aus einer Rolle Scrum Master, einer Rolle Product Owner und mehreren Rollen Developer, insgesamt in der Regel zehn oder weniger Personen.
Scrum – Developer Team
Das Kernstück des Teams bilden die Developers. Sie sind Fachleute auf ihrem Gebiet – meist aber auch interdisziplinär tätig – und dafür verantwortlich, die einzelnen Entwicklungszyklen zu planen, sie umzusetzen und somit das angestrebte Produktziel bis zum Ende des Zyklus zu realisieren.
Zu ihnen zählen für gewöhnlich Verantwortliche für das Programmieren, Testen und Designen des Produkts wie auch für die Businessanalyse zur Optimierung der generellen Prozesse.
Das Developer-Team ist selbstorganisierend, entscheidet also eigenständig, wie und wann es die Aufgaben des aktuellen Sprints bearbeitet. Wichtig ist jedoch, dass am Ende des Sprints ein potenziell fertiges und verwendbares Produkt abgeliefert wird.
Scrum Product Owner
Die Product-Owner-Rolle sieht eine Person vor, die als Bindeglied zwischen dem gesamten Scrum-Team und der Anspruchsgruppe (sogenannten Stakeholders) fungiert. Product Owners sind in erster Linie für die Qualität des Produkts verantwortlich und versuchen stets, diese so hoch wie möglich zu halten.
Sie definieren und formulieren Produktziele, meist in engem Austausch mit den Stakeholders. Sie kommunizieren diese verständlich an das Entwicklungsteam und priorisieren die einzelnen Aufgaben und Entwicklungsschritte zur optimalen Erreichung des (Teil-)Produktziels.
Scrum Master
Scrum Masters kommt eine besondere Aufgabe zu. Sie sorgen dafür, dass das ganze Scrum-Konzept von allen beteiligten Personen verstanden, eingehalten und umgesetzt wird, um die Produktentwicklung bestmöglich zu gestalten. Sie coachen das Team und unterstützen die Mitglieder dabei, sich auf ihre Aufgaben zu fokussieren und diese ohne Hindernisse bestmöglich zu erfüllen. Des Weiteren organisieren und moderieren sie die im Scrum-Framework vorgesehenen Zeremonien und kümmern sich um klare, positive und produktive Arbeits- und Konferenzatmosphären.
Scrum-Zermonien
Das Scrum-Framework sieht eine Reihe von regelmäßigen und fest definierten Zeremonien bzw. Gruppenaktionen vor. Diese sollen dazu dienen, dem gesamten Entwicklungsteam sowie direkt und indirekt beteiligten Personen feste Rahmenbedingungen zu bieten, nach denen effektiv und effizient gearbeitet und das angestrebte Produkt entwickelt werden kann.
Die Zeremonien eines Sprints sind:
- Backlog Refinement
- Sprint Planning
- Daily
- Sprint Review
- Sprint Retrospective
Zusammen bilden sie einen Sprint, also einen Entwicklungszyklus. Währen das Backlog Refinement nicht zwingend vorgeschrieben ist im Scrum-Framework, stellen die anderen Zeremonien regelmäßige Pflichten dar. Kurz zusammengefasst, dienen sie zu Folgendem:
Das Backlog Refinement dient dazu, anstehende User Storys, Aufgaben und Features detailliert zu besprechen, für alle beteiligten Personen vollkommen verständlich zu machen und ggf. zu priorisieren.
Das Sprint Planning wird anschließend dazu genutzt, (idealerweise bereits besprochene und priorisierte) Aufgaben für den anstehenden Sprint auszusuchen und so zusammenzustellen, dass am Ende des Entwicklungszyklus ein entsprechend verwendbares Produkt entstanden ist.
Die Dailys sind, wie der Name schon sagt, ein täglich wiederkehrendes Element während eines Sprints, in welchem dem gesamten Scrum-Team von allen beteiligten Personen ein kurzes Update zu den am Vortag von ihnen erreichten Leistungen, den am aktuellen Tag geplanten Arbeiten und etwaigen Problemen gegeben wird.
Zum Abschluss eines Sprints findet das Sprint Review statt. Dieses stellt meist eine Art Präsentation des im Sprint entwickelten neuen Produktinkrements gegenüber Product Owner und ggf. Stakeholders dar. Von Product-Owner-Seite wird dabei geprüft, ob die für den Sprint angesetzten Ziele erreicht und alle definierten Anforderungen erfüllt wurden. Direktes Feedback von Stakeholder-Seite ist ebenso möglich.
Bevor der nächste Sprint losgeht, findet dann noch ein Sprint Retrospective statt. Dieses Zusammenkommen des gesamten Scrum-Teams wird dafür genutzt, um den vergangenen Sprint Revue passieren zu lassen und in offener und ehrlicher, jedoch nicht anklagender Runde positive wie negative Aspekte des Sprints an- und zu besprechen sowie mögliche Lösungen und Verbesserungen für den kommenden Sprint zu erarbeiten.
Srcum-Artefakte
Während der Verfolgung des Scrum-Frameworks im Produktentwicklungsprozess entstehen mehrere sogenannte Artefakte, die bestimmte Arbeiten und Werte darstellen und zur transparenten Informationsvermittlung für alle beteiligten Personen dienen.
Zu den Artefakten zählen:
- Product Backlog
- Sprint Backlog
- Inkrement
Sie alle haben zudem einen bestimmten inhärenten Fixpunkt, auf den sie ausgerichtet sind.
Product Backlog
Das Product Backlog bildet die Grundbasis des zu entwickelnden Produkts. Alle Anforderungen, Wünsche und Features werden hierin sortiert und möglichst gut beschrieben gesammelt. Es ist ein lebendiger Katalog, aus dem immer weiter geschöpft wird, um das Produkt stetig weiterzuentwickeln.
Sprint Backlog
Das Sprint Backlog ist eine kleinere, meist stark fokussierte Aufgabensammlung mit einem fest definierten Ziel für die nächste Produktversion. Es werden hierfür nur Aufgaben aus dem Product Backlog aufgenommen, die diesem festgelegten Ziel dienen und innerhalb des Sprints auch erledigt werden können.
Inkrement
Das Inkrement stellt schließlich die stets nächste Stufe des Produkts am Ende eines jeden Sprints dar. Es sollte auf der jeweils vorhergehenden Version aufbauen und ein in sich abgeschlossenes und verwendbares Produkt darstellen, entsprechend den gesetzten Anforderungen („Definition of Done“).
Kai Schiefer
QA Engineer portagon GmbH
Aus dem Bereich der Linguistik kommend, habe ich mich stets für Software und Programme mit einer großen Anzahl an Funktionen interessiert. So war ich bereits am Aufbau einer vielschichtigen Webapplikation im Übersetzungsmanagementbereich beteiligt.
Ich arbeite seit Mitte 2021 als QA Engineer in einem aufstrebenden Frankfurter FinTech-Unternehmen mit an der Demokratisierung des privaten Finanzmarktes. Mit Hilfe der Qcademy bekomme ich nicht nur eine fundierte Wissensbasis für meinen Testalltag vermittelt, sondern auch eine Vielzahl an modernen und agilen Methoden, Strategien und Tools vorgestellt, durch deren Einsatz sich meine tägliche Arbeit und die Qualität unserer Software nachhaltig verbessern können.
