Willkommen zum letzten Teil der Blogserie
Nachdem wir uns in den letzten Beiträgen mit den Grundlagen der Softwarearchitektur, agiler Entwicklung im Allgemeinen und agilem Architekturvorgehen beschäftigt haben, betrachten wir im letzten Beitrag der Serie, welche Anforderungen an Architekturen agile Projekte mit sich bringen.

Architekturanforderungen in agilen Projekten

Architekturanforderungen in agilen Projekten sind spezifische Anforderungen oder Kriterien, die bei der Entwicklung der Softwarearchitektur berücksichtigt werden müssen. Durch sie soll sichergestellt werden, dass resultierende Systeme die gewünschten Qualitätsmerkmale, Funktionalitäten und Leistungseigenschaften erfüllt. Diese Anforderungen dienen als Leitlinien für die Gestaltung der Architektur und beeinflussen die technischen Entscheidungen im Entwicklungsprozess. In agilen Projekten sollten Architekturanforderungen agil und anpassbar sein, um auf sich ändernde Anforderungen reagieren zu können.

Architekturanforderungen können verschiedene Aspekte umfassen:

– Leistungsmerkmale umfassen Anforderungen an die Performance, Skalierbarkeit und Reaktionsfähigkeit des Systems unter bestimmten Belastungsbedingungen.
– Sicherheit meint Anforderungen an den Datenschutz, die Sicherheit der Datenübertragung, den Zugriffsschutz und die allgemeine Sicherheit des Systems.
– Skalierbarkeit bezieht sich auf die Fähigkeit des Systems, sich an steigende Anforderungen anzupassen. Sei es in Bezug auf Nutzerzahl, Datenmenge oder Transaktionsvolumen .
– Wartbarkeit sind Anforderungen, die festlegen , wie leicht das System gewartet, aktualisiert und erweitert werden kann, ohne negative Auswirkungen auf die Funktionalität zu haben.
– Erweiterbarkeit meint, wie einfach und nahtlos das System um neue Funktionen oder Module erweitert werden kann, ohne bestehende Codes zu beeinträchtigen.
– Interoperabilität betrifft die Fähigkeit des Systems, nahtlos mit anderen Systemen oder Diensten zu kommunizieren und zu interagieren.
– Architekturmuster und -stile können als Anforderungen festgelegt werden, um sicherzustellen, dass die Architektur den gewünschten Designprinzipien folgt.
– Technologische Anforderungen umfassen spezifische Technologien, Frameworks oder Plattformen, die im Projekt verwendet werden.
– Nicht-funktionale Anforderungen: Dies können nicht-funktionale Anforderungen wie Benutzerfreundlichkeit, Zugänglichkeit, Barrierefreiheit und mehr umfassen.

In agilen Projekten werden Architekturanforderungen oft in enger Zusammenarbeit mit den Stakeholdern erarbeitet und können sich im Laufe des Projektes ändern. Sie dienen als Leitfaden für die kontinuierliche Anpassung und Entwicklung der Architektur, um sicherzustellen, dass das Endprodukt den Anforderungen entspricht und die Erwartungen erfüllt.

Agile Konzepte für Architekturanforderungen

Agile Konzepte für Architekturanforderungen betonen die Flexibilität, Zusammenarbeit und kontinuierliche Anpassung von Anforderungen. Diese Konzepte sollen sicherstellen, dass Architekturanforderungen agil sind und sich in einer sich ständig ändernden Umgebung weiterentwickeln können.

Es folgen einige Beispiele:

– User Stories für Architektur: Ähnlich wie bei funktionalen Anforderungen können Architekturanforderungen als User Stories formuliert werden. Diese User Stories beschreiben die Anforderungen aus Sicht eines Benutzers oder einer Stakeholder-Rolle. Sie fokussieren sich auf den Wert, den die Architektur für diese Benutzer bietet.
– Agile Architekturdokumentation: Agile Konzepte bevorzugen eine leichtgewichtige Dokumentation, die sich schnell anpassen lässt. Diagramme, Skizzen, Whiteboard-Skizzen und kurze Beschreibungen können verwendet werden, um Architekturprinzipien und entscheidungen zu dokumentieren.
– Emergente Architektur: Agile Architekten bevorzugen die Entwicklung einer emergenten Architektur, die sich schrittweise aus den Anforderungen und der Funktionalität entwickelt. Dies ermöglicht es, auf veränderte Anforderungen und Gegebenheiten flexibel zu reagieren, ohne in umfangreiche Vorausplanung zu verfallen.
– Risikoorientierte Architekturanforderungen: Agile Architekten identifizieren und priorisieren Risiken, die mit der Architektur verbunden sind. Anforderungen werden basierend auf diesen
Risiken festgelegt und entsprechende Strategien entwickelt, um sie zu mindern.
– Kontinuierliche Anpassung: Architekturanforderungen werden kontinuierlich überprüft und
angepasst, um sicherzustellen, dass sie aktuell und relevant bleiben. Dies geschieht in enger Zusammenarbeit mit den Stakeholdern, um sicherzustellen, dass die Architektur den aktuellen Bedürfnissen entspricht.
– Just-in-Time-Entscheidungen: Agile Teams treffen Entscheidungen „just-in-time“, wenn die Anforderungen und das Verständnis des Systems wachsen. Dadurch können sie sich auf aktuelle Informationen stützen.
– Kollaboratives Arbeiten: Architekturanforderungen werden durch kollaboratives Arbeiten mit dem Entwicklungsteam, den Produktverantwortlichen und anderen Stakeholdern entwickelt.
Dies fördert das gemeinsame Verständnis und sorgt für eine bessere Umsetzung der Anforderungen.

Diese agilen Konzepte für Architekturanforderungen tragen dazu bei, dass die Architektur flexibel, anpassungsfähig und auf die aktuellen Bedürfnisse ausgerichtet bleibt, während gleichzeitig eine hohe Qualität und Kundenzufriedenheit gewährleistet werden.

Dringlichkeit als Treiber für agile Architekturarbeit

Dringlichkeit als Treiber für agile Architekturarbeit bezieht sich auf die Notwendigkeit, sich auf spezifische Aspekte der Softwarearchitektur zu konzentrieren, die aufgrund ihrer kritischen Bedeutung oder ihrer potenziellen Auswirkungen auf das Projekt priorisiert werden müsse.

Dieser Ansatz basiert auf der Idee, dass nicht alle Teile der Architektur gleich wichtig sind und dass es sinnvoll ist, sich zuerst auf diejenigen Aspekte zu konzentrieren, die einen unmittelbaren und signifikanten Einfluss haben.

Die Dringlichkeit kann verschiedene Gründe haben:

Risikominderung: Wenn bestimmte Architekturaspekte ein hohes Risiko für das Projekt darstellen, sollten sie frühzeitig angegangen werden, um potenzielle Probleme zu minimieren.
Kritische Funktionalitäten: Falls die Architektur direkt mit kritischen Funktionen des Systems verbunden ist, ist es dringend erforderlich, diese Bereiche zu priorisieren, um die Leistung und Zuverlässigkeit sicherzustellen.
Performance und Skalierbarkeit: Wenn das System unter erwarteter Last gut funktionieren muss, ist es wichtig, Architekturentscheidungen zu treffen, die die Performance und Skalierbarkeit optimieren.
Integration: Wenn das System mit anderen externen Systemen oder Diensten interagiert, ist es dringend erforderlich, die Integrationsarchitektur sorgfältig zu planen und umzusetzen.
Änderungen in den Anforderungen: Wenn sich die Anforderungen ändern, kann es notwendig sein, die Architektur schnell anzupassen, um sicherzustellen, dass das System den aktuellen Bedürfnissen entspricht.

Die agile Architekturarbeit unter Berücksichtigung der Dringlichkeit ermöglicht es, schnell auf die wichtigsten Anliegen zu reagieren. So kann sichergestellt werden, dass das Projekt auf einem soliden Fundament aufbaut. Dabei ist jedoch eine Balance erforderlich, um die Dringlichkeit mit den langfristigen Zielen der Architektur und der technischen Integrität in Einklang zu bringen.

Quellen

• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://de.wikipedia.org/wiki/Softwarearchitektur
• https://www.agile-academy.com/
• Mike Cohn: Agile Design: Intentional Yet Emergent.
• Stefan Toth: „Vorgehensmuster für Softwarearchitektur: Kombinierbare Praktiken in Zeiten von Agile und Lean”, 2. Auflage, Hanser Verlag 2015

Agiles Architekturvorgehen

