Scrum (Software Capability Rational Unified Model)

Was ist Scrum?
Scrum ist ein Agiles Projektmanagementframework, es beschreibt somit Praktiken für das Management von (Software-)Projekten. Es ersetzt den deterministischen vorausplanenden Ansatz, welcher alle (auch zukünftige) Ereignisse durch Vorbedingungen eindeutig festlegt, durch eine empirisch adaptive Projektsteuerung. Scrum wurde von Ken Schwaber 1999 eingeführt und 2002 durch sein Buch "Agile Software Developement with Scrum" breiter bekannt. Scrum regelt nicht welche Softwareentwicklungstechniken die Entwickler einzusetzen haben, die Wahl der Softwareentwicklungstechniken wird der Selbstorganisation des Teams überlassen. Meist werden Praktiken angewandt die aus dem Xtreme Programmingundefinedstammen. Im Bezug auf das Testen der Software gibt Scrum ebenfalls nicht vor wie das Testen im ablaufenden Projekt gestaltet werden soll.

Projektmanagementinstrumente
Das Ziel von Scrum ist es schnell und unkompliziert auf Änderung zu reagieren und keine Zeit und Kosten zu verschwenden. Hierfür stehen Scrum mehrere Projektmanagementinstrumente zur Verfügung.

ALM Werkzeug(Application Lifecycle Management)
Wekzeuge dieser Kategorie unterstützen verschiedene Aktivitäten des Entwicklungsprozesses, die bekanntesten Beispiele für ALM Werkzeuge sind : Rally, Version One und Scrum Works. Sie Zeichnen Tasks und Veränderungen auf und helfen beim verwalten der Builds und Releases. Dadurch unterstützen sie den Dialog zwischen Entwicklung und Betriebsseite.

Build
1. Die Entwicklungsstufe einer Software vor Freigabe einer neuen Version.

2. Der Erstellungsprozess einer bestimmten Version einer Software.

=== Kurze Iteration === Scrum unterteilt ein Projekt in mehrere Iterationen, welche eine fest vorgeschriebene Länge haben.Bei jeder Iteration, bei Scrum heißen diese auch Sprints, soll es möglich sein ein potenziell auslieferbares Produkt zu erzeugen, dessen Umfang pro Iteration wächst. Der Grund dafür ist simpel, da die einzelnen Sprints nur einen kurzen Zeitraum einnehmen ist es so deutlich einfacher diese im voraus durch zu planen. 

=== Product Backlog ===

Das Product Backlog besteht aus Bezeichnung, Priorität und Beschreibung. Je niedriger der Wert der bei Priorität angegeben wird ist, umso wichtiger ist die jeweilige Funktion. Unter dem Atribut Beschreibung werden die verschiedenen gewünschten Funktionen genannt und beschrieben und bei Bezeichnung wird beschrieben um was es grob geht (Messen, GUI, Bus Adapter, Drucken). Hierbei wird die Planung nur auf eine simple Liste reduziert, welche lediglich die Arbeitsergebnisse und Ziele darstellen soll, wodurch dem Team eine Menge Arbeit erspart bleibt. Dieses Product Backlog wird vom Product owner (s.u.) geführt und enthält alle Anforderungen und Arbeitsergebnisse. Die einzelnen Elemente des Product Backlog werden, priorisiert wobei auch eine chronologische Reihenfolge oder ein Abhängigkeit nicht geachtet wird. Das Product Backlog ist nicht von Anfang an fest geschrieben sondern wird, wie es bei Agilen Prozessen sein sollte, weiter entwickelt und bearbeitet. Dieses Bearbeiten nennt man auch "Backlog Grooming". Durch dieses dauerhafte neu bearbeiten und priorisieren wird der Plan zuverlässiger, da alles was vermieden wird was Fehler einbringen könnte. Der Kunde hat auch hierbei immer die Möglichkeit Feedback zu geben und somit Einfluss auf die Planung zu nehmen. Der Scrum Master stellt sicher das ein Product Backlog geführt wird welches gemäß des Scrum Prozesses verläuft. Die Tester helfen dabei Akzeptanzkriterien festzulegen, dadurch wird es für sie später leichter Akzeptanztests abzuleiten.

