Freigeben über


Was ist Agile?

Diagram that shows various aspects of Agile feeding into each other, such as collaboration, development, and automated version control and deployment.

Agile ist eine Benennung, die Ansätze für die Softwareentwicklung beschreibt, bei denen die inkrementelle Bereitstellung, die Teamzusammenarbeit, Continuous Planning und Continuous Learning im Vordergrund stehen. Die Benennung Agile wurde 2001 im Agile Manifesto geprägt. In diesem Manifest wurden einige Leitprinzipien für einen besseren Ansatz für die Softwareentwicklung festgelegt. Im Kern erklärt das Manifest vier Wertaussagen, die das Fundament der Agile-Bewegung darstellen. Schriftlich heißt es im Manifest:

Wir haben Folgendes zu schätzen gelernt:

  • Individuen und Interaktionen gegenüber Prozessen und Tools
  • Funktionierende Software anstatt umfassende Dokumentation.
  • Zusammenarbeit mit Kunden anstatt Vertragsverhandlungen.
  • Reagieren auf Veränderungen gegenüber dem Befolgen eines Plans

Das Manifest impliziert nicht, dass die Elemente auf der rechten Seite dieser Anweisungen nicht wichtig oder erforderlich sind. Stattdessen werden Elemente auf der linken Seite besonders geschätzt.

Agile-Methoden und -Praktiken

Es ist wichtig zu verstehen, dass Agile keine Sache ist. Sie führen kein Agile aus. Stattdessen ist Agile eine Denkweise, die einen Ansatz für die Softwareentwicklung antreibt. Da es keinen einzelnen Ansatz gibt, der für alle Situationen funktioniert, stellt der Begriff Agile verschiedene Methoden und Praktiken dar, die mit den Wertaussagen im Manifest übereinstimmen.

Agile-Methoden, die häufig als Frameworks bezeichnet werden, sind umfassende Ansätze für Phasen des DevOps-Lebenszyklus: Planung, Entwicklung, Bereitstellung und Betrieb. Sie geben eine Methode für die Arbeit mit klaren Richtlinien und Prinzipien vor.

Scrum ist das am häufigsten verwendete Agile-Framework und das, mit dem die meisten Menschen beginnen. Agile-Praktiken hingegen sind Techniken, die in Phasen des Softwareentwicklungslebenszyklus angewendet werden.

  • Planning Poker ist eine kollaborative Schätzungspraxis, die Teammitglieder dazu ermutigt, ihr Verständnis darüber zu teilen, was erledigt bedeutet. Vielen Mitarbeitern macht der Prozess Spaß und er fördert nachweislich die Teamarbeit und bessere Schätzungen.
  • Continuous Integration (CI) ist eine gängige Agile-Engineering-Praxis, die häufig die Integration von Codeänderungen in die Mainbranch beinhaltet. Ein automatisierter Build überprüft Änderungen. Dies führt zu einer Reduzierung der Integrationsschulden und einer kontinuierlich auslieferbaren Mainbranch.

Diese Praktiken tragen, wie alle Agile-Praktiken, die Agile-Bezeichnung, da sie mit den Prinzipien im Agile-Manifest übereinstimmen.

Was Agile nicht ist

Mit zunehmender Beliebtheit von Agile haben viele Stereotypen und Fehlinterpretationen einen negativen Schatten auf seine Wirksamkeit geworfen. Es ist leicht, ohne Verantwortung zu sagen: „Ja, wir verfolgen eine Agile-Methode.“. Beachten Sie unter Berücksichtigung dieses Punktes einige Dinge, die bei Agile nicht der Fall sind.

  • Agile ist kein Cowboy-Coding. Agile sollte nicht mit einem „Wir werden es im Laufe der Zeit herausfinden“-Ansatz bei der Softwareentwicklung verwechselt werden. Eine solche Idee könnte nicht weiter von der Wahrheit entfernt sein. Agile erfordert sowohl eine Definition von erledigtem als auch explizitem Wert, der Kunden in jedem Sprint bereitgestellt wird. Während Agile die Autonomie von Einzelpersonen und Teams schätzt, legt es Wert auf eine abgestimmte Autonomie, um sicherzustellen, dass die erhöhte Autonomie einen höheren Mehrwert schafft.
  • Agile funktioniert nicht ohne Genauigkeit und Planung. Im Gegenteil: Agile-Methoden und -Praktiken legen typischerweise Wert auf Disziplin bei der Planung. Der Schlüssel ist die kontinuierliche Planung des gesamten Projekts, nicht nur die Planung im Vorfeld. Die kontinuierliche Planung stellt sicher, dass das Team von der von ihnen ausgeführten Arbeit lernen kann. Durch diesen Ansatz maximieren sie die Rendite von Investitionen (ROI) der Planung.

