SCRUM – Agile Softwareentwicklung

Abstract:

In naher Zukunft wollen wir unsere Softwareprodukte in ein modernes Design einhüllen, um Ihnen eine bestmögliche Oberflächen-Performanz bieten zu können, nebst neuen Produktfeatures die bereits in unserer Pipeline auf Sie warten. Um zukünftig noch flexibler auf Ihre Kundenwünsche und Marktbedürfnisse reagieren zu können, arbeitet unser Entwicklerteam zukünftig nach der SCRUM-Methodik. Was hinter dem Begriff SCRUM steckt, aus welchen Bedürfnissen heraus es entstand und welche Vorteile es bietet, möchten wir Ihnen im folgenden Artikel gerne erläutern.

1. SCRUM – kurz und prägnant

SCRUM steht in erster Linie für ein selbstorganisiertes und transparentes Arbeiten im Team. Neben dem Entwicklerteam werden verschiedene Rollen wie z. B. der Product-Owner oder der SCRUM-Master besetzt. Die Entwicklungsphasen werden als Sprints bezeichnet, was aber keinesfalls bedeutet, dass das Entwicklungsteam ständig unter Volldampf arbeitet. Der kontinuierliche Zyklus, von der Arbeitsplanung bis zum Rollout des Produktes, wird durch verschiedene Meeting-Formen begleitet bzw. gestaltet.

2. SCRUM – warum eigentlich?

Zu Beginn des Industriezeitalters hat man Prozesse in möglichst granulare Prozessbausteine zerlegt. Man konnte damit die Komplexität eines klar definierten und vorhersehbaren Vorgangs stark minimieren, den Prozessablauf transparent gestalten. Den Mitarbeitern wurde nicht mehr geballte Kompetenz bzw. Fachwissen abverlangt und die Einarbeitungszeiten wurden erheblich verkürzt. Auf der anderen Seite hatte das Management aufgrund der Transparenz wesentlich effizientere Möglichkeiten, Prozesse zu kontrollieren und zu optimieren.

Heutzutage hat die Informationstechnologie eine zentrale Rolle in allen Lebensbereichen eingenommen. Dadurch hat es einen deutlichen Zuwachs an Leistung und Komfort, aber auch Schnelllebigkeit gegeben. Wenn ein Auto vom Fließband fährt, ist es in der Regel auch fertiggestellt.

Für Softwareprodukte gilt das in den allerwenigsten Fällen. Eine Software lässt sich in Schichten unterteilen, wie z. B. Frontend, Backend, grafische Benutzeroberfläche, Webserver, Datenbankserver, Modell, View, Controller etc. Eine Vielzahl von Programmiersprachen, Softwarekomponenten und Architekturkonzepten kommen zum Einsatz. Daneben besteht an die meisten Softwareprodukte die Anforderung einer plattformunabhängigen Portierbarkeit.

Kurz und knapp, Softwareprodukte leben von Ihrer Dynamik, sind meist nur auf kurze Sicht planbar und ihre Komponenten stehen in starker Wechselwirkung. Nachdem man in der Frühphase der Softwareentwicklung noch mit präskriptiven Methoden, genannt sei hier Rational Unified Process (RUP), gearbeitet hat, etablieren sich heute immer stärker adaptive Methoden wie SCRUM oder Kanban. Man versucht, den Mitarbeitern einen Gestaltungsspielraum zu geben, setzt auf kürzere Entwicklungszyklen von Teilprodukten, nutzt Synergien aus übergreifendem Know-how im Team und gibt den Mitarbeitern die Möglichkeit, sich stärker fortzubilden bzw. breiter aufzustellen. Durch die stärkere Einbindung der Mitarbeiter in den Entscheidungsprozess werden auch die Identifikation mit dem Produkt und der Spaß an der Arbeit gefördert, der entgegen mancher Meinung mit der Herausforderung wächst.

