Seit 2001 haben wir das Agile Manifest und seither lernt die gesamte IT-Branche, agile Prinzipien und Werte in der täglichen Arbeit der Softwareentwicklung anzuwenden.
Agiles Manifest
Eines der Probleme ist in meinen Augen, dass viele, die behaupten, in einer agilen Umgebung zu arbeiten, die agilen Werte nie gelesen oder wirklich verstanden haben. Bei der Beratung von Teams oder bei Schulungen habe ich unzählige Male gehört, das Agile Manifest behaupte, dass alles, was auf der rechten Seite ist, das ist, was wir nicht tun sollen: z.B. hätten wir im Agilen keine Pläne, keine Verträge, keine Dokumentation oder Prozesse. Ich lernte ein Team kennen, das seine Software-Architekten in der agilen Transition verloren hat, weil Architekten im Agilen Manifest nicht erwähnt werden. Jetzt kämpfen sie mit großen technischen Problemen und es gibt niemanden, der ihnen helfen kann... Aber ist das denn wirklich agil? Das Agile Manifest besagt, dass der Wert in Elementen auf beiden Seiten enthalten ist, aber wenn wir wählen müssen, wählen wir Elemente auf der linken Seite. Die Logik sagt, dass wir alle Elemente des Agilen Manifests haben müssen, wenn wir nachhaltige Software liefern und unseren Lieferzyklus verbessern wollen. Der Aspekt, den agile Methoden hervorheben wollen, ist, dass Dokumentation, Pläne oder Verträge nicht die Ziele des Projekts sind, sondern unterstützende Werkzeuge. Die Ziele eines agilen Projekts sind immer: funktionierende Software zu liefern sowie jedes Teammitglied, die Zusammenarbeit mit Kunden und Reaktion auf Veränderungen wertzuschätzen.
Der Gesamt-Team-Ansatz (The Whole Team Approach)
Die Art und Weise, wie wir die im Agilen Manifest beschriebenen Werte und Prinzipien erreichen, basiert auf dem Gesamt-Team-Ansatz. Da es sich grundlegend verändert, wie wir in einem Projekt zusammenarbeiten, kann man sagen, dass es sich um einen neuen Stil des Projektmanagements handelt, bei dem jeder im Team gleichermaßen für die Qualität und den Erfolg des Produkts verantwortlich ist.
Fachleute in der Softwareentwicklung wissen, dass jede Entwicklungsentscheidung auch eine Qualitätsentscheidung ist. Das Agile Manifest setzt sie als oberste Priorität voraus. Die Softwarequalität hängt nicht vom Softwareentwicklungsmodell ab, das wir verwenden, sondern von der Methode, wie wir alle zusammen als Team den gesamten Softwareentwicklungsprozess strukturieren. Gemeinsam nutzen wir Werkzeuge und Aktivitäten, die das Erreichen einer hohen Softwarequalität unterstützen. Eine dieser Aktivitäten ist das Testen.
Was bedeutet Testen?
Jeder auf der Welt weiß oder kann sich vorstellen, was "Softwareentwicklung" oder "Projektmanagement" sind, aber nur sehr wenige können sagen, was Softwaretest ist, wie man es macht und vor allem warum.
Vor 10 Jahren, als ich meine Karriere im Testen begann, gab es die Aussage: "Jeder kann testen!", mit der Bedeutung, dass man zum Testen keine besonderen Fähigkeiten benötigt. Heute erkläre ich selber: "Jeder kann Software testen", - also jeder: Entwickler, Softwarearchitekt, Product Owner, Supportmitarbeiter und im Betrieb - jeder, der Informationen analysieren und mentales Modell aufbauen kann, um unsichtbare Zeichenketten und Abweichungen zwischen Software und Anforderungen, Geschäftsregeln, User Stories, Standards, Normen und gesetzlichen Vorschriften zu entdecken. Daher lässt sich sagen: Das Testen ist ein intellektueller Sport. Das ist keine branchenübliche Beschreibung, wir sagen vielmehr Testen ist der Prozess, wie wir Informationen über unser Produkt sammeln, mit dem Ziel, dass das Team auf der Grundlage dieser Informationen entscheiden kann, was es als nächstes tun soll.
Zwei Arten von Tests sind in einem agilen Kontext sehr wichtig: automatisierte Regression und explorative Tests. Mit Regressionstests sammeln wir Informationen über Softwarefunktionen, die bereits von Anwendern genutzt werden, und mit explorativen Tests lernen wir mehr über Softwarefunktionen, die wir gerade entwickeln.
Wenn Du Tests durchführst und Dein Team keine Entscheidungen auf der Grundlage der von Deinen Tests gesammelten Informationen treffen kann, bringen die Tests keinen Mehrwert. Wenn Du wöchentliche Berichte schreibst und niemand in Deinem Team diese liest, schaffen die Berichte keinen Mehrwert. Wenn es 12.000 automatisierte Tests gibt und niemand sagen kann, was sie abdecken, bringen die automatisierte Skripts keinen Mehrwert.
Möglicherweise hast Du noch einen Tester in Deinem agilen Team, der als Coach für Testtechniken fungiert und einen Teil der Tests durchführt, aber in einem agilen Team sollte jeder in der Lage sein, Informationen über den aktuellen Stand der Software zu sammeln. Denke daran: Qualität liegt in der Verantwortung des Teams und nicht bei einzelnen Personen.
Die Herausforderung des Wandels
Die Essenz des Gesamt-Team-Ansatzes liegt darin, dass Tester, Entwickler und Geschäftsvertreter in jedem Schritt des Entwicklungsprozesses eng zusammenarbeiten. Da das gesamte Team für Erfolg und Qualität verantwortlich ist, ist das gesamte Team oder zumindest Vertreter jeder Fachrichtung – siehe drei Amigos – an jeder Beratung oder Sitzung beteiligt, bei der Produkteigenschaften präsentiert, analysiert oder geschätzt werden. Für viele Organisationen und Einzelpersonen kann es ein Kampf sein.
Der erste Versuch, zu einer agilen Softwareentwicklung überzugehen, sieht nach meiner Erfahrung in 90% der Fälle wie eine 2-wöchige Wasserfall-Entwicklung aus. Es ist schwierig, die Art und Weise der Zusammenarbeit oder des Denkens einer Person, eine Unternehmenskultur oder bereits bestehende Verfahren zu ändern. Menschen und Unternehmen müssen eingefahrene ungünstige Verfahren überwinden, wie z.B. in Silos zu arbeiten oder jungen Mitgliedern nicht zuzuhören. Gib ihnen Zeit und erkenne die Ängste der Menschen, denn zunächst es ist beängstigend, sich zu ändern! Einige Befürchtungen, die die Menschen mir gegenüber geäußert haben, sind:
"Wie genau soll ich meine Teammitglieder unterstützen?",
"Wenn jeder in der Lage sein sollte zu testen, was soll ich, der Tester, dann noch tun?"
"Wenn das gesamte Team über Themen entscheidet, was soll ich, der Projektleiter, tun? Gibt es noch einen Job für mich?",
"Gemäß unseren Personalrichtlinien und meiner Berufsbezeichnung bin ich Senior Developer, aber ich habe das Testen nie wirklich verstanden. Was wird passieren, wenn andere das herausfinden?"
All das sind berechtigte Fragen und sollten angesprochen werden.
Mit all diesen Fragen steht man aber nicht allein da, viele Mitglieder von Teams auf der ganzen Welt sind damit konfrontiert. Janet Gregory und Lisa Crispin waren zwei der Pioniere im Bereich des agilen Testens. Viele agile Tester nennen ihr Buch "Agile Testing" ehrfürchtig liebevoll die Bibel, weil es das erste umfassende Buch über das Testen in einem agilen Kontext war. Heute gibt es die Erweiterung "More Agile Testing" und die dreitägige praktische Schulung in englischer Sprache "Holistic Testing: Strategies for Agile Teams", für das gesamte Software-Entwicklungsteam mit Spielen und Übungen zu Zusammenarbeit, Planung und agilen Testquadranten. Ich gebe dieses Training selbst, weil ich der Überzeugung bin, damit vielen Teammitgliedern wertvolles Wissen für die Umsetzung in ihrem Berufsalltag geben zu können. Aber egal ob Buch oder Training oder Blogbeiträge lesen oder einfach selbst ausprobieren: Ich ermutige jeden, sich mit dem Gesamt-Team-Ansatz zu beschäftigen, denn es ist ein wichtiger Schritt nach vorn, wenn das gesamte Team sich für Erfolg und Qualität verantwortlich fühlt.
