Bauen ohne Fundament? Agile Entwicklung und Upfront-Architektur im Spannungsfeld

Transkript

1 Baue ohe Fudamet? Agile Etwicklug ud Upfrot-Architektur im Spaugsfeld Baue ohe Fudamet? Agile Etwicklug ud Upfrot-Architektur im Spaugsfeld Frotlastige Architektur ud Agilität scheie wie Feuer ud Wasser, de frühe Festleguge widerlaufe dem agile Ziel, Etscheiduge möglichst spät zu treffe. Aber ka spät icht auch zu spät sei? Welche Frage sollte auch ei agiles Projekt früh kläre? Die Atwort liegt i de Risike ud Rahmebediguge des Projekts. Mit eiem Midestmaß a Aalyse lässt sich der Sweet Spot zwische ugeplatem ud überplavollem Vorgehe treffe. Dieser Artikel erläutert das Spaugsfeld zwische agiler Etwicklug ud eier Upfrot- Architektur ud gibt vom Etwicklugsumfeld abhägige Leitliie für de Umgag damit. Agilität ist Trumpf. Seit der Veröffetlichug des agile Maifests 2001 habe sich agile Praktike ud Vorgehesweise erfolgreich im Maistream der Softwareetwicklug etabliert. Auch Großkozere ud öffetliche Eirichtuge im Allgemeie icht für Sprughaftigkeit bekat habe sich stolz die agile Softwareetwicklug, etwa i Form vo Scrum oder Software-Kaba, auf die Fahe geschriebe. Schaut ma geauer hi, fällt aber oft eie gewisse Zaghaftigkeit auf. Agile Elemete werde beispielsweise ur auf der Ebee der eigetliche Implemetierug eigesetzt, währed adere Etwicklugstätigkeite wie Aforderugsaalyse, Architektur oder Test auße vor bleibe. Viele fürchte, das Kid mit dem Bade auszuschütte. Wäre es möglich, dass diese Agst icht ur aus Uverstädis oder Uvermöge resultiert, soder berechtigt ist? Hat die agile Etwicklug a mache Stelle auch ihre Greze? Die klassische Egieerig-Techike, die sich i de letzte Jahrzehte i der Praxis festige kote, habe weiterhi eie Wert. Vielleicht erweckt die oftmals starke Abgrezug der agile Bewegug vo der klassische, plagetriebee Etwicklug de Eidruck, dass es ötig ist, eie harte Liie zwische dem agile ud eiem geschützte, klassische Teil des Projekts zu ziehe. Gerade i der Softwarearchitektur wird dieser Koflikt sichtbar. Dabei gibt es durchaus Spielräume für eie Kompromiss. weitere Etwicklug abgegrezte Softwarearchitektur-Phase a. I dieser Phase (siehe Abbildug 1) zerlegt ei erfahreer Softwarearchitekt das System passed zu de Aforderuge ud Rahmebediguge i Bausteie, wie etwa Subsysteme ud Kompoete. Er defiiert Veratwortlichkeite, Schittstelle ud Iteraktioe, etwickelt Lösuge für querscheidede Problemstelluge ud erstellt vor allem eie grüdliche Dokumetatio mit reichlich UML-Diagramme. Erst we er sicher ist, dass die Architektur sämtliche Aforderuge erfülle ka, geht es a die Umsetzug. Geau wie beim Bau eies Hauses erfolgt i diesem (Ati-)Modell der Architekturetwurf also vollstädig upfrot. Uterdrücke wir für eie Momet de Wusch, auf die Probleme eies solche Vorgehes eizugehe, ud blicke wir stattdesse auf die erhoffte Vorteile: Plabarkeit durch die abstrakte Zerlegug des Systems: Auf Basis der Bausteizerleguge mit ihre techische Spezifikatioe lasse sich Aufwäde abschätze, was die Budgetierug oder Agebotserstellug erleichtert. Verteile vo Bausteie auf orgaisatorische Eiheite: Projektteams köe passed zusammegestellt werde oder die Umsetzug eier Kompoete wird ahad der Spezifikatio a eie extere Diestleister vergebe. Risikomiimierug durch eie frühzeitige Aalyse der Eiflussfaktore: Der Architekt ka rechtzeitig übergreifede Lösugskozepte für schwierige Aforderuge etwickel ud bewusst otwedige Abwäguge treffe. Erhöhtes Systemverstädis durch eie eiheitliche, kosistete Architektur: Das vermeidet Reibuge oder Zusatzaufwad durch otwedige Refactorigs. Das Ede der Upfrot-Architektur? Die Nachteile der Upfrot-Architektur i ihrer Reiform liege auf der Had. Aforderuge veräder sich über die Projektlebesdauer oder bleibe sogar über lägere Vom Wasserfall zur agile Architekturetwicklug Was bedeutet Softwarearchitektur im klassische Si? Ma dekt vielleicht etwas überspitzt a de Wasserfall-Prozess: A eie abgeschlossee Aforderugserhebug ud -aalyse schließt sich eie vo der Abb. 1: Klassisches Vorgehe zur Architekturerstellug. 50