Akzeptanzkriterien
Akzeptanzkriterien sind Kriterien die das Produkt erfüllen muss um eine Abnahme durch den Kunden/Auftraggeber zu bestehen.

=== Sprint Backlog === Auch in Scrum muss sich das Team mit dem Product Owner zusammen überlegen wer wann welche Anforderungen abhaken kann und Aufgaben erledigen muss. Dies wird pro Sprint immer entschieden und so Schritt für Schritt gemacht. Der Sprint Backlog ist die kleinere Version des Product Backlog. Das Team nimmt sich die am höchsten Priorisierten Anforderungen und Aufgaben und zieht diese in den Sprint Backlog(Pull Prinzip), dass Team bestimmt wieviel es pro Sprint erreichen kann. Es werden Ausschließlich Aufgaben in das Spint Backlog gezogen, welche zum erreichen der in der Story Map vereinbarten Sprint Ziele beitragen. Während dessen müssen sie darauf acht geben, dass alles passend formuliert ist und verstanden werden kann. Alle Anforderungen die nicht ausreichend formuliert sind erfüllen somit nicht die Definition of Ready(Auswahl Kriterium), welche bestimmt ob die Aufgaben in den anstehenden Sprint kommen. Alle, die die Definition of Ready erhalten haben, werden nun in den Sprint Backlog gepackt und jetzt wird auch entschieden ob Abhängigkeiten, resultierenden Aufgaben und Aufwände und eine zeitliche Reihenfolge vorhanden sind, um somit die nötigen Aufgaben für den Sprint aus zu sortieren sind. Sobald dies geschehen ist legt das Team Ausgangskriterien(Definition of Done) fest. Die Tester helfen dabei die Ausgangskriterien festzulegen, dadurch haben es die Tester am Ende einfacher Testfälle von diesen Ausgangskriterien abzuleiten. Die Tester müssen außerdem die Implementierung der erstellten Features testen. Diese Test- und QS-Arbeiten müssen immer im Sprint eingeplant sein, da es nach dem Sprint keine externe Testphase gibt. Es muss darauf geachtet werden, dass diese Überlegungen nur für den anstehenden Sprint gemacht werden, damit der Aufwand gering gehalten wird. Der Sprint Backlog darf, während der Sprint läuft, nicht mehr verändert werden, weil wenn man den Sprint wie angegeben plant bestehen gute Chancen das der Plan eingehalten wird. Das in einem Sprint zu erstellende Feature muss nach Abschluss vom Kunden anwendbar sein, dafür müssen alle nötigen Teilfunktionen vorhanden sein. Es wird also Säulenartig statt wie üblich Schichtweise Entwickelt.

Retrosperktive
In der Retrosperktive wird dem Team die Möglichkeit geboten sich selbst zu untersuchen und einen Plan zur Verbesserung aufzustellen. Die Veränderungen sollen im nächsten Sprint angewandt werden. Die Retosperktive findet nach dem Sprint Review und vor dem nächsten Sprint Planning Meeting statt. Bei einem 1 monatigem Sprint ist die Zeit für die Retrosperktive auf 3 Stunden festgelegt, bei kürzeren Sprints ist diese Zeit proportional kürzer. Das Ziel dieser Sitzungen ist eine kontinuierliche Verbesserung der Vorgehensweise des Teams, weniger des Produkts.

Burndown Diagramm
In einem Burndown Diagramm wird die noch zu leistende Arbeit grafisch dargestellt. Der geplante Verlauf und der Verlauf wie dieses Projekt Real Verläuft wird in einem Graphen veranschaulicht. Jedes Team Mitglied schätzt täglich den Aufwand noch verbleibender Tasks. Ist somit eine Fortschrittskontrolle für das Team und die Auftraggeber/Kunden.

Siehe rechtes Bild:

Initiale Story Map
Jeder Sprint hat eine eigene Story Map, in der Story Map wird dargestellt welche Ziele in den kommenden Sprints erreicht werden könnten, die Story Map ist also eine Absichtserklärung. Die Ziele können sich im Laufe des Projekts aufgrund von Erfahrungen die das Team gemacht hat, oder aufgrund von Änderungswünschen des Kunden verändern. Der Product Owner muss die Kunden aber auch darüber informieren das es nicht garantiert wird das alle in der Story Map verzeichneten Ziele erreicht werden. Die Story Map macht für den Kunden sichtbar, wann welche Funktion released werden könnte und gibt den Kunden einen einblick darin, welche Prioritäten das Team für die einzelnen Funktionen festgelegt hat. Der Kunde kann dadurch ein sofortiges Feedback geben, mit welchen Plan-varianten er einverstanden ist und mit welchen nicht.

Timeboxing
In Scrum hat jeder Sprint die Pflicht lieferfähige Software("potentially shippable product") hervorzubringen. In das Sprint Backlog kommen nur Aufgaben die zu einem einsetzbaren Produkt führen. Die Elemente die zum Ende des Sprints nicht fertig geworden sind fallen weg und um genau das so gut es geht zu vermeiden, versucht das Team die passenden Features auszuwählen, die zum Ende des Sprints abgeschlossen werden können. Hier gilt die Faustregel: Auslieferbar geht vor Funktionsumfang. Dieses Prinzip wird auch Timeboxing genannt. Um das zu ermöglichen wird vor dem Sprint festgelegt ob die einzelnen Features realisiert werden können und welchen Aufwand dies erfordern würde. Ist der Aufwand zu hoch wird das Feature entweder aussortiert, gestückelt oder auf die Grundelemente runter geschraubt. Die Aufwandschätzung ist hier ein kleines Hindernis bei dem es zwei Punkte gibt mit denen es möglich ist dieses Problem besser zu bewältigen als bei den Klassischen Methoden.

1. Der Sprint beinhaltet nur wenige Teile womit eine Schätzung etwas präziser wird und offenen Fragen zur Aufgabe wurden bereits durch die vorherigen Sprints vorbereitet.

2. Das Team verwendet bei der Schätzung eine Methode aus XP die sich "Planning Poker" nennt. Den Erfahrungen gemäß lagen die Schätzung immer erstaunlich gut.

Timeboxing findet nicht nur im Sprint Anwendung sondern auch in anderen bereichen von Scrum in denen es darum geht etwas abzuschließen.

Transparenz
Was bei Kanban das WIP-Board ist, ist bei Scrum die Transparenz. Die Transparenz ist das mit Abstand wichtigste Argument für die veerwendung von Scrum. Im Grunde genommen wird lediglich das Sprint Backlog auf einem Whitboard festgehalten. In den Zeilen des Whiteboards stehen die jeweiligen Anforderungen und anhand der Spalten kann man den Fortschritt erkennen, da hier die Tasks Tickets im Daily Scrum nach rechts oder links wandern. Da das Whiteboard offen für jeden ist weiß auch jeder was aktuell passiert was zur folge hat, dass Fehler durch falsche Kommunikation und aneinander vorbei arbeiten verringert werden können. Fehler werden so immer direkt gesehen und zum Ausdruck gebracht und außerdem bringen die ganzen kleinen Fortschritte mehr Erfolgserlebnisse für das komplette Scrum Team.

Rollen in Scrum Projekten
Anders als bei den klassischen Vorgehensmodellen hat die Rollen Verteilung und der Stellenwert eine andere Bedeutung in Scrum Projekten. Es gibt im Grunde genommen nur drei verschiedene Rollen in Scrum:

Scrum Master
Der Scrum Master ist im Scrum Projekt das was der Projektmanager für die klassischen Vorgehensmodelle ist. Er ist für die Verfolgung und Umsetzung der Praktiken verantwortlich, die im Projekt benötigt werden. Für den Fall das Probleme oder Hindernisse (impediments) auftreten muss er die Lösung finden. Wichtig zu beachten ist, dass der Scrum Master mehr die Funktion eines Trainers oder Coachs hat und nicht die eines Leiters. Er organisiert Workshops etc. zur Lösungsfindung oder neue Ressourcen wie zum Beispiel bessere Werkzeuge. Der Scrum Master sollte auf keinen Fall Probleme ungelöst zurück zum Team schicken, da dies einen Rückfall im Projekt bedeuten würde.

