Architektur in agiler SW-Entwicklung

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.

agile_when

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.

 

20121109_095925
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.

 

20121109_100642
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.

 

20121109_101131
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.

 

20121109_103923
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.

 

20121109_104659
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.

 

meaning
Vorab Architektur Design, wiederholte interaktive Design-Workshops mit allen Beteiligten sind zwingende Voraussetzung, um erfolgreich komplexe Software-Produkte agil zu entwickeln.

 

20121109_125850

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.

 

 

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.