2 Abb. 2: Agiles Vorgehe zur Architekturerstellug. Zeit uklar. Wer icht weiß, ob sei Haus ei Geschäft oder ei Schwimmbad werde soll, sollte mit dem Desig des Erdgeschosses och warte. Eie ausführliche Aalyseud Architekturphase bildet zudem eie Flaschehals ud führt im schlimmste Fall zur Selbstlähmug ( Aalysis Paralysis, vgl. [Sou]). Vorab getroffee Etscheiduge müsse agesichts techischer, fachlicher oder orgaisatorischer Realitäte agepasst oder eu gefällt werde. Das kreative Potezial des Etwicklerteams wird ur eigeschräkt geutzt ud der Wissesaufbau, der sich aus der Umsetzug ud dem Test des Systems ergibt, verzögert sich. Gleichzeitig werde dabei techische oder fachliche Aspekte übersehe, die sich erst bei der Faktore für agiles Vorgehe Domäeerfahrug der Etwicklug reduziert das Risiko vo späte Aforderuge, die ei umfassedes Re-Desig erforderlich mache. Bei bestehede Systeme sid viele grudlegede Etscheiduge scho getroffe worde. Techologische Risike sid dadurch iedriger. Durch die Techologie vorgegebee Architekture reduziere die Gefahr vo Ikosisteze ud de dadurch etstehede Itegratiosaufwad. Gut zu kapselde Techologie helfe dabei, Fuktioalität aufzuteile ud trotzdem erweiterbar zu bleibe. praktische Umsetzug als Herausforderug für de Etwurf herausstelle. Auch produktives Feedback vom Kude bleibt ohe ei lauffähiges Produkt Magelware. Probleme werde also spät erkat ud führe gegebeefalls etgege dem Pla zu späte ud schmerzhafte Etwurfsäderuge. Agile Vorgehesweise versuche explizit, diese Probleme zu vermeide. Die Umsetzug startet so früh wie möglich, um aus der Erfahrug Erketisgewie zu ziehe. Aforderuge werde vo Begi a als veräderlich begriffe ud Lösuge daher icht umfassed, soder iteratiosweise ikremetell etwickelt. Aforderuge mit hohem Busiess-Wert werde bevorzugt umgesetzt ud demostriert, um Faktore für Upfrot-Desig Tabelle 1: Faktore für agiles Vorgehe versus Upfrot-Desig. Harte Radbediguge i Bezug auf querschittliche Aspekte oder Ressource (etwa Speicherverbrauch) köe achträglich ur schwer berücksichtigt werde. Eie verteilte Etwicklug muss uabhägig arbeite köe, was eier geauere Spezifikatioe vorab bedarf. Gesetzliche Vorschrifte erforder isbesodere i Bezug auf das Risikomaagemet i mache Brache ei klassisches phaseorietiertes Vorgehe. Ist eie feste Budgetplaug erforderlich, verträgt sich dies icht mit ubekate Aforderuge ud sich städig veräderde Techologie. frühzeitiges Kude-Feedback zu geeriere. Kreativität ud Motivatio des Teams rücke dabei i de Vordergrud. Betrachte wir also die agile Reiform des Softwareetwurfs. Die Veratwortug für de Architekturetwurf wird icht durch eie ausgezeichete Perso, soder vom gaze Etwicklerteam getrage. Es existiert also keie explizite Architekterolle. Der Fokus jeder Iteratio ist das miimale Produkt, das ei geplates Ikremet a Aforderuge umsetzt. Für techische Fragestelluge werde die eifachste Lösuge gewählt. We sich herausstellt, dass zur Umsetzug weiterer Aforderuge eie adere techische Etscheidug oder eie geteilte Ifrastruktur sivoll wäre, fidet ei Refactorig statt. Abbildug 2 zeigt grob die Schritte des Vorgehes. Das Team trifft also techische Etscheiduge auch solche, die die Architektur betreffe so spät wie möglich, um flexibel zu bleibe. We eie Etscheidug gefällt wird, beruht sie auf dem aktuelle Wissesstad sowohl hisichtlich der Aforderuge, die sich geädert habe köe, als auch hisichtlich der techische ud fachliche Domäe, i die sich das Etwicklerteam durch die bisherige Tätigkeit eiarbeite kote. Zudem ist sich das Team der uvermeidliche Äderuge bewusst ud wählt gezwugeermaße eie Etwurf, i dem Veräderuge ud Erweiteruge möglichst schmerzlos umsetzbar sid, etwa durch Awedug agiler Etwurfsprizipie (vgl. [Mar03]). Gegeüber eiem frotlastige Vorgehe wird Overhead eigespart ud die Wahrscheilichkeit für de Projekterfolg steigt. Sollte ma also auf eie Upfrot-Architekturtätigkeit lieber verzichte? Es gibt viele Projekte, dee das geligt. Dabei sid, wie i Tabelle 1 gegeübergestellt, verschiedee Faktore im Spiel. Hilfreich ist es, we das Team scho eie hohe Kompetez i der Projektdomäe besitzt. Durch diese Erfahrug werde bedeutede Etscheiduge icht übersehe, soder zu eiem geeigete Zeitpukt adressiert. Existiere bereits Erfahruge mit ähliche Projekte, liefer diese wertvolle Dekschabloe ud Vorgabe, vielleicht kommt es sogar zur Architektur-Wiederverwedug. Oder ist der Eisatz eies umfassede Frameworks oder eier Referezarchitektur vorgegebe? Da sid viele grudlegede techische Fragestelluge scho beatwortet ud es ka direkt mit der Umsetzug vo Features begoe werde. 04/

