agile methoden & agile testing

Die Grundlagen der heute als agile Methoden definierten Arbeitsweisen ist das „Agile Manifesto“ aus dem Jahr 2001. In diesem haben eine Gruppe von 17 Softwareentwicklern eine Reihe agiler Werte (und Prinzipien) formuliert, mit der die Softwareentwicklung verbessert werden soll:

• Individuen und Interaktionen sind wichtiger als Prozesse und Tools
• Funktionierende Software ist wichtiger als umfassender Dokumentation
• Zusammenarbeit mit Kunden heißt mehr als nur Vertragsverhandlungen
• Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Daraus folgend leiten sich Prinzipien ab, die ein kooperatives, iteratives und inkrementelles Vorgehen befürworten, das derzeitige genau wie zukünftige Bedürfnisse berücksichtigen kann. Mit iterativ ist ein Vorgehen gemeint, dass einen Prozess so lange wiederholt, bis ein gewünschtes Ergebnis erreicht ist. Idealerweise entwickelt man zunächst nur eine erste funktionale Version einer Produktkomponente. Diese muss den erkannten Bedürfnissen gerecht werden, ohne perfekt zu sein. Sie kann unter realen Bedingungen getestet und im Anschluss verbessert werden. Mit inkrementell ist ein Schritt-für-Schritt-Vorgehen gemeint, bei dem das Projekt organisch wächst. Dies steht Wasserfallmodellen entgegen, die ein Projekt linear fortschreiben, also verschiedene Phasen mit Start- und Endpunkt definieren.

Die Vorteile eines solchen agilen Vorgehens sind:

·   Flexibilität: Agile Teams können schnell auf Unvorhergesehenes und neu entdeckte oder entstandene Bedürfnisse reagieren. Der daraus entstehende Aufwand wird durch das Team neu geschätzt.

·   Transparenz des Projektfortschritts in Echtzeit: Der Kunde kann während des gesamten Projektes Anpassungen vornehmen und den Ressourcenverbrauch einsehen.

·   Durch den regelmäßigen Austausch entsteht ein großes Vertrauen zwischen den Teammitgliedern untereinander und mit dem/den Kunden, der Reibungsverluste in der täglichen Arbeit minimiert.

Für das Arbeiten in agilen Teams sind einige Begriffe und agile Techniken wichtig. Unter agilen Techniken versteht man Praktiken, die sich als hilfreich für die Umsetzung der agilen Werte in der täglichen Arbeit bewährt haben. Einige Beispiele für Best Practices erklären wir Dir hier kurz:

Design Thinking beschreibt ein Mindset agilen Arbeitens, bei dem der Kunde und seine Bedürfnisse im Mittelpunkt innovativer Gestaltungsprozesse steht. Du findest mehr über diese Art des Denkens und Arbeitens unter dem Stichwort “Innovation und Design Sprints” auf unserer Website.

Continuous Integration beschreibt die fortlaufenden Zusammenführung von bestehenden mit neu-entwickelten Komponenten in der Softwareentwicklung. Dank automatisierter Tests und statischer Analysen zur Softwarequalität der einzelnen Bestandteile sowie des gesamten Produktes (Unittest, Integrationstest, Systemtest) kann während der gesamten Entwicklung sichergestellt werden, dass alle neu hinzugefügten Elemente sich nicht negativ auf die Lauffähigkeit der Software auswirken und sich keine Fehler einschleichen. 

Eine Weiterentwicklung dieser kontinuierlichen Integration stellt die Continuous Delivery (CD) dar. Dabei wird in bestimmten Intervallen oder bei Erreichen einer bestimmten Qualitätsmetrik eine neue Version der Software ausgeliefert.

