Die agile Entwicklung war eine Revolution, die die Regel des etablierten Wasserfall/V-Prozesses umgeworfen hat. Wie bei jeder Revolution glauben ihre Anhänger, dass es am besten ist, genau das Gegenteil dessen zu tun, was man bisher getan hat. In der agilen Welt ist das Handeln wichtiger als der Prozess und Anforderungen und Dokumentation schaden mehr als sie nützen. Aufbauend auf der agilen Methode sind Unternehmen der Meinung, dass sie zuerst Code schreiben und sich später mit den Konsequenzen auseinandersetzen sollten, um Geschwindigkeit und Produktivität gegeneinander austauschbar zu machen.
Im Laufe der Zeit haben viele Revolutionäre begonnen, ihre Annahmen neu zu bewerten und erkennen, dass die alte Welt vielleicht nicht perfekt war, aber es gab Bereiche, in denen sie von ihren Vorgängern profitieren könnten. Vor diesem Hintergrund haben Agile- und DevOps-Praktizierende begonnen zu verstehen, dass Anforderungen und Projektdokumentation ein wesentlicher Bestandteil des Entwicklungsprozesses bleiben.
Dieser Artikel bietet Richtlinien, wie Sie nützliche Anforderungen und relevante Dokumentationen erstellen können. Durch die Kombination von Shift-Left, kollaborativen (Three Amigos) und Fail-Fast-Ansätzen können Sie zum frühestmöglichen Zeitpunkt weniger starre Anforderungen definieren und diese mit modernen iterativen Verfahren und Tools verwenden.
Wasserfall verstehen
In den Augen der Agile- und DevOps-Praktizierenden sieht der Wasserfall aus wie die letzten Tage der französischen und russischen Monarchien. In den schlechten alten Zeiten konnte kein Code geschrieben werden, ohne einem komplizierten und starren Prozess zu folgen, dessen Ausführung viel Zeit in Anspruch nahm und häufig zu Fehlern führte. Um zu verstehen, warum dieses Modell so verhasst wurde, lassen Sie uns einen genaueren Blick darauf werfen.
Der Wasserfallprozess wird oft als V-förmige Entwicklung bezeichnet. In diesem Modell wird der Programmierprozess in Schritte zerlegt:
Entdeckung
Anforderungen
Systementwicklung
Architektur
Jeder Schritt muss in einer Reihe ausgeführt werden, und Sie können den nächsten Schritt erst starten, nachdem der aktuelle Schritt abgeschlossen ist. Diese Schritte stellen die linke Seite des V dar und werden von oben nach unten durchgeführt.
Nach Abschluss der Programmierphase wird eine neue Reihe von Testschritten durchgeführt:
Unit
Subsystemintegration
Integration
System
Akzeptanz
Operativ
Es gab eine Reihe von Problemen mit diesem Ansatz. Zuerst einmal erforderte der Erfolg eines V-förmigen Entwicklungsprojektes so viel Vorarbeit wie möglich. Zudem musste man sich an Entscheidungen, die in der Anfangsphase eines Projektes getroffen wurden, so genau wie möglich halten. Nachdem also alle notwendigen Recherchen in der Entdeckungsphase abgeschlossen waren, wurden detaillierte Anforderungen formuliert und ein Design erstellt, das diese Anforderungen strikt einhielt.
Um Zeit zu sparen, wurden weder die Anforderungen noch das Design bis kurz vor dem Ende des Entwicklungsprozesses getestet. Und um es noch schlimmer zu machen, wenn Probleme auftraten, die den ursprünglichen Anforderungen oder den Annahmen, auf denen sie beruhen, widersprachen, wurde ihre Bearbeitung bis zur Testphase verschoben. Diese verzögerten Probleme traten dann typischerweise während der Integration von Subsystemen und Systemen wieder auf, was teils zu riesigen Integrationsproblemen führte. Das Endergebnis war eine Flutwelle technischer Schulden, die die verfügbaren Ressourcen überforderte und oft zum vorzeitigen Ende des Projekts führte.
Behebung der Wasserfall-Probleme durch Shift-Left
Die Lösung der Probleme des Wasserfall-/V-förmigen Modells erfordert einen präventiven Ansatz, der den Prozess (Shift-Left), die Zusammenarbeit (Drei Amigos) und die Implementierung (Fail-Fast) beinhaltet.
Shift-Left-Testen
Shift-Left-Testen verschiebt Aufgaben, die in den späteren Phasen der Entwicklung durchgeführt werden, auf den frühestmöglichen Zeitpunkt im Prozess. Mit anderen Worten, sie werden von der rechten Seite des V auf die linke Seite verschoben. Es gibt vier Arten von Shift-Left-Testen: traditionell, schrittweise, Agile/DevOps und modellbasiert. Dieser Ansatz konzentriert sich auf die Strukturierung von Anforderungen, um deren Wert für den Endanwender hervorzuheben und/oder Anforderungen auf Anwendungsmerkmale abzubilden.
Traditionelles Shift-Left-Testen bedeutet, dass der Großteil der Tests eines Projekts in den frühen Unit- und Integrationsphasen durchgeführt wird und nicht während der späteren System- und Akzeptanztests.
Bei der schrittweisen Verlagerung des Testens nach links wird ein Projekt in kleinere schrittweise Phasen zerlegt und die Tests werden in jeder dieser Phasen durchgeführt
Agile/DevOps Shift-Left-Testing umfasst die Erstellung einer Reihe von kurzen Iterationen, die eigene Tests beinhalten. Diese Iterationen können als eine Gruppe von einzelnen V-förmigen Prozessen betrachtet werden. Dieses Modell wird stark von agilen Methoden beeinflusst, wie z. B. der testgetriebenen Entwicklung (TDD).
Beim modellbasierten Shift-Left-Testen wird versucht, das Testen zu implementieren, indem ein Testmodell erstellt wird, bevor überhaupt Code geschrieben wurde
Drei Amigos
Dieser Ansatz fördert die Zusammenarbeit zwischen den drei Hauptteilen einer Entwicklungsorganisation: dem Unternehmen selbst, vertreten durch Stakeholder, Business-Analysten sowie Produkt-Owner, Entwickler und Tester. Indem sie diese „drei Amigos“ dazu bringen, sich so früh wie mögliche zu treffen und Projekte zu besprechen, bauen sie Vertrauen auf und schaffen ein gemeinsames Verständnis für das Projekt, an dem sie arbeiten. Durch die Zusammenarbeit definieren sie die User Stories des Projekts, die seine Funktionen implementieren und bewältigen den Rückstand bei Implementierungsaufgaben. Gemeinsam definieren die drei Amigos die Kriterien, nach denen das Projekt als abgeschlossen definiert werden kann.
Fail Fast
Dieser Ansatz behandelt die Implementierungsaspekte eines Projekts. In diesem Modell wird die testgetriebene Entwicklung von Entwicklern eingesetzt, um Tests zu verfassen, bevor sie Code schreiben. Code wird in gemeinsamen Versionskontroll-Repositories gespeichert, wo er von jedem am Projekt beteiligten Entwickler aufgerufen werden kann. Fail Fast fördert auch die Verwendung von Continuous Integration-, Delivery- und Deployment-Systemen, die schnell Code erstellen und deployen können. Diese Systeme werden ausgelöst, wenn ein Entwickler seinen Code in ein Source-Management-System einträgt, automatisierte Tests gegen ihn durchführt, um sicherzustellen, dass er bei der Produktivsetzung nicht stoppt, oder eine neue Version der Anwendung erstellt und diese dann sofort releast und deployt. Das häufige Releasen von Software an Endanwender schafft eine Feedbackschleife, die sicherstellt, dass Entwickler das Entwicklungsteam benachrichtigen können, sobald ein Anwender einen Fehler findet. Auf diese Weise können sie den Code reparieren und ihn schnell wieder in die Hände der Anwender bringen.
Anforderungen und Dokumentation: Die fehlenden Teile
Die Implementierung von Shift-Left, drei Amigos und Fail Fast reicht nicht aus. Sie müssen sich immer noch um die Dokumentation und die Anforderungen kümmern. Wie wir bereits gesehen haben, hat das Anforderungsmanagement durch die Verknüpfung mit dem Wasserfallmodell einen schlechten Ruf erlangt. Statt detaillierte Anforderungen zu schreiben, wurde die agile Praxis des Schreibens von User Stories übernommen. Eine User Story ist ein Ein-Satz-Szenario, das eine Aufgabe beschreibt, die der Anwender ausführen möchte. Im Gegensatz zu herkömmlichen Anforderungen behandeln User Stories nur eine begrenzte Anzahl von Annahmen und Resultaten. Außerdem betonen agile Methoden die Wichtigkeit des Schreibens von Code gegenüber jeglicher Form von Dokumentation. Dokumentation wird oft als unnötiger Ballast empfunden, der, so gut er auch sein mag, nie gepflegt wird und schnell veraltet. Für viele agile Entwickler gelten User Stories daher als die einzige Dokumentation, die ein Projekt benötigt.
Die Anwendung von Shift-Left, drei Amigos und Fail-Fast-Ansätzen macht das Schreiben von Anforderungen und Projektdokumentationen zu einem wesentlichen Bestandteil unserer neuen Agile/DevOps-Welt. Beginnen Sie damit, die Anforderungen und Dokumentationsprozesse in die frühesten Phasen eines Projektes zu verlagern. Nachdem Sie die ersten Entwürfe der Anforderungen und Dokumente geschrieben haben, teilen Sie sie mit den drei Amigos zur Überprüfung. Es ist wichtig, dass Sie Ihre Anforderungen in einem System schreiben und verwalten, welches die Zusammenarbeit in Echtzeit ermöglicht. Viele Unternehmen schreiben und teilen noch immer Anforderungen mithilfe von Desktop-Textverarbeitungsdokumenten und Tabellenblättern. Dies macht es schwieriger, Anforderungen anzuzeigen, zu aktualisieren, zu pflegen und zu verfolgen. Wenn Sie die Anforderungen den relevanten Personen zugänglich machen, haben Sie langfristig wichtige Vorteile und erhalten zeitnah qualitativ hochwertiges Feedback.
Indem Sie Anforderungen und Dokumentationen so früh wie möglich zur Verfügung stellen, können fehlerhafte Annahmen und Anforderungen gefunden und behoben werden, bevor Ihre Entwickler jemals eine Zeile Code schreiben. Die Anwendung dieser Prinzipien hat dramatische Auswirkungen auf den gesamten Entwicklungsprozess. Insbesondere wird die Anzahl der Tests und Fehlerbehebungsiterationen, die durchgeführt werden, bevor Ihre Software in den produktiven Betrieb geht, stark reduziert.
Alles zusammen mit Panaya
Eine der besten Möglichkeiten, alle in diesem Beitrag angesprochenen Elemente in die Praxis umzusetzen, ist mit Panaya. Panayas Release Dynamix [RDx]-Lösung unterstützt einen agilen Enterprise Delivery-Ansatz, der auf Shift-Left-Prinzipien basiert. Release Dynamix [RDx] steuert alle Phasen des Entwicklungsprozesses von der Entstehung bis zum Deployment und bietet einen Drei-Amigos-Ansatz für die unternehmensweite Zusammenarbeit. RDx bietet Ihnen außerdem ein kontinuierliches Anforderungs- und Dokumentationsmanagement sowie leistungsstarke Tools für Analyse, Changemanagement und Problemverfolgung.
Fazit: Nach links verschieben & nach oben bewegen
Wie viele Revolutionen begann die agile Entwicklung als eine Randbewegung, die irgendwann den Standard definierte. Insgesamt haben die Änderungen durch Agile- und DevOps-Bewegungen den Softwareentwicklungsprozess erheblich verbessert. Trotz einiger großer Probleme mit den älteren Wasserfall-/V-förmigen Modellen gab es jedoch auch einige Vorzüge ihres Ansatzes für das Anforderungsmanagement und die Dokumentation.
Die Anwendung einer Kombination aus Shift-Left, Drei Amigos und Fail-Fast-Ansätzen kann jeden Entwicklungsprozess erheblich verbessern. Und die Anwendung dieser Ansätze auf Bereiche wie Dokumentation und Anforderungen ist für moderne Agile- und DevOps-Verfahren sehr nützlich. Anforderungen und Dokumentation so früh wie möglich zu schreiben und sicherzustellen, dass sie von allen Beteiligten getestet und überprüft werden, reduziert die Anzahl der Interaktionen vor dem Release, was Ihnen wiederum dabei hilft, zuverlässigere Produkte zu releasen.
Schauen Sie sich nach diesem Artikel Ihren bestehenden Entwicklungsprozess an und versuchen Sie, die Teile zu finden, die verbessert werden müssen. Erfahren Sie mehr über die Shift-Left-, drei Amigos- und Fail-Fast-Ansätze und überlegen Sie, wie sie Ihnen helfen können. Finden Sie einen Weg, diese Ansätze zu nutzen, um Ihre aktuellen Anforderungen und Dokumentationsprozesse zu verbessern und eine integrierte Lösung wie z. B. Panaya’s Release Dynamix [RDx] einzusetzen.