Product Owner
Der Product Owner ist das Gegenstück zum Scrum Master. Er ist für das Projekt der Vertreter der Kunden und fällt Entscheidungen über neue Features oder die Umsetzung von alten. Der Product Owner verantwortet die Produkteigenschaften, aber auch er ist nicht der Leiter des Projekts und ist auch nicht verantwortlich für den Scrum Prozess.

Entwicklungsteam
Das Entwicklungsteam ist für das entwickeln und testen der Software zuständig und trägt auch die komplette Verantwortung für die Arbeitsschritte. Es organisiert sich selbst und trifft auch die Entscheidungen. Es soll so so geplant werden, dass jeder im Team gleichermaßen zum Fortschritt beiträgt und funktionsübergreifend arbeitet. So kann der Team Geist gestärkt werden da nun alle verschiedenen Spezialisten ein und das selbe Ziel haben und nicht in Rollen unterteilt werden. Das Ziel ist es ein cross-functional Team (interdisziplinär) zu bilden, bei dem zwar nicht jeder alle Aufgaben Bereiche direkt zu Anfang erledigen kann aber bei dem jeder bereit ist bei jeder Aufgabe mitzuwirken. Es geht hier immer um das Team als Ganzes und seinen Fähigkeiten und nicht um die einzel Aufgaben.

Komponententeams
Komponententeams werden meist bei größeren Projekten verwendet, bei Komponententeams wird das zu erstellende Projekt in mehrere Komponenten unterteilt und zeitgleich von mehreren Scrum-Teams bearbeitet. Dies ermöglicht es große Projekte in möglichst kurzer Zeit zu entwickeln.

Planung und Vorbereitung in Scrum Projekten
Agil zu arbeiten bedeutet nicht planlos zu arbeiten. Von Sprint zu Sprint wird dazu gelernt, neue Idee entstehen, ein tieferes Verständnis erlangt und neue Einsichten erreicht.Sowohl beim Scrum Team als auch beim Kunden.Die adaptive, empirische Planung schafft eine hohe Flexibilität und macht das Projekt erst richtig agil. Auf Änderungen wird reagiert und Richtungen werden gewechselt. Das alles heißt nicht das man in Scrum Projekten keine Vorgabe braucht oder Anforderungen die mehr als nur den aktuellen Sprint einschließen.

Dafür benutzt man in Scrum Projekten bestimmte Instrumente:

Produktvision
Die Produktvision ist ein Dokument in dem klar geschrieben wird was vom Produkt später erwartet wird. Es ist die Zielvorgabe für die Scrum Teams die über die aktuellen Sprints hinaus reicht. Dieses Bild sollte möglichst knapp und eindeutig formuliert werden, da es dadurch besser und einprägsamer ist. Das Produkt Backlog welches später erstellt wird ist jedoch meistens eher ungeeignet als Produktvision, weil es zu ausformuliert ist und so sich die Anforderungen in der Masse der Details verlieren. Ausserdem ist das Backlog auch dafür da, um die einzelnen Items zu priorisieren und von den weniger wichtigen Items zu unterscheiden.

Meistens reicht als Produktvision auch eine Top 10 Liste der wichtigsten Features, die das Produkt einmal haben soll, oder vielleicht auch eine Beschreibung des Konkurenz Produkt mit dem man sich messen möchte.

Auf der Produktvision wird nach erstellung die Architekturvision aufgebaut und gestaltet.

Architekturvision
Sobald die Produktvision steht muss das Scrum Team sich darüber Gedanken machen, wie die Produktvision nun technisch zu realisieren ist. Die Architekturvision kann man als visualisierung der Produktvision sehen. Wichtig hier ist das man im Team gleiches Verständnis über die Realisierung entwickelt und man muss sich nicht an UML-Diagramme oder der gleichen halten, um die Architekturvision zu gestalten. Das aller wichtigste Kriterium ist, dass jeder im Team das Schaubild versteht. Je anschaulicher es gestaltet ist, desto besser ist es für das Projekt.

