Agiles Software-Engineering

Wem nützt schon eine Software, die eine neue Betriebssystemversion oder bestimmte Daten nicht unterstützt? Veraltetete Software rührt meist daher, dass sich grundlegende Anforderungen geändert haben und diese Änderungen nicht in der Software nachempfunden wurden. Das klassische Software-Engineering ist eine sehr starre Methode, um die Kundenwünsche zu befriedigen. Durch Agilität wird es möglich, Änderungen während der Implementierung einfließen zu lassen und in den klassischen Ansatz Flexibilität zu bringen.

Software als Aufgabe

Software als Aufgabe, nicht als Projekt!
Hauptunterschied zwischen klassisch und agil ist wohl der Paradigmenwechsel das Software-Engineering als endlose Aufgabe und nicht als Projekt anzusehen. Bei einem Projekt handelt es sich um eine Arbeit, die in einer bestimmten Zeit, in einer definerten Qualität und Quantität im Rahmen eines festen Budgets erledigt wird.
Agile Prozesse fußen auf Vertrauen und Transparenz aller Beteiligter. Egal ob im eXtreme Programming, Scrum oder Kanban immer muss der Kunde (Auftraggeber) den Entwicklern sein Vertrauen schenken und ihnen die Aufgabe, eine Software zu entwickeln, anvertrauen. Die Entwickler hingegen müssen transparent arbeiten, Rücksprache mit dem Kunden halten, wenn es Probleme gibt, sich hinterfragen lassen und ungeschönte Zwischenergebnisse präsentieren. Da diese Zusammenarbeit im Wirtschaftssystem mit Konkurenz und Wettbewerb schwierig umzusetzen ist, gliedern Unternehmen, wie die Deutsche Bahn AG, solche agilen Teams in die Abteilungen ein. Das sichert schlussendlich auch das Urheberrecht an der Software für das Unternehmen. Das Team entwickelt die Software intern, hat Zugang zu Geschäftsgeheimnissen, Prozessen und direkten Kontakt zu den späteren Nutzern. Die Methode Scrum entstand als agile Methode im Kontext des Software-Engineerings. Scrum gilt als das Werkzeug, um eine Software zu entwickeln.

Scrum als Werkzeug

Die agile Methode Scrum ist ein iterativer Prozess aus dem Themenbereich der empirischen Prozesssteuerung. Das heißt die Durchführung dieses Prozesses hängt stark von den statistischen Kennzahlen jeder Iteration ab. Wurden beim ersten Durchlauf dieses Prozesses 5 Tasks fertiggestellt und beim folgenden 7 Tasks, rät die Statistik dazu im dritten Durchlauf 9 Tasks zu bewältigen. Vermutlich wird das nicht gelingen, weshalb sich im Verlauf der Zeit ein empirischer Mittelwert bildet, der als Schätzwert genutzt werden kann. Im Bezug auf diese Masterarbeit ist als Prozess die Software-Entwicklung zu verstehen; beginnend bei der Anforderungsaanalyse über den Entwurf, die Implementierung, das Testen, die Inbetriebnahme und die Wartung/Anpassung/Refaktorisierung. Scrum wird vom Scrum-Team auf der einen und den Stakeholdern auf der anderen Seite gelebt. Der Product Owner ist der Vertreter der Stakeholder im Scrum-Team. Er verwaltet das Product Backlog und damit die Systemanforderungen und Bedürfnisse des Kunden. Der Scrum-Master ist ein Helfer für das Entwicklungsteam. Er arbeitet daran, dass das restliche Team arbeiten kann (technisch, rechtlich, organisatorisch) und hat keine Führungsfunktion. Das Entwicklungsteam besteht aus 3 bis 12 Personen und wird aus den Fachexperten gebildet. Im Entwicklungsteam entfallen die Titel wie Tester, Designer, Programmierer, Requirements-Engineer, Datenbankarchitekt, etc.
Die Mitglieder des Scrum-Teams sind gleichberechtigt und selbstorganisierend. Durch ihre Zusammenarbeit entsteht nach jeder Iteration eine Software-Version, die dem Kunden einen Mehrwert liefert. Das Entwicklungsteam entnimmt im Sprint-Planning-Meeting ausgewählte Einträge aus dem Product Backlog und setzt diese Aufgaben um. Das Ergebnis wird dem Stakeholdern im Sprint-Review-Meeting präsentiert. Diese Besprechung fördert ertrauen und Transparenz unter den Beteiligten. Die dritte Säule der empirischen Prozesssteuerung ist die Überprüfung. Dazu dient das Sprint-Retrospektive-Meeting. Dabei trifft sich das Scrum-Team und wertet die letzte Iteration und das Ergebnis aus.
Zur Überprüfung gehört auch, das tägliche Standup-Meeting Daily Scrum. Das Entwicklungsteam reflektiert die Arbeit des vorangegangenen Tages und plant den aktuellen Tag. Alle Meetings sind in ihrer Dauer zwischen 15 Minuten und 4 Stunden begrenzt.

Fazit

Da Scrum für Teams entwickelt wurde, eignete es sich nicht für die Durchführung dieser Masterarbeit. Jedoch können einige Elemente der Agilen Entwicklung auf eine Einzelperson adaptiert werden: angefangen bei den User Stories und deren Unterteilung in Tasks, das Product Backlog, das Iterative Vorgehen in Sprints. Dadurch hängt die Entwicklung der Software nicht an einem Experten, sondern an allen Beteiligten aus der Abteilung. Aus organisatorischen Gründen sollte die Sprintlänge von vier auf sechs Wochen erweitert werden und auch Pausen (Urlaub) ermöglichen.