Continuous Deployment bezeichnet die abschließende Bereitstellung einer automatisierten Software-Release-Pipeline nach dem DevOps-Prinzip. Dabei werden von Entwicklern durchgeführte Änderungen im Quellcodeverzeichnis einer Anwendung automatisch überprüft und für die Produktivumgebung freigegeben. Die Software wird sozusagen immer so entwickelt, dass sie jederzeit vom Hersteller freigegeben und (kontinuierlich) an den Nutzer ausgeliefert werden kann. 

Mit DevOps bezeichnet man die Zusammenarbeit von Entwicklern und IT-Operations in einem Team während des gesamten Produktlebenszyklus’ - von der Entwicklung (Dev) nebst Test bis hin zu Deployment und Betrieb (Operations/Ops). Da es sich bei DevOps um einen fortlaufenden Prozess handelt, wird dieser mit einer Endlosschleife verbildlicht. Auch wenn die Phasen anscheinend schrittweise ablaufen, zeigt die Endlosschleife, dass während des gesamten Lebenszyklus Zusammenarbeit und iterative Verbesserungen unerlässlich sind. Bei trendig haben wir DevOps zu CustDevOps weiterentwickelt, denn auch unsere Kunden müssen Teil unseres Teams sein und der ständige Austausch mit ihnen Teil unseres erfolgreichen Produktes. CustDevOps ist die beständige Iteration aus Design Sprint (Cust/Customer-Sicht), Entwicklung (Dev) und Produktion (Operations/Ops).

Kanban-Boards oder Task-Boards sollen Arbeitslast (Workload) und Arbeitsfortschritt (Workflow) sichtbar machen. Es sind einfache Übersichts-Tabellen, bei denen auf (farbigen) Karten anstehende Aufgaben von einer Spalte auf der linken Seite des Boards (noch nicht begonnen) hin zur rechten Seite des Boards (fertiggestellt) wandern. Die einfachste Unterteilung ist eine dreispaltige aus ToDo, Doing, Done. Je nach Teamgröße und Komplexität kommen weitere Spalten hinzu, z.B. Backlog, ToDo, Doing, Test, Done. Hinzu kommen Team-spezifische Regeln zur maximalen Menge von Aufgaben pro Spalte (sogenannte Work in Progress Limits). Statt also jede Menge Aufgaben anzufangen, deren Arbeitsstatus immer wieder erfragt werden muss, können Teams gemeinsam Aufwände abschätzen und priorisieren, welche und wie viele Tasks zunächst begonnen und beendet werden müssen, bevor neue Aufgaben angefangen werden können.

Scrum ist eine agile Methodik im Bereich Projektmanagement, in der es keine Projektleitung mehr gibt, welche die Aufgaben an die Teammitglieder verteilt. In sogenannten Sprints, die meist zwei bis vier Wochen dauern, werden potentiell auslieferbare Produkte, sogenannte Inkremente, erstellt, die mit jedem weiteren Sprint weiterentwickelt werden.

Scrum kennt drei Rollen: Product Owner (stellt die fachlichen Anforderungen an das Produkt, priorisiert die einzelnen Product Backlog Items und prüft bei Fertigstellung einer Story, ob das Inkrement der Definition of Done entspricht), Scrum Master (verantwortlich für den störungsfreien Ablauf des Scrum-Prozesses und die Unterstützung des Teams bei der Erreichung der Sprint-Ziele) und Development Team/Entwicklungsteam (für die Umsetzung bzw. Entwicklung verantwortlich). Alle Teammitglieder arbeiten eigenverantwortlich, selbstorganisiert und gleichberechtigt.

Der Scrumprozess besteht aus mehreren Artefakten und Zeremonien. Der Product Owner führt eine Liste mit Anforderungen: den Product Backlog. Er legt vor jedem Sprint fest, welche Aufgaben in der nächsten Iteration umgesetzt werden. Dabei müssen alle Anforderungen in natürlicher Sprache und wenigen Sätzen nach dem Prinzip „wer bin ich und was will ich mit welchem Ziel“ ausformuliert sein. Dieses Format nennt man User Stories. Die ausgewählten User Stories werden im Rahmen der Sprintplanung in das sogenannte Sprint Backlog als selected for development übernommen und verschwinden aus dem Product Backlog.

