Vorgehensweisen
Klassische vs. Agile Vorgehensweise
Last updated
Klassische vs. Agile Vorgehensweise
Last updated
In klassischen Prozessmodellen, wie dem Wasserfallmodell wurde oft zu Beginn eines Projektes ein sogenanntes Pflichtenheft erstellt, wo alle möglichen Anforderungen aufgeschrieben wurden. Dieses musste dann von Auftraggeber und Auftragnehmer unterschrieben werden und galt als Vereinbarung für das Produkt, welches aus dem Projekt entstehen sollte.
Das Problem: Oft, oder gar fast immer, haben Programmierer und Kunden nicht die gleiche Vorstellung von einer Lösung.
Daher kam es oft vor, dass zu Beginn eines Projektes mit dem Kunden dieses Pflichtenheft angeschaut wurde und unterschrieben, und dann nach Monaten der Entwicklung das Programm "fertig" war und dem Kunden übergeben wurde. Darauf folgte dann auch immer die Ernüchterung. "Das habe ich so nicht bestellt".
Eine der schwersten Aufgaben in der Softwareentwicklung ist es, die Bedürfnisse des Kunden zu verstehen. In der Regel sind Kunden technisch nicht versiert und wissen nicht, was technisch möglich ist.
Der Kunde kennt nur, was er hat. Wenn er sagt, "ich möchte ein schnelleres Pferd", muss man zuerst das Bedürfnis verstehen. Das schnellere Pferd ist nämlich nicht wirklich das Bedürfnis, sondern bereits ein Lösungsvorschlag basierend auf den Kenntnissen des Kunden. Tatsächlich will er schneller von A nach B kommen.
Wenn man die Wünsche des Kunden zu wörtlich nimmt, kann das die Lösungsfindung wesentlich einschränken.
Unzureichende Kommunikation
Zeitdruck / Zeitmanagement
Ressourcen-Planung
Ziele falsch gesetzt
Unpräzise, stetig ändernde Anforderungen
Ungenügendes Testen
Projektstatus ungenügend verfolgt
Im klassischen Wasserfallmodell haben die Aktivitäten eine klare Reihenfolge.
Analyse: Projektplan, Offerte, Kalkulation, Pflichtenheft
Design: Technische Dokumentation, GUI-Styleguide
Codierung: Umsetzung der Software
Test: Testdokumentation (Testszenarien), Testumgebung/-einrichtung
Integration: Benutzerhandbuch , fertiges System
Die Welt, die Leute und damit auch die Anforderungen ändern sich laufend. In einem klassischen Projektvorgehen hat man aber nicht die Möglichkeit, sich an neue Gegebenheiten, Erkenntnisse oder Wünsche anzupassen.
Fehler werden spät erkannt. (späte Entdeckung von Anforderungs-, Analyse- und Designfehlern, oft erst während Integrationstest)
Risiken werden lange mitgeschleppt («weil jetzt noch nicht codiert/getestet werden darf»)
Nachträgliche Anforderungen können nicht berücksichtigt werden.
Projektfortschritt ist über lange Zeit nicht messbar.
Mit einer agilen Vorgehensweise kann man diese Probleme grösstenteils umgehen.
Das Team von Softwareentwicklern arbeitet in kleinen Iterationen von 2 bis 4 Wochen. Nach jeder Iteration (auch Sprint genant), findet ein Release der funktionsfähigen Software statt, welcher getestet und dem Kunden zur Verfügung gestellt werden oder sogar bereits veröffentlicht werden kann.
Dadurch kann der Kunde von Beginn an der Entwicklung des Produktes teilnehmen und aktiv einschreiten. So werden Missverständnisse sehr schnell erkannt und können korrigiert werden.
Wenn wir das Bild oben nochmal betrachten, kann man auf der Fahrradtour mit einer agilen Vorgehensweise jede Etappe separat planen und sich den neuen Gegebenheiten anpassen.
Die Entwicklung findet in Iterationen / Sprints statt. Die Aktivitäten des Entwicklungszyklus werden in jeder Iteration von neuem durchlaufen. Analyse, Design, Implementierung, Test, Validation, (Release).
Durch die iterative Vorgehensweise entsteht am Ende jeder Iteration ein Produkt. Die Funktionalität der Software nimmt somit inkrementell zu.
Wird eine neue Software entwickelt, kann nach jeder Iteration geprüft werden, ob die Software bereits veröffentlicht und kommerziell genutzt werden kann. So kann ein Produkt potentiell viel früher finanzielle Einnahmen generieren und mit den Einnahmen weiterentwickelt werden.
Potentiell hat man in einer agilen Vorgehensweise also schon früher etwas brauchbares und am Ende durch die ständige Reflexion und Überarbeitung vielleicht sogar ein besseres Resultat.
Weitere Vorteile sind:
Fortlaufendes Kundenfeedback -> verbesserte Kommunikation
Probleme / Risiken werden früher erkannt
Greatest Risk first: Reduktion von Projektrisiken: wenn das Projekt scheitert, dann wenigstens früh (bevor viel Geld ausgegeben wurde)
Im Sommer 2016 veröffentlichte Nintendo gemeinsam mit Niantic das Smartphone Game "Pokemon Go", wobei die Entwickler agil vorgingen.
Die erste Version, die im Frühsommer 2016 erschien, war alles andere als "fertig". Viele Features, die beworben wurden, waren gar nicht vorhanden und kamen später mit regelmässigen Software-Updates nach.
Erst am Ende kommt das Resultat zum Kunden. Es liegt auf der Hand, dass das Resultat meist nicht den Erwartungen des Kunden entsprach ().
Trotzdem hat das Spiel bereits 30 Tage nach Veröffentlichung 100 Millionen Downloads im Google Play Store verzeichnet und den Entwicklern durch In-App-Käufe rund $160 Millionen eingebracht (Quelle: ).
