Pressemitteilung von Herr Andreas Schilling

Software Entwicklung mit Scrum

---

---

Scrum entspricht den Anforderungen der hoch komplexen Softwareentwicklung; hier ist eine traditionelle, planungsorientierte Vorgehensweise nicht angemessen; es bedarf stattdessen einer flexiblen, dynamischen Vorgehensweise mit kurzen Interaktionszyklen. Dank seiner Prozessmodelle und der Rollen bzw. Aufgabenverteilung ist Scrum perfekt geeignet, um umfangreiche Softwareentwicklungs Projekte zu managen.


Wie funktioniert Scrum?

Im Scrum Guide von Ken Schwaber und Jeff Sutherland wird die Vorgehensweise des Scrum detailliert beschrieben. Das Standardwerk wird regelmäßig aktualisiert und steht auf http://www.scrum.org zum kostenlosen Download bereit.


Scrum wurde 1990 entwickelt, 1995 kam die erste Ausgabe des Scrum Guide heraus, in dem Scrum definiert wird als "ein Rahmenwerk, mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen können und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern."


Scrum beruht, anders als die traditionellen Projektmanagementmodelle, nicht auf der durchgängigen Planung von Anfang bis Ende. Softwareprodukte nach der Scrum Methode werden in sogenannten Sprints entwickelt, d. h. es gibt wiederholte Feedbackschleifen in kurzen Intervallen. In regelmäßigen Abständen kann so der aktuelle Stand der Produktentwicklung überprüft werden, ein wichtiger Aspekt angesichts der für die schnelllebige Branche typischen kurzen Produktlebenszyklen. Der iterative Ansatz ermöglicht es den Projektmitarbeitern, steuernd einzugreifen und kurzfristig auf Probleme zu reagieren.


Rollen in Scrum

Scrum sieht 6 zentrale Rollen innerhalb eines Projektes vor.


Scrum Master

Product Owner

Team(mitglieder)

Anwender

Kunde

Manager


Scrum Master, Product Owner und Team sind im Scrum Guide als Scrum Team definiert. Der Scrum Master implementiert die Vorgehensweise, überwacht die Einhaltung der Regeln und organisiert das Team. Der Product Owner ist für den kommerziellen Erfolg des Projektproduktes verantwortlich. Als unmittelbarer Verantwortlicher für das Produkt steht er in Kontakt mit dem Kunden zwecks regelmäßigen Feedbacks und ist zuständig für das Product Backlog. Das Team entwickelt das Produkt und ist zuständig für die Einhaltung der Qualitätsstandards und die Umsetzung des Product Backlogs.


Der Kunde ist Auftraggeber des Projekts und als solcher finanziert er es. Er steht in regelmäßigem Kontakt zum Product Owner, um sein Feedback zum aktuellen Entwicklungsstand zu geben. Anwender sind die Endbenutzer des Produkts. Ihr Feedback fließt ebenfalls in die Projektarbeit mit ein. Anwender und Kunde können identische Personen sein. Das Management steckt die Rahmenbedingungen des Projekts ab. Seine Hauptaufgabe besteht in der Bereitstellung der Ressourcen (Personal, Finanzmittel, Material).


Artefakte

Mit Artefakten werden Scrum Projekte gesteuert. Hierbei handelt es sich um Größen, an denen sich die geleistete Arbeit oder der geschaffene Wert ablesen lassen. Als solche sind sie transparent und ermöglichen die Überprüfung des Projektfortschritts. Die Artefakte enthalten Schlüsselinformationen, die es den Projektteam ermöglichen, ein fertiges Inkrement, ein "Done", liefern zu können. Definiert als Artefakte sind im Scrum Guide das Product Backlog, der Sprint Backlog sowie das Inkrement.


Das "Done" ist hingegen nicht als Artefakt definiert, sondern als separates Hilfsmittel, um Einträge im Product Backlog und Inkremente als erledigt zu markieren.


Meetings

Meetings gehören bei Scrum ebenso zur Projektsteuerung. Zu den 4 Scrum Meetings zählen


das Sprint Planning,

das Daily Scrum,

das Sprint Review

die Sprint-Retrospektive


Gemeinsam mit dem Sprint werden die 4 Meetings als Scrum Ereignisse zusammengefasst.


Projektablauf

Am Anfang des Projekts steht die Produktvision, die sich im Laufe des Projekts mit jedem Sprint konkretisieren wird. Die Vision ist die Grundlage für das Product Backlog durch den Product Owner. In den Sprints werden die Anforderungen des Product Backlogs zunächst priorisiert – daraus ergibt sich das Sprint Backlog – und dann vom Team umgesetzt. Am Ende des Sprints werden den Interessensgruppen – Product Owner, Kunde, Anwender – die Zwischenergebnisse präsentiert, und es werden aufgrund des Feedbacks eventuell Anpassungen vorgenommen. Zudem führt das Team eine retrospektive Analyse des Sprints durch, um für die folgenden Sprints Verbesserungen in der Arbeitsorganisation vorzunehmen.


Weitere Informationen >>> Firmen- & Pressekontakt