3 Baue ohe Fudamet? Agile Etwicklug ud Upfrot-Architektur im Spaugsfeld Abb. 3: Zusammehag zwische Upfrot-Aufwad ud Lösugsqualität. Sprache, Techologie ud Kommuikatiosmechaisme uterscheide sich dari, wie gut ma verschiedee Architekturaspekte kapsel ud später bei Bedarf äder ka. Als Beispiel: Ei guter Programmierer wird i eier Web-Architektur auf JBoss-Basis, bei der er auf die Datebak durch Hiberate zugreift, oft auch ohe explizite Architekturüberleguge ei leicht erweiterbares System erstelle. Aders sieht dies aus i eier Airbag-Steuerug, die eie Mischug aus C-Code ud hadoptimiertem Assemblercode darstellt. Wichtig ist i jedem Fall, dass das Team die Bedeutug der Architektur akzeptiert ud die otwedige Pflege betreibt. I eier agile Etwicklug wird Techical Debt also agesammelte techische Qualitätsmägel der Software, die dazu führe, dass die Softwareetwicklug im Laufe der Zeit zuehmed lagsamer wird - erkat ud agegage, etwa durch techische User- Storys. Das Team kommt ohe eie feste Architekterolle aus, solage die dahiterstehede Tätigkeit stattfidet. Jedes Teammitglied wird Architekturaspekte aspreche ud verfolge (vgl. [Cop10]). Zurück auf Los? Je streger die Aforderuge ud Radbediguge sid, je geriger die Sicherheit, mit der ma sich im Lösugsraum bewegt, oder je größer das Projekt ist, desto leichter gerät das Gebäude is Wake. Werde die Architekturetscheiduge uabhägig i de eizele Iteratioe getroffe, so führt dies zu eier lokale Optimierug bezoge auf die jeweils aktuelle Problemstellug (liks i Abbildug 3). Die Betrachtug des Gesamtsystems also die Suche ach dem globale Optimum (rechts i Abbildug 3) wird dabei leicht außer Acht gelasse. Dieser Asatz fuktioiert, we das lokale Optimum für ei erfolgreiches Produkt ausreicht. Bei harte Radbediguge, wie zum Beispiel kappe Speicherressource, Timig- oder Sicherheitsaforderuge, ist jedoch die Gefahr groß, dass ei lokales Optimum de Aforderuge icht gerecht wird. Das macht eie späte ud womöglich kostspielige Überarbeitug erforderlich. Nehme wir als Beispiel ei streges Zeitbudget i eiem Echtzeitsystem. Füge wir i eizele Schritte Fuktioalität hizu, fällt es zuächst leicht, das Zeitbudget zu erfülle, de jede Fuktio verbraucht ur eie Bruchteil des Budgets. Schwierigkeite werde erst erkebar, we die Etwicklug weiter fortgeschritte ist. Hier ist vo Afag a eie globale Sichtweise trotz zuächst höhere Aufwads hilfreich. Es gibt also Eiflussfaktore, die vorausschauedes Deke oder lägerfristiges Plae ud Etwerfe ötig mache. Dazu zähle auch orgaisatorische Faktore: Abb. 4: Gegeüberstellug verschiedeer agiler Architekturasätze. 52

