Was ist die Agile-Methodik?

Wenn ein Team ein neues Projekt beginnt, muss es die Anforderungen und Wünsche der Kund(inn)en und Endbenutzer(innen) berücksichtigen. Das Team muss dann basierend auf den Anforderungen der Kund(inn)en einen Satz an Kriterien formulieren, damit klar ist, was entwickelt werden soll. Es ist jedoch nicht immer einfach, die Vision einer Person in From spezifischer Anforderungen abzubilden. Außerdem entwickeln sich Anforderungen im Laufe eines Projekts oft weiter, was zu einem Produkt führen kann, dass den Erwartungen der Kund(inn)en nicht mehr entspricht. Agile Bereitstellung soll dieses Problem lösen, indem eine Produktlösung iteriert wird und jede Iteration den Kund(inn)en gezeigt wird. Diese können dann Feedback geben, wodurch sichergestellt wird, dass das in Entwicklung befindliche Produkt den Anforderungen entspricht.

Agile-Methoden sind im Software Engineering, wo in der Regel die Zusammenarbeit über mehrere Teams hinweg erforderlich ist, sehr beliebt. Zu diesen funktionsübergreifenden Teams können Software Engineers, Business Analysts, Produktmanager(innen) und Vertreter(innen) des Kundenteams gehören. Sie alle arbeiten zusammen, um eine Softwarelösung zu entwickeln, die den Anforderungen der Kund(inn)en entspricht. Die Teams unterteilen das Projekt in kleine Abschnitte, die jeweils ein greifbares Ergebnis liefern sollten. Sobald ein Abschnitt abgeschlossen ist, erhalten die Kund(inn)en eine Demonstration, worauf sie Feedback geben. Dieses wird dann herangezogen, um die Anforderungen zu aktualisieren oder neu zu erstellen, damit das Projekt planmäßig verläuft.

Der primäre Nutzen der Agile-Methodik ist der inhärente Fokus auf die Endbenutzer(innen). Indem die Kund(inn)en in den Entwicklungsprozess einbezogen und kontinuierlich informiert werden, wird sichergestellt, dass das Produkt so entwickelt wird, wie diese es möchten. Dies erspart Unternehmen und Engineering-Teams teure und langwierige Softwareentwicklungsprojekte, bei denen letztendlich Produkte entwickelt werden, die nicht den Kundenbedürfnissen entsprechen. Indem die Endbenutzer(innen) während des gesamten Entwicklungsprozesses im Fokus stehen, bleiben sie trotz neuer Wettbewerber, die in den Markt eintreten, viel wahrscheinlicher beim Unternehmen und werden zu treuen Kund(inn)en. Da beim iterativen Ansatz der agilen Softwareentwicklung Software in logischen Phasen erstellt wird, sollte sich auch die Codequalität verbessern, da sie schrittweise überarbeitet wird.

Während jede Agile-Methode einen gemeinsamen Rahmen und ein gemeinsames Ziel hat, können sich ihre Techniken zur Erledigung von Aufgaben stark unterscheiden. Sehen wir uns nun drei Methoden an.

Der Scrum-Ansatz

Die Scrum-Methodik basiert auf dem Konzept eines täglichen Treffens, bei dem sich jedes Team jeden Morgen beispielsweise für 15 Minuten trifft. Bei diesem Meeting gibt jedes Teammitglied ein kurzes Update darüber, was es am Vortag erreicht hat, was für den heutigen Tag geplant hat und vor welchen Hindernissen man steht. Mit diesem Ansatz können Teams auch in zweiwöchentlichen, sogenannten „Sprints“ arbeiten. Jeder Sprint hat ein Ziel, z. B. die Erstellung einer neuen Softwarefunktion, und es werden nur Aufgaben zum Sprint hinzugefügt, die nötig sind, um dieses Ziel zu erreichen. Am Ende des Sprints wird die neue Funktion den Kund(inn)en präsentiert, um Feedback zu erhalten, und der Kreislauf beginnt von vorne.

Der Kanban-Ansatz

Anstelle von Sprints wird beim Kanban-Ansatz ein sogenannter Backlog verwendet, also eine geordnete Liste an Aufgaben, die erledigt werden müssen. Die wichtigsten Aufgaben stehen ganz oben auf der Liste und die Entwickler(innen) arbeiten eine Aufgabe fertig ab, bevor sie mit der nächsten weitermachen. Der Product Owner – ein(e) interne(r) Kollege oder Kollegin, der oder die die Vertretung nach außen übernimmt und Ansprechperson der Kund(inn)en ist – ist für die genaue Einhaltung und Sequenzierung der Prioritätenliste verantwortlich.

Die Retrospektive

Die meisten Agile-Methoden nehmen in bestimmten Abständen oder nach Abschluss eines bestimmten Teils eines Projekts eine Retrospektive vor. Bei einer Retrospektive wird besprochen, welche Teile des Prozesses gut liefen und welche Bereiche verbessert werden könnten. Das Team kann diese Erkenntnisse dann in der nächsten Projektphase umsetzen, um neue Strategien einzuführen, die den gesamten Workflow verbessern können.

Kurz gesagt: nein. DevOps kombiniert Softwareentwicklung und IT Operations, um Prinzipien für eine kontinuierliche Softwarebereitstellung zu bieten. Dadurch soll der Entwicklungslebenszyklus verkürzt werden, um funktionierende Software schneller zu entwickeln, zu testen und in die Produktion freizugeben. DevOps-Expert(inn)en arbeiten in einer kollaborativen Atmosphäre zusammen, teilen Wissen und Inhaberschaft für die zu entwickelnde Software. Dazu gehört auch, auf Alarme zu reagieren und zur Lösung von Problemen beizutragen.

