Wie definiert sich notwendige "Agilität" bei der Abwicklung größerer technisch orientierter Projekte (z.B. in der Software-Entwicklung)?
2 Antworten
Man entwickelt kleine Inkremente und liefert diese stuckweise aus - holt sich Feedback und setzt dieses unmittelbar um.
Man ist in der Lage auf wechselnde Anforderungen schnell zu reagieren und kann neue Technologien schnell im Produkt verwerten.
vor allem nicht solcher, bei denen man sich auf einen Festpreis einlassen musste.
Ja, solche "Projekte" wirst du aber kaum mehr finden. Das was mir da einfällt sind irgendwelche eingebetteten Systeme für Lebenskritische Bereiche (Software zum Steuern einer Herzpumpe, Bremssystem im Auto, etc.)
Alles was unter "normale Anwendungen" fällt kannst du mit anderen Methoden gar nicht mehr wirklich umsetzen.
In dem Moment wo du zwischen Anforderungsermittlung und "Ausrollen" der Anwendung mehr als 1 Jahr brauchst, weißt du gar nicht mehr ob das was du da entwickelt hast wirklich das ist was der Kunde wollte / brauchte.
Ich kann dir aus der Praxis sagen, die meisten Teams arbeiten agil bzw. versuchen es zumindest.
Daran ist viel Wahres. Aber leider gibt es halt auch wichtige Projekte, die sich nicht in nur einem Jahr erledigen lassen.
Und genau bei denen sollte man nicht erst nach 2 Jahren überprüfen ob man das Entwickelt hat was auch gebraucht war xD
Ja, da will ich Dir nicht widersprechen.
Es bedeutet aber nicht, dass das sog. "Wasserfallmodell" überholt sei (wie viele der Agilisten meinen). Überholt ist nur die alte — bis in die 1990-er Jahre vorherrschende Meinung —, dass man zu jedem Zeitpunkt an genau einer seiner Phasen arbeite, das Ergebnis früherer Phasen also festgeschrieben sein müsse bis hin zum Projektende.
Agil zu arbeiten bedeutet, anzuerkennen, dass die Ergebnisse sämtlicher Phasen — sogar die der Anforderungsanalyse — schon vor Projektende sich als teilweise überholt, also abzuändern, herausstellen können.
"Agilität" im weitesten Sinne bedeutet, dass man keinen festen Plan einfach abarbeitet, sondern dass man ein Produkt in Iterationen entwickelt und am Ende jeder Iteration den Stand bewertet und Entscheidungen für die Weiterentwicklung trifft.
Solches Vorgehen ist angebracht für Prototyping (bzw. unverbindliche Ideen-Entwicklung im Rahmen von z.B. Förderprojekten), aber sicher nicht für die — hoffentlich erfolgreiche — Abwicklung größerer technisch orientierter Projekte, vor allem nicht solcher, bei denen man sich auf einen Festpreis einlassen musste.