Begraben Sie den Wasserfall nicht

TLDR: Wenn Sie Sprints verwenden, arbeiten Sie möglicherweise nicht wirklich agil. Gleichzeitig bedeutet die Unterteilung Ihres Prozesses in Entwicklungs- und Lieferphasen nicht unbedingt, dass Sie ihn falsch machen. Allerdings kann es mehr schaden als nützen, wenn Sie die tatsächliche Methodik, die Sie praktizieren, unter einem Etikett verstecken. Und wenn der Entwicklungsprozess Ihres Unternehmens linear abläuft, sollten Sie ihn nicht unter den agilen Elementen begraben.

Einführung

Im modernen Software-Diskurs sind "Wasserfall", "Monolith" und "jährliche Releases" Synonyme für Misserfolg. Es scheint, dass Sie, wenn Sie nicht gerade eine Variante der agilen Entwicklung praktizieren (auch wenn es nur dem Namen nach ist ), machen Sie es falsch.

Und warum ist das so? Und ist der "Wasserfall" ein gerader Weg in die Katastrophe, wie er so oft dargestellt wird?

Um das herauszufinden, lassen Sie uns zunächst einen Blick auf die frühen Jahre der Softwareentwicklung werfen.

Auf dem (sehr vereinfachten) Weg der Erinnerung

Die ersten Softwareprogramme wurden nicht von Informatikern, sondern von Elektroingenieuren geschrieben. Diese Ingenieure benutzten keine IDEs oder kopierten von Stack Overflow - die ersten Programme wurden sorgfältig von Hand entworfen, wobei sie in der Regel die Schaltkreise und die Konfiguration eines bestimmten Computersystems berücksichtigten. Nachdem sie den Algorithmus und die Operationen geschrieben und validiert hatten, war es an der Zeit, das Programm auszuführen. Die Ausführung nahm ebenfalls viel Zeit in Anspruch (wenn auch immer noch schneller, als es menschlich möglich war) und die Rechenzeit wurde unter Kollegen und Gleichgesinnten aufgeteilt. Wenn Ihr Programm also Fehler machte oder abstürzte, mussten Sie zurück ans Zeichenbrett gehen und es später erneut versuchen, wenn Sie in der Warteschlange wieder an der Reihe waren.

Der erste Patch eines Softwareprogramms war ein buchstäblicher Patch auf ein Loch in einer Lochkarte.

Und der erste Fehler war ein buchstäbliches Insekt, das sich zwischen den Schaltkreisen befand.

Damals nahmen all diese Elemente (Planung, Design, Implementierung, Testen und Ausführung) viel Zeit in Anspruch. Da die Kosten für Fehler recht hoch waren, war eine sorgfältige Ausführung entscheidend.

Als das Schreiben von Programmen immer aufwändiger wurde und einen Überblick erforderte Projekt , geliefert von Gruppen von Menschen, den Auserwählten Die Entwicklungsmethodik spiegelt das wider. Sie kopiert die sorgfältige und gründliche Vorgehensweise bei der Entwicklung, die man normalerweise in der realen Welt der Ingenieursarbeit antrifft, wo die Kosten für Fehler hoch sind, d.h. verbrauchter Strom, verschwendete Zeit und verlorenes physisches Material.

Ein "Wasserfall[1]"Methodik folgt einem linearen Ablauf, der normalerweise Folgendes umfasst:

• Erfassen der Anforderungen und Sicherstellen ihrer Vollständigkeit
• Entwerfen der Software entsprechend den Anforderungen
• Code-Implementierung
• Verifizierung der Ergebnisse (in der Regel mit Akzeptanztests durch den Benutzer)
• Danach tritt die Software in die Wartungsphase ein (in der durchschnittlich 80 % des für die Software ausgegebenen Geldes verbraucht werden).

[1] Eine wichtige Anmerkung - Dr. Winston Royce, der das klassische Wasserfallmodell schuf, hat Möglichkeiten für Feedback vorgesehen (Royce, W. W. Managing the Development of Large Software Systems. In IEEE WESCON, Seiten 328-338, Los Angeles, 1970. IEEE.).

Neue Morgendämmerung verblasst

Dieser Ansatz zeigte seine Schwächen, als die Softwareentwicklung immer komplexer wurde - sie begann, sich mit dieser neuen Sache namens "Internet" zu befassen, wurde auf verschiedenen Technologien aufgebaut und erforderte manchmal sogar die Integration von Softwarepaketen Dritter.

Und so trafen die Probleme der langen Planung und Umsetzung mit der Geschwindigkeit des technologischen Fortschritts zusammen, was oft dazu führte:

1. Der Anwendungsfall des freigegebenen Produkts hat sich zum Zeitpunkt seiner Freigabe geändert.
2. Die Unfähigkeit, während des Entwicklungszyklus auf den Wettbewerb zu reagieren und sich schnell anzupassen.
3. Der Kommunikations-Overhead zwischen mehreren beteiligten Parteien erfordert viele Übergaben, was zum Verlust des Kontexts und zur Einführung von Annahmen führt, wodurch viele Bugs und Fehler erst spät im Prozess auftreten.

Gleichzeitig wurden die Technologie, die Computer und die Humanressourcen weithin verfügbar und die Ausführungszyklen wurden billiger. Außerdem begann die Softwareentwicklung langsam Konzepte wie automatisierte Tests, automatisierte Bereitstellung und Versionskontrolle zu übernehmen, was schließlich in der Erkenntnis gipfelte:

Fehler bei der Softwareentwicklung müssen Sie nicht mehr viel Geld kosten, vorausgesetzt, Sie erkennen, validieren und beheben sie schnell.

Willkommen bei Agile

Agile Praktiken hielten zu Beginn des Jahrhunderts offiziell Einzug in die Mainstream-Softwarekultur mit der Veröffentlichung des "Agiles Manifest" im Jahr 2001. Die zugrundeliegenden Ideen waren zwar nicht neu, aber es war die erste erfolgreiche Bewegung, die einen klaren Fokus auf frühere Praktiken wie Kanban, SCRUM, Extreme Programming usw. setzte . Sie stellte die Zusammenarbeit, die Bereitstellung von Funktionalität und Flexibilität in der Planung über die starre Planung, die umfangreiche Dokumentation und die Abhängigkeit von Werkzeugen und Prozessen in den Vordergrund.

Die meisten agilen Methoden halten sich an diese Grundsätze. Die Arbeit wird in Iterationen geliefert, was häufigeres Benutzerfeedback und Kurskorrekturen während des Entwicklungszyklus ermöglicht. Bestimmte Methoden wie SCRUM konzentrieren sich darauf, mit jeder Iteration ein funktionierendes Produktinkrement freizugeben, egal wie klein das Entwicklungsteam es machen kann - wichtig ist nur, dass es freigegeben wird.

Wesentliche Elemente der Scrum-Methodik

Seitdem sind agile Praktiken aufgrund ihrer offensichtlichen Vorteile zu Recht die "Standard"-Wahl für Softwareentwicklungsprojekte. Die Stakeholder können sehen, wie das funktionierende Endprodukt mit jeder Iteration allmählich geliefert wird, während die Entwickler den Kurs korrigieren können, was ihre interne und externe Zusammenarbeit verbessert und die Arbeit nach der Veröffentlichung minimiert.

So weit so gut, oder?

Wie Sie wahrscheinlich selbst wissen, gibt es in der realen Welt bei vielen Projekten immer noch Verzögerungen bzw. Probleme bei der Einführung von Funktionen, die Benutzer bekommen nicht immer das, was sie sich gewünscht haben, und Bugs landen immer noch in der Produktion. Wo liegt also das Problem?

Die Realität setzt ein

Es gibt natürlich kein einzelnes Problem, das bei der Softwareentwicklung zu Fehlern führt, aber wenn es um Methoden geht, kann man ein häufiges Problem wie folgt zusammenfassen:

Viel zu oft wird eine Methodik einfach so angewandt, ohne die Bedürfnisse des Unternehmens, des Teams, des zu entwickelnden Produkts oder die Anforderungen an das Produkt ganzheitlich zu betrachten. Die Methodik wird (vor allem, wenn sie gehyped wird und glänzt) zu einer "Silberkugel", die "uns zum nächsten FAANG machen wird".[2]" und wird auf jeden Aspekt des Unternehmens angewandt und oft nie wieder überdacht.

Vor sieben Jahren versuchte jeder zweite Beitrag auf LinkedIn, "Blockchain" in die Beschreibung seines Produkts aufzunehmen. Danach war es "Microservices", dann war es "maschinelles Lernen" und 2019 war es "KI". Natürlich lässt sich einiges davon damit erklären, dass die Marketingabteilung darauf achtet, das Unternehmen im Gespräch zu halten, indem sie mit den neuesten Trends Schritt hält, aber wenn "KI" keinen Nutzen für die Funktionalität Ihres Unternehmens bringt, sollten Sie es bei Ihren nächsten Produktzielbesprechungen ausklammern.

Das Gleiche gilt für eine Methodik - wenn sie einem Team ohne vorherige Untersuchung aufgedrängt wird (oder weil sie einen "coolen Namen" hat, wie die Spotify-Modell, das bei Spotify eigentlich nie verwendet wurde), wird es zu einer Belastung für das Team. Fragen Sie sich selbst: "Bin ich in meinem täglichen Leben jemals auf eine der folgenden Situationen gestoßen":

