Der Software Development Life Cycle (SDLC) beschreibt den siebenstufigen Prozess, den jede Software von der ersten Idee bis zur Wartung des fertigen Produkts durchläuft. Stellen Sie sich das wie einen Fluss mit sieben Schleusen vor: Das Wasser erreicht zwar so oder so das Meer, aber die Schleusen ermöglichen es Ihnen, den Wasserstand zu regulieren – und eine Schleuse, die Sie nie gebaut haben, können Sie auch nicht schließen, wenn der Pegel steigt.
Dieser Artikel ordnet 18 Agile-Praktiken diesen Phasen zu, damit Sie sehen, was wohin gehört, welche Kosten mit der Einführung verbunden sind und welche Risiken dadurch minimiert werden. Er richtet sich an Entscheidungsträger, die über das Budget für die Softwarebereitstellung bestimmen: CTOs, Heads of Engineering oder Product Leader, die Prioritäten bei der Finanzierung setzen und gegenüber dem Vorstand für die Ergebnisse verantwortlich sind. Diese Praktiken werden weltweit von Teams eingesetzt, unter anderem bei uns bei Imaginary Cloud.
SDLC steht für Software Development Life Cycle. Entgegen der landläufigen Meinung handelt es sich dabei weder um ein Framework noch um einen fest definierten Prozess. Es ist ein konzeptionelles Modell: eine Darstellung der Softwareentwicklung in einer Reihe von Schritten, die von der ersten Idee bis zur Bereitstellung reichen.
Unabhängig von der Methodik Ihres Teams werden alle sieben Schritte mehr oder weniger detailliert abgedeckt. Ein Wasserfallmodell betrachtet jeden Schritt als eigenständige Phase, wobei das Ende jeder Phase einen Meilenstein darstellt, der vor Beginn der nächsten Phase freigegeben werden muss. Eine agile Methodik fasst dieselben sieben Schritte in wiederkehrende, zyklische und iterative Abschnitte zusammen und deckt sie in jeder Iteration ab.
Das Konzept von Agile in der Softwareentwicklung existiert bereits seit Jahrzehnten. Bis Ende der 90er Jahre waren wasserfallorientierte Projekte die Norm – und damit auch die damit verbundenen Probleme: schwerfällige Prozesse, mangelnde Flexibilität und ein tiefer Widerstand gegen Veränderungen. Dann zeichnete sich eine neue Richtung ab.
Zu diesem Zeitpunkt begannen agile Methoden (die damals noch gar nicht so genannt wurden) wie Scrum, XP, Crystal, Feature-Driven Development (FDD) und Dynamic Systems Development Method (DSDM) aufzutauchen.
Vier Dinge. Agile begrüßt sich ändernde Anforderungen, anstatt sie einzufrieren, liefert Software kontinuierlich statt in einem einzigen Release, bringt Business-Verantwortliche und das Entwicklungsteam in engen, stetigen Austausch und integriert regelmäßige Reflexionen zur kontinuierlichen Verbesserung.
Trends kommen und gehen. Der eigentliche Nutzen von Agile liegt darin, die bekannten, mühsamen und wiederkehrenden Probleme der Softwareentwicklung aus einem anderen Blickwinkel zu betrachten.
Anstatt den ausgetretenen Pfad der vier Werte im Agilen Manifestzu beschreiten, sprechen wir über die Prinzipien und bewährten Methoden von Agile. Sie werden oft übersehen, was schade ist, da sie viel mehr Details der Denkweise enthalten, die Agile vermitteln soll.
Die zwölf Prinzipien hinter dem Agilen Manifest, veröffentlicht unter agilemanifesto.org/principles, sind der Bezugspunkt für alles Folgende.
Eine „Praxis“ ist die „tatsächliche Anwendung oder Nutzung einer Idee, Überzeugung oder Methode im Gegensatz zu den damit verbundenen Theorien“. Genau das ist eine Agile-Praxis: die Theorie des agilen Arbeitens, angewandt auf etwas Reales.
Sie können diese Praktiken anwenden, ohne einer bestimmten agilen Methodik zu folgen. Die alleinige Nutzung von TDD (Test Driven Development) macht Ihre Bereitstellung natürlich noch nicht agil. Die meisten dieser Methoden werden als Agile-Praktiken bezeichnet, weil sie entweder aus einer agilen Methodik hervorgegangen sind oder von agilen Praktikern entwickelt wurden.
Verschiedene Methodiken fördern unterschiedliche Praktiken, um sie objektiver und produktiver zu gestalten. Jede konzentriert sich in der Regel auf einen einzelnen Aspekt: Management, Entwicklung, Tests und so weiter.
Hier ist also die Liste, zugeordnet zu den Schritten Ihres SDLC. Einige lassen sich mehrfach im Laufe eines Projekts anwenden, und eine Praxis, die eine Phase vollständig abdeckt, deckt oft die nächste teilweise mit ab. Die Faustregel lautete schon immer: weniger Fokus auf Strenge, mehr Fokus auf das Erreichen der gewünschten Ergebnisse.
Wenn Sie entscheiden müssen, wo Sie zuerst investieren sollen, zeigt die folgende Tabelle, was die Einführung der Praktiken in den jeweiligen SDLC-Phasen typischerweise erfordert, welches Risiko sie beseitigt und wie lange es dauert, bis sich dies in der Bereitstellung bemerkbar macht.
| SDLC-Phase | Einführungskosten | Beseitigtes Risiko | Zeit bis zur Amortisation |
|---|---|---|---|
| Planung | Ein bis zwei Workshop-Tage von Product Owner, Lead Engineer und Business Sponsor | Entwicklung des falschen Produkts sowie spätere Diskussionen über den Projektumfang | Sofort: Vision und Backlog dienen dem Team als direkte Arbeitsgrundlage |
| Analyse und Anforderungen | Eine Woche eines funktionsübergreifenden Teams für ein Lean Inception oder den Designprozess | Anforderungen, die erst mitten in der Entwicklung entdeckt werden – wenn sie am teuersten einzubinden sind | Ein bis zwei Sprints, sobald das Backlog zur Ruhe kommt |
| Entwurf und Prototyping | Einige Tage für architektonische Spikes sowie die Disziplin, Entwurfsentscheidungen offen zu halten | Eine verfrühte Architektur, die mühsam rückgängig gemacht werden muss, sobald reale Anforderungen vorliegen | Ein bis zwei Quartale, da Änderungsanträge nicht mehr das Fundament belasten |
| Entwicklung | Tools für kontinuierliche Integration sowie ein fester Anteil der Entwicklerzeit zum Schreiben von Tests | Integrationskonflikte, Regressionen und technische Schulden, die sich unbemerkt anhäufen | Ein bis drei Monate, sobald die Testabdeckung dicht genug ist, um Regressionen abzufangen |
| Testen | Testautomatisierung samt Tool-Lizenzen und der erforderlichen Pipeline-Laufzeit | Fehler, die die Produktion erreichen, sowie manuelle Testzyklen, die sich mit jedem Release verlängern | Ein bis zwei Quartale, da sich Regressionszyklen von Tagen auf Minuten verkürzen |
| Bereitstellung und Betrieb | Aufwand für Infrastructure-as-Code und DevOps-Kapazitäten (entweder neu eingestellt oder intern aufgebaut) | Langsames, risikoreiches Release-Management und lange Wiederherstellungszeiten bei Störungen | Drei bis sechs Monate, gemessen an der Bereitstellungsfrequenz und der mittleren Wiederherstellungszeit |
Planungsmethoden sind die kostengünstigsten auf dieser Liste und die einzigen, die sich sofort auszahlen. Eine Woche Zeitaufwand der richtigen Leute verhindert, dass ein Team sechs Monate lang das falsche Produkt entwickelt.
Die erste Phase Ihres Projekts sollte die Produktvision sein. Die anfängliche Konzeption erfordert einige kurze Definitionen: Wer sind die Kunden, wer ist das Team, was ist der grobe Leistungsumfang (und was gehört nicht dazu), wie sieht der technische Entwurf aus, welche Risiken gibt es sowie eine Schätzung von Zeit und Kosten.
Ein hilfreiches Extra ist das Vision Statement, auch bekannt als „Elevator Pitch“. Es besteht aus einem einzigen Satz: Für einen Zielkunden, der ein Bedürfnis hat, ist das Produkt eine Kategorie, die einen entscheidenden Vorteil bietet – im Gegensatz zur Hauptkonkurrenz und dank eines klaren Alleinstellungsmerkmals.
Wenn Sie eine neue Idee validieren, beginnt hier das Nachdenken über ein Minimum Viable Product , noch lange bevor die erste Zeile Code geschrieben wird.
Das Business Model Canvas prägt das Produkt, das Sie entwickeln wollen, und bietet einen praxisorientierten Ansatz zur Definition von Geschäftsmodellen. In Verbindung mit Lean Startup dient es als visuelle Übersicht der Ideen und Vorstellungen hinter einem bestehenden oder neuen Unternehmen.
Es funktioniert, indem es das Geschäftsmodell auf eine einzige Seite zwingt, unterteilt in neun Blöcke: Aktivitäten, Partner, Ressourcen, Nutzenversprechen, Kunden, Kanäle, Kundenbeziehungen, Kosten und Einnahmen. Das Ausfüllen dieser Blöcke verwandelt Annahmen in Hypothesen, die Sie benennen, diskutieren und testen können. Genau darin liegt der Wert für eine Planungssitzung.
Das Product Backlog ist die Liste der Geschäfts- und Projektziele. Sie enthält alles, was das Team voraussichtlich entwickeln wird, und wird vom Product Owner gepflegt. Es ist ein lebendiges Dokument: Es wird kontinuierlich aktualisiert, priorisiert und nach Geschäftswert geordnet.
Es kann auch Produktverbesserungen, Fehlerbehebungen, technische Fragen und Ähnliches enthalten. Sein Zweck ist es, alles, was zur Erreichung der Produktvision erforderlich ist, an einem Ort zu bündeln.
Eine Anforderung, die im Workshop entdeckt wird, kostet ein Gespräch. Dieselbe Anforderung, die mitten in der Entwicklung entdeckt wird, kostet Nacharbeit, und nach der Veröffentlichung kostet sie einen Hotfix und das Vertrauen des Auftraggebers. Genau diese Lücke schließt die hier investierte Woche.
Paulo Caroli entwickelte die Lean Inception als seine Adaption und Weiterentwicklung der Inception-Phase, wie sie bei ThoughtWorks praktiziert wurde. Die Idee ist, Design Thinking und Lean Startup in einem Discovery-Workshop zu kombinieren, um das MVP des Produkts zu definieren: das Minimum Viable Product, also die kleinste Version eines Produkts, die dem Nutzer dennoch einen Mehrwert bietet.
Der einwöchige Workshop zielt darauf ab, die Richtung zu finden, die das Team für den Bau des idealen Produkts einschlagen sollte. Man kann es sich als eine Erweiterung des oben genannten Themas Produktvision vorstellen. Er umfasst zudem die Definition von Personas, User Journeys, Features sowie technische, UX- und geschäftliche Reviews – alles innerhalb dieses einwöchigen Zeitrahmens.
Der Produktdesign-Prozess ist unsere Art bei Imaginary Cloud, die Entstehung digitaler Produkte zu definieren. Wir setzen ihn intern bei unseren Projekten ein, und auch verschiedene Akteure der Branche nutzen ihn extern. Er deckt alle Schritte ab, die nötig sind, um eine Lösung zu schaffen, die sowohl für das Unternehmen als auch für den Nutzer funktioniert, wobei Kunden und Product Owner – gemeinsam mit den Nutzern – in den Mittelpunkt der Diskussion gestellt werden.
Je nach Komplexität des Produkts und der erforderlichen Tiefe bei der Lösungsfindung kann dies ein bis mehrere Wochen in Anspruch nehmen. Zwölf Schritte, von der Recherche und Ideenfindung über die Umsetzung bis hin zur technischen Bewertung, dienen dazu, die Produktentwicklung so präzise wie möglich zu steuern. Wir haben die Entstehung dieses Prozesses und jeden einzelnen Schritt in unserem Leitfaden zum Produktdesign-Prozessdokumentiert.
Wir haben das Product Backlog bereits als Methode zur Strukturierung Ihrer Produktziele erwähnt. Es lohnt sich, eine Methode für die Arbeit damit vorzustellen, sofern Sie User Stories zur Erstellung und Pflege dieses Backlogs verwenden.
User Story Mapping, die von Jeff Patton beschriebene Technik, ermöglicht eine visuelle Aufschlüsselung oder ein „Slicing“ von User Stories. So können diese in einer sinnvollen Reihenfolge für das Produkt angegangen werden: erst das Grundgerüst, dann die kleineren Details.
Warum der Aufwand? Weil es zeigt, wie sich Funktionen über das gesamte Projekt verteilen, anstatt sie nur als gruppierte Liste darzustellen. Wie dünn oder dick die einzelnen Slices sind, um eine durchgängige Erzählung zu erreichen, ergibt sich aus dem direkten Austausch mit Kunden und Nutzern.
Designentscheidungen sind am teuersten, wenn sie rückgängig gemacht werden müssen. Die hier angewandten Methoden sind bewusst schlank gehalten: Legen Sie sich nur auf so viel Architektur fest, wie für den Start nötig ist, und halten Sie den Rest offen, bis die Anforderungen konkret sind.
Domain-Driven Design, oder DDD, strukturiert Softwarearchitektur-Modelle mithilfe einer Abstraktion der Geschäftsdomäne der Anwendung. Dies erfordert eine enge Zusammenarbeit zwischen Technik und Fachbereich, was zu einem der Hauptmerkmale von DDD führt: einer gemeinsamen Sprache (Ubiquitous Language). Das bedeutet, dass sich Entwickler, Tester und Business-Stakeholder auf ein einheitliches Set an Fachbegriffen einigen, das in Code, Gesprächen und Dokumentationen gleichermaßen verwendet wird.
Da DDD stark auf der Domänenebene basiert und Konzepte der objektorientierten Programmierung nutzt, erfreut es sich in der OOP-Community großer Beliebtheit. Der Grundgedanke lässt sich jedoch unabhängig vom Programmierparadigma anwenden, insbesondere da er als Basis für TDD, BDD, CI, Refactoring und andere Methoden dienen kann.
DDD unterteilt die Domäne in begrenzte Kontexte (Bounded Contexts) – Bereiche des Unternehmens, in denen ein Modell und ein Vokabular konsistent gelten. Innerhalb dieser Kontexte werden Entitäten (Entities) modelliert, also Objekte mit einer Identität, die über Änderungen hinweg bestehen bleibt, wie etwa ein Kunde. Zudem gibt es Wertobjekte (Value Objects), die ausschließlich durch ihre Attribute definiert sind, wie beispielsweise eine Postanschrift. Zusammen bilden sie ein strategisches Design für die Anwendung, das Struktur, Lebenszyklus und Verhalten der Domäne präzise und kohärent vereint.
Ein Spike ist ein gängiger Begriff aus dem agilen Umfeld, der aus dem XP (Extreme Programming) stammt. Er bezeichnet eine Art User Story, die dazu dient, einen Lösungsansatz zu erforschen und gerade so viel Verständnis zu gewinnen, dass das Risiko bei der Umsetzung minimiert wird. Ein Architectural Spike geht einen Schritt weiter und fokussiert sich auf Software-Design und Architektur.
Er definiert das Grundgerüst der Modellierungsarchitektur und wie die Komponenten zusammenwirken – pragmatisch genug, um auf Basis der begrenzten Informationen über die Problemdomäne eine Lösung vorzuschlagen. Die Definitionen umfassen in der Regel Softwareschichten, Subsystemgrenzen, oft auch funktionsfähigen Code sowie Versionsverwaltungstools als minimales Skelett der Anwendung. Dies speist die Systemmetapher, eine „einfache, gemeinsame Geschichte darüber, wie das System funktioniert“, die jeder im Projekt nutzen kann, um es zu beschreiben.
Während sich das Projekt und die Anwendung weiterentwickeln, werden auch Architektur und Design angepasst und verfeinert. Der Architectural Spike ist lediglich der erste Schritt in diese Richtung; die folgende Methode beschreibt, wie es danach weitergeht.
Das elfte Prinzip des Agilen Manifests besagt: „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams“. Rein auf das Design bezogen, stellt sich jedoch die Frage, was das in der Praxis bedeutet.
Emergent Design entwickelt die Lösung evolutionär und lässt Design und Architektur während des gesamten Entwicklungsprozesses Gestalt annehmen. Um es mit Fachbegriffen auszudrücken: Statt BDUF (Big Design Up Front) setzen Sie auf JEDI (Just Enough Design Initially).
Durch inkrementelles Arbeiten können sich Entwickler auf das konzentrieren, was das Projekt tatsächlich benötigt, und vermeiden eine verfrühte, suboptimale Architektur. Adressieren Sie die Anforderungen, die Sie haben. Entwerfen Sie nichts für Anforderungen, die Sie nur vermuten.
Ist Emergent Design unumstritten? Keineswegs. Der Einwand lautet, dass ein undefiniertes Grundgerüst der Anwendung das Risiko birgt, dass strukturelle Entscheidungen stückweise von demjenigen getroffen werden, der gerade den Code schreibt. Dieses Risiko ist real, und genau deshalb gibt es den oben genannten Architectural Spike: ein Skelett, das gerade ausreicht, um zu starten – und nicht mehr.
Hier liegen die dauerhaften Kosten. Tools für Continuous Integration sind günstig. Die Zeit, die Entwickler in das Schreiben von Tests investieren, ist es nicht – und dieser Aufwand endet nie. Was man dafür erhält, ist die Fähigkeit, die Codebasis auch im dritten Jahr noch genauso schnell anzupassen wie im dritten Monat.
Continuous Integration (CI) bedeutet, dass es einen zentralen Code-Hauptstrang gibt, in den die Änderungen und Ergänzungen der Entwickler – sei es in einem gemeinsamen Projekt-Repository oder einem Branch – zusammengeführt werden. Jede Integration sollte eine Reihe von Schritten auslösen, wie etwa automatisierte Tests und Tools zur Überprüfung des Programmierstils, die in der Regel von einem CI-Tool in Verbindung mit einem Versionsverwaltungssystem gesteuert werden.
XP empfiehlt, dies mehrmals täglich zu tun, damit jederzeit eine lauffähige, integrierte Version des Codes existiert. CI ist die erste Phase einer Kette, die auch Continuous Deployment (eine Anwendung wird automatisch in die Produktion überführt, wenn sie alle Schritte des automatisierten Bereitstellungsprozesses erfolgreich durchläuft) und Continuous Delivery (die Codebasis ist jederzeit in verschiedenen Umgebungen bereitstellbar) umfasst.
Die Standardstrategie für Continuous Integration ist die von Martin Fowlerbeschriebene: ein einziges Quell-Repository, ein automatisierter und selbsttestender Build, häufige Commits in den Hauptzweig, ein schneller und stets funktionsfähiger Build sowie eine transparente, sichtbare Pipeline.
Die Vorteile summieren sich: Fehler werden effizienter erkannt, der manuelle Integrationsaufwand entfällt, Umgebungen stehen für Builds jederzeit zur Verfügung, der Prozess wird transparenter (was die Kommunikation verbessert) und die Testabdeckung wird robuster. Zudem schafft CI Raum für Pull Requests und Code-Reviews.
DORA, das Forschungsprogramm, das 2014 begann und seitdem Daten von zehntausenden Ingenieuren gesammelt hat, identifiziert Continuous Integration beständig als eine der technischen Fähigkeiten, die eine höhere Software-Lieferleistung vorhersagen – gemessen an Durchsatz und Stabilität. Ein wichtiger Punkt zur Aktualisierung: Im Bericht für 2025 hat DORA das Akronym als eigenständigen Namen etabliert, die jährliche Studie von „Accelerate State of DevOps“ in State of AI-assisted Software Developmentumbenannt und die ursprünglichen vier Liefermetriken um eine fünfte erweitert: Neben der Bereitstellungshäufigkeit, der Durchlaufzeit für Änderungen, der Fehlerrate bei Änderungen und der Wiederherstellungszeit nach fehlgeschlagenen Bereitstellungen wurde eine Dimension für Zuverlässigkeit hinzugefügt.
Test-driven Development, kurz TDD, ist eine testbasierte Programmierung. Unter Verwendung automatisierter Unit-Tests folgt sie einem wiederholbaren Ablauf:
Das Ziel ist ein klarerer, einfacherer und fehlerfreier Code, geschrieben von jemandem, der sich bereits vor der ersten Zeile Gedanken über Struktur, interne Schnittstellen und Verantwortlichkeiten gemacht hat.
Zahlreiche Tools unterstützen Unit-Testing und TDD. Die bekanntesten sind die xUnit-Familie, also die Unit-Testing-Frameworks, die auf dem ursprünglichen SUnit basieren: JUnit, NUnit, XPyUnit, PHPUnit und deren Verwandte.
Für Entwickler, die noch nie so gearbeitet haben, ist TDD ein Paradigmenwechsel. Der häufigste Einwand lautet, dass es zu viel Zeit und Mühe kostet, um sich zu lohnen. Finden Sie den Mittelweg: TDD sollte Ihnen sowohl mehr getesteten als auch saubereren Code liefern.
Ein Vorbehalt: TDD kann nicht Ihre gesamte Qualitätssicherungsstrategie sein, worauf wir noch zu sprechen kommen, wenn wir über QS reden. Die automatisierten Tests, die dabei entstehen, sollten Teil Ihrer Continuous-Integration-Strategie sein, da deren Ausführung einer der Schritte ist, die CI erst ermöglichen.
Zwei Definitionen von Refactoring nach Martin Fowler sollte man im Hinterkopf behalten. Die erste bezeichnet es als disziplinierte Technik zur Umstrukturierung bestehenden Codes, bei der die interne Struktur geändert wird, ohne das externe Verhalten zu beeinflussen. Die zweite beschreibt es als Änderung der internen Softwarestruktur, die das Verständnis erleichtert und die Modifikation kostengünstiger macht – ebenfalls ohne das beobachtbare Verhalten zu verändern. Beide finden sich auf Fowlers eigener Definition von Refactoring.
Die Notwendigkeit dafür kündigt sich meist durch einen „Code Smell“ an: ein Hinweis darauf, dass eine Reorganisation fällig ist, weil der Code Schwachstellen aufweist oder potenzielle Probleme birgt. Ein häufiger Anwendungsfall für Refactoring ist der Abbau von technischen Schulden, die sich im Stillen anhäufen und sich lange bevor sie als Problem erkannt werden, durch langsamere Lieferzyklen bemerkbar machen. Übrigens: Bei TDD wird der Schritt, in dem man Code umschreibt, der den Test bereits besteht, ebenfalls als Refactoring bezeichnet.
Wir können das mit Zahlen belegen. Als AppTweak, eine Plattform für App-Store-Optimierung, wegen ihres Homepage-Dashboards auf uns zukam, lautete die ehrliche Wahl: neu bauen oder refactoren. Wir haben uns für Refactoring entschieden. Unsere Frontend-Entwickler wurden in eines der Teams von AppTweak integriert, arbeiteten nach deren Projektmanagement-Regeln, anstatt unsere einzuführen, und strukturierten die Zustandsverwaltung des Dashboards in React und TypeScript mit Redux und Redux-Saga um. Das beobachtbare Verhalten blieb gleich, das Innenleben nicht. Die Ladezeit sank um 80 Prozent. Das ist das Argument für Refactoring in einem Satz: Die Nutzer erhielten ein schnelleres Dashboard, und niemand musste die Auslieferung stoppen, um dies zu erreichen.
Der Hinweis, den wir jedem CTO geben würden, der vor derselben Entscheidung steht: Refactoring lohnt sich, wenn die Architektur solide ist und der Code lediglich drumherum veraltet ist. Wenn das zugrunde liegende Modell falsch ist, polieren Sie etwas, das Sie eigentlich ersetzen sollten – dann ist ein Neubau, kein Refactoring, die ehrlichere Investition.
Aufwand in Code zu stecken, der bereits funktioniert, ist schwer zu verkaufen. Es steigert jedoch die Wartbarkeit, Kohäsion, Lesbarkeit, Performance und Wiederverwendbarkeit, was den Zeitaufwand in der Regel rechtfertigt.
Beim Refactoring geht es nicht darum, neue Funktionen zu entwickeln. Das geht über den Zweck hinaus. Das Ziel ist immer, das aktuelle Verhalten beizubehalten, wobei bestehende oder neue Tests sicherstellen, dass dies auch so bleibt. Häufige Beispiele: Verwendung von Entwurfsmustern, Polymorphie, Kapselung von Feldern, Änderung der Verwendung von Parametern, Exceptions und so weiter.
In der Testphase lassen sich Kosten und Risiken am einfachsten beziffern. Automatisierung verursacht Kosten für Entwicklung und Lizenzen. Die Alternative ist ein manueller Regressionszyklus, der mit jedem Release länger wird, bis er das Tempo des gesamten Projekts bestimmt.
BDD soll verhindern, dass Fachbereich, Entwicklung und Test mit drei unterschiedlichen Verständnissen desselben Features arbeiten.
BDD steht für Behaviour-Driven Development, einen Entwicklungsansatz, der die Kommunikation zwischen Fach- und Technik-Teams verbessert, um Software mit echtem geschäftlichem Mehrwert zu erstellen. Es dient als verbindendes Element zwischen Fachleuten, Entwicklern, QA-Testern und allen anderen Projektbeteiligten, damit die Eigenschaften der Anwendung von allen gleichermaßen verstanden und beschrieben werden. Dies erreichen Sie, indem Sie Spezifikationen als Szenarien und Beispiele formulieren und das „Gegeben-Wenn-Dann“-Muster verwenden, um das tatsächliche Verhalten der Lösung abzubilden.
ATDD (Acceptance Test-Driven Development) geht einen Schritt weiter und nutzt die Basis von BDD, um automatisierte Abnahmetests für das in den Szenarien definierte Verhalten zu implementieren. Es ähnelt TDD: Automatisieren Sie eine Reihe fehlschlagender Abnahmetests und schreiben Sie dann den Code, der diese erfolgreich macht.
Test-Tools wie Behat, Cucumber und SpecFlow unterstützen ausführbare Spezifikationen. Damit können Sie ATDD auf Basis der in BDD definierten Anforderungen durchführen.
Automatisierte Tests sind zwar keine formale Agile-Praxis, bilden aber das Fundament der Qualitätssicherung in agilen Projekten. Sie machen ATDD, TDD und CI erst sinnvoll. Ohne sie wird Qualitätssicherung zu einer Phase statt zu einer festen Gewohnheit.
Dabei wird eine separate Software eingesetzt, um Tests gegen Ihre Anwendung auszuführen: für externe Schnittstellen wie mobile oder browserbasierte GUI-Tests, für die interne Kommunikation zwischen Schichten wie APIs oder für Performance-Tests. Der größte Vorteil ist die Vermeidung manueller Wiederholungen und der damit verbundenen menschlichen Fehlerquellen.
Die Vorteile zeigen sich besonders bei Strategien wie Regressionstests oder in einer Continuous-Integration-Pipeline. Da die Implementierung dieser Tests Aufwand erfordert, sollte man genau abwägen, was wann automatisiert werden soll.
Auch Entscheidungen zur Testabdeckung sind wichtig: Unit-, Integrations- oder umfassende End-to-End-Tests erfordern unterschiedlichen Aufwand und bieten je nach Fokus unterschiedlichen Mehrwert. Die DORA-Studien identifizieren kontinuierliches Testen – also automatisierte Tests, die bei jedem Commit statt in einer Phase vor dem Release laufen – konsequent als eine der Fähigkeiten, die leistungsstarke Delivery-Teams von anderen unterscheidet.
Ähnliches gilt für das Toolset, das eine sorgfältige Auswahl statt einer Standardlösung verdient. Selenium, Jasmine und RSpec sind Beispiele für Tools, die für unterschiedliche Testzwecke entwickelt wurden.
Sitzungsbasiertes Testen ist eine weitere Praxis, die zwar nie offiziell als „agil“ deklariert wurde, aber dennoch weithin in der agilen Welt übernommen wurde. Es ist eine strukturiertere Form des manuellen explorativen Testens: Software wird ohne vorheriges Design oder definierte Testfälle getestet, um gezielt nach Fehlern zu suchen.
Es folgt dem Prinzip „Teile und herrsche“, indem zeitlich begrenzte Tests in Sitzungen unterteilt werden. Die Schritte umfassen Mission, Charter, Sitzung, Sitzungsbericht, Debriefing und Analyse, die zusammen genau das richtige Maß an Detailtiefe für den Prozess bieten.
Im agilen Kontext können Sie mehrere Sitzungen pro User Story definieren und je nach Risiko tiefer oder oberflächlicher testen. Diese Flexibilität ermöglicht es, mit dem Tempo Schritt zu halten.
Manuelle Tests haben neben der Automatisierung weiterhin ihre Berechtigung. Eine explorative Sitzung findet Fehler, für die niemand einen Test geschrieben hat – genau die Art von Fehlern, die sonst in der Produktion landen. Erst das Zusammenspiel beider Strategien garantiert die Qualitätssicherung, die ein Projekt benötigt.
Diese Praktiken zahlen sich am langsamsten aus, fallen aber am stärksten auf, wenn sie fehlen. Die Bereitstellungshäufigkeit und die durchschnittliche Wiederherstellungszeit sind die beiden Kennzahlen, nach denen ein Vorstand früher oder später fragen wird – und beide werden in dieser Phase festgelegt.
DevOps ist die Kombination und Zusammenarbeit von Entwicklungs- und IT-Betriebsteams, um eine kontinuierliche und schnelle Bereitstellung zu erreichen. Es bringt beide Seiten zur Zusammenarbeit und unterstreicht durch das Konzept der Infrastructure as Code (IaC), wie wichtig ihre Kommunikation und Integration sind.
Der Weg dorthin umfasst Infrastructure Automation (Systeme, Konfigurationen und App-Bereitstellungen, die als Code in der Projektstruktur hinterlegt sind), Continuous Delivery (automatisierte und zeitnahe Erstellung, Prüfung und Bereitstellung von Apps) sowie Site Reliability Engineering (Betrieb von Systemen, d. h. Überwachung und Orchestrierung, um sicherzustellen, dass sie diese Funktionalitäten von Anfang an unterstützen).
Dies bildet die „DevOps-Leiter“:
Zu den Vorteilen von DevOps zählen Skalierbarkeit, Zuverlässigkeit, Sicherheit, schnelle Bereitstellung (und eine kürzere Markteinführungszeit, wo dies relevant ist), eine kürzere durchschnittliche Wiederherstellungszeit (MTTR), die Vermeidung menschlicher Fehler sowie eine geringere Ausfallrate bei neuen Releases.
Die Größe dieser Lücke ist messbar. In ihrem 2024 State of DevOps Reportstellte DORA fest, dass die leistungsstärksten Unternehmen bei Bedarf bereitstellen, Änderungen in weniger als einem Tag in die Produktion überführen und den Dienst in unter einer Stunde wiederherstellen, während die leistungsschwächsten Unternehmen dieselben Kennzahlen in Monaten messen. Die Ausgabe 2025 fügt für alle, die in Tools investieren wollen, eine wichtige Einschränkung hinzu: KI fungiert hauptsächlich als Verstärker, der die Stärken von Teams mit soliden Bereitstellungsgrundlagen und die Fehlfunktionen derjenigen, die diese nicht haben, vergrößert. DevOps ergänzt Agile: häufige Bereitstellung, frühzeitige Fehlererkennung, mehr Transparenz bei der Überwachung einer Anwendung. Es ist zudem in skalierte Agile-Frameworks wie SAFe (das Scaled Agile Framework, das zur Anwendung von Agile über viele Teams hinweg eingesetzt wird) integriert.
Hinter diesen Zahlen steht ein konkretes Beispiel. Bei einem Marktplatzprojekt mit Tausenden von großen Assets wurde die Plattform auf Heroku gehostet, was die Skalierbarkeit einschränkte. Das Team migrierte die Datenbank von MySQL zu PostgreSQL und die Infrastruktur zu AWS. Die erste Phase wurde in zwei Monaten abgeschlossen, danach wurde auf Basis einer kontinuierlichen Entwicklung weitergearbeitet. Die Entscheidung für AWS statt Heroku fiel nicht aus Selbstzweck, sondern wegen des Skalierungsspielraums, den der alte Anbieter nicht bieten konnte – zu Kosten, die für den Kunden transparent waren.
Dies deckt Bereiche ab, die bereits unter Continuous Integration und DevOps beschrieben wurden, und korreliert eng mit automatisierten Tests. Wenn man diese Konzepte zusammenführt, ist Continuous Deployment der nächste Schritt nach Continuous Integration.
Dabei wird durch automatisierte Tests sichergestellt, dass korrekter Code automatisch in die Produktion überführt wird, meist mithilfe von DevOps-Infrastruktur-Tools. Diese automatisierte Bereitstellung führt häufig zu Verwechslungen mit Continuous Delivery: Beide teilen sich zwar die Abkürzung, doch bei Continuous Delivery erfolgt der Schritt in die Produktion manuell.
Continuous Deployment ist der vollständige, durchgängig automatisierte Software-Bereitstellungsprozess, der so oft ausgeführt werden kann, wie es die jeweilige Anwendung erfordert. Die typischen Schritte sind:
Zusammengenommen bieten diese Schritte die Gewissheit, dass der Code abgedeckt, geprüft und ausgereift genug ist, um ohne größere Risiken in die Produktion zu gelangen – mit der Option, die Änderung bei Bedarf einfach über die Pipeline rückgängig zu machen.
Bedenken bei der Automatisierung eines so wichtigen Prozesses sind berechtigt, und die Risiken sind durchaus real. Der Aufbau der Struktur ist zudem mit Kosten verbunden, sowohl für das Pipeline-Engineering als auch für das erforderliche Monitoring. Im Gegenzug hören Releases auf, Ereignisse zu sein, die geplant und geprobt werden müssen, was die Bereitstellung kleiner Änderungen erst wirtschaftlich macht.
Kanban ist eine Methode des Workflow-Managements, die die zu steuernde Arbeit visualisiert. Sie entstand im Bereich der japanischen Lean-Produktion, genauer gesagt im Toyota-Produktionssystem.
In jüngerer Zeit haben ihre Grundgedanken als Kanban-Methode Einzug in die Softwarebranche gehalten, deren wichtigstes Instrument das Kanban-Board ist. Dieses Board dient als visuelles Echtzeit-Repository für Informationen und Fortschritte eines Prozesses und macht Blockaden sowie Engpässe sofort sichtbar.
Die Spalten repräsentieren die Schritte im Arbeitsfluss und beinhalten das Konzept der laufenden Arbeit (Work in Progress) sowie deren Limitierung pro Spalte, was eine wertvolle Ressource darstellt. Die Grundidee ist, dass Ihre Aufgaben (Tickets, Issues und alles andere, was das Team nachverfolgt) durch jede Spalte des Boards fließen.
Kanban ist eine evolutionäre Methode, die einfach zu implementieren ist und sich während der Anwendung schrittweise weiterentwickeln lässt. Da es sich um ein nicht-disruptives Change-Management-System handelt, wird es häufig in Betriebs- und Wartungsprojekten eingesetzt. In diesem Kontext ist es Scrum überlegen: Bei kontinuierlichen Arbeitsabläufen mit unvorhersehbarem Eingang ist der feste Rahmen von Sprints oft nur zusätzlicher Aufwand ohne echten Mehrwert für die Vorhersehbarkeit, da Aufgaben, die am dritten Tag des Sprints anfallen, nicht bis zum nächsten warten können.
Kanban ist nicht strikt als Agile-Praxis definiert. Es wird jedoch genutzt, um agile und schlanke Prinzipien umzusetzen und gleichzeitig die Zufriedenheit von Mitarbeitern und Kunden zu steigern.
Ziel war es, konkrete Optionen aufzuzeigen, die Sie in jedem Softwareentwicklungszyklus einsetzen können, mit einem klaren Fokus auf agile Praktiken.
Keine der 18 Methoden muss sofort eingeführt werden, und die Reihenfolge ist wichtiger als die Anzahl. Beginnen Sie dort, wo es in Ihren Projekten am meisten schmerzt – sei es bei ständigen Anforderungsänderungen, langwierigen Regressionszyklen oder langsamen Releases. Diese Maßnahmen zahlen sich am schnellsten aus, und die obige Tabelle soll Ihnen helfen, dies als Budgetentscheidung und nicht als bloße Präferenz zu betrachten.
Bei Imaginary Cloud bewerten wir jedes Szenario individuell. Anstatt ein Standardset auf jedes Projekt anzuwenden, setzen wir die Methoden und Techniken ein, die zum aktuellen Stadium des Produkts und zum Risiko des Kunden passen. So sah ein integriertes Refactoring für AppTweak völlig anders aus als ein Greenfield-MVP, obwohl beide auf dieselben oben genannten Praktiken zurückgriffen.
Basierend auf der Expertise unseres Teams können wir definieren und empfehlen, wie Sie agile Methoden optimal nutzen und in welchem Stadium Ihres Webanwendungs- oder UI/UX-Design-Projekts Sie diese am besten einsetzen. Sie können unsere Fallstudien durchstöbern um zu sehen, wie das in der Praxis aussieht.
Planung, Analyse und Anforderungen, Design und Prototyping, Softwareentwicklung, Testen, Bereitstellung sowie Betrieb und Wartung. Jede Methodik deckt diese sieben Phasen mehr oder weniger detailliert ab. Der Unterschied liegt darin, ob sie einmalig als sequenzielle Phasen durchlaufen werden, wie beim Wasserfallmodell, oder wiederholt innerhalb jeder Iteration, wie bei Agile.
Nein. Der SDLC ist ein konzeptionelles Modell, das die Phasen beschreibt, die Software durchläuft; Agile ist eine Denkweise, und die dazugehörigen Methoden sind Wege, diese Phasen zu durchlaufen. Ein agiles Team plant, analysiert, entwirft, baut, testet und implementiert ebenfalls. Es führt lediglich alle sieben Schritte in kurzen, sich wiederholenden Zyklen aus, anstatt in einem einzigen Durchgang.
Planung: Produktvision, Business Model Canvas und Product Backlog. Analyse und Anforderungen: Lean Inception, Produktdesignprozess und User Story Mapping. Design und Prototyping: Domain Driven Design, Architectural Spikes und Emergent Design. Entwicklung: Continuous Integration, TDD und Refactoring. Testen: BDD und ATDD, automatisierte Tests und sitzungsbasiertes Testen. Bereitstellung und Betrieb: DevOps, Continuous Deployment und Kanban.
Ja. Praktiken wie TDD, Continuous Integration, Refactoring und Kanban sind unabhängig von einer bestimmten Methodik, und die meisten Teams führen sie nacheinander ein. Umgekehrt gilt: Die Durchführung von Scrum-Zeremonien ohne diese Praktiken macht die Bereitstellung allein noch nicht agil.
Nutzen Sie Lieferergebnisse anstelle von Checklisten zur Einführung. Die DORA-Liefermetriken – Bereitstellungshäufigkeit, Durchlaufzeit für Änderungen, Fehlerrate bei Änderungen und Wiederherstellungszeit nach fehlgeschlagenen Bereitstellungen (ergänzt um eine Zuverlässigkeitsdimension im Jahr 2025) – zeigen Ihnen, ob eine Praxis die Auslieferungsqualität des Teams verbessert hat. Erfassen Sie diese Werte, bevor Sie eine Praxis einführen, um eine Vergleichsbasis zu haben.
Das hängt von der Phase ab. Planungspraktiken zahlen sich sofort aus, da sie den Plan liefern, nach dem das Team arbeitet. Entwicklungs- und Testpraktiken benötigen ein bis drei Monate, bis eine Testsuite dicht genug ist, um Regressionen abzufangen. Bereitstellungs- und Betriebspraktiken benötigen drei bis sechs Monate, gemessen an der Bereitstellungshäufigkeit und der durchschnittlichen Wiederherstellungszeit.
Sie sind unsicher, was Sie zuerst finanzieren sollen? Kontaktieren Sie uns und wir analysieren, wo Ihr Prozess derzeit Zeit verliert, welche Praktiken zum aktuellen Stadium Ihres Produkts passen und welche Kosten mit deren Einführung verbunden sind.
Softwarebegeistert und agil. Kann leicht beim Kochen, Volleyball spielen oder etwas Zeit mit Videospielen verbringen.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
