Ist agil mehr als nur kleine Wasserfälle?

Ich habe bei meinen Projekten hauptsächlich die Wasserfallmethode verwendet, aber jetzt erweitere ich meinen Horizont um agile Methoden. Nach dem, was ich bisher gelesen habe und vielleicht die falschen Dinge gelesen habe, bedeutet Agilität kleine Wasserfälle. Anstelle eines großen Wasserfalls, der sich über ein oder zwei Jahre erstreckt, gibt es kleine Wasserfälle, die sich über Wochen oder höchstens einige Monate erstrecken.

Ist mein Verständnis richtig oder steckt mehr dahinter? Was sind die agilen Philosophien?

Auf einer einfachen Ebene ja. Das einfache Ausführen eines Wasserfalls alle zwei Wochen macht Sie nicht agil , aber es ist iterativ (was die Hälfte der Agilität ausmacht).

Das Wasserfallmodell definiert Phasen - Anforderungen, Architektur, Design, Implementierung, Verifizierung (Test), Validierung (Abnahmetest) und Freigabe. In jeder iterativen Methode durchlaufen Sie jede dieser Phasen in jeder Iteration. Es kann zu Überschneidungen kommen, aber Sie ermitteln und erfassen Anforderungen, übernehmen die Architektur und das Design des Systems, um die Implementierung zu ermöglichen, entwickeln die neuen Funktionen oder beheben die Fehler, testen die neuen Module und legen sie dem Kunden zur Abnahme vor Testen und Bereitstellen.

Agilität ist jedoch viel mehr als nur iterativ und inkrementell. Die Mieter von Agile werden im Manifest für Agile Software Development erfasst . Das Manifest enthält vier wesentliche Punkte:

Individuen und Interaktionen über Prozesse und Werkzeuge

Sie beziehen häufig einzelne Personen ein. Viele Implementierungen konzentrieren sich auf sich selbst organisierende und selbststeuernde Teams. Fast alle haben häufige Interaktionen mit dem Kunden oder mit jemandem, der die Stimme des Kunden hat. Anstatt eine Reihe formaler Verfahren und Tools zu verwenden, können die am Projekt beteiligten Personen bestimmen, wie das Projekt ausgeführt wird, damit es auf die bestmögliche Weise ausgeführt wird.

Arbeitssoftware über umfangreiche Dokumentation

In einem Softwareprojekt ist das primäre Ziel die Bereitstellung von Software. In einigen Projekten werden jedoch Dokumente verschwenderisch erstellt, die keinen Mehrwert bieten. Scott Ambler hat einen guten Artikel über Agile / Lean Documentation geschrieben . Es geht nicht darum, keine Dokumentation zu erstellen, sondern darum, eine Dokumentation auszuwählen, die Ihrem Team, zukünftigen Entwicklern, dem Kunden oder dem Benutzer einen Mehrwert bringt. Anstatt Dokumentation zu erstellen, die keinen Mehrwert bietet, erstellen Ihre Softwareentwickler Software und zugehörige Tests.

Zusammenarbeit der Kunden bei Vertragsverhandlungen

Anstatt die Bedingungen und Zeitpläne und Kosten im Voraus zu definieren, wird dies zu einer ständigen Anstrengung für den Kunden. Beispielsweise können Sie Ihre Anforderungen in Form von User Stories erfassen und ihnen Punkte zuweisen. Nach einigen Iterationen entscheiden Sie sich für eine Geschwindigkeit (Punkte / Iteration) und können bestimmen, wie viele Funktionen Ihr Team in einer Iteration implementieren kann. Da Ihr Kunde Feedback dazu gibt, welche Funktionen den größten Mehrwert bieten, kann er jederzeit entscheiden, wann das Projekt abgeschlossen ist. Bei häufiger Lieferung und Kundeninteraktion kann eine beliebige Anzahl von Dingen passieren - die Anforderungen wurden erfüllt, und das Projekt endet mit der Wartung und dem endgültigen Ende der Lebensdauer. Der Kunde stellt fest, dass er nicht alles benötigt, was er für das Ende des Projekts gedacht hat Projekt scheitert das Projekt und der Kunde sieht dies früh und kann es abbrechen ...

Reagieren, um nach einem Plan umzuschalten

Sie haben kein großes Design oder keinen endgültigen Plan im Voraus und müssen immer dann nacharbeiten, wenn sich dieses Design oder dieser Plan ändern muss. Sie schätzen und überarbeiten Schätzungen fortlaufend auf der Grundlage der von Ihnen zur Verfügung gestellten Informationen. Sie wählen Ihre Metriken sorgfältig aus, um einen Einblick in den Zustand des Projekts zu erhalten und um zu erfahren, wann interne Änderungen vorgenommen werden müssen. Sie fügen häufig Anforderungen hinzu, entfernen sie und priorisieren sie erneut mit dem Kunden. Letztendlich verstehen Sie, dass Veränderung die einzige Konstante ist.

