Vorteile und Nachteile der agilen Softwareentwicklung
Die Agile Softwareentwicklung ist eine moderne und gute Methode um IT Projekte umzusetzen.
In diesem Beitrag werden die Vorteile und die Nachteile dieser Entwicklungsmethodik aufgezeigt.
Einführung
Der lange Zeit beliebteste Programmier-Ansatz war (und ist zum Teil noch) die sogenannte Waterfall-Methode (Englisch für Wasserfall).
Hierbei ging man Schrittweise vor. Zum Start des Projektes wurden alle Anforderungen niedergeschrieben. Dann wurde das komplette Design erstellt (System-Design, Screen-Design, etc.). Danach wurde der komplette Code erstellt. Nach welchem dann das Testing des Systems und die anschliessende Wartung folgt.
Hierbei gibt es einige Herausforderungen in Waterfall, welche man versucht durch die Agile Softwareentwicklung zu lösen.
Einige davon sind:
- Alle Anforderungen sind zum Start des Projektes nicht bekannt: Zum Teil wissen die Projektbeteiligten, unter welchen sich auch Nicht-IT Experten befinden, nicht welche Funktionalitäten das System haben muss.
- Viele Anforderungen entstehen erst während des Projektes: Während des Projektes, dass heisst, nach der Entstehung der ersten Funktionalitäten wird dann klar, dass wichtige Punkte in der Planungsphase am Anfang übersehen wurden.
- Fehlende Zeit für die Planungsphase: Um im Wasserfall-Modell Erfolg zu haben, braucht es eine ausgiebige Planungsphase. Nur so können die wichtigsten Dinge besprochen und geplant werden. Die Projektinvolvierten, wie bereits erwähnt sind darunter viele Nicht-IT Experten/ Manager/ Entscheidungsträger/ Budgetverantwortliche, etc. die eventuell nicht Lange auf den Start der Aufgabe warten wollen. Für diese, sogenannten Stakeholder, sind Funktionalitäten, zum Beispiel ein Formular auf der Software, auf welchem man Nachrichten versenden kann, wichtiger. Diese wollen “Resultate” sehen und nicht mit “uncoolen und langweiligen” Planungsphasen verbringen, welchen man niemanden in Rechnung stellen kann.
- Grobe Fehler werden erst zum Ende des Projektes sichtbar: In vielen unzureichend geplanten Waterfall Projekten werden grobe Fehler erst zum Ende der Aufgabenstellung sichtbar, wenn bereits mehrere Monate in das Land gestrichen sind und der Abnahme-Chef auf der Kundenseite merkt, dass das Software-System gar nicht das kann, was man initial wollte.
Vorteile
Im Folgenden einige Vorteile, welche Agile mit sich bringt und mit welchen einige der bisher beschriebenen Nachteile (von Waterfall) behoben werden.
1) Programmierung kann sofort starten
Mit minimalen Anforderungen an das IT System kann das Projekt gestartet werden. Das liegt auch daran, dass der Agile Ansatz bereits davon ausgeht, dass nicht alle, oder sogar nur wenige, Anforderungen zum Beginn der Aufgabe vorhanden sind.
Erst im Zeitverlauf werden weitere Anforderungen von den Projektbeteiligten formuliert.
Würde der Kunde, in dieser Methode, zum IT Unternehmen mit Änderungswünschen, während der Entwicklungsphase kommen, dann würde das IT Unternehmen die neuen Wünsche mit Freude annehmen. Da man hiermit bereits gerechnet und und es sogar ein Bestandteil der Arbeitsweise ist.
Zwischenfazit zu diesem Punkt: Die Mitarbeiter und der Kunde sind befreit von einer “lästigen” Planungsphase und können jederzeit Änderungswünsche einbringen.
2) Resultate sind nach kurzer Zeit sichtbar und erscheinen in regelmässigen Abständen
Das Ziel bei Agile ist es unter anderem in relativ kurzen Abständen funktionierende Funktionalitäten zu lieferen.
Dies kann zum Beispiel in sogenannten Sprints geschehen (Teil des Agilen Frameworks Scrum). Hier werden Zeiteinheiten, zum Beispiel “eine Woche” oder “ein Monat”, vereinbart, nach denen Teile des Systems “fertig” sind und vom Kunden begutachtet werden können.
Zwischenfazit zu diesem Punkt: Der Kunde kann erste Resultate sehen und diese seinem eigenen Management mit gutem Gewissen weitergeben/ vorzeigen.
3) Resultate können vom Kunden und von internen Testern geprüft werden
Dadurch das immer wieder fertige Bestandteile des System zur Verfügung stehen, kann zum einen der Kunde, und zum anderen die internen Software-Tester, das Programm auf die Tauglichkeit prüfen.
Der Kunde kann relativ schnell in die laufende Entwicklung eingreifen, falls er/ sie sieht, dass es nicht ganz in die erwünschte Richtung geht.
Die Tester können durchgängig am System prüfen, ob alle Funktionalitäten richtig laufen. Auch Tester werden in der Lage sein, Fehlentwicklungen frühzeitig zu erkennen.
Zwischenfazit zu diesem Punkt: Grobe Fehlentwicklungen und dadurch entstehende unangenehme Mehrkosten (Zeit, Aufwand, Budget) für das Entwicklerteam und den Kunden können vermieden werden.
4) Änderungswünsche sind erwünscht, beziehungsweise möglich
Dieser Vorteil wurde bereits im ersten Punkt erwähnt. Zeigt jedoch einen Hauptgrund auf, warum man, in manchen Fällen, auf Agile setzen sollte.
Das IT System wird so geschrieben, dass auch neue Funktionalitäten, eingearbeitet werden können. Das Einzige was zu beachten ist, ist das neue Anforderungen erst nach Ablauf eines Sprints (d.h. einer einwöchigen oder einmonatigen Phase) begonnen werden.
Zwischenfazit zu diesem Punkt: Man muss den Kunden nicht von Änderungswünschen, während des Projektes, abhalten, welches man beim Waterfall Modell oft machen muss.
5) Alle Beteiligten sind im ständigen Kontakt
Kommunikation ist wichtig in IT Projekten. Agile fördert und verlangt das.
Beispielsweise werden tägliche Standup-Meetings für das Entwickler-Team vorgeschrieben. Hier wird täglich berichtet, welche Aufgaben gestern gemacht wurden, heute anstehen und vor welchen Herausforderungen man stand oder stehen wird.
Auch zwischen dem Entwickler-Team und dem Kunden gibt es ständigen Kontakt. Meistens jedoch zum Ende einer einwöchigen oder einmonatigen Programmier-Phase.
Zwischenfazit zu diesem Punkt: Durch ständige Kommunikation kann die Entwicklung in kurzen Schritten angepasst werden.
6) Die Aufgaben werden priorisiert
Das komplette IT Projekt wird in Teilaufgaben eingeteilt und nach deren Wichtigkeit priorisiert. Meistens sind das die schwierigsten Aufgaben, welche zudem den höchsten Mehrwert für den Kunden bringen.
Da diese Arbeiten zuerst angegangen und umgesetzt werden, hat der Kunde einen maximalen Nutzen von der Umsetzung.
Unwichtige Funktionalitäten können zum Ende der Aufgabestellung hin erledigt werden.
Zwischenfazit zu diesem Punkt: Besonders zum Start eines Projektes sind alle Augen auf die Umsetzung gerichtet und der Kunde und dessen Management wollen Resultate sehen. Der Mehrwert ist durch die Priorisierung von Anfang an sichtbar.
Nachteile dieser Methode
Es gibt jedoch auch einige Nachteile der Agilen Softwareentwicklungs-Methode. Diese werden im Folgenden aufgezeigt.
1) Nicht alle Entwickler sind zufrieden mit dieser Methode
Bei Entwicklern handelt es sich in den meisten Fällen, um Menschen, die nicht unbedingt die kommunikativsten sind. Viele Programmierer wollen ihre Ruhe haben, wenn es um das Erledigen und Umsetzen von Funktionalitäten geht.
Ständige Meetings und ständiges erklären der bisherigen Aufgaben kann “nervig” wirken. Besonders die kurzen, täglichen Meetings können anstrengend sein. Besonders wenn man nicht viel vorzuweisen hat (meistens braucht es ein paar Tage bis man etwas handfestes vorzeigen kann).
Besonders für Softwareentwickler welche lange Zeit mit der Waterfall Methode gearbeitet haben, kann Agile abschreckend wirken.
Zwischenfazit zu diesem Punkt: Agile kann zu hoher Unzufriedenheit bei den Entwicklern führen, wenn sich diese mit dieser Methode nicht gut auskennen, oder nicht damit “aufgewachsen” sind.
2) Erhöhter Testing Aufwand
In dieser Methode wird ständig gestestet. Daher braucht es einen oder mehrere zusätzliche Testing-Mitarbeiter welche die Aufgabenstellungen während der ganzen Projektphase prüfen.
Dies kann nicht zu verachtende Mehrkosten bedeuten.
Zwischenfazit zu diesem Punkt: Besonders Testing-Aufwendungen sind eher schwer bei Kunden zu verkaufen und darauf wird oftmals auch gerne verzichtet. Auch beim IT Unternehmen selbst fehlt oft der Wunsch noch mehr Personen für das Projekt abzustellen.
3) Projektkosten sind nicht gut einschätzbar
Wenn Anforderungen zum Beginn nicht einschätzbar sind, da Funktionalitäten und Projektanforderungen “On-The-Go” (während des Projektes) entstehen, dann kann ein externer Dienstleister keine genauen Kostenrahmen für die Entwicklung angeben.
Dies ist jedoch oftmals für Abteilungen eines Unternehmens, welches diese Dienstleistungen einkauft, ein Entscheidungskriterium (für oder gegen den Dienstleister; für oder gegen das Projekt; etc.).
Zwischenfazit zu diesem Punkt: Ein externer Kunde möchte in den meisten Fällen wissen, was für Investitionen während des Projektes auf diesen zukommen. Eine Entscheidungsfindung für oder gegen das IT Projekt wird daher erschwert.
4) “Zuviel” Kommunikation notwendig
Jede der Teilaufgaben muss auf “Done” (Englisch für “fertig”) gestellt werden, bevor man zur nächsten Aufgabe geht. Das bedeutet dass, unter anderem, die Endnutzer und Kunden ständig involviert und mit diesen kommuniziert werden muss.
Zeit ist jedoch, bei den meisten Kunden und besonders bei dessen Mitarbeitern, knapp. Daher kann es auch beim Kunden zu Unzufriedenheit führen. Beziehungsweise kann es zu Verzögerungen führen, da der Kunde “keine Zeit” hat, um sich mit den “internen Prozessen” des IT Unternehmens zu beschäftigen.
Zwischenfazit zu diesem Punkt: Die grosse Frage ist auch, ob sich der Kunde wirklich so sehr für Softwareentwicklung interessiert, so dass er auch die ganzen Prozess-Teile von Agile mitmacht. Dies ist in den meisten Projekten nicht der Fall.
Wann macht Agile Sinn?
Wie man sieht, Agile hat seine Vorteile und Nachteile. Wann macht diese Methodik jedoch Sinn. Hier ein paar Szenarien.
Agenturen
Agenturen arbeiten meistens mit externen Unternehmen zusammen, um für diese Web- und Softwareapplikationen zu schreiben.
Diese externen Unternehmen sind meistens durch deren Fachabteilungen vertreten, welche mit Budgets belegt sind.
Hier sind genaue Projektkostenabschätzungen oftmals notwendig, da der Entscheider bei der Fachabteilung, bei seinem Management mit genauen Zahlen argumentieren kann. Feste Preise kann man jedoch nur in der Waterfall Methode erzielen.
Gleichzeitig haben Unternehmenskunden jedoch keine Lust lange an Projekten zu planen “Das ist ja Aufgabe des IT Unternehmens” oder lange auf Resultate zu warten. Welches wiederum die Agile Methode bedingt.
Für eine Agentur ist daher eine gemischte Methode am sinnvollsten. Hierbei wird ein fixer Preis angegeben, in dem man das gesamte Projekt einschätzt. Es braucht gleichzeitig auch einen guten Vertriebsmann/ -frau, welcher aufzeigt, dass Änderungswünsche einen Mehraufwand erzeugen werden.
Intern, in der Agentur, wird dann mit Agile gearbeitet und zum Kunden hin wirkt das Projekt ein wenig wie Waterfall, da es zwar schnell Updates zu den neuesten Features gibt, der Kunde jedoch nicht ständig mit User Acceptance Testing (Endkunden-Testing und Abnahme der Funktionalitäten) und ähnlichen Agilen Praktiken beauftragt wird.
Softwareunternehmen
Softwareunternehmen erstellen IT Lösungen, welche in den meisten Fällen, in einer Art Lizenz-Modell, deren Kunden bereitgestellt werden.
Auch hier ist Waterfall die angebrachtere Methode. Oftmals besteht kein so grosser Zeitdruck, auch weil die Qualität der Funktionalitäten, die Stabilität des Systems, die Ausgereiftheit der Architektur und die Fehlerfreiheit im Vordergrund stehen und es weniger darum geht Managementstrukturen zufrieden zu stellen.
Interne Abteilungen
Abteilungen von Unternehmen arbeiten auch besser mit Waterfall (zum Beispiel interne Projekte die von den eigenen Entwicklern/ Mitarbeitern umgesetzt werden). Auch hier sind die Eigenschaften, welche im vorherigen Punkt genannt wurden, wie zum Beispiel Qualität der Funktionalitäten, etc. viel wichtiger als ein Einhalten eines Abgabetermins oder eines Budgets.
Es werden in den meisten Fällen Vollzeit-Mitarbeiter an dem Projekt arbeiten. Diese “Kosten”-Punkte/ Gehälter müssen dem Management nicht unbedingt beschrieben werden.
Ein Systemausfall ist bei kritischen Systemen, in vielen Fällen, viel schlimmer als eine ausufernde Projektzeit.
Externe Vergabe von Projekten über die Fachabteilung
Dieser Punkt geht zurück auf die Fachabteilungen welche Projekt vergeben. Hier ist meistens die Vergabe über Waterfall einfacher. Auch weil es für einen Laien, welcher in der Fachabteilung arbeitet, verständlich ist.
Besonders aus der Sicht der Fachabteilung, in Unternehmen, macht Agile wenig Sinn. Das beauftragte IT Unternehmen selbst kann dann intern diese Methode nutzen, um das Projekt umzusetzen.
Siehe auch den Punkt weiter oben “Agenturen”.
Externe Vergabe von Projekten über die IT Abteilung
Die IT Abteilung hat in vielen Fällen die Kompetenz die kundenseitigen Aufgaben in einem Agilen Projekt auszuführen. Hier kann dann Agile die richtige Wahl sein, auch weil Projektaufwendungen für einen IT Experten aus der IT Abteilung besser erkenntlich und einschätzbar sind. So können die Kosten auch ohne Waterfall im Rahmen gehalten werden.
Kernsysteme in Unternehmen
Wichtige Systeme, welche das Herz eines Unternehmens ausmachen, sollten immer im Waterfall Ansatz erstellt werden. Oder aus einem Mix aus Waterfall und Agile.
Eine allzuschnelle Entwicklung, wie es bei Agile vorgesehen ist, ist besser nicht angeraten. Auch weil solche Kernsystem über den Erfolg und Misserfolg von solchen Unternehmen entscheidend sind.
Innovative Projekte und junge Teams
Bei innovativen Projekten mit jungen Teams kann Agile die bessere Methode sein. Besonders Startups können von solchen Prozessen profitieren.
Meistens geht es jedoch einfach darum, dass sich die Methode sehr modern gibt und es alle gleichzeitig erlernen können. Es gibt in jungen Teams meistens nicht den Hang zu Waterfall. Auch weil es den meisten einfach nicht aus der Praxis bekannt ist 🙂 .
Unsere Erfahrung
Softwareprojekte die langfristig Erfolg haben sollen, sollten mit Waterfall umgesetzt werden. Dabei sollten Elemente von Agile und andere Methoden (zum Beispiel Kanban, etc.) eingearbeitet werden.
Eine komplette Agile Entwicklung kann nur Sinn machen, wenn die Systeme nicht allzu kritisch sind. Dies ist oftmals der Fall bei Software für Fachabteilungen in Unternehmen. Es lässt sich beispielsweise verkraften, wenn die Personalsoftware für einen Tag ausfällt, etwas langsamer läuft oder optisch nicht so ansprechend ist.
Welche Erfahrung haben Sie gemacht? Wann macht welche Methode Sinn? Wie gehen Sie vor?
Interessante Links:
Mehr Informationen zur agilen Softwareentwicklung auf dem lise Blog
Best Practices zu dieser Art von Softwareentwicklung
Bilder: Flickr.com/ Williams/ Lips
Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.
Schreibe einen Kommentar