Was braucht angemessene Architektur von agilen Projekten?

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

In meinem vorigen Blogeintrag ) habe ich beschrieben, wie ein moderner, skalierender Architekturprozess aussehen kann. Als Entscheidungsgrundlage, ob und wenn ja wie viel Architektur man braucht, wurden dabei Anforderungen identifiziert: Besonders Risikoreiche oder qualitative Anforderungen machen den Architekturzyklus sinnvoller. Nun möchte ich einen Blick auf agile Projekte werfen: Wie dockt das beschriebene Entwicklungsmodell hier an?

Was es braucht…

Gerade in agilen Projekten ist es wichtig zu entscheiden wann Architektur wichtig ist und wann man besser direkt in die Umsetzung geht. Ein Problem das ich hierbei schon öfter beobachtet habe ist, dass qualitative Anforderungen und teilweise auch Risiken zu wenig sichtbar sind, um die richtige Entscheidung zu treffen. Funktionale Anforderungen in einem Backlog zu sammeln ist hier nicht genug. Konkrete, explizite Qualitätsanforderungen zu Wartbarkeit, Sicherheit, Verfügbarkeit, etc. sind nicht nur für die Architekturarbeit essentiell, sondern auch für die Entscheidung ob Architekturarbeit nötig ist.

Qualitätsanforderungen verankern

Mir sind drei Möglichkeiten bekannt, qualitative Anforderungen in agilen Projekten zu „verankern“:

• Als Qualitätsgeschichte: Qualitative Anforderungen (etwa zu Skalierbarkeit) kommen, wie funktionale Anforderungen auch, als Story in den Backlog.
• Als Akzeptanzkriterium: Qualitative Anforderungen werden als Akzeptanzkriterium funktionalen Anforderungen zugeschlagen.
• Als allgemeiner Merker: Qualitative Anforderungen werden als omnipräsent kommuniziert. Jedes Teammitglied denkt immer an Qualität xy und wird eventuell durch einen Eintrag in der Definition of Done daran erinnert.

In bestimmten Situationen haben sicher alle genannten Optionen so ihre Probleme. Definiert man Qualitäten allerdings konkret genug, kann man ein sinnvolles Zusammenspiel der Techniken erreichen. So kommen Qualitätsgeschichten zum Einsatz wenn entsprechende Anforderungen relativ unabhängig bearbeitbar sind, Akzeptanzkriterien kommen bei direkten Erweiterungen funktionaler Anforderungen zum Einsatz und allgemeine Merker bei sehr breit wirkenden Anforderungen.

Agile Architektur

Durch die explizite Erhebung und Verankerung von qualitativen Anforderungen, kann die Entscheidung zur Architekturarbeit leichter erfolgen. Der Architekturzyklus wird z.B. durchlaufen wenn Qualitätsgeschichten hochprior im Backlog liegen, wenn Akzeptanzkriterien große Bedenken auslösen oder ein allgemeiner Merker erarbeitet werden soll (etwa eine breite Entwicklungsvorgabe zur Verwendung von Interfaces). Die Arbeit erfolgt in den Iterationen, parallel zur Umsetzung und natürlich vom Kundenvertreter priorisiert. Letzteres schafft eine potentielle „Streitschnittstelle“, die implizit angenommene Risiken aufdeckt und für Transparenz sorgt.

Fazit

Auch wenn ich sie hier nicht in aller Ausführlichkeit besprechen kann, sind die vorgestellten Ansätze, in der ein oder anderen Form, in vielen Projekten zu finden. Der gemeinsame Einsatz führt dabei zur Umschiffung vieler Nachteile, sorgt für bessere Entscheidungen was Architekturarbeit betrifft und erlaubt die sinnvolle Bewertung von Architekturlösungen. Dabei sollte der schlanke, kundenorientierte Prozess agiler Projekte nicht an Schwung verlieren.