Agil zu sein bedeutet, sich auf die Menschen zu konzentrieren und ihre Bedürfnisse zu erfüllen, indem schnell hochwertige, wertschöpfende Software bereitgestellt wird. Wenn sich die Bedürfnisse des Kunden ändern, passen Sie sich diesen Bedürfnissen an, um sich auf die Wertschöpfung zu konzentrieren. Es gibt spezielle Implementierungen von agilen Methoden, die sich jedoch alle auf den Menschen, die rechtzeitige Bereitstellung funktionierender Software und die Anpassung an sich schnell ändernde Umgebungen konzentrieren.

Ja und nein - der eigentliche Prozess kann als eine Reihe kleiner Wasserfälle angesehen werden, aber der Unterschied besteht darin, dass sich der Prozess aus dem Input des gesamten Teams (Entwickler, Qa, Unternehmen usw.) im Nachhinein entwickelt und verbessert, was dazu führen sollte zu einer viel engeren Einheit, die in der Lage ist, auf Probleme zu reagieren und genau zu planen und zu liefern. Ich bin grob über die Vereinfachung hier, es gibt viel mehr, aber ich denke nicht, dass dies ein schlechter Ausgangspunkt ist.

Ich würde sagen, das ist einfach ausgedrückt. Ja, wenn Sie es erreichen, sind es kleine Wasserströme, aber es steckt so viel mehr dahinter, dass es funktioniert. Eine ganze Methodik, die Ihre Herangehensweise an Projekte verändert ... Ganz zu schweigen von der dafür erforderlichen Denkweise.

Wenn Sie es mit Agile ernst meinen, finden Sie hier eine gute (und lange) Reihe von Webcasts, die Sie interessieren könnten:

http://autumnofagile.net/

Vergiss Agile eine Minute, denke darüber nach, was mit "Wasserfall" gemeint ist.

Es gibt eine Anforderungsphase, in der jeder versucht, herauszufinden, welche Probleme das Endprodukt lösen muss. Die Leute streiten sich eine Weile darüber und dann unterschreiben sie alle eine Reihe von Anforderungen. Zu diesem Zeitpunkt ist Ihr Geltungsbereich definiert, Verträge werden unterzeichnet, und der Kunde kann abwarten, bis Sie ein Produkt gefunden haben, das diese definierten Anforderungen erfüllt.

Als nächstes gibt es eine (oder vielleicht zwei) Entwurfsphasen. Die Designer (die möglicherweise Entwickler sind oder nicht) streiten sich darüber, wie das System zusammenarbeiten muss, um die Anforderungen für die Freigabe zu erfüllen. Probleme können auftreten, wenn sie eine Anforderung nicht genau verstehen, was bedeuten kann, dass sie zum Kunden zurückkehren müssen, möglicherweise die Anforderungsphase erneut eröffnen (und eine weitere Runde von Abmeldungen erhalten) oder zumindest das Änderungsmanagement in die Tat umsetzen müssen . Oft geben die Designer einfach ihre besten Schätzungen ab. Möglicherweise haben sie ein logisches Datenmodell und viele UML-Dateien, die ein neues System beschreiben und beschreiben, wie es funktionieren soll. Dann melden sie sich ab.

Jetzt können die Entwickler auf der Grundlage des abgemeldeten Designs mit dem eigentlichen Codieren beginnen. Probleme können auftreten, wenn sie das Design nicht ganz verstehen, was bedeuten kann, dass sie zum Designer zurückkehren müssen, möglicherweise die Designphase erneut eröffnen (und eine weitere Runde von Abmeldungen erhalten) oder zumindest das Änderungsmanagement in die Tat umsetzen müssen . Die Designer können wiederum erkennen, dass die Verwirrung tatsächlich auf die Anforderungen zurückgeht, was bedeutet, dass sie Anforderungsdiskussionen, Abmeldungen und weiteres Änderungsmanagement erneut eröffnen müssen. Häufig geben die Programmierer (die eine absehbare Deadline haben) einfach ihre bestmögliche Vermutung ab. Sie tun, was sie können, um Funktionscode zu erstellen. Dann geben sie es zum Testen frei.

Jetzt beginnt die Phase der Systemtests. Die Tester testen auf der Grundlage ihres Verständnisses der Anforderungen und des Designs und registrieren das, was sie als Fehler wahrnehmen, in einem System zur Fehlerverfolgung / Änderungsverwaltung ein Designfehler, der es an das Design zurückschickt, etc ... Eventuell bestehen die Systemtests und werden am abgemeldet.