[2] Facebook, Apple, Amazon, Netflix, Google

1. "Wir arbeiten mit "Agile", aber die Veröffentlichung war bereits nach 3 Sprints geplant, und wir haben noch nicht einmal mit UAT begonnen.
2. "Die Anforderungen an unseren Service sind glasklar, aber wir müssen unser Produkt weiterhin den Stakeholdern vorführen, von denen die meisten nicht anwesend sind und die anderen sowieso nie mit dem Service interagieren werden!"
3. "Wir würden gerne mit der Arbeit beginnen, aber die IT-Abteilung muss sich mit den Mitarbeitern von Operations abstimmen und Patrick ist bis nächsten Monat beurlaubt, so dass wir dieses Mal einen Wartungssprint durchführen werden.
4. "Wenn wir mit dem Implementierungssprint fertig sind, beginnt das Testteam mit dem Verifizierungssprint, und danach erhalten wir die Ergebnisse zur Verbesserung!"

Es kommt vor, dass ein Unternehmen eine bestimmte Methodik anwendet, aber so tut, als wäre es etwas anderes. Das einfachste Beispiel ist, wenn Sie jeden Schritt des Wasserfallprozesses in eine Sammlung von Sprints umwandeln, nur um "agil" zu sein.

Am Ende haben Sie die Vorteile von beiden und die Nachteile von beiden.

Wenn also keine Methode ein Allheilmittel ist, wie können Sie dann eine für Ihr Team auswählen und anwenden? Lassen Sie uns ein paar Fakten auf den Tisch legen.

Agil, Wasserfall und Ihr Team

Im Großen und Ganzen lassen sich die Unterschiede zwischen Agile und Waterfall wie folgt zusammenfassen:

• Agilität bietet sich an, wenn Sie Dinge nach und nach entdecken müssen.
  • ... während Waterfall gut funktioniert, wenn die Anforderungen von Anfang an kristallklar sind
• Agilität ermöglicht Ihnen eine effiziente Zusammenarbeit mit den Interessengruppen und das Einholen von Feedback während der Demos während der Lieferung.
  • ... aber wenn keine Änderungen der Anforderungen zu erwarten sind, spart Waterfall Ihnen Zeit
• Agile legt die Verantwortung auf die Entwickler, fördert die Selbstverbesserung und erwartet multidisziplinäre Teams
  • ... während der sequenzielle Charakter von Waterfall hervorragend mit aufgabenorientierten Gruppen mit etablierten Arbeitsabläufen funktioniert

Um den effektivsten Ansatz zu ermitteln, stellen Sie sich die folgenden Fragen, bevor Sie ein neues Projekt beginnen:

• Sind meine Anforderungen klar?
• Ist mein technischer Stack bereit?
• Habe ich eine feste Frist?
• Ist der Zeitplan für das Projekt kurz?
• Habe ich in den Teams verfügbare Ressourcen mit dem erforderlichen Fachwissen?

Wenn Sie alle diese Fragen mit "Ja" beantwortet haben, kann "Wasserfall" tatsächlich eine gute Wahl sein, wenn Sie Ihr Projekt kontinuierlich und mit einem bekannten Kontext, Ziel und einer Reihe von Werkzeugen und Ressourcen durchführen.

Aber wenn Sie auf diese Fragen mit etwas wie:

• Die Anforderungen sind nur sehr allgemein gehalten, und wir müssen die Software zunächst mit Endbenutzern testen, bevor wir uns auf den Endzustand einigen können.
• Der technische Stack kann sich ändern, wenn wir feststellen, dass die Software nicht wie erwartet funktioniert.
• Es wird keine Frist gesetzt, bis die Software Gestalt annimmt
• Unser Team besteht aus multidisziplinären Entwicklern, die alle die gleichen Fähigkeiten haben.

Vielleicht tendieren Sie eher zu "Agile": implementieren, veröffentlichen, das Produkt dem Kunden zeigen, neu gruppieren, überdenken und erneut versuchen.

Letztendlich wird jede einzelne Situation einzigartige Herausforderungen und Chancen mit sich bringen, bei denen dogmatisches Denken über Ansätze zur Softwareentwicklung nicht hilfreich ist. Und vielleicht ist es an der Zeit, dass moderne Unternehmen sich nicht mehr immer nur an ein Regelwerk halten, sondern bei der Bereitstellung von Softwareprodukten eher einen "Getriebe"-Ansatz verfolgen und je nachdem, wie schnell (oder vorsichtig) sie vorgehen wollen, den passenden Gang einlegen.