1. Agiles Projektmanagement

Projekte in der Webentwicklung sind oft komplex und bedürfen einem gutem Projektmanagement. Leider kann der Verlauf eines größeren Projektes aufgrund von sich ändernden Anforderungen oder nicht erwarteten Komplikationen oft nicht genau vorhergesagt werden. Daher werden immer öfter agile Methoden eingesetzt, da es dadurch einfacher ist auf kurzfristige Änderungen zu reagieren und die Projektplanung anzupassen.

Einer der bekanntesten Vorgehensmodelle für agiles Projektmanagement ist Scrum. Wie Scrum genau eingesetzt wird und welche Rollen und Abläufe es gibt, wird in diesem Blogartikel näher behandelt.

2. Scrum

Scrum ist ein Framework für das Managen von komplexeren Projekten und wurde erstmals 1996 auf der OOPSALA Konferenz von Ken Schwaber und Jeff Sutherland vorgestellt. Inzwischen ist es weit verbreitet und wird von unzähligen Tech-Firmen für das Softwareprojektmanagement eingesetzt. Es stellt ein einfaches Prozessmodell für die Entwicklung von Produkten dar und basiert auf den Grundsätzen der agilen Softwareentwicklung. Scrum setzt sehr stark auf die Selbstorganisation der Teammitglieder, ein Projektmanager mit umfangreicher Autorität im klassischen Sinne existiert in Scrum nicht.

Scrum basiert auf drei Prinzipien – Transparenz, Überprüfung und Anpassung. Das bedeutet, dass alle Fortschritte und Hindernisse täglich und für alle sichtbar festgehalten werden und so alle Projektmitglieder über den aktuellen Stand informiert sind. Funktionalitäten werden in definierten Abständen, sogenannten Releases, geliefert und beurteilt. Nach jedem Release werden die Anforderungen neu beurteilt und wenn nötig angepasst.

Die Projektlaufzeit wird bei Scrum in sogenannte Sprints eingeteilt. Ein Sprint kann zwischen 1 und 4 Wochen andauern. Während dieser Zeit wird dem Produkt neue Funktionalität hinzugefügt bzw. die vorhandene Funktionalität verbessert. Wichtig ist, dass ein Sprint niemals länger dauert, als im Vorhinein geplant. Sollten sich während eines Sprints die Anforderungen ändern, kann er jedoch abgebrochen werden. Am Ende jedes Sprints sollte ein voll funktionsfähiges Zwischenprodukt stehen, das dem Auftraggeber zur Überprüfung vorgelegt wird. Auf Basis seines Feedbacks wird dann weiter am Produkt gearbeitet.

In der folgenden Grafik ist der gesamte Ablauf ersichtlich, was jedoch genau dahinter steckt, wird folglich noch näher beschrieben.

3. Rollen

Bei Scrum gibt es sechs verschiedene Rollen. Diese sind zum einem die internen Rollen, nämlich Team, Product Owner und Scrum Maser und zum anderen die externen Rollen, wie Manager, Kunde und User. Bei den externen Rollen handelt es sich vor allem um jene Personen mit einem besonderen Interesse am Ergebnis des Prozesses. Die Entwicklung passt sich an deren spezifischen Anforderungen an, indem regelmäßig Feedback eingeholt wird. Welche Aufgaben und Pflichten die internen Rollen haben, wird nun genauer erklärt.

1. Scrum Master

Der Scrum Master ist für Erfolg und Produktivität des Teams verantwortlich und gehört somit nicht zum Entwicklungsteam. Die Aufgaben des Scrum Masters sind vor allem dafür zu sorgen, dass alle Regeln und Prinzipien von Scrum eingehalten werden und optimale Arbeitsbedingungen für das Team gegeben sind. Er managed also den Scrum Prozess, bereitet Scrum-Meetings vor, leitet diese und beseitigt alle aufkommenden Hindernisse. Jedoch ist der Scrum Master kein Projektleiter, da das Team Entscheidungen eigenständig trifft und der Scrum Master nur bei "Endlosdiskussionen" entscheidet.

