Agile Softwareentwicklung durch Spezialisten und Generalisten

Die klassische Softwareentwicklung setzt auf fest definierte Ziele und klare Absprachen zwischen Kunden und Entwicklern: Funktionen, Standards, Schnittstellen – aber auch Zeitpläne und Budgets werden vorab fixiert und die Aufgaben der Beteiligten in Lasten- und Pflichtenheften festgeschrieben. Das Ergebnis ist meist ein Softwaremonolith, der (mehr oder weniger) pünktlich und (idealerweise) zum vereinbarten Preis ausgeliefert wird. Gerade bei komplexen und innovativen Projekten stößt ein solches Vorgehen an Grenzen.

Hier sorgen agile Methoden für mehr Flexibilität. Denn bei ihnen wird auf ein bindendes Gesamtkonzept verzichtet und die realen Bedürfnisse der User rücken in den Fokus. Stetige Verbesserung und enge Kooperation ersetzen starre Pläne. In agilen Projekten entwickelt man die Funktionalitäten schrittweise in Iterationen – die Software wird kontinuierlich getestet, optimiert und implementiert. Dazu werden crossfunktionale Entwicklerteams zusammengestellt, denen ein hohes Maß an Eigenverantwortung abverlangt – und in gleichem Maß Entscheidungsspielraum zugebilligt wird. Ihre zentralen Aufgabenbereiche – außer der eigentlichen Programmierung – sind das Anforderungsmanagement (Requirements Engineering), die Software-Architektur und das Testing.

Klassisches Requirements Engineering findet in agilen Projekten weniger Platz, denn der flexible Umgang mit Änderungen gehört zu den agilen Prinzipien. Verglichen mit klassischen Pflichtenheften kommt man hier mit viel schlankerem Anforderungsmanagement aus. Zudem fehlt im agilen Umfeld die Rolle eines definierten Requirements Engineers. Wer aber kümmert sich dann darum? Bei SCRUM und verwandten Methoden fällt einem der Product Owner ein: Er ist das Verbindungsglied zu den Stakeholdern. Es ist seine Aufgabe, ihre Bedürfnisse und Wünsche zu verstehen, sie abzuwägen und daraus realistische Produkteigenschaften und Ziele abzuleiten. Zur Dokumentation und Priorisierung nutzt er das Product Backlog. Entscheidend dafür sind Kriterien wie die Wichtigkeit für den Zielkunden, der Aufwand im Verhältnis zum erwarteten Nutzen oder mögliche Risiken. Aber im Backlog sind Anforderungen nicht in Stein gemeißelt. Sie sind das Ergebnis von Teamarbeit und müssen kontinuierlich verfeinert und aktualisiert werden.

Eine häufige Schwierigkeit ist, das Verständnis von Anforderungen zwischen Stakeholdern und dem Team zu vermitteln – denn die Beteiligten schauen aus unterschiedlichen Perspektiven auf das Projekt. Um Missverständnisse zu vermeiden, haben sich User Stories etabliert. Damit wird ein überschaubares, kurzfristig umsetzbares Feature beschrieben – prägnant und aus User-Sicht. Das Besondere dabei: Alle Beteiligten sollen unter dem Beschriebenen dasselbe verstehen und so ein gemeinsames Ziel entwickeln. Zur User Story gehört auch, den Nutzen und Wert eines Features zu benennen, um kreative Lösungsansätze zu entwickeln – statt formale Details abzuarbeiten. Als Tool in agilen Projekten sollten User Stories weitgehend unabhängig voneinander implementierbare Features beschreiben. Nur so lassen sie sich iterativ und inkrementell umsetzen. Und: User Stories müssen zeigen, wie sich Funktionen testen lassen.