Wie bei agilen Projekten üblich ist die Architekturvision nicht, sobald sie fertig ist, endgültig, sodern kann und soll verändert werden.

Die Architekturvision fungiert als eine Art "roter Faden" durch das Projekt. Sie bildet eine Realisierung die nicht bei jedem Sprint neu aufgesetzt werden muss. Ausserdem dient es dabei die Tasks zu bündeln und auf das Team aufzuteilen. Gerade für das Testen spielt die Architekturvision eine wichtige Rolle, da so Testobjekte und Schnittstellen deutlich gemacht werden.

Team Charta

Anstatt wie bei den klassischen Vorgehensweisen auf Test- und Qualitätssicherunsplan basiert zu arbeiten nutzt Scrum, sofern es nicht anders vorgegeben ist, IEEE 730 und IEEE 829 als Checklisten. Der Scrum Master bespricht diese mit dem Team und sortiert die Punkte aus die für das Projekt nicht relevant sind. Sobald Diskussions Bedarf vorliegt bespricht das Team diesen Punkt und formuliert so die Projektregeln. Diese Projektregeln werden festgehalten, was dann die Team Charta bildet. Die Formulierung kann knapp gehalten werden, da die Team Charta vom Team selbst auf erlegte Regeln sind und somit freiwilig.

Testmanagement
Da das Scrum Team interdisziplinär und selbst organisatorisch handelt gibt es so gesehen keinen wirklichen Testmanager im Team. Die Aufgabe des Scrum Master ist es zu organisieren oder falls nötig die Ausbildung der Teammitglieder zu verbessern. Leitungsaufgaben werden von Sprint-Plannungspraktiken übernommen, Testaufgaben werden über die Tasks geplant oder über die Definition of Done. Auswertung des Testfortschritts funktioniert bei funktionierender Continous Integration automatisch. Man erkennt schnell das der Testmanager nicht mehr notwendig ist.

Es gibt dennoch eine Rolle die den Testmanager in Teilaspekten ersetzt. Die Teststrategie festlegen und den Test inhaltlich planen sind dennoch Aufgaben die ein bestimmtes Know-How und Erfahrung erfordern. Hierfür braucht man dann doch ein Gruppenmitglied mit passender Ausbildung und Erfahrung als Softwaretester, welches sein Know-How beisteuert und den Test fachgerecht aufsetzt und den Product owner bezüglich Produktqualität und Produktfreigaben in Kenntnis setzt.

Fehlermanagement
Zwar spielt das Fehlermanagement eine nicht so große Rolle wie in den Klassischen Vorgehensweisen, jedoch wird immer noch ein Fehlermanagementsystem genutzt. Fehler werden in Scrum Projekten in den meisten Fällen direkt behoben was somit keinen Eintrag erfordert. Dennoch gibt es folgende Fälle in denen ein Eintrag nötig wird:
 * 1) Der Fehler wurde manuell aufgedeckt oder durch sonstige Aktivitäten.                                                                           -> Der Eintrag dient zum Reproduzieren
 * 2) Der Fehler erfordert ausführlichere Analysen oder Entscheidungen, die möglicher Weise weitere Personen betreffen  -> Der Eintrag dient zum Informieren der betroffenen Personen
 * 3) Der Fehler kann nicht im selben Sprint behoben werden.                                                                                                -> Der Eintrag dient dazu den Fehler nicht zu vergessen

Testpyramide
Zeigt die Menge aller durchzuführenden Tests auf den verschiedenen Teststufen, vom Unit Tests über Integrationstests bis zu den Systemtests.

Akzeptanztest
Akzeptanztests sind eine formale Art des Testens hinsichtlich der Benutzeranforderungen, Bedürfnissen und der Geschäfftsprozessen. Diese Art von Test wird durchgeführt um dem Kunden/Auftraggeber die Entscheidung, ob ein Produkt zur Abnahme bereit ist, zu ermöglichen.