2. Product Owner

Anders als der Scrum Master ist der Product Owner für das Ergebnis zuständig und soll so die Entwicklung gemeinsam mit dem Kunden vorantreiben. Der Product Owner ist sozusagen die Schnittstelle zum Kunden und der Visionär des Produkts. Zu den Aufgaben gehört vor allem die Erstellung und Reihung des sogenannten Product Backlogs. Der Product Backlog ist eine Liste von Anforderungen, welche ständig weiterentwickelt wird und deren Einträge geordnet und priorisiert werden. Zu den Aufgaben des Product Owner zählt weiters eine Aufwandschätzung, wie etwa das Planning Poker, welche gemeinsam im Team durchgeführt werden und die Entscheidung über die Wichtigkeit, also eine Priorisierung, einzelner User Stories. Der Product Owner trägt die Verantwortung hinsichtlich Zeit, Funktionalität und Kosten des Produktes.

3. Team

Die Aufgabe des Teams ist die Entwicklung der Software, dazu wird im Sprint der Product Backlog abgearbeitet. Ein Team im Scrum-Prozess besteht je nach Gesamtgröße des Projektes aus 5-9 Personen, welche in den unterschiedlichen Bereichen, wie Entwicklung, Testing oder Design tätig sind. Wichtig ist, dass es keine strikten Hierarchien gibt und das Team selbstständig und selbstorganisiert arbeitet. Das heißt, es müssen die für den Sprint gesetzten Ziele erreicht werden, das Team kann jedoch auch externe Berater beiziehen. Der Scrum Master steht dem Team als Coach zu Verfügung.

4. Artefakte

Artefakte sind die Ergebnisse von Aktivitäten im Softwareentwicklungsprozess und dienen als Orientierung im Prozess. Bei Scrum gibt es insgesamt 3 Artefakte – den Product Backlog, den Sprint Backlog und das Product Increment.

1. Product Backlog

Wie bereits kurz beschrieben, beinhaltet der Product Backlog , in einzelne Einträge gegliedert, alle Anforderungen an das Projekt. Wichtig ist, dass es sich beim Product Backlog um eine Prioritäten-Liste handelt was bedeutet, dass jeder Eintrag nach seinem Nutzen für das Endprodukt eingeordnet wird und es darauf geachtet wird, dass es eine klare Priorisierung und damit keine gleichrangigen Anforderungen gibt. Wie erwähnt, ist der Product Owner für die Ordnung und Priorisierung der Einträge verantwortlich.

2. Sprint Backlog

Aus dem gesamten Product Backlog wird eine Auswahl an Anforderungen getroffen, die innerhalb eines Sprints bearbeitet werden sollen. Diese werden im Sprint Backlog festgehalten. Der Sprint Backlog enthält also jene Aufgaben, welche im jeweiligen Sprint erledigt werden sollen um ein funktionsfähiges Zwischenprodukt entwickeln zu können.

3. Product Increment

Das Product Increment ist das Ergebnis aus allen in einem Sprint fertiggestellten Einträgen des Product Backlogs und den Resultaten aus vorherigen Sprints und stellt somit ein Zwischenergebnis des Projektes dar.

5. Ablauf

Da nun alle Rollen und Artefakten des Scrum Prozesses bekannt sind, wird der genaue Ablauf näher erklärt. Grundsätzlich besteht Scrum aus fünf Aktivitäten – Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective und Product Backlog Refinement.

1. Sprint Planning

Im Sprint Planning wird der nächste Sprint geplant, indem jene Anforderungen aus dem Product Backlog bestimmt werden, die im nächsten Sprint vom Team umgesetzt werden sollen. Dabei werden die Anforderungen in konkrete Aufgaben zerlegt. Wichtig dabei ist, dass einheitlich spezifiziert wird, was gemacht werden muss, damit eine Aufgabe als erfolgreich umgesetzt gilt. Es ist also wichtig, dass ein gemeinsames Verständnis über die Anforderungen erreicht wird. Die im Sprint Planning festgelegten Anforderungen werden im Sprint Backlog festgehalten.