2.1. Kochrezept SCRUM-Suppe

Will man SCRUM im gesamten Unternehmen einführen, bedarf es schon etwas mehr Aufwand. Um die Methodik in der Entwicklung einzuführen, reichen jedoch oft schon ein paar grundlegende Veränderungen aus.

Die Entwicklerteams sollten aus maximal sieben Personen bestehen. Der Product-Owner bildet die kundenseitige Schnittstelle, liefert dem Entwicklerteam sogenannte User-Stories, schätzt deren Aufwand und Dringlichkeit nach Kennzahlen wie z. B. dem Business-Value und speichert diese wiederum in einem Product-Backlog. Im besten Fall ist der Product-Backlog heutzutage schon in einer Aufgabenverwaltungssoftware wie beispielsweise Jira (Atlassian) enthalten und mit ein paar Handgriffen auf die eigenen Bedürfnisse der Abteilung angepasst. Das Entwicklerteam bedient sich zur Planung der Sprints aus dem Product-Backlog. Die User-Stories des Product-Backlogs werden in regelmäßig stattfindenden Estimation-Meetings vom Entwicklungsteam nach dem Grad ihrer Komplexität geschätzt.

Ein probates Mittel für die Komplexitätsschätzung stellen hierbei die Story-Points dar, maßlose, relative Zahlen, die meist aus einer Zahlenreihe der unreinen Fibonacci-Folge herausgenommen werden. Die Entwicklungszyklen, in SCRUM als Sprint bezeichnet, dauern zwischen zwei und vier Wochen. So kann man auf Veränderungen und Kundenwünsche besser reagieren und frühzeitig erkennen, in welche Richtung sich ein geplantes Produkt entwickelt.

Vor jedem Sprint finden zwei Sprint-Plannings statt. Hier wird zum einen der Sprint-Umfang bestimmt, zum anderen werden die User-Stories vom Entwicklerteam in einzelne Tasks aufgedröselt. Das Pensum eines Tasks sollte möglichst im Rahmen eines Arbeitstages liegen. Während des laufenden Sprints sollten keine Veränderungen mehr vorgenommen werden. Der laufende Sprint sollte in der Regel für alle Beteiligten transparent und sichtbar sein. Dazu empfiehlt es sich, neben einer Software auf das bewährte Whiteboard zurückzugreifen.

Der Sprint wird dazu in mehrere Phasen aufgeteilt (i. d. R. von ToDo über Progress nach Test bis letztendlich zu Done). Vorab wird mit dem SCRUM-Team vereinbart, ab welchem Entwicklungsstand eine User-Story im Sprint als abgeschlossen gilt (Definition of Done). In einem Sprint-Review werden die erreichten Ziele des jeweiligen Sprints präsentiert und besprochen. Zur Reflektion der Entwicklungszyklen und Verbesserung gibt es zudem ein Sprint-Retrospektive-Meeting. Während des gesamten SCRUM-Prozesses ist der SCRUM-Master eine Art Mediator. Er bemüht sich, äußere und innere Störungen im Entwicklungsteam zu beheben. Er achtet darauf, dass sich jeder Beteiligte an die Spielregeln hält und bildet einen neutralen Bezugspunkt.

2.2. Erfahrungen

Die Einführung neuer Prozesse dauert erfahrungsgemäß, weil sich alle Beteiligten darauf einstellen müssen. Wir stehen derzeit noch am Anfang dieses Prozesses. Wir haben uns deshalb von einem SCRUM-zertifizierten IT-Consultant der Fa. Hawlitzek IT-Consulting GmbH im Rahmen eines Workshops praktische Tipps geben lassen. Welchen Eindruck SCRUM bei unseren Mitarbeitern hinterlässt und welche Auswirkungen dies auf die Arbeitseffizienz und die Qualität unserer Produkte hat, darüber würden wir Sie gerne in zukünftig folgenden Beiträgen auf dem Laufenden halten.