4 schwerpukt Tipp Verteilte 4: Abahmetests Projektarbeit sollte (mehrere immer Teams grü oder sei Stadorte) Zero Bug erfordert Policy. eie geplate Auch Zerlegug we das Release ud frühe och ei Schittstelledefiitio. paar Woche etfert sei mag, ist es sehr wichtig, Testfälle icht läger als otwedig fehlschlage zu lasse auch we ma die vermutliche Ursache ket. Je größer der Umfag ud die Projektorgaisatio sid, desto wichtiger wird Ei fehlschlageder Testfall ka durchaus Probleme verdecke, die erst ach Behebug der eie tragfähige Modularisierug, um offesichtliche Ursache zu Tage trete. Ziel des Kommuikatioskoste zu beschräke. Teams muss es sei, die Testfälle auch währed der Etwicklug grü zu halte. Grü bezieht sich hier auf die Sigalfarbe, die traditioell i Build Umgebuge Die betriebswirtschaftliche eigesetzt werde. Rahmebediguge beötige Schätzuge, die auf eiem frühe Etwurf beruhe, ud forder rechtzeitige Iput für das Risikomaagemet des Projekts. gehesweise, we die Erweiterug durch Umpriorisierug doch icht stattfidet ud Stadards ud Norme, die de Etwicklugsprozess betreffe etwa i die Tests weiterhi mauell durchgeführt werde müsse. sicherheitskritische Aweduge wie Aus userer Erfahrug loht sich eie Persoetrasport, Alagesteuerug sprechede, achvollziehbare Zuordug oder Medizitechik übe Druck hi vo Aforderuge (User-Storys) ud zu eier frotlastige Architekturtätigkeit aus, um Sicherheitsrisike adressie- Akzeptaztests. Wird eie Aforderug verädert oder erweitert, fließt der Auf - re zu köe. wad für eie otwedige Apassug besteheder Akzeptaztests mit i die Eie umfagreiche Upfrot-Architektur Schätzug ei. Gibt es außerhalb des harmoiert jedoch icht gut mit eier agile Etwicklug. Der ger gewählte Kom- Etwicklugsteams Iteressete für die Akzeptaztest-Kriterie, erhalte diese promiss, agiles Vorgehe a die Spitze des wertvolles Feedback zu de Auswirkuge V-Modells also i die Implemetierug der Äderug. Köe Aforderuge ud zu verbae, führt zu eier suboptimale Akzeptaztests eiader icht zugeordet Mischform (siehe Abbildug 4). Grudschwierigkeite der klassische Welt blei- werde, kommt das böse Erwache bei der Etwicklug: Die Äderuge dauer füf be größteteils erhalte: Miute, das Apasse der fehlgeschlagee alte Akzeptaztests zwei Tage. der Flaschehals i der Architektur (vgl. [Boh10]) Mauelle Tests Mauelle Tests sid auch i agile Pro - der problematische Umgag mit veräderliche Aforderuge jekte wichtig. Sie schließe die Lücke zwische automatisierte Tests ud aufwädig oder gar icht automatisiert prüfbare die Gefahr des Over-Egieerigs Aforderuge. Dabei köe mauelle Tests zeitaufwädig ud fehlerafällig sei. die Realitätsfere des Architekturetwurfs magels schelle Feedbacks Auch i der agile Welt eige Projekt - teams dazu, mauelle Tests zu verachlässige, we die Zeit am Ede eier Auf der adere Seite maifestiert sich ur ei Bruchteil der mögliche Verbesseruge, die Tipp ma 5: Pair-Testig sich erhofft. im Späte UAT. Äderuge sid User-Acceptace-Tests i diesem Modell sollte icht dabei vorgesehe ie ud auch durch das die Softwareetwickler schelle Kude-Feedback durchgeführt daruter. werde. Mit UAT mittels adere Pair-Testig Worte: hat Das leidet ist zwar sich ei dagege möglicher bewährt. Asatz, Hier führt aber ei selte der beste. Beutzer Sei de größter UAT durch, Vorteil der Etwickler ist die Tatsache, sitzt dass daebe er sich ud bekommt ohe eie direkt größere wertvolles über Feedback de eigee zur Beutzbarkeit Schatte seier eie Sprug klassische Arbeit. Im V-förmige Idealfall ist dieser Softwareetwicklugsprozess Kude selbst itegriere oder ei Mitarbeiter lässt. Mit mit freud- tie- Tester der lichem fem Spott fachliche spricht Wisse, ma aber vom keie Agstha- weitere Ketisse über de Quellcode. Iteratio kapp wird. Das führt zu eiem gefährliche Trugschluss: We es akzeptabel ist, mauelle Tests im Notfall wegzulasse, sid sie scheibar icht wichtig. Auch i der agile Welt ist es der Zweck vo Tests, Fehler i der Software zu fide. We automatisierte Tests dazu ur bedigt i der Lage sid, gibt es lediglich eie Alterative: mauelles beziehugsweise exploratives Teste, bei dem die Tester ihre Kreativität ud Spotaität eisetze, um Fehler zu fide. Ei weset- Abb. 5: Visualisierug des Agsthase- Modells. licher Nutze maueller Tests besoders bei eue Features ist die kotextbezogee Perspektive auf die zu prüfede se-modell. Der Name kommt vo der Fuktioalität. De im Gegesatz zu visuelle Überlagerug des Scrum-Sprits automatisierte Tests ket der mauelle mit eiem V-Modell (siehe Abbildug 5). Tester dere aktuelle Kotext. We es Kude ud Budget zulasse, Upfrot ka auch agil sei plae wir am Ede eier Iteratio für alle Was ist also sivoll? Iteressaterweise Etwickler eie Tag ei, desse Fokus auf habe die verschiedee Heragehesweise a de Etwurf eie gemeisame Mo- maueller Testdurchführug liegt. Ziel dieses Tages ist es, die Software zerbreche zu tivatio: Sowohl klassische Architekturtätigkeit als auch agiler Etwurf strebe eie lasse. Geligt es, de Code durch Beut - zer eigabe oder Datekostellatioe zu Risikomiimierug a. Auf der klassische zerbreche, wird für die Situatio, die dazu Seite ist das Ziel, durch eie frühe Aalyse geführt hat, ei automatisierter Test der Eiflussfaktore ud Risike sicherzustelle, dass der Etwurf etscheidede, geschriebe. Aschließed wird der Ma - gel ach voll ziehbar behobe ud mit dem globale Qualitätsaforderuge erfülle automatisierte Test dafür gesorgt, dass die ka. Auf der agile Seite wird dem Risiko so ge woee höhere Robustheit erhalte vo Fehletwickluge dadurch begeget, bleibt. dass frühzeitig Erfahruge aus der Implemetierug ud das Feedback vom Kude Plädoyer für Nichteigeholt werde. Automatisierug I beide Fälle erreicht ma die Risikomiderug durch Wissesaufbau. Ud bei- We die geforderte Fuktioalität implemetiert wurde, also sämtliche automatisierte Tests durchgeführt ud um evetuell de Arte vo Wissesaufbau die globale Brille der frühe Aalyse ud die lokalere otwedige mauelle Tests der eue Sicht der iterative Umsetzug köe Features ergäzt wurde, schließt sich eie ud sollte sich ergäze. Nicht umsost weitere mauelle Stufe a. legt die Fachliteratur dem modere Architekte as Herz, iterativ-ikremetell Der User-Acceptace-Test (UAT) diet dazu, eie Software uter reale Bedi gu - zu arbeite (vgl. [Sta14]) ud baldmöglichst Feedback aus der Umsetzug oder ge zu teste ud zu prüfe, ob eie Software effiziet ud effektiv geutzt werde ka. Software, die für Edaweder aus eiem frühe Durchstich eizuhole. Ud adersherum: We ma etwa i eiem agile Product Backlog die User-Storys gedacht ist, muss bei dieser Testart vom Beutzer selbst geprüft werde. Dazu ist es icht ur ach ihrem Busiess-Wert, sootwedig, de fachliche Kotext der zu prüfede Soft ware zu kee ud eizu- OBJEKTspektrum ist eie Fachpublikatio des Verlags: SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf Tel.: / Fax: / ifo@sigs-datacom.de der auch ach de mit ihe verbudee beziehe. Test werk zeuge sid hierzu icht globale Risikoaspekte priorisiert, stehe i der Lage. Aus userer Sicht ist ei vollstädig automatisierter UAT auch i der die Chace größer, das globale Optimum azusteuer. Viele Beefits der Architekturarbeit sid scho ohe ausführliche Et- agile Welt icht seriös durchführbar ausgeomme automatisierte Smoke-Tests, die wurf zu erte solage die grudlegede die Vollstädigkeit der Fuk tio alität oberflächlich prüfe. Gele getlich werde auto- Aalysetätigkeit trotzdem stattfidet ud isbesodere die Risike früh idetifiziert matisierte GUI-Tests (Graphi cal-userwerde. Grobe Lösugsskizze ud ei Iterface) als UAT bezeichet. Diese Tests bewusster Umgag mit Risike gebe dem sid fuktioale Tests uter Eibeziehug agile Team de otwedige Impuls heraus aus de Sackgasse auf dem Weg hi eier Oberfläche ud köe zum Beispiel im Regressiostest eie wertvolle Beitrag zu eiem mögliche Lösugsraum. Der leiste. Sie sid aber kei Er satz für die Wuschzustad: Just Eough Software Eibeziehug des Mesche als Tester. Architecture (vgl. [Fai10]). Der Graubereich Kosequeterweise Tipp 6: Zeitaher gibt es UAT. izwische viele Techike Währed ud Frameworks, der UAT i der die klassische versuche, diese Graubereich Projektwelt eie zwische abgeschlossee Upfrot-Arbeit ud darstellt, dem agile bietet es Regelfall sich i agile abzudecke. Projekte Phase Dies betrifft a, umittelbar isbesodere ach dem Abschluss die agile eier Etwicklug Fuktioalität i große Nutzer-Feedback Orgaisatioe. eizuhole. Oft wird eie eigee Will der Phase Etwickler am Afag i Folge des des Projekt-Lebeszyklus Feedbacks Äderuge vorgeschlage vorehme, bezeichet als Sprit 0, Iteratio 0 oder Iceptio ist seie Arbeit effektiver als ach eiem UAT-Feedback mehrere Woche. (siehe Abbildug 4). I dieser Vorlaufphase stehe das Durchdrige der Problemstellug ud die Erarbeitug eier grudlegede Architektur im Fokus. So sieht bei- Ei Fokus des UAT liegt auf der Istal - lierbarkeit der Software. Diese lässt sich spielsweise [Amb12] im Disciplied Agile leicht i Kombiatio mit der obe Delivery (DAD) eie Iceptio-Phase vor beschriebee automatisierte Prüfug auf (vgl. [DAD]). Im Scaled Agile Framework Vollstädigkeit awede: We dieser (SAFe) (vgl. [Lef13]) ist eie techologische Smoke-Test erfolgreich war, ließ sich die Visio eigeplat, die der Systemarchitekt Software offebar erfolgreich istalliere. vor jedem Release erarbeitet. I hoch regulierte Brache, wie etwa der Medizi- Ziel des UAT ist es, die Beutzbarkeit eier Software zu prüfe. Aus eigeer Erfahrug techik oder der Automobilbrache, gibt wisse wir, dass für eie erfolgreiche UAT es zudem regulatorische Aforderuge, i alle Teststufe gewissehaft gearbeitet die zu Begi eie Gefährdugsaalyse ud werde muss. Für Et wickler gibt ichts darauf aufbaued i Bezug auf sicherheitsrelevate Fuktioe eie Upfrot-Archi- Schlimmeres als eie UAT, der vo de Tester oder vom Kude ach weige tektur forder (vgl. [ISO11]). Miute abgebroche wird, weil viele offesichtliche Fehler i de vorherige Teststufe We dabei jedoch die Architekturetscheiduge vo de Etwicklugsteams icht etdeckt wurde ud der Software getret ud zu eiem Systemarchitekte magelde Qualität bescheiigt wird. verlagert werde ud we aus Feature- Teams wieder Kompoeteteams werde, Last ud Performace-Tests da ist ma beim Agsthase-Modell a- Die Teststufe Last- ud Performace-Tests diet im Wesetliche dazu, drei icht- 404/2014 /