Die Worte „Architektur“ und „Agilität“ scheinen kaum in einen Satz zu passen. Denn Architektur lässt starre Strukturen vermuten, nicht flexible Dynamik. Und dennoch: Auch agile Projekte brauchen Architektur und basieren auf ähnlichen Grundfragen: Welche Plattform, welche Technologien und Frameworks kommen zum Einsatz? Wie kommunizieren die Systemteile miteinander? Nach welchen Prinzipien lassen sich verfügbare, performante und sichere Funktionen entwickeln? Darüber hinaus entwickelt sich die agile Architektur von Sprint zu Sprint kontinuierlich weiter. Architektonische Aufgaben übernimmt das selbstorganisierte Team. Es trifft seine Entscheidungen zum spätestmöglichen Zeitpunkt, hält Optionen lange offen und sammelt erst Informationen und Erfahrungen. Denn eine abstrakte Vorab-Modellierung, die künftige Anforderungen vorhersehen will, vergeudet Ressourcen. Es gilt also, Entwürfe so flexibel zu halten, dass Erweiterbarkeit und Änderbarkeit des Produkts ohne großen Codierungsaufwand möglich bleiben.

Agile Architekten arbeiten entwicklungsnah und kommunizieren ihre Vorstellungen in einem frühen und veränderbaren Stadium: Denn zeitnahes (und am besten persönliches) Feedback reduziert Projektrisiken deutlich. Zudem sollten Architekten ihre Entwicklungsnähe nutzen, um Source Code, Prototypen und technische Konzepte inkrementell zu bewerten. Umgekehrt gilt für agile Entwickler, dass sie ein Bewusstsein für Architektur und ihre Prinzipien brauchen, und dass sie Konsequenzen von Architekturentscheidungen beurteilen können. Der wechselseitige Rückkopplungsprozess verschafft den Entwicklern großen Einfluss auf die Architektur. Und die Architekturdokumentation? Sie muss kompakt sein, leicht pflegbar, aktuell, transparent und verständlich. Eine gute Beschreibung umfasst alle nötigen Informationen, um das Gesamtsystem zu verstehen – mehr nicht. Insbesondere auf ausufernde Details und Quellcode sollte verzichtet werden.

Wenn Agilität frühen Kundennutzen durch kurze Entwicklungszyklen erzeugen will, erhält das Software-Testing eine zentrale Funktion. Denn die Tests schaffen den Abgleich zwischen Funktionskriterien, Kundenerwartung und tatsächlicher Produkteignung. In agilen Projekten sind die Tests eine präventive Maßnahme, um Einschränkungen zu berücksichtigen oder geänderte Anforderungen unmittelbar umsetzen zu können. Dafür wird das Testdesign häufig schon vor der eigentlichen Softwareentwicklung erstellt – das Prinzip der testgetriebenen Entwicklung. Das Testing rückt dabei nah an das Anforderungsmanagement und die User Stories heran, aus denen sich die Abnahmekriterien für das Teilprodukt ergeben. Daraus wiederum lassen sich Basisanweisungen für die durchgehenden Tests eines Sprints ableiten, um das Teilprodukt gegenüber den Anforderungen zu bewerten.

Die Kopplung von Anforderungsmanagement und Testing führt auch dazu, dass die Testspezialisten von Beginn an dabei sein müssen. Und weil jedes Teilprodukt kontinuierlich weiterentwickelt (und potentiell auslieferbar sein muss), braucht es durchgehende und häufige Tests. Dafür sollten die Tester mit den Entwicklern zusammenarbeiten, sich Aufgaben teilen und voneinander lernen. Zudem fordern die häufigen Änderungen in agilen Projekten ein hohes Maß an Testautomation, um mit der Geschwindigkeit der Entwicklung Schritt zu halten und das Regressionsrisiko im Griff zu behalten. Konsequente und systematische Tests eignen sich, um das technische und funktionale Verständnis im Team zu fördern. Aber trotz massiver Testautomatisierung bleiben oft Lücken in der Testabdeckung, denn Nutzer gehen mit der Software anders um, als zuvor erwartet. Solche Fehlerquellen lassen sich mit „explorativen Tests“ finden. Dabei kommen die Tester den Fehlern durch kreatives Probieren auf die Schliche – damit am Ende eines Sprints Software geliefert werden kann, die dem Kunden einen erkennbaren Mehrwert bietet.