Dieser Ansatz verfolgt die Integration agiler Prinzipien und Methoden in den Prozess der Gestaltung und Entwicklung von Softwarearchitekturen. Er zielt darauf ab, die traditionell starren und vorausplanenden Ansätze zur Architekturdefinition zu überwinden und stattdessen eine flexible, anpassungsfähige und inkrementelle Herangehensweise zu fördern.
Im Rahmen des agilen Architekturvorgehens werden Architekten und Entwickler ermutigt, zusammenzuarbeiten, kontinuierlich zu lernen und sich ändernden Anforderungen anzupassen.

Einige Merkmale des agilen Architekturvorgehens sind:

– Kontinuierliche Anpassung: Anstatt eine vollständige Architektur im Voraus zu entwerfen, entwickeln agile Teams eine initiale Architekturrichtung und passen sie im Laufe der Zeit an, während sie mehr über das Projekt und die Anforderungen erfahren.

– Inkrementelle Entwicklung: Die Architektur wird schrittweise entwickelt, wobei es sich mit jeder Iteration weiterentwickelt und den sich ändernden Bedürfnissen des Projekts angepasst wird.

– Enge Zusammenarbeit: Architekten arbeiten eng mit dem Entwicklungsteam zusammen, um sicherzustellen, dass die Architekturprinzipien in den laufenden Entwicklungsprozess integriert werden. Architektur wird in vielen agilen Ansätzen von Anfang mitgedacht. So kann der Architekt einem Team zugeordnet sein und seine Tätigkeiten innerhalb des Teams
ausüben. So wird sichergestellt, dass Architekturprinzipien in den Entwicklungsprozess von Stunde null mitgedacht werden.

– Einfache Kommunikation: Anstatt umfangreicher Dokumentation bevorzugt das agile Architekturvorgehen eine klare und verständliche Kommunikation, um die Architekturentscheidungen im Team zu teilen.

– Schnelles Feedback: Durch häufige Auslieferungen von funktionierender Software und Prototypen erhalten Architekten kontinuierliches Feedback durch die Stakeholder, Nutzer und ggf. Kunden im Review. Während des Sprints können je nach Wunsch Personen eingeladen werden. Der PO achtet darauf, dass er oder sie Feedback gibt.

– Evolutionäre Architektur: Die Architektur entwickelt sich ständig weiter, um den sich ändernden Anforderungen gerecht zu werden. Dies ermöglicht einen Fokus auf das Wesentliche und trägt dazu bei, unnötige Komplexität zu vermeiden.

– Risikoreduktion: Durch das frühe Erkennen von potenziellen Architekturproblemen und die Möglichkeit, Gegenmaßnahmen zu ergreifen, werden Risiken minimiert.

Architekturarbeit iterativ und agil gestalten – Risikogetriebene Architekturarbeit

Risikogetriebene Architekturarbeit bezieht sich auf den Ansatz, bei dem die Identifikation, Bewertung und Behandlung von Risiken eine zentrale Rolle bei der Entwicklung und Gestaltung der Softwarearchitektur spielt. Anstatt sich ausschließlich auf technische oder funktionale Aspekte zu konzentrieren, legt dieser Ansatz den Schwerpunkt auf die Einschätzung und Minderung von Risiken, die sich auf den Erfolg des Projekts auswirken könnten.

Die Grundidee hinter der risikogesteuerten Architekturarbeit besteht darin, die kritischen Risiken zuerst anzugehen, um frühzeitig sicherzustellen, dass das Projekt auf einem stabilen Fundament aufgebaut wird. Dies beinhaltet:

–  Identifikation von Risiken: Die Architekten analysieren und identifizieren potenzielle Risiken in Zusammenhang mit den Anforderungen, der Technologie, der Skalierbarkeit, der Performance, der Sicherheit und anderen relevanten Faktoren.

– Bewertung von Risiken: Die identifizierten Risiken werden bewertet, um festzustellen, welche davon die größte Bedrohung für den Erfolg des Projekts darstellen.

– Priorisierung von Risiken: Basierend auf der Bewertung werden die Risiken nach ihrer Dringlichkeit und Auswirkung priorisiert. Diejenigen mit höherer Priorität werden zuerst angegangen.

– Entwicklung von Risikominderungsstrategien: Für die identifizierten und priorisierten Risiken werden Strategien entwickelt, um sie zu mindern oder zu verhindern. Dies kann durch technische Lösungen, Architekturanpassungen oder alternative Herangehensweisen erfolgen.