All dies ergänzt perfekt die Agile-Prinzipien. Durch die Automatisierung von Tests kann beispielsweise Code sicher, schnell und dadurch häufiger für die Produktion veröffentlicht werden. Das bedeutet, dass die Software den Kund(inn)en häufiger gezeigt werden kann, wodurch eine Feedbackschleife im Sinne der Agile-Methodik entsteht.

Personen und Interaktionen gehen über Prozesse und Tools

Sicherzustellen, dass die richtigen Leute miteinander sprechen und zusammenarbeiten, ist wichtiger als die Tools und Prozesse, die sie verwenden.

Funktionierende Software geht über umfassende Dokumentation

Aufgrund des iterativen Charakters des Entwicklungsprozesses können kontinuierliche Änderungen dazu führen, dass die Dokumentation schnell veraltet ist. Um sicherzustellen, dass die aktuellsten Prozesse und Ziele im Fokus stehen, ist funktionierende Software das primäre Maß für den Fortschritt, wobei Dokumentation weiterhin als Single Source Of Truth unterstützt werden soll.

Zusammenarbeit mit Kund(inn)en geht über Vertragsverhandlungen

Die ständige Neuverhandlung von Verträgen verlangsamt den Fortschritt. Stattdessen sollte der Fokus auf der engen Zusammenarbeit mit den Kund(inn)en liegen, um deren Anforderungen bestmöglich zu verstehen.

Auf Veränderungen reagieren oder einem Plan folgen?

Planung ist nützlich, aber manchmal ändern sich Anforderungen und Prioritäten. Das Team sollte flexibel und in der Lage sein, auf Veränderungen zu reagieren.

Alle agilen Softwareentwicklungsprozesse teilen sich einen Kernsatz von Rollen. In erster Linie hat jeder agile Entwicklungsprozess eine(n) Endbenutzer(in) (der bzw. die alle Endbenutzer(innen) repräsentiert) oder eine(n) Kund(in). Die Softwarelösung wird für sie erstellt oder geändert. Wenn der bzw. die Produktempfänger(in) ein(e) Direktkund(in) ist, sollte er bzw. sie während des Entwicklungsprozesses konsequent in Demonstrationen eingebunden werden. Dadurch kann er bzw. sie genaues und zeitnahes Feedback geben.

Eine weitere wichtige Rolle ist der Product Owner. Diese Person arbeitet oft im gleichen Unternehmen wie das Softwareentwicklungsteam. Sie ist jedoch die Vertretung der Kund(inn)en oder Endbenutzer(innen) und erhält und beantwortet Fragen, die auftauchen, während der Kunde bzw. die Kundin nicht anwesend ist. Wenn die Software für eine bestimmte Benutzergruppe (im Gegensatz zu Direktkund(inn)en) bestimmt ist, wird der Product Owner zur Stimme der Benutzer(innen).

Schlussendlich gibt es auch noch das Softwareentwicklungsteam, das in der Lage sein muss, gemeinsam alle Teile der erforderlichen Lösung zu entwickeln. Teams können unterschiedlich groß sein, aber es ist üblich, dass agile Teams weniger als 10 Mitglieder haben. Bei den Scrum-Methoden wird empfohlen, nicht mehr als neun Teammitglieder zu haben, einschließlich des Product Owners, eines Scrum Masters und der Softwareentwickler(innen).

Vor Agile folgten Softwareentwicklungsteams Prozessen, die zusammen als Wasserfallmodell bekannt waren. Dabei wurde ein Projekt in ein lineares Set aus Phasen unterteilt, wobei jede Phase auf dem Ergebnis der vorherigen Phase aufbaute.

Die erste Phase kann beispielsweise die Analyse sein, bei der Geschäftsanalytiker(innen) Workshop-Vorschläge für eine aktualisierte Lösung für die aktuelle Software vergleichen. Nachdem man sich für eine neue Lösung entschieden hat, beginnt die Phase der Anforderungserfassung. Dann ziehen die Entwickler(innen) diese Anforderungen heran, um die Lösung zu erstellen. Nach dem Erstellen wird die Lösung getestet, bevor sie schlussendlich präsentiert wird. Danach beginnt die Wartungsphase.

In den 1990er-Jahren kamen flexiblere Ansätze für die Softwareentwicklung auf, die schließlich unter dem Begriff „Agile“ zusammengefasst wurden. Aufgrund der inhärenten Unflexibilität des Wasserfallmodells wurde es oft als für die Softwareentwicklung nicht geeignet erachtet, da es Feedback nicht in den Entwicklungsprozess einbezieht. Es beruht stark auf zu 100 % genauen Anforderungen, die immer komplett statisch bleiben müssen. Dies konnte immer weniger mit der Softwareentwicklung vereinbart werden, da sich die Anforderungen der Kund(inn)en sowie die Technologien weiterentwickelten. Infolgedessen löste der flexiblere, iterative Ansatz der Agile-Methoden das Wasserfallmodell ab.

Der Agile-Ansatz konzentriert sich auf die Zusammenarbeit und kontinuierliche Iteration, um ein Ziel zu erreichen. Aus diesem Grund ist es für DevOps-Teams üblich, beim Erstellen von Softwarelösungen Agile-Methoden zu verfolgen.

Es stehen mehrere Agile-Methoden zur Verfügung, die jede eine spezialisierte Interpretation der vier Kernprinzipien bieten. Ihre Absicht ist jedoch die gleiche: ein Produktziel durch kontinuierliche Zusammenarbeit, Demonstration und Integration von Feedback zu erreichen.