Agile Software-Entwicklung wird oftmals gleichgesetzt, mit try and error. Mit Entwicklung, die sich mit nicht-funktionalen Anforderungen erst befasst, wenn diese vom Product Owner definiert werden. Dies ist eine meist sehr teure Fehlinterpretation. Die einzige Vorgabe, die in Scrum und anderen agilen Methodiken gemacht wird, ist so viel oder wenig Architektur-Vorgaben zu machen, wie nötig.
Die Frage, der sich stellt, ist, wann eignet sich dieses Vorgehen:
Sinnvoll eingesetzt wird agile Methodik in Produktentwicklungen, in denen die Anforderungen noch nicht von beginn an klar sind und mit häufigen Änderungen gerechnet werden muss. Oder aber auch, wenn die eingesetzte Methodiken nicht zum gewünschten Projektfortschritt führen.
Doch auch wenn eingesetzte Technologien wohlbekannt sind und/oder die Anforderungen klar definiert sind, kann agile Methodik eingesetzt werden. Der Umkehrschluss ist allerdings nicht möglich, dh. je komplexer die Technologie und je unklarer die Anforderungen, desto wahrscheinlicher kann agile Methodik den Projekterfolg positiv beeinflussen.
Doch gerade wenn die Anforderungen von Beginn an bereits wohl definiert sind, ist eine grundsätzliche Architekturvorgabe äusserst hilfreich, sofern sie von den implementierenden Teams getroffen , und nicht von Aussen vorgegeben wird.
Insbesondere wenn das neue Produkt nicht auf der ‚grünen Wiese‘, sondern in eine bestehende Infrastuktur eingebunden werden muss, so ist noch mehr Wert auf eine eingehende Architekturanalyse zu legen.
Dies kann zum einen im ‚Sprint 0‘ oder aber solange wie nötig in parallelen Architektur-Stories zu Beginn und während der Entwicklung erfolgen.Eigenständige und von der Entwicklung entkoppelte Architektur-Teams haben sich hier jedoch als negative Entwicklung entpuppt, da gerade in komplexen Umgebungen die Architekturentwicklung eng an die laufende Entwicklung gebunden ist.
In der Regel werden agile Puristen sich darauf berufen, dass Architekturdesigns nichts mit agiler Entwicklung zu tun haben, da sie keinen Wert in Form von implementierten Features darstellen.
Dem ist jedoch entgegenzustellen, dass wiederum das Pareto-Prinzip auch hier gilt: 80% aller Fehler können mit 20% des Aufwandes zum Entwicklungsbeginn vermieden werden. Insbesondere bei komplexen, definierten Anforderungen ist eine ausführliche (Design-)Planung unerlässlich.
Gerade wenn in eine bestehende komplexe Infrastruktur ein neues Produkt implementiert wird, ist eine ausführliche Design- und Architekturphase unerlässlich. Auch wenn der Feature- und Zeitdruck erheblich ist, lässt sich auf
Spikes für diese unerlässlichen Vorarbeiten nicht verzichten. Hier hat sich
Impact Mapping als effiziente Methodik für die Verknüpfung von Business Cases und Implementierung etabliert.
Vorab Architektur Design, wiederholte interaktive Design-Workshops mit allen Beteiligten sind zwingende Voraussetzung, um erfolgreich komplexe Software-Produkte agil zu entwickeln.
Agile Software-Entwicklung lebt von der Kommunikation und Konversation. Wie sämtliche Erkenntnisse in der IT davon leben. Sofern diese Kommunikation nicht über Visio-Grafiken erfolgt, sondern tatsächlich als physikalisches Medium transportiert wird, sind beste Voraussetzungen gegeben, um adhoc genau die Menge an Architektur-Vorgaben zu definieren, wie für eine erfolgreiche Umsetzung benötigt werden.