„Pläne sind wertlos, aber die Planung ist alles.“ – Dwight D. Eisenhower

  • Agile ist keine Entschuldigung für das Fehlen einer Roadmap. Dieses Missverständnis hat der Agile-Bewegung insgesamt wahrscheinlich den größten Schaden zugefügt. Organisationen und Teams, die einen Agile-Ansatz verfolgen, wissen absolut, wohin sie wollen und welche Ergebnisse sie erreichen möchten. Veränderungen als Teil des Prozesses zu erkennen, ist etwas anderes, als jede Woche, jeden Sprint oder jeden Monat eine neue Richtung einzuschlagen.
  • Agile ist keine Entwicklung ohne Spezifikationen. Es ist in jedem Projekt erforderlich, ihr Team darauf auszurichten, warum und wie die Arbeit geschieht. Ein Agile-Ansatz für Spezifikationen umfasst die Sicherstellung, dass Spezifikationen die richtige Größe aufweisen und sie angemessen widerspiegeln, wie das Team seine Arbeit abwickelt und bereitstellt.
  • Agile ist nicht in der Lage, ungeplante Arbeit und andere Unterbrechungen zu bewältigen. Es ist wichtig, Sprints termingerecht abzuschließen. Aber nur weil ein Problem auftaucht, das die Entwicklung ablenkt, heißt das nicht, dass ein Sprint scheitern muss. Teams können Unterbrechungen planen, indem sie im Voraus Ressourcen für Probleme und unerwartete Schwierigkeiten festlegen. Dann können sie diese Probleme angehen, aber mit der Entwicklung im Terminplan bleiben.
  • Agile ist auch für große Organisationen geeignet. Eine häufige Beschwerde lautet, dass die Zusammenarbeit, eine Schlüsselkomponente von Agile-Methoden, in großen Teams schwierig sei. Ein weiterer Kritikpunkt ist, dass skalierbare Agile-Ansätze Strukturen und Methoden einführen, die die Flexibilität beeinträchtigen. Trotz dieser Missverständnisse ist es möglich, Agile-Prinzipien erfolgreich zu skalieren. Informationen zur Überwindung dieser Schwierigkeiten finden Sie unter Agile auf große Teams skalieren.
  • Agile ist nicht ineffizient. Um sich an die sich ändernden Bedürfnisse der Kunden anzupassen, investieren Entwickler bei jeder Iteration Zeit, um ein funktionierendes Produkt zu demonstrieren und Feedback zu sammeln. Es trifft zu, dass diese Anstrengungen die Zeit reduzieren, die sie für die Entwicklung aufwenden. Doch die frühzeitige Einbindung von Kundenanforderungen spart später deutlich Zeit. Wenn die Funktionen mit der Vision des Kunden übereinstimmen, vermeiden Entwickler spätere größere Überarbeitungen.
  • Agile eignet sich recht gut für die heutigen Anwendungen, bei denen es oft um Datenstreaming geht. Solche Projekte erfordern in der Regel mehr Datenmodellierungs- und ETL-Workloads (Extract-Transform-Load) als Benutzeroberflächen. Diese Tatsache macht es schwierig, verwendbare Software in einem konsistenten, engen Zeitplan zu demonstrieren. Aber durch das Anpassen von Zielen können Entwickler immer noch einen Agile-Ansatz verwenden. Anstatt bei jeder Iteration an der Erledigung von Aufgaben zu arbeiten, können sich Entwickler auf die Durchführung von Datenexperimenten konzentrieren. Anstatt alle paar Wochen ein funktionierendes Produkt vorzustellen, können sie darauf abzielen, die Daten besser zu verstehen.

Warum Agile?

Warum sollten sie also einen Agile-Ansatz in Betracht ziehen? Es ist klar, dass sich die Regeln des Engagements rund um die Entwicklung von Software in den letzten 10 bis 15 Jahren grundlegend geändert haben. Viele der Aktivitäten sehen ähnlich aus, aber die Landschaft und die Umgebungen, in denen wir sie anwenden, unterscheiden sich deutlich.

  • Vergleichen Sie, wie es heute ist und Anfang der 2000er Jahre war, Software zu kaufen. Wie oft fahren Kunden zu einem Laden, um Geschäftssoftware zu kaufen?
  • Überlegen Sie, wie Feedback von Kunden zu Produkten gesammelt wird. Wie hat ein Team vor den sozialen Medien verstanden, was Kunden über ihre Software denken?
  • Überlegen Sie, wie oft ein Team die von ihm gelieferte Software aktualisieren und verbessern möchte. Jährliche Updates sind im modernen Wettbewerb nicht mehr machbar.

Diego Lo Guidice von Forrester drückt dies absolut treffend in seinem Blog Transforming Application Delivery (Oktober 2020) aus.

„Alles hat sich dramatisch verändert. Nachhaltigkeit bedeutet neben Umweltfreundlichkeit und Sauberkeit auch, dass das, was wir heute bauen, morgen einfach und schnell geändert werden kann. Strategische Pläne sind kurzfristig, und Planung und Veränderung sind kontinuierlich.“ – Diego Lo Guidice, Forrester

Die Regeln haben sich geändert und Organisationen auf der ganzen Welt passen nun ihre Herangehensweise an die Softwareentwicklung entsprechend an. Agile-Methoden und -Praktiken versprechen nicht, jedes Problem zu lösen. Sie versprechen jedoch, eine Kultur und ein Umfeld zu schaffen, in dem Lösungen durch Zusammenarbeit, kontinuierliches Planen und Lernen sowie den Wunsch, häufiger qualitativ hochwertige Software zu liefern, entstehen.

Nächste Schritte

Die Entscheidung, die Agile-Route zur Softwareentwicklung zu nutzen, kann interessante Möglichkeiten zur Verbesserung Ihres DevOps-Prozesses bieten. Ein wichtiger Satz von Überlegungen konzentriert sich darauf, wie sich die Agile-Entwicklung mit dem aktuellen Ansatz einer Organisation vergleichen und unterscheiden lässt.