Alle User Stories aus dem Sprint Backlog werden in einem Sprint Planning Meeting zwischen Product Owner und Development Team besprochen. Der Scrum Master moderiert dieses Meeting und stellt die sorgfältige Planung und die Formulierung eines Sprint-Ziels sicher. Im Anschluss zieht sich das Development Team Aufgaben aus dem Sprint Backlog. In einem täglichen, 15-minütigen Daily-Scrum-Meeting, auch Daily Standup genannt (da alle Beteiligten dieses im Stehen absolvieren), planen die Teammitglieder den Tag, informieren sich die gegenseitig zum Status ihres jeweiligen Aufgabenfortschritts, entstandener Hindernisse und äußern Hilfegesuche, sollte ihnen bei der Erfüllung ihrer Aufgaben etwas im Weg stehen. 

Am Ende eines Sprints werden ein Sprint Review und eine Sprint Retrospektive durch das gesamte Scrum-Team durchgeführt:

Der Sprint Review reflektiert den vergangenen Sprint und dient dazu, das Inkrement den Stakeholdern vorzustellen und über die weitere Roadmap mit ihnen zu diskutieren. 

Im Anschluss findet die Sprint-Retrospektive im Development-Team unter Anwesenheit des Scrum Masters statt. Mit Blick auf den vergangenen Sprint werden aufgetretene Probleme erörtert und Erfolge gefeiert. Die Retrospektive dient dazu, die Zusammenarbeit des Development Teams zu optimieren und Fehler nicht zu wiederholen. Unmittelbar nach der Retrospektive beginnt der nächste Sprint bis hin zur Fertigstellung des Produktes.

Das Scaled Agile Framework (SAFe) ist ein etabliertes Rahmenwerk, um Scrum bzw. Agilität in größeren Dimensionen anzuwenden, also zu skalieren. SAFe bietet agile Lösungen für alle Ebenen einer Organisation: von Teams über Bereiche bis hin zur Unternehmenssteuerung. Hierfür wird Agilität auf einer höheren Abstraktionsebene angestrebt: Das Programm-Inkrement. Auf dieser Ebene werden dann Anforderungen formuliert, Meetings gelebt und an ineinandergreifenden Backlogs gearbeitet.

LeSS (Large Scale Scrum) ist eine Erweiterung der Rollen, Zeremonien und Artefakte des Scrum Frameworks für die Organisation mehrerer Scrum Teams. Ziel einer LeSS-Implementierung ist die Reduktion von Komplexität und die Maximierung von Agilität einer Organisation, damit immer die werthaltigste Arbeit erledigt werden kann. LeSS beruft sich besonders auf das Ausprobieren durch Experimente nach der Devise: Es gibt keine Best Practices, es gibt nur Praktiken, die in einem bestimmten Kontext gut sind. Daher bietet LeSS genug Konkretes um anzufangen und genug Flexibilität, um zu skalieren.

In den meisten Fällen ist allerdings ein Skalierungsframework nicht nötig, um die verschiedenen Teams zu koordinieren und Abhängigkeiten aufzulösen. Insbesondere wenn nur ca. eine Handvoll Teams zusammen an einem Produkt arbeitet können diese Herausforderungen durch intensive Kommunikation, oder etwas institutionalisierter, in Form eines Scrum of Scrums gelöst werden. Ein Scrum of Scrums ist eine zusätzliche Zeremonie im Rahmen eines Sprints, bei der, häufig direkt im Anschluss an die Daily Scrums der Teams, Vertreter aus den einzelnen Teams zusammenkommen, um ihre Planungen abzustimmen und Abhängigkeiten aufzulösen.