– Prototyping und Validierung: In einigen Fällen kann es erforderlich sein, Prototypen oder Proof of Concepts zu erstellen, um die Wirksamkeit der gewählten Risikominderungsstrategien zu überprüfen.

– Iterative Anpassung: Während des Entwicklungsprozesses wird die Risikobewertung laufend überprüft und aktualisiert, um sicherzustellen, dass neue Risiken erkannt und behoben werden.

Indem die Architekten die Risiken von Anfang an berücksichtigen und angehen, können potenzielle Probleme frühzeitig erkannt und gemindert werden. Die Wahrscheinlichkeit von Fehlern und Verzögerungen wird dadurch verringert. Dieses Vorgehen trägt dazu bei, dass die Softwarearchitektur solide, stabil und den Anforderungen des Projekts gerecht wird.

Rollenmodelle für Architekten in agilen Projekten

In agilen Projekten können verschiedene Rollenmodelle für Architekten existieren, je nach Größe des Teams, der Art des Projekts und den spezifischen Anforderungen.

Hier sind einige gängige Rollenmodelle für Architekten in agilen Projekten:

– Agiler Architekt: Diese Rolle ist für die Gestaltung der Softwarearchitektur verantwortlich, wobei der Schwerpunkt auf Flexibilität, Zusammenarbeit und Anpassungsfähigkeit liegt. Der agile Architekt arbeitet eng mit den Entwicklungsteams und den Produktverantwortlichen zusammen, um sicherzustellen, dass die Architektur die agilen Werte und Prinzipien widerspiegelt.

– Architekt als Teil des Entwicklungsteams: In kleinen agilen Teams kann der Architekt Teil des Entwicklungsteams sein und aktiv am Coden und an der Umsetzung von Features teilnehmen.
Dies ermöglicht eine enge Zusammenarbeit und eine kontinuierliche Ausrichtung der Architektur auf die Entwicklungsarbeiten.

– Technologieberater: Ein Architekt kann als Technologieberater dienen, der das Team bei der Auswahl geeigneter Technologien, Frameworks und Tools unterstützt. Sie helfen dabei, sicherzustellen, dass die gewählten Technologien die Anforderungen des Projekts erfüllen und gut in die Architektur passen.

– Architekturcoach: Diese Rolle befasst sich damit, das Team in Bezug auf bewährte Methoden, Architekturmuster und Prinzipien zu schulen. Der Architekturcoach fördert das Verständnis für Architekturpraktiken und hilft dem Team, bessere technische Entscheidungen zu treffen.

– Evangelist für Qualität und Wartbarkeit: Architekten können die Verantwortung übernehmen, sicherzustellen, dass die entwickelte Software qualitativ hochwertig, wartbar und skalierbar ist. Sie setzen Standards für Codequalität und arbeiten mit dem Team zusammen, um sicherzustellen, dass diese Standards eingehalten werden.

– Architekturstratege: Diese Rolle übernimmt die langfristige Sicht auf die Architektur und hilft, eine Vision für die technische Entwicklung des Produkts zu definieren. Sie berücksichtigen technologische Trends, organisatorische Ziele und zukünftige Anforderungen, um sicherzustellen, dass die Architektur langfristig erfolgreich bleibt.

Es ist wichtig zu beachten, dass die Rollenmodelle für Architekten in agilen Projekten variieren können. In jedem Fall ist die Zusammenarbeit zwischen den Architekten, dem Entwicklungsteam, den Produktverantwortlichen und anderen relevanten Stakeholdern entscheidend. So kann sichergestellt werden, dass die Architektur den Bedürfnissen der Kunden, Nutzer und Stakeholder gerecht wird und agil umgesetzt wird.

Möglichkeiten, Stakeholder in die agile Architekturarbeit zu involvieren

Die Einbeziehung von Stakeholdern in die agile Architekturarbeit ist entscheidend, um sicherzustellen, dass die entwickelte Software den Anforderungen und Erwartungen aller relevanten Parteien entspricht. Wir möchten drei Möglichkeiten betrachten, wie Stakeholder in die agile Architekturarbeit eingebunden werden können:

– Regelmäßiges Feedback und Reviews: Durch das Abhalten regelmäßiger Meetings oder Reviews, erhalten Stakeholder die Gelegenheit, die Ergebnisse des Sprints zu betrachten und Feedback zu geben. Dies geschieht in Form von Demos, Präsentationen oder Diskussionen. Das Team kann gemeinsam mit den Stakeholdern experimentieren, wie das Review gestaltet werden soll. Stakeholder können ihre Anforderungen, Erwartungen und Bedenken kommunizieren, was zu einer kontinuierlichen Anpassung und Verbesserung der Architektur führt.

