Architektur

„Anforderungen? Paah, wir arbeiten jetzt doch agil.“

Zuvor wurde diese Blog-Artikel-Serie über typische Missverständnisse im Kontext Agilität und Software-Architektur bereits mit einem einführenden Beitrag und einem vorangegangen ersten Missverständnis gestartet.

Missverständnis 2: „Was wollt ihr? Anforderungen? Paah, wir arbeiten jetzt doch agil.“

Agilität war ursprünglich dazu gedacht, um bei der Softwareentwicklung auf von außen eingesteuerte Anforderungen flexibel und schnell reagieren zu können. Regelmäßiges Feedback ist bei allen agilen Ansätzen das zentrale Werkzeug, um in einem dynamischen Umfeld passend reagieren zu können. Oftmals ist es auch so, dass innerhalb eines Unternehmens eine große Dynamik herrscht, die mit Agilität teilweise aufgefangen werden kann. Aus Sicht eines Projekts sind das aber alles äußere Einflüsse.

Leider kommt es aber immer wieder vor, dass Agilität innerhalb eines Projekts vorgeschoben wird, um Anforderungen im Projekt nicht klar herauszuarbeiten. Gewisse Anforderungen haben Auswirkungen auf grundsätzliche Architekturentscheidungen. Es ist von enormer Bedeutung, dass die wesentlichen Qualitätsanforderungen für die zu schaffenden Lösungen möglichst früh bzw. zumindest rechtzeitig abgeleitet werden. Sie bestimmen die grundsätzlichen Entscheidungen beim Aufbau einer Architektur und müssen besonders langfristig tragfähig sein, da sie fast immer auch die wesentlichen Kostentreiber in den Projekten sind.

Qualität in agilen Projekten

Hier besteht also ein seltsamer Widerspruch zwischen langfristiger Stabilität in den Grundanforderungen einer Architektur und der über die Agilität geforderten stetigen Wandelbarkeit. Der Architekt hat in einem agilen Projekt unter anderem die Aufgabe diesen Widerspruch abzuwägen und die Langfristperspektive nicht aus dem Blick zu verlieren. Zudem ist es so, dass nicht immer alle Zielparameter in gleichem Maß angestrebt werden können. Insbesondere qualitative Architekturziele widersprechen sich oft in ihrer Zielsetzung, z. B. erlangt man mit maximaler Anpassbar- und Konfigurierbarkeit selten auch die maximale Robustheit in einem System.

Erfahrung und technisches Verständnis sind notwendig, um diese Arten von Anforderungen voneinander unterscheiden zu können. Es ist beispielsweise einfach in einer Benutzeroberfläche ein Feld hinzuzufügen oder Farben und Labels schnell mal anzupassen, aber es ist von entscheidendem Unterschied im grundsätzlichen Systemdesign, ob nur 100 oder 1.000.000 Events pro Minute verarbeitet werden müssen. Kritiker behaupten dann oft: „Wenn wir das alles so genau wissen müssen, dann landen wir wieder beim Wasserfall.“ Das ist aber aus unserer Sicht wieder das entgegengesetzte Extrem. Die Kunst des Architekten ist es, Langfristanforderungen früh zu erkennen und Architekturentscheidungen zum richtigen Zeitpunkt im agilen Projekt zu treffen, nämlich früh genug, dass Kosten zur Umsetzung noch gering sind und spät genug, dass nicht zu früh andere Optionen verbaut werden. Denn jede getroffene Entscheidung hat auch ihren Preis und nicht jeder Lösungsansatz ist mit jedem anderen Ansatz problemlos kombinierbar. Die langfristige Kostenperspektive muss dabei im Blick behalten werden und der Lösungsentwurf muss dennoch genügend Raum zur Anpassbar- und Erweiterbarkeit bieten.

Fazit

Anforderungen müssen trotzdem weiterhin auch zu jedem Zeitpunkt in einem agilen Projekt erarbeitet und definiert werden. Bei Scrum sollten beispielsweise durch die „Definition of Ready“ klar vorgegeben sein, was in einer Story an Anforderungen definiert sein muss, bevor diese eingeplant werden kann. Nur durch klar definierte Anforderungen, die im Rahmen der Vorbereitung der Stories verfeinert werden, kann ein gutes Ergebnis unter Beibehaltung einer hohen Qualität erzielt werden.