Nach dem SCRUM-Vorgehen muss in der DoD klar definiert sein, nach welchen Kriterien etwas als ausreichend bearbeitet gilt. Mögliche Kriterien für die Definition of Done können Akzeptanzkriterien der User Story, eine vollständige Dokumentation des Inkrements, die vereinbarten Tests (Unit-, Integrations-, System-, nicht-funktionale Tests) wurden erfolgreich ausgeführt, Mobile Responsivität o.ä. sein. Diese Kriterien werden vom Scrum-Team bereits im ersten Sprint festgelegt und fortlaufend angepasst. Die Definition of Done ist besonders für das Entwicklungsteam von Bedeutung, denn dieses liefert das fertige (also das der DoD entsprechende) Inkrement an den Product Owner.

Extreme Programming (XP) ist ein agiles Framework für die Softwareentwicklung, das bewährte Techniken der Softwareentwicklung auf eine bestimmte Art einsetzt:  Stetige Reviews, fortwährendes Testen, kontinuierliches Design und Redesign sowie stetiges Feedback, kurze Releasezyklen und die starke Einbeziehung des Kunden oder Auftragnehmers. Insbesondere für Projekte, deren Anforderungen sich oft und schnell ändern, ist das Extreme Programming geeignet. Grundsätzlich sollen Risiken wie Terminüberschreitungen, ausufernde Kosten und geringe Softwarequalität minimiert werden.

Die fünf Werte von XP sind Kommunikation (im Team und auf Augenhöhe), Einfachheit (“Was ist das Einfachste, was funktionieren wird?”), Feedback (Verbesserungsmöglichkeiten erkennen, Vorgehensweisen anpassen), Mut (effektives Handeln auch in persönlich herausfordernden Fragestellungen) und Respekt (sachliches und wertschätzendes Miteinander).

Unter Collective Code Ownership versteht man die ausdrückliche Vereinbarung unter allen Teammitgliedern, dass jede und jeder nicht nur das Recht, sondern die Pflicht hat, bei Bedarf Änderungen am Code vorzunehmen. Dabei kann es darum gehen, eine Entwicklungsaufgabe abzuschließen, einen Fehler zu beheben oder den Code insgesamt zu verbessern. In diesem Zusammenhang wird oft die Pfadfinder-Regel (“Boy Scout Rule”) zitiert: Hinterlasse den Code, den Du bearbeitest, immer in besserem Zustand, als Du ihn vorgefunden hast.

Das Pair Programming ist ein Vorgehen, bei dem zwei Entwickler an einem Computer gemeinsam Code schreiben, man spricht alternativ auch von Tandem Programming. Es ist ein sehr kommunikatives, kollaboratives Vorgehen, bei dem besserer Code durch das gegenseitige Reviewen erreicht werden soll. Einer der beiden Entwickler schreibt den Code und nimmt dabei die Rolle des Drivers bzw. Pilots ein. Der andere denkt über die Problemstellung und entstehende Lösung nach, kontrolliert den geschriebenen Code und spricht Dinge an, die ihm dabei auffallen. Er übernimmt die Rolle des Navigators bzw. Observers. Pair Programming eignet sich aufgrund seiner positiven Teamarbeits-Effekte auch gut für die Einarbeitung von weniger erfahrenen Entwicklern durch einen Mentor oder für das “Pairing”, bei dem zwei Personen unterschiedlicher Skill-Herkunft miteinander zusammenarbeiten, damit das gemeinsame Produkt eine höhere Qualität erreicht und beide von- und miteinander lernen.

Test-Driven Development ist eine Praktik aus dem Extreme Programming, bei der Testfälle dazu genutzt werden, die Entwicklung zu leiten. TDD ist ein iterativer Prozess, in welchem der Entwickler zunächst einen automatisierten Testfall für den als nächstes umzusetzenden Code schreibt. Dieser schlägt natürlich, da ja noch kein Code geschrieben wurde, bei der ersten Ausführung fehl (Red). Hiernach wird, meist in einigen wenigen kurzen Iterationen, genau so viel Code entwickelt, dass der Testfall erfolgreich durchgeführt werden kann (Green). 