2. Daily Scrum

Während dem Sprint findet jeden Morgen ein etwa viertelstündiges Meeting statt - das Daily Scrum. Dabei treffen sich alle Teammitglieder, meist auch Scrum Master und Product Owner, um den aktuellen Status des Sprints zu besprechen. Jedes Teammitglied erklärt kurz, was seit dem letzten Daily Scrum umgesetzt wurde, welche Probleme oder Hindernisse auftraten und welche Aufgaben bist zum nächsten Meeting anstehen. Jedoch dient das Daily Scrum nicht einer möglichen Problemlösung, sondern allein dem Informationsaustausch. Fragen bzw. Probleme, die während des Daily Scrums nicht geklärt werden können, werden an den Scrum Master zur Klärung gegeben, oder in einer separaten Besprechung geklärt.

3. Sprint Review

Am Ende eines jeden Sprints werden im Rahmen eines Sprint Review die Ergebnisse des aktuellen Sprints vom Team präsentiert und vom Product Owner geprüft, ob alle Anforderungen der einzelnen Product Backlog Einträge, die in diesem Sprint bearbeitet wurden, auch wirklich erfüllt wurden. Außerdem wird Feedback von interessierten Stakeholdern eingeholt und wenn nötig die Anforderungen im Product Backlog angepasst. Dadurch ist schnell ersichtlich, ob die umgesetzten Funktionalitäten auch den Bedürfnissen der Zielgruppe entsprechen und das Projektteam kann schnell auf Anforderungsänderungen reagieren.

4. Sprint Retrospective

Hierbei geht es darum, dass sich das Team am Ende eines Sprints trifft und zusammen mit dem Scrum Master reflektiert, was in diesem Sprint gut funktioniert hat und welche Punkte noch Verbesserungsbedarf haben. Es geht also nicht um die Überprüfung des Product Increments sondern um die geleistete Arbeit im Team während des Sprints. Ziel ist es dadurch die Zusammenarbeit kontinuierlich zu verbessern.

5. Product Backlog Refinement

Da sich, wie bereits erwähnt, die Anforderungen an ein Projekt laufend ändern können, ist es wichtig auch den Product Backlog stetig aktuell zu halten. Hierzu muss der Product Owner den bestehenden Product Backlog am besten immer zu Beginn und Ende eines Sprints durchgehen und gegebenenfalls aktualisieren, weiterentwickeln und verfeinern.

6. Fazit

Scrum ist als agiles Verfahren dafür ausgelegt, schnell auf sich ändernde Situationen zu reagieren und sich anzupassen. Zudem werden nach jedem Sprint neue Anforderungen an die Software erfüllt und der Kunde erhält so ein immer lauffähigeres Produkt. Damit soll vermieden werden, dass der Kunde erst am Ende ein tatsächlich von den Anwendern einsetzbares Produkt erhält und erst dann Änderungswünsche auftauchen. Die Priorisierung der Anforderungen nach Geschäftswert sorgt zusätzlich dafür, dass der Kunde frühzeitig seine wichtigsten Funktionen nutzen kann.

Damit Scrum jedoch als Projektmethode funktionieren kann, müssen gewisse Voraussetzungen erfüllt sein. Zum einem muss das Unternehmen eine positive Fehlerkultur pflegen und genug Vertrauen in die Mitarbeiter haben, dass diese eigenverantwortlich und selbstorganisiert arbeiten können. Aber auch das Team selbst muss eine gewisse Selbstständigkeit mitbringen und eigene Lösungswege zu finden. Sind diese Anforderungen erfüllt stellt Scrum ein gutes Framework dar, im schnelllebigen Softwaresektor schnell auf Änderungen zu reagieren und ein gutes Klima zwischen Auftraggeber und -nehmer aufrecht zu erhalten.