Christian Fischer
von Christian Fischer 09.03.2016
5 Min. Lesezeit

Softwareentwicklung bewegt sich in der Regel in einem komplexen Umfeld bei dem zu Beginn nicht alle Anforderungen und Rahmenbedingungen bekannt sind und diese sich mit der Zeit auch ändern können. Eine vollständige Analyse und damit Lösungsdefinition vor der Umsetzung ist daher in der Regel nicht möglich oder wie es Edward V. Berard bereits treffend auf den Punkt brachte: “Walking on water and developing software from a specification are easy if both are frozen.” Welche Möglichkeiten bieten agile Methoden in diesem Umfeld?Aufgrund der im Vorfeld nicht möglichen Lösungsdefinition werden in agilen Vorgehensmodellen die Architekturentscheidungen erst dann getroffen, wenn die Implementierung diese erforderlich machen. So können Erfahrungen aus den vorangegangen Produktinkrementen einfließen und späte Anforderungsänderungen möglichst lange ohne höhere Aufwände berücksichtigt werden.

Als Folge dieser Verschiebung wird die Architekturarbeit nicht durch einen von der Umsetzung losgelösten Softwarearchitekten geleistet, sondern muss durch das Entwicklungsteam wahrgenommen und verantwortet werden. Viele unerfahrene Teams sind sich der daraus resultierenden Aufgaben nicht bewusst, da es hierfür keine konkreten Artefakte oder Methoden in agilen Vorgehensmodellen wie Scrum oder Kanban gibt. Eine Reihe von Problemfeldern sind die Folge, von denen mir die folgenden immer wieder begegnen.

  • Flache Lernkurve
    Neue Mitarbeiter benötigen eine sehr lange und damit teure Einarbeitungsphase bis sie sich in der Architektur zurechtfinden und wissen, wie Erweiterungen oder Änderungen implementiert werden können, da keine aktuelle Beschreibung zum Aufbau und den Schnittstellen der Software existiert.
  • Angst vor Verbesserung
    Bereits getroffene Architekturentscheidungen werden nicht neu bewertet, da weder die damals gültigen Rahmenbedingungen noch die aktuellen Qualitätsanforderungen bekannt sind.
  • Fehlende Architekturdokumentation
    Das Agile Manifest bewertet funktionierende Software höher als eine umfangreiche Dokumentation. Bedauerlicherweise wird dieses oft so interpretiert, dass eine Beschreibung der aktuellen Architektur als wertlos erachtet und diese daher nicht erstellt wird. Die Folge sind Mängel in der Nachvollziehbarkeit der getroffenen Entscheidungen sowie der Konsistenz der aktuellen Architektur.

Um diesen Gefahren vorzubeugen, haben sich in agilen Entwicklungsteams Praktiken und Artefakte entwickelt.

  1. Constraints im Product Backlog 
Nichtfunktionale Anforderungen machen den größten Teil der Rahmenbedingungen aus, an denen sich die Architektur einer Software ausrichten muss. Ähnlich wie bei den User Stories müssen auch hierfür Akzeptanzkriterien definiert werden, anhand derer die Erfüllung der gewünschten Qualitätsmerkmale überprüft werden kann. Wie bereits von Mike Cohn vorgeschlagen, bietet es sich an, diese Anforderungen in Form von Constraints als Einträge ins Product Backlog aufzunehmen. Damit ist gewährleistet, dass die Nichtfunktionalen Anforderungen priorisiert werden und bei der Entwicklung Berücksichtigung finden.

  1. Architecture Round Table
Um die inkrementell entstehende Architektur nicht dem Zufall zu überlassen, trifft sich das Entwicklerteam regelmäßig, um über Lösungsalternativen zu entscheiden. Teamübergreifend können entsprechende Communities of Practice als Gremien genutzt werden.  

  1. Codenahe Dokumentation
Um die Architekturdokumentation auf dem aktuellen Stand halten zu können, muss diese nahe am Code erstellt und gepflegt werden, so dass jeder Entwickler die von ihm gemachten Änderungen zeitgleich dokumentieren kann. Durch die implizite Nutzung des Versionsmanagement ist die lückenlose Historie gewährleistet und jederzeit transparent, auf welchen Softwarestand sich die Dokumentation bezieht.
  
  1. Cookbooks

Ergänzend zu den in der Architekturdokumentation beschriebenen, zugrunde liegenden Konzepten und Mustern helfen konkrete Beispiele, die Konsistenz innerhalb der entwickelten Software zu wahren. Neue Mitarbeiter erfahren durch diese Cookbooks in kürzester Zeit, wie neue Anforderungen in der bereits existierenden Struktur umgesetzt und integriert werden können.

  1. Technical Debt Backlog

Trotz gewissenhafter Analyse und umfänglich abgestimmter Architekturentscheidungen lässt sich im Laufe der Entwicklung die Entstehung von Technischen Schulden nicht vermeiden. Sich ändernde Rahmenbedingungen ebenso wie die technologische Weiterentwicklung führen mit der Zeit zu Problemen, die sowohl die Softwarequalität als auch die Umsetzungsgeschwindigkeit beeinträchtigen können. Die notwendigen Verbesserungen müssen zusammen mit den damit verbundenen Aufwände und Auswirkungen in einem Technical Backlog transparent gemacht werden. 

Mehr zum Einsatz dieser Methoden, wie sie in den Scrum-Prozess integriert werden und welche Werkzeuge hilfreich sind, erfahren Sie in meinem Vortrag “Kollaborative Software Architektur in Agilen Teams” auf dem Frankfurter Entwicklertag am 10. März 2016.

Kommentare