Ein Kernkonzept der agilen Methoden beruht auf der Co-Location, um die Abstimmungswege und die Zusammenarbeit zu erleichtern. Hier stellt sich die Frage, ob in Zeiten der Digitalisierung, der Revolution des Homeoffice und der zunehmenden Online-Kommunikation, bei der der Gesprächspartner meist nur einen Klick entfernt ist, eine Co-Location notwendig ist. Es gibt zahlreiche globale Roll-out-Projekte, bei denen Teams auf der gesamten Welt verteilt arbeiten und den Projekterfolg genauso gut meistern wie Teams in der gleichen Umgebung. Manchmal übertreffen diese verteilten Projekte sogar die Projekte, bei denen alle Mitarbeiter an einem Ort sind, dies lässt sich vermutlich auf die große Diversity der Teilnehmer zurückführen.
Es kommt häufig vor, dass der Qualitätsaspekt in agilen Entwicklungsmethoden vernachlässigt wird. Jedoch ist es gerade bei agilen Entwicklungsmethoden von großer Bedeutung, die Qualität von Beginn an zu berücksichtigen. Hier spricht man vom Shiftleft-Ansatz. In einfachen Worten steht hinter Shift-left die Idee, die Qualität der Software durch ein Verschieben der Aufgaben im Lebenszyklus so weit wie möglich nach vorne (links) zu verlagern. So sollen die Technical Debts und die Cycle-Time reduziert werden. Der Fokus rückt vom Auffinden von Fehlern hin zur Prävention von Fehlern. Was passiert, wenn man sich entscheidet, die Qualitätssicherung auszulagern? Hierzu betrachten wir ein Beispiel, welches in ähnlicher Weise erfolgreich umgesetzt wurde.
Beispiel-Testansatz für Distributed Agile Testing
Wie Abbildung 1 zeigt, wurde gemeinsam mit dem Kunden ein Testansatz gewählt, der genau auf die Anforderungen des Kunden im agilen Set-up abgestimmt ist.
Die wichtigen Unit-, Service-Layer- und Performanz-Tests sind weiterhin fester Bestandteil der Entwicklung und werden im In-Sprint Scope ausgeführt. Für dieses Modell wurden die Aufgaben des funktionalen Tests, die Testautomatisierung, der Regressionstest und das Defektmanagement an das Offshore-Team übergeben, welches diese Aktivitäten sowohl In-Sprint als auch Cross-Sprint ausführt.
Abb. 1: Beispiel-Testansatz
So erstellt das Offshore-Team im Sprint die funktionalen Testfälle und führt diese manuell aus. Bei erfolgreichem Durchlauf werden diese in die Automatisierung überführt und falls notwendig direkt in den Cross-Sprint-Regressionstest aufgenommen. Werden Fehler im Prozess festgestellt, so werden diese in Jira dokumentiert und dem entsprechenden Entwicklungsteam zugewiesen.
Um die Organisation über die Teams zu vereinfachen, wurde ein Workflow zwischen dem Kunden, dem Onshore- und Offshore-Team abgestimmt und festgelegt (siehe Abbildung 2). Hierdurch konnte Transparenz über den Ablauf und das Vorgehen geschaffen werden, was die Akzeptanz des Entwicklungsteams gesteigert und allen Beteiligten die erfolgreiche Zusammenarbeit ermöglicht hat.
Abb. 2: Beispiel-Workflow
Anwendungsformen für Distributed Agile Testing
Im agilen Kontext findet man viele Variationen und Umsetzungen der bekannten Vorgehensmodelle und Frameworks wie Scrum oder SAFE. Oft adaptieren Projekte nur zum Teil die Mechanismen, Strukturen und Abläufe dieser Modelle, um, zusammen mit den ganz individuellen Projektbedingungen und internen Vorgaben, ein passendes Arbeitsmodell umzusetzen. Die Vielzahl an Modellen stellt die Qualitätssicherung immer wieder vor sehr spannende Herausforderungen.
Die angesprochene Vielfalt spiegelt sich auch in den möglichen Anwendungsszenarien im Bereich Distributed Agile Testing wider. In der Praxis sind die folgenden beiden Modelle besonders häufig anzutreffen:
- Distributed Testing und
- Distributed Delivery.
Distributed Agile Testing
Der Ansatz des Distributed Agile Testing beinhaltet die Verlagerung der Qualitätssicherung im verteilten Modus und wird in Abbildung 3 schematisch dargestellt.
Abb. 3: Distributed Testing
Scrum Master, Product Owner sowie das Development-Team und die fachliche Expertise verbleibt in einer Co-Location. Es wird jedoch ein dediziertes Test-Team gebildet, welches die Testaktivitäten Offshore oder auch Nearshore übernimmt. Dieses Team kann in einem skalierten Ansatz mit mehreren Teams ähnlich eines Test-Factory-Ansatzes die Testaktivitäten als Service übernehmen. Es ist aber ebenso möglich, dass die Tester jeweils einem agilen Team zugeordnet sind und für dieses exklusiv die Qualitätssicherung übernehmen. In diesem zweiten Ansatz kann die Weiterentwicklung des im Test-Team vorhandenen Know-hows durch einen regelmäßigen Team-Wechsel der einzelnen Teammitglieder zusätzlich gefördert werden.
Zur Koordination der Testaktivitäten, insbesondere bei skalierten Projekten mit mehreren agilen Teams, sollte, wie bereits angesprochen, ein Test-Koordinator eingesetzt werden. Dieser übernimmt zum einen die Koordination, zum Beispiel teamübergreifender Testaktivitäten wie Integrations- und End-2-End-Tests, zum anderen übernimmt er eine Brückenfunktion bezüglich der räumlichen Trennung der Teammitglieder im verteilten Projektansatz, um den notwendigen Kommunikationsfluss sicherzustellen.
Um die Qualitätssicherung zu fördern, kann es sinnvoll sein, im Onshore-Umfeld des Projekts einen QA-Lead zu benennen oder dessen Rolle onshore zu vergeben. Der QA-Lead ist unter anderem für die gewählte Teststrategie und die Strategie zur Testautomatisierung zuständig. Weiterhin übernimmt er vor Ort das teamübergreifende Status-Reporting an die Projektleitung. Er ist aber, ähnlich zu der Rolle des Scrum Masters, ebenso verantwortlich dafür, Projekthemmnisse und Verbesserungspotenzial im Bereich Quality-Engineering zu identifizieren und die testrelevanten Prozesse zu optimieren. Hierbei sollte er insbesondere den Fokus auf die im Team notwendigen Skills, den Einsatz von geeigneten Tools, aber auch den Informationsfluss und die Motivation des Teams legen. Trotz des verteilten Ansatzes ist es von großer Wichtigkeit, dass gemäß dem agilen Vorgehen die Verantwortung für Qualität nicht allein beim dedizierten Test-Team, sondern in der Verantwortung aller Beteiligten liegt.
Distributed Agile Delivery
Im Gegensatz zum Ansatz des Distributed Agile Testing wird bei Distributed Delivery (siehe Abbildung 4) nicht nur die Aktivität des Testens, sondern auch die Entwicklungstätigkeit in ein Delivery Center ausgelagert.
Abb. 4: Distributed Delivery
Fachbereich, Product Owner und Scrum Master bleiben weiterhin in einer Co-Location. Auch der im Distributed Agile Testing bereits vorgestellte QA-Lead ist in der Co-Location verortet. Je nach Aufbau und Größe des Projekts, zum Beispiel bei einem skalierten Ansatz mit mehreren Agilen Teams, sind hier neben dem beschriebenen Test-Koordinator auch Rollen für die Koordination der Entwicklungsaktivitäten denkbar und sinnvoll.
Bei einer Auslagerung von Entwicklung und Testen in Offshore-Abteilungen lassen sich Synergieeffekte nutzen, insbesondere bei einem hohen Grad an Testautomatisierung sowie der Verwendung von TDD (Test-Driven Development) oder ATDD (Acceptance Test-Driven Development).
Möglichkeiten und Herausforderungen
Beide Ansätze des verteilten Testens bieten die Vorteile der Ausnutzung von Offshore/ Nearshore-Ansätzen (Kostenersparnis, Nutzung von lokal nur begrenzt vorhandenem Expertenwissen, Skalierung der Kapazitäten passend zum jeweiligen Projektbedarf). Ebenso ist eine mögliche Zeitverschiebung zwischen on- und offshore ein nicht zu unterschätzender Faktor, da der Arbeitstag virtuell um die entsprechenden Stunden verlängert wird. Natürlich ist eine Verteilung der Aktivitäten aber auch mit den im Vorfeld beschriebenen Herausforderungen verbunden.
Die starke räumliche Trennung zwischen fachlichen Stakeholdern sowie Entwicklern und Testern scheint dem Gedanken der täglichen persönlichen Zusammenkunft zum Beispiel zum Daily Stand-up sowie der so gewinnbringenden engen Zusammenarbeit entgegenzustehen. Ebenso wird durch die organisatorische Trennung in Entwickler- und Test-Teams der positive Aspekt von interdisziplinären und selbstorganisierenden agilen Teams erschwert, da vermehrt auf koordinative Rollen zurückgegriffen werden muss. Ein solcher Ansatz kommt daher in der Regel eher bei großen, komplexen und entsprechend skalierten Projekten zum Einsatz.
In einem Projekteinsatz wurde ein entsprechendes Modell zum Beispiel in einer Konstellation mit 27 agilen Teams über einen Zeitraum von mehreren Jahren umgesetzt.
Der Herausforderung bezüglich Informationsfluss, Zusammenarbeit und gemeinsamer Verantwortung wurden zum einen durch den Einsatz von täglichen Videokonferenzen und einer ständig offenen Videoschaltung als virtuelles Fenster zum offshore arbeitenden Büro begegnet. Zum anderen wurde aber auch kein reiner On-/Offshore-Ansatz gewählt, sondern ein Teil der Entwickler- und Test-Teams war stets vor Ort. Die Kollegen wurden also, obwohl eigentlich offshore verortet, immer für einen begrenzten Zeitraum auch in der Co-Location eingesetzt und regelmäßig durch Kollegen aus dem Offshore-Bereich Entwicklung und Test ausgetauscht. Durch diesen regelmäßigen Austausch wurde der Teamgedanke durch persönlichen Kontakt erheblich gefördert und die fachlichen Kenntnisse konnten vor Ort sehr viel schneller und tiefer ausgebaut werden.
Um weitere Synergieeffekte zu erzeugen, wurden sowohl Entwickler als auch Tester nicht nur zwischen on- und offshore, sondern auch durch die verschiedenen agilen Teams rotiert. Dies führte zusätzlich zu einem breiten Verständnis der teamübergreifenden Zusammenhänge und integrativen Funktionen des gesamten Projekts.
Fazit
Diejenigen, die bereits im agilen Umfeld Erfahrungen sammeln durften, werden zustimmen, dass die Sicherung der Qualität in agilen Projekten besondere Herausforderungen bereithält. Der verteilte Ansatz kann viele Vorteile bieten, führt aber auch zu zusätzlichen Problemen, die beachtet werden müssen. Beispiele hierfür sind bereits im einfachen menschlichen Miteinander durch die kulturellen Unterschiede zu finden, mitunter kommt es gar zu „Wir gegen die“-Gedanken, da im agilen Zusammenarbeiten Fehler und Schwächen sehr viel offensiver angesprochen und adressiert werden, als dies normalerweise im traditionellen Ansatz mit dedizierten Teams und geschlossenen Verantwortlichkeiten der Fall ist. Aber auch der direkte Kontakt zueinander, das Treffen in der Kaffeeküche, der Smalltalk beim Gang in der Kantine sind im verteilten Ansatz nicht mehr alltäglich, was zudem den Zusammenhalt des Teams und dadurch oft auch die Produktivität beeinflussen kann.
Wie im Beispiel dargestellt, sollte ein Prozessflow festgelegt werden, welcher die Kanäle und Strukturen für die notwendigen Kommunikationen regelt. Virtuelle Kanban Boards, multimediale Meetingräume mit 360°-Kamera, Microsoft Teams, permanente Video-Sessions und digitale Whiteboards helfen bei der direkten Kommunikation.
Ebenso kann der Zusammenhalt des Teams durch regelmäßige persönliche Treffen am Projekt- und Offshore-Standort, durch die übergreifenden Austauschprogramme und durch teambildende Maßnahmen und Events (z. B. Virtuelle Lunch-Termine) erfolgreich gefördert werden.