– Involvieren in Planung und Priorisierung: Durch die Einladung von Stakeholdern zur Teilnahme an Planungssitzungen, in denen kommende Aufgaben und Prioritäten besprochen werden, erhalten diese die Möglichkeit, ihre Perspektiven mit einzubringen und sicherzustellen, dass die Architekturarbeit die für sie wichtigen Aspekte berücksichtigt. In aller Regel sollte bei einem Scrum Vorgehen nicht die gesamte Stakeholderschaft im Planning
vertreten sein. Der PO ist die Stimme des Kunden und des Nutzers, er oder sie muss priorisieren welche Backlog Stories eingeplant werden gemeinsam mit den Devs.

– User Stories und Anforderungen: Arbeiten Sie mit den Stakeholdern zusammen, um User Stories und Anforderungen zu erstellen oder zu überarbeiten, die in die Entwicklung der Architektur einfließen. Diese User Stories können als Grundlage für die Architekturarbeit dienen und sicherstellen, dass die entwickelte Architektur die gewünschten Funktionen und Eigenschaften erfüllt.

Die Schlüsselkomponente in allen diesen Ansätzen ist die offene Kommunikation und enge Zusammenarbeit mit den Stakeholdern. Dies ermöglicht es, Missverständnisse zu vermeiden, frühzeitig auf Feedback zu reagieren und sicherzustellen, dass die Architektur die Bedürfnisse und Erwartungen aller Beteiligten erfüllt.

Quellen

• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://de.wikipedia.org/wiki/Softwarearchitektur
• https://www.agile-academy.com/
• Mike Cohn: Agile Design: Intentional Yet Emergent.

Mythbusting: Im Bezug auf Dokumentation wird das agile Manifest oft missverstanden. Agiles Arbeiten verzichtet nicht auf Dokumentation, sondern setzt diese anders ein. So wird z.B. auf Lastenhefte verzichet und in kleine Arbeitspakete geschnürrt.

Wie funktioniert das?

Die agile Softwarearchitektur priorisiert funktionierende Software über umfassende Dokumentation und betont die enge Zusammenarbeit zwischen Architekten, Entwicklern und Kunden. Die Architekten arbeiten eng mit den Stakeholdern zusammen, um Anforderungen zu verstehen und kontinuierliches Feedback zu erhalten. Die Architektur wird inkrementell entwickelt und angepasst, um auf sich ändernde Anforderungen und Erkenntnisse zu reagieren.

Wozu das alles?

Dieses Vorgehen spiegelt die Werte des agilen Manifests wider, wobei Individuen und Interaktionen, funktionierende Software, Zusammenarbeit mit Kunden und die Bereitschaft zur Anpassung an Veränderung im Mittelpunkt stehen. Agile Softwarearchitektur fördert die Schaffung einer evolutionären Architektur, die auf klare Kommunikation, schnelles Feedback und ständige Anpassung setzt. Dies ermöglicht es den Entwicklungsteams, flexibel auf Herausforderungen zu reagieren und hochwertige Softwarelösungen zu liefern, die den Kundenanforderungen gerecht werden.

Wir freuen uns, Ihnen eine spannende Blogserie in drei Teilen anzubieten, die sich mit den Grundlagen und den Herausforderungen der Softwarearchitektur im agilen Umfeld beschäftigt.

Teil 1: Grundlagen der Softwarearchitektur und Agilität

Starten Sie mit uns in die Grundlagen, um die essenziellen Konzepte der Softwarearchitektur und agilen Methoden zu verstehen.

 Teil 2: Agiles Architekturvorgehen

Im zweiten Teil tauchen wir tiefer ein und zeigen Ihnen, wie Sie agile Prinzipien erfolgreich in Ihre Architekturansätze integrieren können.

 Teil 3: Architekturanforderungen in agilen Projekten

Abschließend beleuchten wir die spezifischen Anforderungen, die in agilen Projekten an die Architektur gestellt werden, und wie Sie diesen gerecht werden können.

 Seien Sie dabei und erweitern Sie Ihr Wissen über die Schnittstelle von Softwarearchitektur und Agilität.

Grundlagen der Agilität