5 Baue ohe Fudamet? Agile Etwicklug ud Upfrot-Architektur im Spaugsfeld gelagt. Auch we ei Projekt icht ohe Upfrot-Architekturtätigkeite auskommt, sollte das Ziel sei, die grudlegede Idee der agile Etwicklug aufrechtzuerhalte. Was bleibt? Agilität ud eie explizit betriebee Architekturtätigkeit müsse ud sollte also kei Widerspruch sei. Letztedlich geht es darum, so früh wie möglich das otwedige Wisse aufzubaue, um de Risike des Projekts begege zu köe. Je ach Produkt liege diese Risike i uterschiedlichem Umfag i Usicherheite der Aforderuge oder i der Architektur begrüdet. Sid die Aforderuge uklar, ist aber die Architektur ukritisch, so sollte das Projekt auf Upfrot-Tätigkeite verzichte. Dies ist i Brache mit eier kotiuierliche Fuktiosetwicklug ud i schelllebige Märkte der Fall. Voraussetzug ist, dass Safety-Aspekte eie utergeordete Rolle spiele ud dass die verfügbare Ressource wie Speicher ud Recheleistug ohe große Probleme erweitert werde köe. Bei harte Radbediguge higege sid geeigete Architekturüberleguge uverzichtbar. I de meiste hardwareahe Etwickluge sid späte Äderuge a der Umgebug icht mehr möglich. Sid Termie icht verhadelbar ud sehr viele verteilte Etwickler a der Etwicklug beteiligt, wäre es fahrlässig, Upfrot-Tätigkeite zu verachlässige. We es geligt, de Pukt der miimal otwedige Plaug zu treffe, we ma gerade geüged Aalyse betreibt, um die richtige Stoßrichtug i de globale Etwurfsraum zu fide, ud we dem Team die globale Risike bewusst sid, da ist die optimale Balace gefude. Damit ist die Architektur atürlich icht am Ede aber das Fudamet trägt. Literatur & Liks [Amb12] S.W. Ambler, M. Lies, Disciplied Agile Delivery, IBM Press 2012 [Boh10] M. Bohle, Emergete Architektur: Der machtlose Architekt, i: OBJEKTspektrum 3/2010 [Cop10] J. Coplie, G. Bjørvig, Lea Architecture for Agile Software Developmet, Wiley 2010 [DAD] Disciplied Agile Delivery (DAD), siehe: [Fai10] G.H. Fairbaks, Just Eough Software Architecture: A Risk-Drive Approach, Marshall & Braierd 2010 [ISO11] ISO, ISO :2011, Road vehicles Fuctioal safety Part 2: Maagemet of fuctioal safety, 2011, siehe: [Lef13] Leffigwell, LLC., Scaled Agile Framework, 2013, siehe: [Mar03] R.C. Marti, Agile Software Developmet: Priciples, Patters ad Practices, Pretice-Hall 2003 [Sou] Sourcemakig, Aalysis Paralysis, siehe: [Sta14] G. Starke, Effektive Softwarearchitekture: Ei praktischer Leitfade, Carl Haser Verlag 2014 die Autore Sebastia Seifert (Sebastia.Seifert@methodpark.de) arbeitet als Seior Software Egieer im Team Medical Devices bei Method Park. Er ist Traier für de isaqb Certified Professioal for Software Architecture. Otmar Seckiger (Otmar.Seckiger@methodpark.de) ist bei Method Park als Cosultat mit de Schwerpukte Prozessverbesserug ud agiles Software-Projektmaagemet tätig. 54