Nun kann der Entwickler diesen Teil des Programms anpassen ohne seine Funktionalität zu verändern, da er dies mit dem Testfall jederzeit prüfen kann. Dies ermöglicht es ihm den Code zu verbessern, insbesondere ihn wartbarer und testbarer zu gestalten (Refactoring). Sobald dies geschehen ist, beginnt der Prozess von Neuem.

Vorteile dieses Vorgehens liegen darin, dass nur notwendiger Code von höherer Qualität entwickelt wird und für jeden Teil des Systems umfangreiche automatisierte Unit-Tests vorliegen.

Agile Techniken, die die Entwicklung aus fachlicher Sicht durch Testfälle anleiten, sind Acceptance Test Driven Development und Behaviour Driven Development. Die Praktiken sind eng miteinander verwandt und unterscheiden sich nur in Details.

Bei diesen Vorgehensweisen detailliert das Team die Anforderungen mit Hilfe von Beispielen aus der realen Anwendungsdomäne. Diese Beispiele können danach in Form von Akzeptanztestfällen automatisiert werden und dienen den Entwicklern als Leitschnur zur Umsetzung der fachlichen Funktionalitäten.

Ein weiterer Vorteil liegt darin, dass diese Testfälle gleichzeitig die fachliche Spezifikation des Systems darstellen und diese, aufgrund der Ausführbarkeit, niemals ihre Aktualität verliert, also eine “lebende” Dokumentation des Systems darstellt. 

Feature Driven Development ist eine schlanke Projektmanagementmethode zur Entwicklung werthaltiger Software. Grundlage des Frameworks ist die Annahme, dass ein Feature Wert für den Kunden enthält.

Zu Beginn eines FDD-Projekts wird zunächst ein fachliches Gesamtmodell für das zu entwickelnde System zusammen mit den Stakeholdern entwickelt. Im zweiten Schritt werden aus dem Gesamtmodell schrittweise Features abgeleitet, wobei ein Feature einem Schritt der zu unterstützenden Geschäftstätigkeit entspricht.

Diese Features werden nun einzeln geplant und danach iterativ und inkrementell zunächst entworfen und dann entwickelt und getestet. Dabei wird versucht, die Realisierung eines Features in unter zwei Wochen zu schaffen.

Als technische Schulden bezeichnet man zukünftige, zusätzliche Aufwände, die aus der aktuellen Lieferung von – bewusst oder unbewusst – nicht perfekten Produkten agiler Software-Entwicklung entstehen.

Retrospektiven sind Teamtreffen, bei denen in geschützter Atmosphäre rückblickend (“retrospektiv”) gemeinsam bewertet werden soll, was in der vorangegangenen Teamarbeit gut oder weniger gut gelaufen ist und was sich daraus für die zukünftige Zusammenarbeit lernen lässt. Agile Methoden setzen auf einen regelmäßigen, evolutionären Verbesserungsprozess gemäß des „Inspect & Adapt“-Prinzips (Prüfen & Anpassen). Idealerweise folgt auf jeden Sprint eine Retrospektive mit dem gesamten Team.

Durch kontinuierliches Feedback können Teams ihre Prozesse optimieren und Kundenrückmeldungen einbeziehen, um den nächsten Release zu verbessern. Auch ein punktuelles oder für eine bestimmte Herausforderung maßgeschneidertes externes Coaching kann agilen Teams helfen, die eigenen Arbeitsweisen gespiegelt zu bekommen und wertvolles Feedback für Optimierungen der eigenen Arbeit zu erhalten. trendigs Consultants sind geübt und haben langjährige Erfahrung, um agile Teams in ihrer Arbeit wertschätzend und erfolgssteigernd zu begleiten.