Agile Prinzipien sind eine Reihe von Leitlinien und Werten, die angewendet werden, um eine flexible, kundenorientierte und effiziente Arbeitsweise zu fördern. Das „Agile Manifesto“ betont die Wichtigkeit von Individuen und Interaktionen, funktionierender Software, Zusammenarbeit von Kunden und die Bereitschaft zur Anpassung an Veränderungen.

Die agilen Prinzipien sind:

• Individuen und Interaktionen über Prozesse und Werkzeuge

Die Zusammenarbeit zwischen den Teammitgliedern und die klare Kommunikation stehen im Vordergrund. Effektive Zusammenarbeit führt zu besserem Verständnis und letztendlich zu einer erfolgreichen Umsetzung.

• Funktionierende Software über umfassende Dokumentation

Die Priorität liegt darauf, funktionierende Software zu entwickeln, die den Nutzerbedürfnissen entspricht. Dokumentation ist wichtig, aber sie sollte nicht den Fokus von der tatsächlichen Entwicklung ablenken.

• Zusammenarbeit mit Kunden über Vertragsverhandlung

Die enge Zusammenarbeit mit dem Nutzer ermöglicht es dem Team, ihre Anforderungen und Bedürfnisse besser zu verstehen. Feedback der Nutzer ist von großer Bedeutung, um die Software kontinuierlich zu verbessern.

• Reagieren auf Veränderung über das Befolgen eines Plans

Anstatt strikt einem starren Plan zu folgen, sollten agile Teams bereit sein, auf Änderungen und neue Erkenntnisse flexibel zu reagieren. Veränderungen werden als eine Möglichkeit zur Anpassung und Verbesserung begriffen.

Aufbauend auf den 4 Werten leitet das agile Manifest zwölf Prinzipien für die Zusammenarbeit zwischen Entwicklungsteam und Kunden ab:

1. Höchste Priorität ist frühe und kontinuierliche Auslieferung zu gewährleisten. Dieses Vorgehen soll sicherstellen nicht an Bedürfnissen der Nutzer vorbei zu entwickeln.
2. Änderungen sind erwünscht. Durch kontinuierliches Feedback kann dieses Vorgehen zum Wettbewerbsvorteil werden.
3. Funktionsfähige Software, die in kurzen Zeitspannen ausgeliefert werden können.
4. Arbeite eng mit Kunden und Nutzern zusammen, um Anforderungen zu definieren und laufend Feedback zu erhalten.
5. Bilde motivierte Individuen aus und gebe ihnen die Umgebung und Unterstützung, die sie benötigen. Vertraue darauf, dass sie die Arbeit erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht.
7. Funktionierende Software ist das primäre Maß für Fortschritt.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Entwickler, Sponsoren und Anwender sollten ein konstantes Tempo auf unbestimmte Zeit aufrechterhalten können.
9. Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design verbessert die Agilität.
10. Einfachheit – die Kunst die Menge nicht erledigter Arbeit zu maximieren – ist essenziell.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams.
12. In regelmäßigen Abständen reflektieren das Team und seine Mitglieder darüber, wie sie effektiver werden können, und passen ihr Verhalten entsprechend an.

 Diese agilen Prinzipien dienen als Grundlage für agile Entwicklungsmethoden wie Scrum, Kanban, Extreme Programming und andere, um Teams bei der Entwicklung hochwertiger Software mit hoher Flexibilität und Nutzerzufriedenheit zu unterstützen.

In agilen Softwareentwicklungsprojekten wird zunehmend auf evolutionäre Softwarearchitektur und emergentes Design im Gegensatz zu vorher festgelegter Architektur (engl.: „Big Design Up Front“) gesetzt. Dabei soll durch Techniken wie Behavior Driven Development, testgetriebene Entwicklung und vor allem Refactoring sichergestellt werden, dass das technische Design und die Architektur im Laufe eines Softwareentwicklungsprojektes ständig an die Anforderungen angepasst werden.

 Wie sich agiles Arbeiten in der Gestaltung von Softwarearchitektur umsetzen lässt, werden wir im zweiten Teil unserer Blogserie „Agile Softwarearchitektur“ mit dem Thema „Agiles Architekturvorgehen“ betrachten.

Quellen

• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://de.wikipedia.org/wiki/Softwarearchitektur
• https://www.agile-academy.com/
• Mike Cohn: Agile Design: Intentional Yet Emergent.