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.
Agiles Anforderungsmanagement
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.
Agile Softwarearchitektur
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.
Agiles Testing
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.
Ein Fehler ist aufgetreten.
Cookie-Einstellungen
ookies sind kleine Daten, die von einer Website gesendet und vom Webbrowser des Benutzers auf dem Computer des Benutzers gespeichert werden, während der Benutzer surft. Ihr Browser speichert jede Nachricht in einer kleinen Datei namens Cookie. Wenn Sie eine andere Seite vom Server anfordern, sendet Ihr Browser das Cookie an den Server zurück. Cookies wurden entwickelt, um Websites einen zuverlässigen Mechanismus zum Speichern von Informationen oder zum Aufzeichnen der Browsing-Aktivitäten des Benutzers zu bieten.
- Erforderliche Cookies
Erforderliche Cookies
Diese Cookies ermöglichen grundlegende Funktionen und sind für die einwandfreie Nutzung der Webseite erforderlich. Zum Beispiel den Zugriff auf sichere Bereiche der Webseite, oder das Aufbewahren Ihrer Trainingsauswahl im Warenkorb für einen späteren Zugriff.
- Statistiken
- OffOn
Statistiken
Diese Cookies werden auch als „Leistungscookies“ bezeichnet und sammeln Informationen darüber, wie Sie eine Website nutzen, z. B. welche Seiten Sie besucht haben und auf welche Links Sie geklickt haben. Keine dieser Informationen kann verwendet werden, um Sie zu identifizieren. Es ist alles aggregiert und daher anonymisiert. Ihr einziger Zweck ist die Verbesserung der Website-Funktionen. Dies schließt Cookies von Analysediensten von Drittanbietern ein, sofern die Cookies ausschließlich dem Eigentümer der besuchten Website dienen.
Betroffene Lösungen:- Google Analytics
- Marketing
- OffOn
Marketing
Diese Cookies verfolgen Ihre Online-Aktivitäten, um Werbetreibenden zu helfen, relevantere Anzeigen zu schalten oder die Häufigkeit zu begrenzen, mit der Sie eine Anzeige sehen. Diese Cookies können diese Informationen mit anderen Organisationen oder Werbetreibenden teilen. Dies sind dauerhafte Cookies und fast immer von Drittanbietern.
Betroffene Lösungen:- Google Ads
- LeadLab
- Meta