Schließlich kommt der Kunde zurück und führt Benutzerakzeptanztests am neuen System durch. Hier entscheiden sie, ob die von den Testern getestete, von den Entwicklern entwickelte und von den Designern entworfene Lösung tatsächlich ihren Wünschen entspricht. Ist dies nicht der Fall, müssen Sie möglicherweise zur Entwurfsphase zurückkehren oder die Anforderungen erneut prüfen.

Die Idee hinter dem Wasserfall ist, dass es schwierig (und sehr unerwünscht) ist, zurückzukehren, wenn eine Phase abgeschlossen ist. Verschiedene Personen sind in der Regel in verschiedene Phasen involviert, daher gibt es mehrere Übergaben, von denen jede ein hohes Risiko für Fehlinterpretationen und Informationsverlust mit sich bringt. Es gibt auch eine signifikante Lücke zwischen der Aussage der Kunden und dem Zeitpunkt, zu dem sie sehen, was gebaut wurde, und dem Zeitpunkt, zu dem sich die tatsächlichen Anforderungen möglicherweise geändert haben.

Agile Methoden konzentrieren sich auf eine starke Kommunikation und Zusammenarbeit zwischen allen interessierten Parteien. Das Prinzip "Zusammenarbeit der Kunden über Vertragsverhandlungen" bedeutet, dass Sie nicht eine Reihe von Ab- und Übergaben durchführen müssen, sondern einfach mit dem Kunden zusammenarbeiten müssen, wobei jede Iteration die Anforderungen für ein Puzzleteil bestimmt und sofort Tests, ein Design und einen Arbeitscode zu erstellen - wobei alle Akteure so direkt wie möglich miteinander kommunizieren (Vermeidung von Übergabekosten und -risiken). Der Arbeitscode kann vom Kunden schnell getestet werden, wodurch Verzögerungsrisiken vermieden werden. Alle Aktivitäten finden in einem kollaborativen Strudel statt, nicht in einem Abwärtsfluss.

Um einen hervorragenden Überblick über die Vorgehensweise agiler Methoden zu erhalten, kann ich Allistair Cockburns Agile Software Development: The Cooperative Game wärmstens empfehlen .

Ja, das ist mehr oder weniger richtig. Es wurde viel darüber geschrieben und diskutiert, wie es zu tun ist, aber ein Haufen kleiner Wasserfälle ist der springende Punkt.

Die konkrete Umsetzung einer Reihe kleiner Wasserfälle ist jedoch nicht trivial. Sie werden beispielsweise nicht in ein paar Jahren von großen Projekten zu einer Reihe kleiner Projekte wechseln. Es gibt noch ein großes Projekt mit einem Arbeitsvolumen von 1-2 Jahren. Sie müssen also das große Projekt in mehrere kleine Projekte aufteilen. Das mag ziemlich offensichtlich erscheinen, aber es füllt Seiten und Seiten von Büchern.

Ist das richtig oder steckt mehr dahinter?

Beide. Ja, das ist eine genaue Zusammenfassung des Konzepts, aber es werden viele Details zusammengefasst. Ich meine, so ziemlich jeder Aspekt der Planung ändert sich, wenn Sie nur für die nächste Woche statt für das nächste Jahr planen.

Wenn Sie sich die statische Struktur (Prozessdefinition) eines agilen Projekts ansehen, sieht es ja wie viele kleine Wasserfälle aus. Ziel eines agilen Projekts ist es jedoch, schneller und besseres Feedback zu erhalten .

• Sie führen eine testgetriebene Entwicklung durch, um sofort festzustellen, ob Ihre Software noch funktioniert
• Ein Kunde ist vor Ort und führt Abnahmetests durch, um festzustellen, wann Sie fertig sind
• Sie haben Rückblicke, um Ihren Prozess darauf abzustimmen, was gut gelaufen ist und was nicht.

Das agile Manifest hebt einige Unterschiede zwischen agil und Wasserfall hervor (wie von den Unterzeichnern wahrgenommen).

Wirklich "agil" bedeutet oft Wasserfälle von 1-2 Tagen, nicht Wochen. Das bedeutet nicht, dass Sie nicht einem Gesamtplan folgen und die tatsächlichen Release-Zyklen 1-2 Tage betragen. Aber Sie sollten jeden Tag versuchen, ein funktionierendes, getestetes Produkt zu haben, und Sie könnten es - theoretisch - jeden Tag veröffentlichen.

Scrum verwendet beispielsweise Sprints von 4 Wochen, aber ein Sprint ist nicht nur ein Wasserfall (sollte es zumindest nicht sein). Sie können die Prioritäten jeden Tag ändern, wenn Sie feststellen, dass etwas nicht so läuft, wie es zu Beginn des Sprints geplant war.